Про Oracle Business Intelligence

Вопросы об OLAP занимают особое место. В отличие от большинства других технологий, где часто можно услышать вопрос \”Что такое Discoverer?\” или \”Что такое Spatial?\”, когда дело касается OLAP чаще всего слышен вопрос: \”Мы хотим поставить себе OLAP. Что нам нужно для этого сделать?\”

То есть OLAP – это такой термин, который у многих на слуху, но когда начинаешь задавать дополнительные вопросы, очень часто выясняется, что под OLAP-ом может пониматься что угодно. Однажды даже, после 5-минутного объяснения, я услышал \”Я не понял, а что, OLAP это разве не система управления документооборотом?\”

Хотя, справедливости ради скажу, что большинство спрашивающих все-таки знают, что OLAP – это из области аналитики.

Так что, прежде чем разбираться что такое Oracle OLAP, давайте попробуем разобраться что вообще такое OLAP?

Термин OLAP – расшифровывается как OnLine Analytical Processing. То есть примерно можно перевести как \”Обработка данных в реальном времени\”. Это не упоминание какой то конкретной технологии или архитектуры, а как бы формулировка задачи.

На самом деле даже сам термин OLAP появился уже гораздо позже появления промышленных серверов, которые называются сейчас OLAP-серверами. Термин был введен в употребление в 1993 году Эдгаром Коддом, \”отцом\” реляционных СУБД. В своей работе \”Providing OLAP to User-Analysts: An IT Mandate\” он также сформулировал 12 правил OLAP, которым должна удовлетворять OLAP система. Вот эти правила:

1. Multidimensional Conceptual View
2. Transparency
3. Accessibility
4. Consistent Reporting Performance
5. Client-Server Architecture
6. Generic Dimensionality
7. Dynamic Sparse Matrix Handling
8. Multi-User Support
9. Unrestricted Cross-dimensional Operations
10. Intuitive Data Manipulation
11. Flexible Reporting
12. Unlimited Dimensions and Aggregation Levels

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

• В большой системе таблиц может быть сотни, они связаны между собой сложными цепочками отношений. И зачастую для того чтобы достать результат запроса \”На какую сумму за сегодня было продано товара X?\” нужно написать SQL, объединяющий десятки таблиц. Очевидно что такой код сложно и долго писать и отлаживать. А ведь запросов у пользователей может быть много и разных, под каждый такой SQL не напишешь.
• Еще одна проблема заключается в том, что результатом запроса часто является не детальная, а агрегированная выборка. То есть нужно взять миллионы записей, просуммировать их и вернуть результат, который покажет помесячное изменение продаж. Очевидно, что запросы, которые суммируют миллионы записей, сильно нагружают сервер и могут просто мешать накоплению транзакционных данных. А если потом станет интересно посмотреть как менялись продажи по годам?
• Вечная мечта разработчиков аналитических систем – сделать так, чтобы бизнес-пользователи, сами, с минимальным привлечением IT специалистов могли получать интересующую их информацию. Очевидно что обычный пользователь не напишет SQL на 10 листов и не сможет сам оптимизировать запросы.

Естественно, есть и другие проблемы.

Конечно, эти проблемы существовали и до Кодда, Кодд сформулировал требования к идеальной системе.

Разработчики видели эти проблемы и до его работы.

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

Измерение – это объект, который хранит, например, справочник \”География\”. Но в каждом измерении может быть прописана иерархия. То есть можно прописать, что есть уровень \”Весь мир\”, который включает в себя уровень \”Континенты\”, он в свою очередь \”Страны\” и так далее, можно дойти до городов и даже глубже.

Куб – это хранилище фактов. Каждый факт можно адресовать уникальным сочетанием элементов измерений. Например, если у нас есть трехмерный куб, который хранит продажи по товарам, то запись типа (\’26.01.2007\’,\’Батон нарезной\’,\’Гастроном 26\’, 2000) может говорить о том, что в Гастрономе 26 сегодня было продано нарезных батонов на 2000р. А похожий факт (\’26.01.2007\’,\’Батон нарезной\’,\’Все магазины\’, 100000) будет говорить, о том, что по всем магазинам сегодня было продано батонов нарезных на 100000р.

Детальные данные будут периодически перекачиваться в OLAP сервер, будут рассчитаны агрегаты, чтобы не считать их на лету и т.д.

Дальше можно сделать пользовательский интерфейс, который позволяет пользователю самому выбрать срез данных, например выбрать дату – сегодняшнюю, товар – \”Батон нарезной\” и \”Все магазины\” и легко изменить этот срез, например подняться по иерархии до группы товаров, или до уровня месяцев по другому измерению. Или наоборот опуститься до почасовой разбивки дня. Такой интерфейс позволяет даже неискушенному пользователю легко получать ответы на свои вопросы, в табличном или графическом виде и при этом, не привлекая IT специалистов. Не всегда, конечно. Но если нагрузка на IT специалистов при этом значительно снизится – это и будет положительным эффектом внедрения OLAP системы.

