CC BY
398
ПРОЦЕССИНГ МНОГОМЕРНЫХ КУБОВ В СИСТЕМАХ OLAP РЕАЛЬНОГО ВРЕМЕНИ
В.А. Климанов
Целью данной работы является исследование процессинга многомерных кубов в системах OLAP реального времени. В данной статье рассматриваются основные критические характеристики таких систем, оказывающие непосредственное влияние на время ответа на пользовательские запросы.
Введение
Идея Real-Time OLAP заключается в том, что большинство данных, запрашиваемых пользователем, являются агрегированными, поэтому нет необходимости хранить детальные данные как в хранилище данных (далее ХД), так и в многомерной базе данных (далее МБД), как при использовании MOLAP архитектуры.
Классический OLAP предполагает отражение изменений, произошедших в тран-закционных источниках, не непрерывно, а в определенные моменты времени. Частота синхронизации куба может колебаться в самых широких пределах в зависимости от природы приложения, скорости обновления и объемов данных [1].
В ситуациях крайне динамично развивающихся бизнес-процессов, когда значительная часть данных в хранилище устаревает очень быстро, а аналитик должен работать не с исторической, а с постоянно обновляемой информацией (например, биржевые торги), такой подход неприемлем. Требуется сразу по мере поступления даже одиночной транзакции отражать ее в кубе и пересчитывать с ее учетом агрегаты. Приложения подобного рода относятся к области OLAP реального времени (real-time OLAP).
В данной работе производится исследование функционирования работы приложений, построенных на основе OLAP реального времени, рассматриваются особенности процессинга многомерных кубов, производится оценка минимального времени между запросами в таких системах и максимального числа таких запросов.
Процессинг многомерных кубов
Под процессингом куба имеется в виду расчет агрегатов и наполнение структуры куба агрегатами и детальными данными [3]. В случае ROLAP агрегаты будут храниться в таблицах или представлениях реляционного источника. В случае HOLAP или MOLAP агрегаты помещаются в специальную многомерную структуру. Перенос в многомерную структуру детальных данных происходит только в том случае, если выбран формат хранения MOLAP, что несколько увеличивает время процессинга, но впоследствии позволяет повысить скорость обработки аналитических запросов. Процессинг добавляет в куб изменения, произошедшие в транзакционных источниках. Процессинг выполняется в определенные моменты времени по команде администратора либо по расписанию. В Microsoft SQL Server 2000 задача процессинга входит в список стандартных заданий DTS, кроме того, ее можно выполнить программным путем при помощи DSO.
В зависимости от ситуации для куба можно выбирать один из трех вариантов процессинга. Первый вариант - дифференциальный процессинг (incremental update) - соответствует ситуации штатной работы, когда куб пополняется изменениями, наработанными транзакционным приложением, скажем, за последний день, и на основе этих изменений досчитываются кумулятивные агрегаты. Это наиболее быстрый вариант процессинга. В этом случае Analysis Services создает временный раздел по условию фильтра, установленного администратором (например, Время = Текущий день), обрабатывает его, а затем добавляет к основному разделу куба (если куб состоит из нескольких разделов, то раздел-назначение необходимо оговорить особо). Второй вариант - обновле-
ние куба (refresh data) - применяется, когда в транзакционных источниках изменились данные, уже перемещенные в куб (например, если задним числом была сделана проводка, филиалы прислали корректировки и т.д.) В этом случае существующий куб очищается, данные в него перезагружаются и агрегаты пересчитываются заново. Наконец, третий вариант - полный процессинг (full processing) - представляет собой предыдущий вариант плюс пересчет всей структуры агрегатов (а не только их значений). Он используется при создании нового куба, а также в случае изменения его структуры, например, при удалении или добавлении новых измерений. Это наиболее длительный вариант процессинга. Использование нескольких разделов позволяет гибко настроить процедуру процессинга. Одной из типичных ситуаций, например, может быть разбиение куба на разделы, соответствующие периодам времени T1, T2, T3, где T1 - относительно небольшой актуальный период, за который, как правило, происходят изменения (этот раздел будет обрабатываться во время каждого процессинга); T2 - изменения допускаются, но происходят относительно редко, он будет обрабатываться только в случае этих изменений; T3 - архивные данные. Скажем, T1 - текущий год, T2 - прошлый, T3 - вся остальная история предприятия. Процессинг T2, скорее всего, потребуется в начальный период текущего года, когда раздел T1 еще не очень велик, и длительность его процессинга незначительна. Следует иметь в виду, что при произвольном изменении условия фильтра раздела может потребоваться повторная обработка всего куба.
Процессинг измерений бывает двух видов: Incremental Update и Rebuild Dimension Structure. В первом случае источник измерения прочитывается заново, определяются (по Member Key) новые члены, которые добавляются в измерение.
Второй способ, как следует из названия, заново перестраивает структуру измерения и применяется в случае добавления/удаления уровней и других изменений в иерархии, например, при переподчинении членов между родителями. Для появившихся в SQL Server 2000 медленно меняющихся измерений перечень ситуаций, требующих перестройки структуры, значительно ослаблен. Перестройка структуры измерения влечет за собой полный процессинг всех кубов, что не позволяет работать с данными кубами в течение этого времени. Сказанное до сих пор относилось к так называемым общим измерениям, которые существуют как независимые от куба сущности и могут входить в несколько кубов в пределах одной базы данных. Частные измерения - это измерения, которые незаметны вне того куба, где они были определены. Для частных измерений Incremental Update соответствует Refresh Data куба, а Rebuild Structure - Full Processing.
Во время процессинга запросы к транзакционным данным генерируются автоматически с использованием стандартного синтаксиса SQL. Длительность процессинга, таким образом, складывается из двух этапов: времени выполнения запроса на чтение операционным источником и обработки полученных результатов собственно в Analysis Services (1).
Тпр Тчт + Тоб . (1)
Для исследования эффективности первого этапа можно оценить время выполнения запроса, который формируют Analysis Services, встроенными средствами СУБД, используемой в транзакционном приложении. Например, в случае SQL Server для этого можно воспользоваться утилитой SQL Profiler. Отредактировать текст формируемого запроса невозможно. Как уже отмечалось, в качестве реляционных ресурсов для Analysis Services допускается широкий спектр OLE DB- и ODBC-источников, поэтому отсутствие возможности влиять на запрос является своего рода платой за универсальность. Можно порекомендовать, например, создать в операционном источнике представление, в определение которого заложить все необходимые предикаты, параметры оптимизатора и проч. Дополнительная настройка может быть проведена с помощью корректировки свойств OLE DB-соединения в определении источника данных многомерной БД. Оптимизация структуры куба (Cube Editor -> Tools -> Optimize Structure)
позволяет выявить и устранить лишние связи между таблицами. Например, Analysis Services идентифицирует члены измерения внутри уровня по Member Key Column. Как правило, в этом качестве выступает первичный ключ таблицы измерения. Если по этому же ключу таблица измерения связана отношением «один ко многим» с таблицей фактов, система предложит использовать внешний ключ таблицы фактов, что позволит сэкономить на довольно дорогом операторе join. В целом для типа и размера Member Key справедливы те же рекомендации, что и для индексного ключа. Чем короче ключ, тем меньше места требуется на его хранение и тем быстрее выполняется операция сравнения. Целочисленные ключи практически всегда выигрывают по сравнению со строковыми. На втором этапе в SQL Server 7.0 для каждого раздела выделялись два параллельных потока: Reader и Processing/Aggregation. Первый добавлял результаты запроса в буфер опережающего чтения, второй вычислял агрегаты и переносил (MOLAP) детальные данные в многомерную структуру, периодически (в целях экономии памяти) сбрасывая результаты на диск во временный каталог OLAP сегментами по 64 Кбайт. Таким образом, использование более чем двухпроцессорных конфигураций в предыдущей версии не давало выигрыша в скорости процессинга раздела.
В SQL Server 2000 это ограничение снято. Однако, как показывает практика, с точки зрения производительности эффективнее разбивать куб на несколько разделов, каждый из которых обрабатывается своей парой потоков, чем выделять суммарно эквивалентное количество потоков для обработки куба того же размера, состоящего из единственного раздела.
Особенности функционирования систем OLAP реального времени
Появившаяся в SQL Server 2000 поддержка ROLAP-измерений и индексированных (материализованных) представлений (indexed views) позволяет реализовать систему OLAP реального времени ценой меньших усилий с точки зрения администрирования. Если форматом хранения раздела куба является ROLAP, Analysis Services по умолчанию пытаются создать индексированное представление для хранения агрегатов данного раздела. В отличие от классических, индексированные представления содержат не только определение запроса, но и его результаты, которые обновляются всякий раз, когда происходят изменения в исходных данных [3]. С этой точки зрения индексированные представления ведут себя подобно обычным индексам, что позволяет поддерживать содержащиеся в них агрегаты в постоянно актуальном состоянии. Специально выделенный поток (listener thread) служит средством коммуникации, с помощью которого аналитический сервер получает от реляционного источника данные об изменениях, произошедших в таблицах, соответствующих ROLAP-разделам и ROLAP-измерениям, и автоматически обрабатывает их в фоновом режиме, очищая серверный кэш. Включение оповещений достигается установкой свойства Enable Real-Time Update при создании ROLAP-раздела или ROLAP-измерения.
Использование OLAP реального времени налагает определенные ограничения, так как в качестве реляционного источника при этом должен использоваться только SQL Server 2000 (иначе не будет работать механизм оповещений), причем, очевидно, Enterprise Edition (должны присутствовать индексированные представления). Аналитический сервер также должен быть построен на основе SQL Server 2000 Enterprise Edition, так как функциональность ROLAP-измерений включена только в эту версию, как отмечалось выше. ROLAP-разделы, построенные на основе индексированных представлений, не могут включать меры с агрегатными функциями min(), max(), должны основываться на таблицах (не на представлениях), источником меры должно быть поле типа not null и т. д.
Платой за реальное время являются потери в скорости выполнения OLAP-запросов. SQL Server 2000 позволяет их снизить, допуская непустое множество агрегатов за счет поддержки индексированных представлений. Кроме того, гибкая архитектура куба предполагает дальнейшую оптимизацию. Например, можно разбить куб на два раздела: меньший, ROLAP, соответствующий ситуации реального времени, основанный на данных, скажем, текущего месяца, и MOLAP-раздел, содержащий всю остальную историческую информацию.
Несколько модифицированный вариант этой идеи состоит в том, чтобы создавать не разделы, а отдельные кубы для текущих и архивных данных и строить объединяющий их виртуальный куб, с которым и будут работать конечные пользователи.
Для наглядности изобразим структуру типичной OLAP системы реального времени (рис. 1).
Рис. 1. Структура Real-Time OLAP
Упрощенно процесс функционирования системы OLAP реального времени выглядит так. В реляционное хранилище приходит транзакция, обновляющая (дополняющая) значения какого-либо измерения. По этому событию вызывается пересчет агрегированных значений куба. Естественно, это занимает определенное время - назовем его временем расчета агрегатов t. После выполнения сервером описанных операций пользователь получает в клиентском приложении обновленные агрегаты с учетом каждой поступившей транзакции обновления измерений. Эти транзакции поступают на сервер через некоторый промежуток времени - назовем его интервалом обновляющих транзакций I.
Оценка ограничений на функционирование Real-Time OLAP
Для проведения экспериментов, связанных с OLAP реального времени, использовался Microsoft SQL Server 2000 SP2, установленный на рабочей станции с одним процессором 600 МГц и 256 Мб памяти, под управлением Windows 2000 Professional. Для выполнения экспериментов использовалось небольшое приложение, написанное на Visual Basic, инициирующее обновляющие транзакции на сервере через определенные промежутки времени. При этом производились замеры времени расчета агрегатов для каждой транзакции. В качестве клиента использовалась рабочая станция под управление Windows 2000 Professional с процессором тактовой частоты 1,8 ГГц и 256 Мб оперативной памяти.
Экспериментальный куб данных содержал три измерения. Каждое измерение содержало 1000 значений, объединенных в сбалансированную иерархию. Таким образом, куб, используемый для определения основных характеристик Real-Time OLAP системы имел структуру, представленной в табл. 1.
Уровень Diml Dim2 Dim3
1 1 1 1
2 10 10 10
3 100 100 100
Таблица 1. Структура МБД
Единичная обновляющая транзакция добавляла 10 значений на нижний уровень иерархии, в результате чего инициировался пересчет агрегатов на верхних уровнях. После проведения каждой серии экспериментов исходный куб восстанавливался исходным числом значений измерений.
В общем случае поток обновляющих транзакций может быть распределен по случайному закону. В данной работе мы рассмотрим случай, когда интервал обновляющих транзакций является детерминированным, т.е. временные значения этого интервала постоянны: I = I1 = I2 = ... = IN = const.
Для достижения максимальной производительности, доступной для данной аппаратной конфигурации сервера, важно, чтобы соблюдалось следующее условие:
T < I, (2)
где Т - время расчета агрегатов после поступления единичной обновляющей транзакции. Однако данный случай в работе сервера встречается нечасто и может быть рассмотрен лишь как идеальный вариант. На практике же бывает так, что транзакции поступают с интервалом меньшим, чем время обработки одной транзакции. В этом случае сервер задействует встроенные средства параллельной обработки, используя общие ресурсы процессора и памяти, в результате чего время выполнения одной транзакции увеличивается по сравнению со временем, как если бы выполнялась только лишь одна эта транзакция.
Очевидно, что время, затрачиваемое на выполнение расчета агрегатов для каждой транзакции, зависит в общем случае от интервала следования обновляющих транзакций и их числа:
t, = t(Ih N) = t(I, N). (3)
Поэтому для определения минимального интервала следования обновляющих транзакций необходимо варьировать обе эти величины. Для наглядности построим графики зависимостей полученных результатов. Зависимость времени расчета агрегатов от числа обновляющих транзакций представлена на рис. 2.
Т = Т
время Т4 lmin
расчета агрегатов
N1 N2
N,
Ni
^число обновляющих
транзакции
Рис. 2. Время расчета агрегатов в зависимости от числа обновляющих транзакций
На рис. 2 интервалы следования обновляющих транзакций связаны следующей зависимостью : I\ < I2 < < I4.
Экспериментально было показано, что при достижении некоторого значения числа обновляющих транзакций Nmax время расчета агрегатов становилось бесконечно большим. Таким образом, было показано, что для Real-Time OLAP систем существует некоторое максимальное значение числа обновляющих транзакций, выше которого сервер уже не может их обработать:
t ^ œ
N=Nm
(4)
При достижении этого значения время расчета агрегатов резко увеличивается, а время ожидания ответа на запрос клиентского приложения также стремится к бесконечности, что следует из зависимости (4).
Работа OLAP системы реального времени ограничивается также еще одной величиной - минимальным интервалом следования обновляющих транзакций /min. На рис. 3 представлена зависимость времени расчета агрегатов от интервала между обновляющими транзакциями.
t,
время расчета агрегатов
Ii
I, интервал обновляющих транзакций
Рис. 3. Зависимость времени расчета агрегатов от интервала обновляющих
транзакций
Как видно из рис. 3, время расчета агрегатов становится бесконечно большим при достижении некоторого интервала обновляющих транзакций /ш;п:
t ^ œ
I=Im
(5)
При достижении этого значения время расчета агрегатов резко увеличивается, и время ожидания ответа клиентского приложения также стремится к бесконечности, что следует из зависимости (5).
Таким образом, экспериментально мы показали, что для любой OLAP системы реального времени существуют ограничения на ее нормальное функционирование ввиду наличия определенного числа обновляющих транзакций и минимального интервала их следования. В данном эксперименте для описанной аппаратной платформы эти значения составили:
Nmax = 35 обновляющих транзакций,
Imin = 5,5 сек.
Заключение
В данной работе были определены особенности процессинга многомерных кубов OLAP систем реального времени, а также основные критические характеристики данной архитектуры, влияющие на время ответа на пользовательские запросы, - максимальное число обновляющих транзакций и минимальный интервал их следования.
Экспериментальная часть данной работы показывает важность учета этих характеристик при проектировании подобных систем. Рассмотренные в статье проблемы носят, в основном, технологический характер.
Литература
1. Архипенков С.Я., Хранилища данных. М.: Диалог-МИФИ, 2002. 560 с.
2. Хрусталёв Е.М. Агрегация данных в OLAP-кубах. // Открытые системы. 2003. № 5. С. 33-38.
3. Шуленин А.А. Масштабируемость аналитических систем. // Windows & .Net Magazine/RE. 2002. № 2. С. 13-17.
