Трансляция сводных таблиц в беспроводных сетях

2003 г

Трансляция сводных таблиц в беспроводных сетях

Подготовлено: по материалам зарубежных сайтов
Перевод: Intersoft Lab
Авторские права: market@iso.ru

В этой статье рассматривается проблема эффективной трансляции бизнес-данных, представленных в виде сводных таблиц, по беспроводным каналам связи.

Беспроводные сети довольно прибыльны, они быстро развиваются и, поэтому, всё чаще становятся средством доступа к корпоративной информации. Растущая популярность карманных компьютеров, а также доступность легких, но мощных ноутбуков приводит к широкому развертыванию на этих мобильных устройствах клиентского интерфейса сложных бизнес-приложений.

Успешная деятельность любого предприятия часто зависит от средств поддержки принятия решений: без них не удается вовремя обнаруживать и правильно использовать благоприятные для бизнеса возможности. Для грамотного принятия решений руководители и менеджеры должны иметь постоянный доступ к самой свежей и важной информации, которая обычно представляется в агрегированной форме, адаптированной для аналитических нужд пользователя.

Для выполнения запросов к Хранилищу или к витрине данных предприятия, как правило, используются OLAP-инструменты, обеспечивающие многомерные представления данных для поддержки принятия решений. В многомерной модели данные представлены в виде кубов, а для хранения информации используется схема «звезда» (star schema).

Эта схема состоит из одной таблицы фактов, в которой хранятся анализируемые показатели (например: объемы продаж или доходы) и нескольких таблиц измерений (например: продуктов, времени, регионов и т.п.). OLAP-запросы обычно выполняются на консолидированных данных, полученных из таблиц фактов.

Необходимые сводные данные можно получить с помощью специального оператора data cube, который обычно представляет собой объединение нескольких операторов Group-By, применяемых к таблице фактов. Кубу данных для схемы с N атрибутами соответствует 2^N возможных подкубов . Поскольку data cube — ресурсоемкий оператор, то часто на OLAP-сервере в виде сводных таблиц хранятся именно подкубы, что обеспечивает эффективность доступа и выполнения запросов, отправленных с клиента. Обычно сводная таблица моделируется как запрос агрегирования, где измерениями для анализа служат атрибуты Group-By, а фактами — атрибуты агрегирования. Важным свойством таких таблиц, которое мы назовем зависимостью извлечения (derivation dependency), является то, что сводная таблица может быть выведена из одной или нескольких других. Например, если детальная сводная таблица T_D используется для получения более абстрактной T_A , значит, T_A находится в зависимости извлечения по отношению к T_D.

Рассмотрим пример фондовой биржи. Пусть маклеры и инвесторы, которые ими руководят, пользуются портативными устройствами или ноутбуками, и в этой интерактивной среде они решают вопросы покупки и продажи акций, анализируя их по множеству параметров (измерений).

Причем приоритетность измерений постоянно меняется, поскольку в зависимости от ситуации на рынке колеблется спрос на различные акции. Соответственно колеблется и частота обращений к акциям (а значит, и измерениям), которые считаются наиболее популярным.

В этом случае процесс анализа можно рассматривать как последовательность сессий. Каждая сессия начинается с некоторого набора сводных таблиц, включающих несколько измерений, и при необходимости, для получения более детальной информации, происходит углубление в таблицы с большим количеством измерений.

В условиях беспроводной сети остро встает вопрос эффективной доставки сводных таблиц на клиентские места (например в рамках беспроводного интранета компании), оснащенные интерфейсными OLAP-инструментами.

Рассмотрим основные методы и алгоритмы, разработанные для решения этой задачи.

Методы трансляции

В беспроводных сетях трансляция является основным методом функционирования на физическом уровне. Именно она используется для распространения информации в беспроводных каналах и гарантирует масштабируемость при передаче большого объема данных. Особенно эффективно рассылку данных можно осуществлять, комбинируя две схемы — push- и pull-трансляцию. Этот подход основан на асимметрии в беспроводных коммуникациях и позволяет сократить энергопотребление в режиме приема. Предполагается, что клиентские устройства — небольшие, портативные, а в качестве источников питания обычно используют аккумуляторы. Что же касается серверов, то у них производительность канала связи и мощность для передачи больших объемов данных намного больше, чем у клиентских устройств.