У схемы хранения измерения-кубы много преимущств, который хорошо видны аналитикам:

• Навигация по фактам осуществляется легко, пользователь сам может выбирать уровень детализации.
• Можно легко определять вычисления над фактами. При этом не нужно писать громоздкий SQL, а можно как в Excel написать формулу, например, что ячейка 2 получается из ячейки 1 умножением на 5. Все знают, что даже не очень продвинутые пользователи с успехом пользуются Excel.
• Как следствие, можно работать не с отдельной ячейкой, а описать одной формулой операцию над целым диапазоном, так как будто это одна ячейка.
• Если нам нужны агрегированные данные, не нужно ждать, пока сервер обсчитает сумму по миллиону измерений. Достаточно просто указать ячейку куба с координатами, соответствующими агрегированной сумме. И даже не нужно указывать ячейку, интерфейс пользователя сам сгенерирует запрос с указанием координаты нужной ячейки. Конечно, чтобы агрегированный результат был в этой ячейке он должен быть предварительно обсчитан.
• И т.д.

Но, конечно эти чудеса возникают не просто так. Куб это хорошо, но вот представим, что у нас куб из пяти измерений в каждом из которых по 100 элементов. Значит суммарное количество ячеек в кубе – 100 в пятой степени. Что означает 10 000 000 000 ячеек. 10 миллиардов, если я не ошибаюсь. Даже если каждая ячейка кодируется одним байтом – это будет больше гигабайта. Ну это сейчас гигабайт – немного, а 20-30 лет назад это был колоссальный объем.

С другой стороны, 5 измерений по 100 элементов это много? Тоже нет. Даже если брать наш пример. В каждом году 365 дней – уже минимум по 365 элементов каждый год (можно конечно кодировать день и год разными измерениями) Количество магазинов и регионов тоже легко может выйти за 100, а уж номенклатура товаров и подавно. А если добавить измерений? Сделать не 5, а хотя бы 6. Даже если в каждом измерении оставить по 100 элементов это увелчит объем куба в 100 раз. И будет 100 гигабайт. Это называется \”Взрыв данных\”. Поэтому 10 миллиародов ячеек, – это маленький кубик.

Спасает то, что на самом деле из этих миллиардов ячеек реально содержат данные очень немногие. Считается, что средняя реальная наполненность куба – доли процента от общего потенциального объема. То есть кубы очень разрежены. А значит, можно не резервировать место на диске под все ячейки, а придумать метод каким образом можно кодировать эти \”пустоты\”. И вот тут на самом деле скрываются особенности реализации разных OLAP серверов, ноу-хау их производителей – методики хранения огромных кубов при ограниченном объеме дискового пространства.

Разреженность порождает еще один вопрос. Поскольку данные разрежены, мы уже знаем, что фактически полезных ячеек в кубе меньше процента. Но внутри многомерного пространства куба они распределены крайне неравномерно. И это вызывает непредсказуемость реального размера, занимаемого кубом она диске, особенно если данных много. Предположим, есть у нас 2-мерный куб. И мы знаем что ячейки с (0,0) по (100,100) пустые. А значит мы можем сделать пометку, что этот диапазон пустой и его можно не хранить. А в случае, если придет запрос на ячейку (49,78) будет возвращено пустое значение.

Теперь предположим, что в следующую загрузку куба, в ячейку (50,50) попадает значение. Все. Значит, сказать что диапазон с (0,0) по (100,100) пустой уже нельзя. И значит нужно хранить несколько записей о пустотах в том же диапазоне. А если попадет не 1, а 10 значений в случайном порядке? Значит этих диапазонов будет гораздо больше. А если вспомнить, что пространство в кубе не двумерное, а 5 или 10-мерное, то задача становится очень интересной.

В отличие от реляционной базы, где можно сказать, что если закачать в таблицу данных в два раза больше, что и на диске файлы будут занимать в два раза больше. В действительности, конечно, это зависит от многих факторов, но будет наверное удивительно если вдруг файлы станут занимать в 10 раз больший объем при увеличении данных в таблице в 2 раза. А в OLAP так может быть. Может быть и противоположный случай. Данных загрузили в два раза больше, а объем почти не изменился. Хотя конечно такой вариант встречается реже.

