ОЦЕНКА ОБЪЕМОВ МНОГОМЕРНЫХ КУБОВ В OLAP СИСТЕМАХ А.К. Дорожкин
Статья посвящена рассмотрению вопросов, связанных с оценкой объемов многомерных кубов, являющихся основой OLAP систем, в зависимости от их структуры и характера данных, лежащих в их основе. Помимо этого, в статье представлен способ расчета объема многомерного куба независимо от реализации OLAP сервера.
Введение
Специфика практически всех систем поддержки принятия решений заключается в хранении и обработке огромного объема данных, на основе которого аналитик принимает то или иное решение. Размеры хранилищ данных достигают размеров в несколько терабайт, и, если лидеры на рынке реляционных баз данных еще в состоянии поддерживать такие объемы информации, то для OLAP серверов подобные объемы данных на сегодняшний день являются недостижимыми. Поэтому встает необходимость в прогнозировании объема многомерной базы данных.
Еще из школьного курса геометрии известно, что объем многомерного куба определяется как произведение длин его ребер. В многомерных базах данных аналогом длины ребра является количество членов измерения. Однако в OLAP системах не все так просто, как в геометрии. Из теории многомерных баз данных известно, что объем многомерного куба, помимо числа членов измерений, еще зависит от двух составляющих. Это плотные и разреженные измерения, а также хранение агрегированных показателей. Чем выше степень разреженности куба, тем сильнее оказывают влияние на его объем характер исходных данных, лежащих в основе куба.
Целью данной работы является создание аналитической модели, позволяющей прогнозировать объем многомерного куба. Ввиду того, что модель не имеет привязки к конкретной реализации сервера многомерной базы данных, для определения объема многомерного куба мы не будем учитывать объемы, занимаемые метаданными и зарезервированным пространством, а также различные механизмы оптимизации хранимых данных, такие как, например, сжатие хранимых данных, используемые в Cognos PowerPlay и Microsoft Analysis Services. Поэтому размер многомерного куба мы будем определять по числу заполненных ячеек.
Для оценки объема многомерного куба мы будем использовать понятие размера многомерного куба. Чтобы различать эти понятия, определим объем как пространство, физически занимаемое на жестком диске или любом другом носителе тем или иным объектом. А под размером будем понимать значение, вычисляемое на основе логических параметров объекта, таких как количество записей таблице, количество измерений куба, размер поля данных и т. д.
Агрегация
С понятием агрегация в многомерных базах данных очень тесно связано понятие «взрыв» базы данных. Данный процесс заключается в том, что количество ячеек агрегированных данных больше, чем детальных, к тому же агрегированные данные оказываются в несколько раз плотнее, чем детальные. Поэтому зачастую при загрузке 10-50 Мб детальных данных результирующий объем многомерной базы данных получается около 1 Гб. В своем стремлении заранее рассчитать все возможные значения разработчики многомерных баз данных иногда забывают, что в очень большой многомерной базе данных потери времени на операциях ввода/вывода могут превосходить затраты времени на расчет многих значений «на лету». Поэтому рекомендуется [3] заранее рас-
считывать одну треть необходимой информации, оставляя остальные показатели для расчета «на лету». В данной работе нас больше интересуют вопросы, связанные не с проектированием многомерных баз данных, а с количественной оценкой «взрыва» базы данных, т.е. определение количества новых ячеек многомерного куба, которые появятся в результате выполнения агрегации.
Прежде чем приступить к рассмотрению вопросов, связанных с агрегацией, введем понятие плотности детальных данных, которое определим как отношение числа непустых ячеек на последних уровнях иерархий к произведению числа членов на этих уровнях:
р = Ndet (1)
I det " V '
П di,n i=1
?
где di,n - число членов на последнем уровне иерархии i-ого измерения, Ndet - число заполненных ячеек детальных данных (количество загруженных фактов).
В случае, когда плотность детальных данных равна 1, количество ячеек агрегированных данных определяется как разность между количеством ячеек всего куба и количеством ячеек детальных данных:
n n
Nagg = Ncube - N det = П dt -П dun (2)
i=1 i =1
В [4] описаны и протестированы различные алгоритмы оценки объема многомерных кубов, однако они связаны либо с подсчетом вероятностей, либо с оценкой объема многомерного куба на основе выборки, что не совсем подходит для данной работы, так как здесь необходима аналитическая зависимость. Поэтому требуется найти такое подмножество данных, к которому можно эффективно приложить понятие плотности. Минимальной единицей агрегации является ячейка агрегации, под которой будем понимать набор ячеек, принадлежащих j-ому уровню иерархии и лежащих на пересечении конкретных членов измерений, по крайней мере, одно из которых принадлежит j-1 (более высокому) уровню иерархии.
Для наглядности на рис. 1 представлен двумерный вариант процесса агрегации.
Ячейка агрегаци
Уровень ll ■<
Уровень ll-1 ■
Уровень ll
Уровень l
I---
ч •V
\
г 1 Г
►
Детальные данные (уровень ll)
Рис. 1. Агрегация
На рис. 1 пунктирной линией изображены альтернативные варианты агрегации. Процесс агрегирования может происходить по одному из этих двух направлений. Как видно из рис. 1, одна ячейка агрегации порождает п!+1 ячеек агрегации на предыдущих уровнях иерархий (п - число измерений), т.е. для двумерного варианта - 3, для трехмерного - 7 и т.д. Легко понять, что максимальное число агрегатов будет достигнуто, если порождаемые ячейки будут также заполнены полностью. В этом случае ячейка аг-
регации считается полностью заполненной, т.е. любое увеличение ячеек в рамках данной ячейки агрегации не приведет к увеличению числа агрегатов. Количество ячеек на последующем уровне иерархии, которое формирует одна ячейка агрегации, можно выразить следующим выражением:
МТ=1 (п (+(з)
¿=1 V 1=1 1= У
Однако определение общего количества ячеек агрегированных данных на основании понятия ячейки агрегации является достаточно трудоемким и ненаглядным, особенно в условиях разреженных данных. Для определения числа агрегатов в случае неполного заполнения куба, т. е. зависимости числа агрегатов от плотности детальных данных, будем использовать понятие кубоида, определенное в [5] как подмножество членов измерений куба, содержащее агрегированные значения. В данной работе под кубоидом мы будем понимать набор ячеек, принадлежащих определенному набору {/с1, /с2, ..., /сп} уровней всех измерений. Легко понять, что количество кубоидов многомерного куба равно
=Ш (4)
¿=1
В общем случае количество агрегированных данных можно рассчитать как произведение плотности данных в каждом кубоиде на его «геометрический объем» (максимально возможное количество ячеек):
1
М„ = I р* Б , (5)
¿=1
где значение -1 отвечает за исключение детальных данных из списка кубоидов, так как они не являются агрегированными данными, р; - плотность данных в ¿-ом кубоиде, Бг -максимально возможное количество ячеек в ¿-ом кубоиде (или его «геометрический объем»), которое определяется как
п
2,...,1сп} = ^Г . (6)
¿=1
Выражение (6) определяет количество ячеек, принадлежащих кубоиду, лежащему на пересечении /с1, /с2, ..., /сп уровней всех иерархий.
Для окончательного вывода зависимости между плотностью детальных данных и количеством агрегатов необходимо вывести закономерность между рг- и р. Как известно из [3], агрегированные данные значительно плотнее, чем детальные, поэтому в качестве оператора перехода от рг- к р можно использовать отношение количества ячеек кубоидов:
р Б
' ~ /с1,/с 2,...,/сп (7)
Р 1с1,1с2,..,1сп
где р/с1,/с2,...,/сп - текущие уровни соответствующих измерений, а Бы, /с2, ..., ¡сп - количество ячеек данного кубоида. Однако эта зависимость носит не линейный, а обратно экспоненциальный характер, так как плотность кубоида не может быть больше 1 (количество заполненных ячеек не может превысить количество ячеек вообще). Как показывают эксперименты (см. следующий раздел), зависимость плотности кубоида от плотности детальных данных носит следующих характер:
Б а.
>
р/с1,/с2,...,/сп ~ 1 е Б/с1/с2 -/сп . (8)
Таким образом, объединив выражения (5) и (8), получим число агрегированных ячеек в зависимости от плотности детальных данных:
N
N cuboid
• I
(
S,
i =1
S di
Л
1 - e s,
lc1,lc 2,...,lcn
(9)
Проверка модели
Для подтверждения адекватности разработанной модели был проведен ряд экспериментов и на основе полученных результатов выполнен расчет основных показателей. Для более объективного рассмотрения изложенного выше теоретического материала в качестве серверов многомерных баз данных использовались три популярных продукта от лидеров на рынке программного обеспечения. Это Analysis Services от компании Microsoft, PowerPlay от компании Cognos и Express Server от компании Oracle. Распределение членов по уровням измерений представлено в табл. 1.
Уровень\Измерение Diml Dim2 Dim3 Dim4
1 1 1 1 1
2 10 10 10 10
3 20 100
4 100
5 1000
Таблица 1. Распределение членов по измерениям
Таким образом, общее число ячеек детальных данных составило 10 млн., всего ячеек в кубе - 15,2 млн. В качестве источника данных для многомерных кубов использовалась база данных Oracle со схемой «звезда», в которую загружались данные, индексируемые по измерениям случайным образом. Были выполнены измерения объемов многомерных баз данных, получаемые после выполнения агрегации, а так же с помощью программы на языке Oracle Express подсчитаны количество заполненных ячеек во всех кубоидах многомерного куба, в том числе и детальных данных, а также плотности кубоидов, на основании числа заполненных ячеек и распределения членов измерений по уровням иерархий.
Следует отметить два момента. В-первых, так как для всех трех многомерных баз данных использовался один источник данных, то распределение плотностей кубоидов в базах данных Microsoft Analysis Services и Cognos PowerPlay было точно таким же, как и в Oracle Express, поэтому повторного подсчета заполненных ячеек не требовалось. Второй момент касается заполнения многомерного куба случайным индексированием по измерениям. Так, например, в таблицу фактов хранилища данных загружается 50 000 записей с индексацией по измерениям случайным образом. Однако это совсем не значит, что многомерный куб будет содержат все 50 000 записей, так как некоторые комбинации внешних ключей таблиц-размерностей будут повторяться и, соответственно, несколько записей таблицы фактов попадут в одну ячейку.
Согласно выражению (4), число кубоидов данного многомерного куба равняется 2*2*3*5=60. Мы не будем приводить здесь всю таблицу плотностей кубоидов полученного многомерного куба, ввиду ее большого размера, а приведем только основные характеристики эксперимента, т.е. зависимости общего количества ячеек и объемов многомерных баз данных (см. табл. 2), а также плотности некоторых кубоидов от плотности детальных данных (см. табл. 3).
Для наглядности результаты представлены также в графическом виде (рис. 2).
Число Плотность Всего ячеек Объем многомерной базы
детальных многомерного данных (МБ)
Записей таблицы фактов Ячеек детальных данных данных куба Oracle Expres MS SQL Cognos
1000 1000 0.0001 38786 7.58 0.24 0.34
10000 9996 0.0009996 249367 28.58 0.55 0.59
50000 49878 0.0049878 789525 64.66 0.84 1.22
100000 99503 0.0099503 1254353 87.58 1.05 1.97
200000 198046 0.0198046 1931621 110.08 1.46 3.53
500000 487725 0.0487725 3229843 122.66 2.67 8.25
1000000 951527 0.0951527 4669180 123.58 4.33 4.34
5000000 3935587 0.3935587 9098883 123.23 19.19 14.75
10000000 6321590 0.632159 11511878 123.58 37.66 22.84
Таблица 2 Результаты экспериментов по агрегации
Объем МБД 140
120
100
SO Й0 40
20
О 210s 410s б -10s 810s 1 107 заполненных ячеек
Рис. 2. Объем данных многомерной базы данных от числа детальных данных
Как видно из табл. 2, объем данных Oracle Express примерно в три раза превышает объем МБД от Microsoft и Cognos. В первую очередь это зависит от механизмов оптимизации хранения данных, так как многомерные базы данных были заполнены одним и тем же набором данных, и размер типа показателя во всех базах данных составлял 8 байт. Многомерные кубы в рамках данного эксперимента заполнялись единицами, и продукты от Microsoft и Cognos, применив механизмы оптимизации хранения данных, добились более компактного представления данных. Однако, как хорошо видно из рис. 2, объем многомерной базы Oracle стабилизировался при значении числа записей в таблице фактов 500 тысяч, в то время как объемы данных для продуктов Microsoft и Cognos продолжали линейно расти. Это связано с механизмом управления плотными измерениями, которые в схеме многомерной базы данных для Oracle соответствовали Dim3 и Dim4.
Значение Full на рис. 2 соответствует случаю, когда плотность детальных данных равна 100%, так как из табл. 2 видно, что даже при случае 10 млн. записей в таблице фактов, что соответствует максимально возможному числу ячеек детальных данных, плотность детальных данных составляет всего лишь 63% из-за повторений записей в
- Oracle
--------- Microsoft
------------- Cognos
- Размер
случайном наборе данных. График, обозначенный толстой черной линией, соответствует размеру данных, который определяется как произведение числа заполненных ячеек на размер типа данных показателя (8 байт для всех баз данных).
Отношение размера данных и фактического объема многомерной базы данных представлено на рис. 3.
Отношение размера к объему МБД 12
Oracle
Microsoft
Cognos
1 -10
Количество заполненных ячеек
Рис. 3. Отношение размера МБД и ее реального объема
Как видно из рис. 3, отношения объема многомерной базы данных и ее размера трех серверов многомерных баз данных сходятся с ростом числа загруженных фактов.
Рассмотрим плотности кубоидов в зависимости от плотности детальных данных. В таблице 3 индексы кубоидов соответствуют номеру измерения. Как уже было отмечено выше, в таблице 3 представлены далеко не все из 60 имеющихся кубоидов, так как только кубоиды с номерами 23* и далее имеют плотность меньше 100% практически для всех значений плотности детальных данных. Для наглядности результаты представлены в графическом виде (рис. 4).
Плотность 2321 3322 3312 4222 5321
детальных
данных
0.0001 0.0944 0.00499 0.04875 0.00994 0.001
0.0009996 0.6346 0.048785 0.3941 0.09494 0.009954
0.0049878 0.9927 0.221335 0.9195 0.39385 0.048821
0.0099503 1 0.39353 0.9936 0.6313 0.095138
0.0198046 1 0.63162 0.99995 0.86407 0.181343
0.0487725 1 0.918245 1 0.993 0.393158
0.0951527 1 0.99335 1 0.99995 0.631938
0.3935587 1 1 1 1 0.993109
0.632159 1 1 1 1 0.999947
Таблица 3. Плотности кубоидов
Как видно из рис. 4, характер роста плотности кубоидов близок к 1 —^ и опре-
е
деляется согласно выражению (8). В табл. 4 приведены результаты расчета плотности выбранных ранее кубоидов, а в табл. 5 - выраженные в процентах погрешности расчетов по сравнению с реальными данными.
Р'¿гЦгЗ,.^ 1
0.3
0.6
0.4
0.2
0
1 1 1
7 -
|| / -
; /
г / -
1 / -! ! 1
1 1 1 1 1
О 0.1 0.2 0.3 0.4 0.5 0.6 0.7 Р^
Рис. 4. Плотности кубоидов в зависимости от плотности детальных данных
Плотность 2321 3322 3312 4222 5321
детальных
данных
0.0001 0.0952 0.00499 0.0488 0.00995 0.00099
0.0009996 0.632 0.04875 0.3933 0.09513 0.00995
0.0049878 0.9937 0.221 0.9174 0.39273 0.0486
0.0099503 0.99995 0.392 0.9931 0.63029 0.0947
0.0198046 0.99999 0.628 0.99995 0.86199 0.1797
0.0487725 1 0.913 1 0.99238 0.3859
0.0951527 1 0.991 1 0.99993 0.6138
0.3935587 1 0.9999 1 1 0.9805
0.632159 1 1 1 1 0.99826
Таблица 4. Рассчитанные плотности кубоидов
Плотность детальных данных 2321 3322 3312 4222 5321
0.0001 0.81 0.049 0.042 0.102 0.0499
0.0009996 0.41 0.068 0.191 0.196 0.0783
0.0049878 0.048 0.276 0.227 0.285 0.341
0.0099503 0.004 0.398 0.051 0.1604 0.447
0.0198046 0 0.493 0 0.2402 0.924
0.0487725 0 0.602 0 0.062 1.826
0.0951527 0 0.195 0 0.002 2.862
0.3935587 0 0 0 0 1.273
0.632159 0 0 0 0 0.174
Таблица 5. Погрешность расчетов плотности кубоидов
Как видно из табл. 5, погрешность рассчитанных значений незначительна и не превышает 3%, что говорит об адекватности полученных аналитических зависимостей.
Однако в табл. 5 заметно некоторое увеличение значений погрешности для крайнего правого столбца. Это связано с тем, что данный столбец отвечает за кубоиды с относительно большим «геометрическим» объемом. Следовательно, чем больше «геометрический» объем кубоида, тем больше погрешность расчета его плотности.
Исходя из рассчитанных значений плотностей кубоидов и их «геометрических» размеров, можно рассчитать значение размера многомерного куба по формуле (9), не прибегая к подсчету всего числа заполненных ячеек, как это было при формировании табл. 2. Таким образом, можно спрогнозировать приблизительный объем многомерного куба. Результаты данного расчета представлены в табл. 6.
Как видно из таблицы 6, ошибка не превышает 2%, что говорит о хорошей точности метода расчета.
Плотность Расчетный размер Реальный размер Ошибка (%)
детальных данных (Мб) (МБ)
0.0001 0.297 0.296 0.31
0.0009996 1.901 1.903 0.08
0.0049878 6.009 6.024 0.25
0.0099503 9.544 9.57 0.27
0.0198046 14.67 14.74 0.47
0.0487725 24.40 24.64 0.97
0.0951527 35.062 35.62 1,57
0.3935587 69.03 69.42 0.56
0.632159 87.77 87.83 0.061
Таблица 6. Расчетное значение размера
Заключение
В статье были рассмотрены основные вопросы, связанные с оценкой объемов многомерных кубов в зависимости от их структуры и характера данных, лежащих в их основе, а также предложен метод расчета количества заполненных ячеек агрегированных данных на основании плотности детальных данных. Предложенный метод, в отличие от ранее известных, требует меньше вычислительных затрат, при достаточной точности результатов, что подтверждено проведенными экспериментами.
Литература
1. Oracle Express: Database design and performance guide [Электронный ресурс]. Oracle Corp. Режим доступа http://otn.oracle.com - 2001.
2. D. Stark, S. Humphrey Data Blocks - The Key to Optimizing Hyperion [Электронный ресурс]. Mountain View, CA: Analysis Team, Inc. Режим доступа http://www.analysisteam.com - 2003.
3. N. Pendse, Database explosion [Электронный ресурс]. London: Optima Publishing, Режим доступа http://www.olapreport.com - 2005
4. A. Shukla, P. M. Deshpande, J. F. Naughton, and K. Ramasamy, Storage estimation for multidimensional aggregates in the presence of hierarchies // Proceedings of 22nd Very Large Dabases. Bombay, India: Mumbai, 1996. Р. 522-531.
5. Y. Feng, D. Agrawal, Range CUBE: Efficient Cube Computation by Exploiting Data Correlation // 20th International Conference on Data Engineering . Boston: IEEE Computer Society, 2003. Р. 658-671.