В режиме push-трансляции сервер многократно посылает информацию без опроса клиентов. Любое число клиентов может прослушивать канал трансляции и извлекать информацию. Если данные подстроены точно под нужды клиентов, то такая схема эффективно использует низкую пропускную способность беспроводного канала и идеальна для достижения максимальной масштабируемости.

В режиме pull-трансляции клиенты посылают конкретные запросы. Если на одни и те же данные приблизительно в одно и то же время поступает несколько клиентских запросов, то сервер может их агрегировать и передать данные только один раз. Такая схема также позволяет эффективно использовать канал с низкой пропускной способностью и очевидно повышает эффективность приема информации пользователем.

Беспроводная OLAP-модель

На рис. 1 показана архитектура среды, в которой трансляция данных происходит по запросу пользователей. Эта схема в наибольшей мере подходит для поддержки беспроводной обработки OLAP-запросов. Функции сервера состоят в поддержке и распространении сводных таблиц. Интересно, что проблема планирования трансляции, возникающая в беспроводных OLAP-системах, характеризуется вышеупомянутой особенностью — зависимостью извлечения. Иными словами, каждый клиентский запрос направлен на одну сводную таблицу, но эта таблица может включать в себя другую сводную таблицу, запрашиваемую иным клиентом. Однако каждая таблица, отвечающая определенному запросу, требует некоторых затрат на обработку, и при выборе конкретной таблицы для трансляции необходимо эти издержки учитывать.

Так как для эффективной рассылки данных общие алгоритмы планирования доставки часто используют агрегирование запросов, то зависимость извлечения дает дополнительную возможность оптимизации, повышая производительность и масштабируемость.

Рис.1. Беспроводная OLAP-система

Например (см. рис. 1), зафиксировав значение по измерению «Клиент» из детализированной таблицы («Поставщик – Клиент») можно получить абстрактную таблицу («Поставщик»).

Таким образом, идея использования сводных таблиц для выведения одних таблиц из других используется довольно широко. Ее смысл состоит в выборе надлежащего набора таблиц для хранения, чтобы повысить скорость обработки запросов, учитывая пространственные ограничения.

Для упрощения процесса выбора используется решетка поиска, которая представляет собой направленный граф, отображающий пространство подкубов, между которыми фиксируются зависимости извлечения. Например на рис. 2 показана решетка для схемы «Поставщик (ПС) – Продукт (ПР) – Клиент (К)».

Рис.2. Решетка Кубов Данных

Зависимость извлечения сводных таблиц и идея решетки поиска применяется при выборе таблиц при трансляции в беспроводных каналах для минимизации времени ожидания ответа на запрос пользователя.

В этом случае предполагается, что все решетки подкубов хранятся на сервере (такое допущение разумно, особенно для относительно небольших витрин данных). Клиент посылает запрос на таблицу по каналу восходящей связи. Затем он прослушивает канал нисходящей связи в ожидании ответа. Клиент может находиться в одном из двух режимов:

в режиме настройки (tune), прослушивая канал трансляции;
в режиме ожидания ответа (wait).

Выполнение запросов клиентов полностью зависит от сервера, доступ к локальному хранилищу и кэширование предыдущих ответов для последующего использования не осуществляется.

Минимальная единица трансляции называется пакетом (packet) или сегментом (bucket). Транслируемая таблица разделяется на одинаковые по размеру пакеты, первый из которых называют пакетом-дескриптором (descriptor). В заголовке пакета передаются данные или дескриптор, а также расстояние (временной интервал) до начала следующего пакета-дескриптора и расстояние от начала дескриптора до пакета. Пакет-дескриптор содержит таблицу с идентификатором, описывающим агрегируемые измерения транслируемой таблицы, количество значений атрибутов или кортежей и количество пакетов данных, составляющих эту таблицу.

Период передачи таблицы называют циклом трансляции (broadcast cycle): каждая таблица передается в течение определенного цикла, который начинается с момента трансляции пакета-дескриптора. Длительности циклов для разных таблиц при этом могут различаться.