Тем более что, нужно не забывать, что в кубе хранятся не только детальные факты, а и агрегированные. Нужно просуммировать все данные по всем сочетаниям элементов измерений. И даже если есть у нас всего один факт, занимающий одну ячейку – что продан один нарезной батон в одном магазине в за один день, то если мы будем считать агрегаты, нам нужно записать его и в ячейку (\”Январь 2007\”,\”Все магазины\”,\”Батон нарезной\”) и (\”Год 2007\”,\”Гастроном 26\”,\”Все товары\”) и во множество других сочетаний. Кстати это пример того, как один детальный факт, порождает множество агрегатных фактов.
И объем агрегатов это также как и реальный объем куба на диске – вещь весьма малопредсказуемая.

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

Есть и еще один момент – даже оптимизированный куб, все равно занимает значительный объем на диске. Этот объем обычно гораздо больше, чем объем доступной оперативной памяти. А значит, сложные вычисления между ячейками могут вызвать сканирование большого объема данных на диске и загрузки их в память. Памяти мало. А пользователь ожидает мгновенного отклика от сервера. В общем, это еще одна задача для разработчиков OLAP. Как оптимально воспользоваться небольшим объемом оперативной памяти, для того чтобы успешно эмулировать нахождение там куба, потенциальным объемом в сотни и тысячи миллиародов ячеек?

Сейчас память значительно подешевела, а вот 20-30 лет назад это было совсем интересно.

Первый продукт, который выполнял OLAP запросы был Express компании IRI и был выпущен в 1970 году. За 23 года до того, как Кодд ввел в употребление этот термин в 1993. Забегая вперед скажу, что именно эту компанию купил Oracle в 1995 году и IRI Express стал легендарным Oracle Express Server.

Что и говорить, в семидесятых годах IT ландшафт был другой, были другие представления о софте и железе.
Со временем развивалось ПО, появлялись новые технологии, которые позволили делать то, о чем в семидесятых наверное и не мечтали. Появились хранилища данных, где а реляционной базе данные лежали в виде, гораздо более удобном для анализа (схемы \”Звезда\” и \”Снежинка\”)

И возникла возможность, предоставить OLAP интерфейс, который построен не над многомерной СУБД, а над реляционной.
Причем пользователь работает в той же идеологии измерений и кубов с фактами, а каждое его действие сопровождается автоматической генерацией SQL запросов к реляционной базе, в зависимости от контекста. А объема дисков, памяти и мощности процессоров стало хватать для того, чтобы делать эти вычисления на лету. Конечно тоже не всегда. Но во многих случаях, стало возможным обойтись без специализированного OLAP сервера. Примером такого продукта является Oracle Discoverer.

Такой подход стали называть реляционным OLAP-ом или ROLAP (Relational OLAP). А OLAP с использованием многомерного сервера – MOLAP (Multidimensional OLAP).

На самом деле у ROLAP есть множество преимуществ.
Например, данные не нужно перекачивать в многомерный сервер. А значит они могут быть доступны для анализа практически сразу, после того как туда попадают. Также не нужны специалисты со знанием специализированной многомерной СУБД для ее обслуживания.

Но конечно, у MOLAP есть то, чего нет у ROLAP, например возможность адресовать любую ячейку или группу ячеек в многомерном пространстве. И как следствие возможность проводить любые вычисления между любыми ячейками. В реляционной базе на SQL легко делаются только вычисления внутри строки. А если вы хотите, например посчитать скользящее среднее, которое требует вычисления с использованием данных, лежащих в разных строчках таблицы, да еще и с движущимся \”окном\”, то это делается довольно сложно. Хорошо, что в Oracle есть аналитические функции для этого. Во многих СУБД их нет вообще.

Еще одно преимущество MOLAP – это работа с агрегатами. В реляционной базе у вас или нет агрегатов или работу с ними нужно эмулировать средствами OLAP продукта. В Oracle есть материализованные представления. Но это опять же в Oracle.

Поэтому стали возникать гибридные схемы (Hybrid OLAP). Агрегаты хранятся в MOLAP, а детальные данные в реляционной базе.

Наверное из-за того, что OLAP как концепция вещь не новая, многие про нее знают. Но под OLAP чаще всего понимается именно MOLAP. Довольно часто встречются люди, которые считают что аналитика==MOLAP и других вариантов нет. И даже записывают в спецификацию проекта MOLAP сервер не задумываясь, нужен ли он им на самом деле.

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

В следующей части расскажу непосредственно про Oracle OLAP и Express Server.

Продолжение здесь.

__________________________________

Читайте также:

• Что такое OLAP? Часть 2. Oracle Express и Oracle OLAP
• Oracle покупает Hyperroll
• Впечатления от Oracle OLAP 11g. Часть 3.
• Семинар и тренинг по Oracle OLAP 11g в Москве
• Best Practices for Discoverer Plus OLAP

А еще можно почитать мой твиттер @apivovarov

Trackback This Post | Subscribe to the comments through RSS Feed