Пусть запрос в восходящий канал связи Q характеризуется набором Group-By атрибутов D. Тогда запрос представим как Q^D, а соответствующую ему таблицу как T^D. Сводная таблица T^D¹ включает в себя таблицу T^D², если D2 D1, или, другими словами, T^D² зависит от T^D¹. Обозначим количество атрибутов (измерений) в множестве D как |D|.

Посылая в канал восходящей связи запрос на некоторую таблицу T^R, клиент сразу же настраивается на нисходящий канал в поиске пакетов-дескрипоторов. Обнаружив такой пакет, клиент классифицирует содержащуюся в нем таблицу (пусть это будет T^B) следующим образом:

Точное соответствие: измерения в сводной таблице T^Bсовпадают с измерениями в таблице T^B(т.е. R = B).
Включающее соответствие: T^B включена в T^R, но T^B в точности не соответствует T^R (т.е., R B и R ≠ B).
Нет соответствия: R B.

Например: пусть R = («Поставщик – Продукт»), тогда B₁ = («Поставщик – Продукт – Клиент») включает R, а для B₂ = («Продукт») и B₃= («Поставщик – Клиент») не имеется соответствия. В зависимости от типа соответствия клиент будет либо настраиваться на получение дальнейшей последовательности пакетов для чтения таблицы T^B, либо ожидать следующего цикла трансляции.

Мобильные клиенты

Особая ситуация возникает, когда клиентские места представляют собой мобильные устройства. В данном случае самое главное — экономия энергии. Как уже говорилось, мобильные компьютеры работают от аккумуляторов, которые располагают ограниченным ресурсом мощности. Поэтому сокращение энергопотребления является одним из основных условий, которое должно быть учтено при разработке алгоритма трансляции.

Решением этой проблемы являются методы индексирования для запросов с одним или множеством атрибутов. Основная их идея состоит в том, чтобы обеспечить на клиенте достаточную информацию по индексации, при этом характер доступа к потоку данных мобильного устройства может меняться от «спящего» (doze) режима ожидания до активного (active), когда прослушиваются все поступающие данные. Очевидно, что в спящем режиме потребляемая мощность в десятки раз меньше, чем в активном.

Описанная выше модель соответствует условиям для мобильного доступа. Напомним, что в каждом заголовке пакета есть указатель, задающий временной шаг для следующего пакета-дескриптора в трансляции. Послав запрос, компьютер-клиент прослушивает нисходящий канал и настраивается на первый пакет-дескриптор. Если ему подходят следующие пакеты данных, он остается в активном режиме и скачивает транслируемую таблицу, если нет — переходит в спящий режим, экономя энергопотребление. Переключение в активное состояние происходит согласно прочитанному временному сдвигу только перед началом следующего цикла трансляции (то есть перед получением пакета-дескриптора для очередной передаваемой таблицы). Активизировавшись, клиент получает дескриптор и повторяет проверку на соответствие.

Алгоритмы планирования

Для решения проблемы трансляции данных в беспроводной среде было предложено несколько алгоритмов-планировщиков, эффективность которых можно оценить по следующим показателям:

Время доступа. Время ожидания пользователем ответа на запрос. Состоит из двух компонентов — времени настройки и времени ожидания.
Время настройки. Период времени, в течение которого клиент прослушивает канал связи, читая пакет-дескриптор или поток пакетов данных, содержащих запрошенную сводную таблицу.
Время ожидания. Период времени, в течение которого клиент ожидает появления в канале запрашиваемого пакета-дескриптора. В этот период клиентский сетевой интерфейс на клиенте отключен, и канал не прослушивается.
Энергопотребление. Для мобильных клиентов сокращение энергопотребления особенно важно. Этот параметр имеет значение и для других компьютеров с учетом негативного эффекта излишнего нагрева, который снижает надежность цифровых сетей и повышает расходы на охлаждение.

В представленной модели запросы поступают на разные таблицы, размеры которых могут отличаться. Поэтому одинаковое качество обслуживания для всех запросов невозможно и нецелесообразно. С другой стороны, запросы можно логически сгруппировать в классы, качество сервиса для каждого из которых будет разным. Таким образом, эффективность алгоритма будет характеризовать показатель доступности (для его расчета используется дополнительные показатели):

Время обслуживания (service time) — время, необходимое серверу для завершения передачи таблицы в канал нисходящей связи в режиме без приоритетного прерывания.
Относительная длительность запроса (stretch) — отношение времени отклика (доступа) на запрос к времени обслуживания.
Доступность (fairness) — среднеквадратичное отклонение для значений параметра stretch.

Время обслуживания зависит от размера таблицы, и, следовательно, за счет параметра stretch удается нормализовать значение времени доступа относительно размера таблицы. Низкое значение стандартного отклонения указывает на правильно выбранную методику планирования задач трансляции, а высокое значение говорит о том, что для некоторого класса таблиц трансляция ведется не в оптимальном режиме.

Рассмотрим подробнее пять основных алгоритмов-планировщиков:

Первым прибыл — первым обслужен (First ComeFirstServed, FCFS),
Первый — с наименьшим временем обслуживания (ShortestServiceTimeFirst, SSTF),
Первыми — самые популярные запросы (Most RequestsFirst, MRF).
RxW,
STOBS-α.

Первым прибыл — первым обслужен (ПППО). Этот простой метод планирования предполагает, что запросы обслуживаются и транслируются по мере их поступления.

Первым — с наименьшим временем обслуживания (ПСВО). В первую очередь планировщик обслуживает тот элемент данных, который требует минимальных ресурсов. В нашем случае в качестве ресурса выступает канал нисходящей связи. Поэтому первым транслируется элемент данных с минимальным размером.

Первыми — самые популярные запросы (ПСПЗ). В первую очередь планировщик выбирает для трансляции тот элемент данных, на который поступило максимальное количество запросов.

RxW. В этой схеме используются преимущества ПСПЗ и ПППО. В каждом цикле трансляции сервер выбирает некоторый элемент с максимальным значением параметра R×W, где R — количество запросов на этот элемент, W — максимальное время ожидания ответа на запрос.

Описанные выше алгоритмы-планировщики в некоторых случаях работают хорошо, а в некоторых не дают приемлемых результатов. Выбор планировщика трансляции тесно связан с особенностями конкретного приложения, в котором могут применяться особые структуры данных и методы доступа. Пример тому, OLAP-кубы. Для них необходим специальный алгоритм, который повысил бы эффективность доступа в среде трансляции.

Особенности доступа к сводным OLAP-таблицам следующие:

Гетерогенность: сводные таблицы отличаются по размеру и количеству измерений.
Асимметричный доступ: запросы с OLAP-клиентов часто образуют некоторый «горячий участок» внутри решетки куба данных. Большинство запросов относится к таблицам небольшой размерности, а затем выполняется углубление в более детальные.
Зависимость извлечения: использование детальных таблиц для извлечения более абстрактных.

Планировщик трансляции сводных таблиц по запросу (Summary Tables On-DemandBroadcastScheduler,STOBS-α)

Этот алгоритм состоит из двух компонентов — нормализующего компонента, который учитывает первые две из перечисленных выше особенностей сводных таблиц, и α-параметра, который позволяет транслировать одни и те же данные нескольким клиентам.

Сервер собирает запросы клиентов по мере их поступления. Для каждого запроса Q^X к сводной таблице T^X рассчитываются следующие показатели:

R — количество запросов на T^X. Эта величина увеличивается с поступлением каждого запроса на эту таблицу.
A — промежуток времени, затраченный запросом Q^X в ожидании таблицы T^X.
S — размер таблицы T^X.

При решении какую таблицу отправить следующей сервер выбирает запрос с максимальным значением параметра (RхA)/S.

Параметр α определяет меру гибкости при передаче сводной таблицы и ликвидирует из очереди трансляции несколько зависимых от нее таблиц. Например, если α = 2 и сервер выбирает для трансляции таблицу T^X, то из очереди удаляются все запросы на любую таблицу T^Y, которая в решетке поиска находится двумя уровнями ниже и может быть выведена из T^X (см. рис. 2 — таблица, которую можно вывести из другой, всегда находится ниже последней).

Формально, T^Y может и не транслироваться в случае передачи T^X, если Y X и |X| – |Y| ≤α . Следовательно, клиент может использовать таблицу T^X, включающую изначально запрашиваемую им таблицу T^Y, если Y X и |X| – |Y| ≤α.

Значение a меняется в диапазоне от нуля до максимального размера куба данных — MAX. Если α= 0, то никакой гибкости в использовании сводных таблиц нет, и доступ клиента возможен только при точном соответствии. Если a = MAX, то клиенту передается первая же таблица, включающая его исходный запрос. В случаях, когда 0 < α < MAX, транслируется первая таблица, включающая исходную и расположенная в решетке куба на a уровней выше.

Проводя различия между STOBS-α и алгоритмами, требующими точного соответствия запросу, назовем описанные выше алгоритмы строгими (STOBS-0 также относится к этой категории), а семейство STOBS-α, где α > 0, назовем гибкими. При этом, значение α известно серверу и клиентам (оно может входить в дескриптор таблицы).

В качестве примера рассмотрим решетку, показанную на рис. 3 (в ее узлах расположены сводные таблицы). Q^X — запрос на четырехмерную таблицу (d₁, d₂, d₃, d₄). Допустим, что узлы решетки, показанные на рисунке — это таблицы, на которые есть по крайней мере один запрос. Пусть α = 2. Также предположим, что для трансляции выбрана таблица T^X, соответствующая запросу Q^X. Тогда клиенты, запросившие таблицы (d₁, d₂), (d₁, d₃), (d₁, d₂, d₃) и (d₁, d₂, d₄) будут удовлетворены таблицей T^X, а запросившие таблицы (d₁), (d₂), (d₃) и (d₄) будут ждать следующего цикла трансляции.

Рис. 3 Гибкость алгоритма.

Параметр (RхA)/S учитывает все факторы, влияющие на время доступа, параметр aопределяет меру гибкости алгоритма. Преимущество гибкого подхода к трансляции состоит в том, что удовлетворяется запрос клиента не только в случае точного соответствия. Недостаток — лишнее время, которое тратит клиент, прослушивая в канале детальную, а не сводную таблицу. Выбрав разумное значение α, можно найти приемлемый баланс между сокращением времени ожидания и увеличением времени прослушивания.

Сравнение алгоритмов

Все описанные выше алгоритмы сравнивались в соответствие с упомянутыми показателями эффективности. Превосходство схемы STOBS-α наблюдается как в отношении времени доступа, так и в отношении равнодоступности и сокращения энергопотребления.

В таблице 1 для каждого алгоритма указано среднее время доступа и среднее потребление энергии на запрос в сети, состоящей из 90 клиентов.

Таблица 1. Сравнение алогоритмов-планировщиков.

Алгоритм	Среднее время доступа (сек)	Среднее потребление энергии (Дж)
ПСВО	9,5	0,64
ПППО	10,1	0,66
RxW	7,2	0,53
STOBS-0	4,9	0,43
STOBS-2	2,9	0,40

Заключение

В статье проведен краткий обзор новых подходов к эффективной поддержке «мобильного» принятия решений, при этом акцент был сделан на важности метода трансляции, который обеспечивает эффективный доступ к Хранилищу данных предприятия. И хотя речь шла в основном о беспроводных и мобильных вычислительных средах, те же результаты можно использовать и в кабельных сетях, где поддерживается многоадресная передача.

В результате:

Рассмотрен новый способ объединения запросов, основанный на зависимости извлечения (derivation dependencies) между сводными таблицами, в сравнении с методом, основанным на точном соответствии запросу.
Алгоритмы-планировщики были разделены на две категории (строгие и гибкие) в зависимости от возможности передачи более детальных таблиц в качестве ответа на запрос. Кратко описано семейство эвристик STOBS, позволяющих сократить время доступа и энергопотребление при передаче OLAP-кубов.
Проведено небольшое сравнение существующих алгоритмов планирования в отношении их пригодности для рассылки сводных таблиц OLAP.

В целом можно отметить, что базовый алгоритм STOBS обеспечивает разумный компромисс между различными параметрами трансляции, что приводит к существенному сокращению среднего времени доступа и потребления энергии для беспроводных клиентов. Кроме того, он дает хороший баланс между сокращением времени ожидания и увеличением времени прослушивания канала. Последнее особенно важно для пользователей мобильных компьютеров.