Про Oracle Business Intelligence

Теперь перейдем собственно к Oracle OLAP.

Как я уже упомянул, в 1995 году Oracle приобрел компанию IRI – пионера в области MOLAP, производителя Express. Я сам впервые столкнулся Oracle Express в 1999 году. Если бы я не прочитал, что первая его версия появилась в 1970, никогда бы не подумал.

На самом деле, с 1970 продукт несколько раз переписывался, в том числе и на другие языки программирования. И в 1995, когда его купил Oracle, Express был лидером в своем классе.

Семейство Oracle Express состоит из нескольких продуктов:

• Oracle Express Server – собственно многомерный сервер.
• Oracle Express Objects – RAD среда, напоминающая Visual Basic, с помощью которой можно написать любой интерфейс пользователя.
• Oracle Express Analyzer – смотрелка кубов (в том случае если вы не хотите писать собственный интерфейс). Этот же Analyzer является runtime-средой для приложений, написанных на Objects.
• Express Web Publisher – компонент, который позволяет публиковать данные из Express на вебсайтах.

У Express Server есть помимо стандартных возможностей просмотра содержимого кубов, есть ряд интересных и иногда даже уникальных возможностей. Например:

• Возможность не только читать данные из куба, но и писать их в куб (Writeback), причем в произвольную ячейку или группу ячеек. Для этого даже не надо переводить куб в какой-либо специальный режим. На самом деле даже расчет агрегатов производится как вычисление значения нужной агрегированной ячейки и последующей записью ее в куб. Эта возможность очень востребована на пример при What-If (что-если) анализе. Когда нужно изменить некий параметр, и после этого пересчитать значение связанных с ним ячеек. Или когда значение агрегата не вычисляется, а вводится пользователем. Такое часто бывает в финансовых приложениях.
• Модели (MODELS) – специальная конструкция в Express, позволяющая описать многошаговую последовательность вычисления одних данных на основе других, причем в нескольких вариантах сразу (оптимистическом, пессимистическом и т.д.) Результат будет зафиксирован в кубе и доступен уже просто для чтения другим пользователям.
• Формулы – по сути, это аналог View в реляционных базах. То есть имея данные в кубах, можно описать виртуальный куб, который содержит данные из других кубов и вычисления над ними. Для пользователя формула видна как обычный куб. Например если у нас есть кубик содержащий продажи по дням в некоторой валюте, то имея второй куб с курсами валют на каждую дату, можно написать формулу, которая будет для каждой даты и для каждой валюты пересчитывать данные по курсу. Для пользователя это будет видно как обычный куб, у которого добавится еще одно измерение – требуемая валюта. Формулы хранятся в кубе.
• Наконец, программы. Это аналог хранимых процедур в реляционных базах. Не все можно описать языком запросов. Часто требуется написать процедуру из многих шагов, итераций и т.д. В Express можно было написать на собственном языке Express Language практически все что угодно: процедуры загрузки, агрегации, преобразования, очистки. И даже можно писать формулы (см. пред пункт), включающие в себя результаты вычисления программы по введенным параметрам.

При этом, все это работало очень быстро и вообще Express нетребователен к ресурсам. На основе Express написан, например, продукт Oracle Financial Analyzer, предназначенный для планирования и бюджетирования. Этот продукт успешно использует все вышеперечисленные возможности Express.

Все сложности с которыми сталкивались разработчики MOLAP движков и те гибкие возможности, которые были в Express давали и свои минусы – если объем данных значителен, нужны были хорошие навыки по оптимизации сервера. В общем как и с любой СУБД.

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

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

И тут начальник IT департамента заказчика обычно задумывается: \”Не факт, что наши аналитики станут эффективные принимать решения (и правда, эффективность принятия решений зависит не от инструмента, а скорее от мозгов аналитика, инструмент только помогает), а нужно покупать новые сервера, нанимать новых людей, организовывать систему безопасности для этой системы и проч.\” В общем, иногда он может решить продолжать работать по старинке, чем городить что-новое. Закон жизни.

Учитывая это, в Oracle пришли к идее, что если взять движок Express Server и поместить его вместе с OLAP-данными внутрь СУБД Oracle, то это даст ряд преимуществ, тем более что диски и память стали дешевле:

• Упрощение администрирования. Не нужно создавать специальную систему резервного копирования только для OLAP, бэкап OLAP данных будет происходить вместе с бэкапом базы Oracle.
• Не нужна специальная система безопасности для OLAP – полномочия будут раздаваться централизованно, так как это делается в Oracle.
• Если OLAP база располагается на том же сервере что и транзакционная, то не нужна перекачка данных между транзакционным и OLAP сервером, а это выигрыш в производительности.
• Можно организовать прозрачный доступ пользователя к OLAP и не OLAP данным. Даже через обычный SQL.
• И т.д.

В итоге решение о включении Express в состав СУБД было принято. И появилась OLAP опция СУБД Oracle. Которая сейчас называется просто Oracle OLAP. Express существует и продается, в том числе в составе Oracle Financial Analyzer, но усилия разработчиков в основном направлены на OLAP опцию базы.

Но так как процесс интеграции нереляционной СУБД внутрь реляционной оказался не так прост, то он занял некоторое время.
Сначала, в первом релизе Oracle 9i не было MOLAP, был организован только ROLAP.
Во втором релизе появился MOLAP (то есть движок Express был интегрирован в базу), но понадобилось время и несколько промежуточных релизов чтобы оптимизировать код.

Фактически, в 9-ой версии к функциональности OLAP ничего нового не добавлялось, и только в версии 10g, а особенно в 10.2 появился новый функционал, который позволяет делать то, что нельзя было делать в Express. Например:

• Секционирование (partitioning) – идея такая же, как и в секционировании в базе – большой куб можно разбить на несколько маленьких, а при запросе оптимизатор автоматом выбирает нужные секции, из которых берутся данные. К тому же в многомерном пространстве уничтожение в кубе одного измерения и замена его на несколько маленьких кубов может дать порядковое уменьшение объема.
• Появление так называемых compressed composites – технология, позволяющая сжимать кубы, что дает эффект как в объеме диска, так и в производительности. (часто гораздо быстрее прочитать с диска сжатый кусок данных и на лету распаковать, так как память гораздо быстрее чем диск, чем читать с диска уже распакованный фрагмент) Правда в сжатый композит писать нельзя, но это не всегда и нужно.
• Возможность работы на запись нескольких пользователей одновременно. (В Express в любой момент времени такой пользователь мог быть только один)

Поэтому, если вы только знакомитесь с Oracle OLAP лучше всего начинать с версии 10.2.

К сожалению, OLAP опция не поддерживает тот API, который был в Express, поэтому приложения, написанные на Express Objects не могут работать с OLAP опцией. Вместо этого в OLAP есть Java OLAP API, через который работает например Discoverer for OLAP.

Для написания собственных приложений, можно использовать этот API, плюс так называемые Business Intelligence Beans – Java компоненты, которые сами умеют доставать данные из OLAP, используя API и выводить данные в табличном и графическом виде. На самом деле, их применение гораздо шире. Хотя начались они и с OLAP опции, но отображение информации в табличном и графическом виде необходимо не только в OLAP опции, поэтому со временем BI Beans стали использоваться во многих продуктах Oracle, например в Enterprise Manager-е. И вообще, поскольку рисовалки графиков и таблиц принимают на вход данные в XML формате, то их можно использовать практически с чем угодно. Если вы, конечно, пишете на Java.

Но если вы Java не используете, вы можете работать с кубами MOLAP при помощи обычного (почти) SQL. Дело в том, что в Oracle существует табличная функция OLAP_TABLE, которая при обращении к ней из SQL ведет себя как VIEW, но в нее можно передавать параметры, говорящие движку MOLAP, что нужно достать из куба.
Выглядеть этот запрос будет, например так (взято отсюда):

SELECT *
FROM TABLE(
OLAP_TABLE(
\'AWG DURATION SESSION\',
\'\',
\'\',
\'MEASURE quant AS NUMBER FROM cubname_quantity
DIMENSION firms FROM FIRMS_DIM
WITH ATTRIBUTE firm_name FROM FIRMS_DIM_LONG_DESCRIPTION
DIMENSION countues FROM COUNTRIES_DIM
DIMENSION time FROM TIME_DIM\'
)
)


Такой запрос можно положить во VIEW и делать запросы к этой VIEW с помощью любого SQL-инструмента. Таким образом нет необходимости поддержки специального API со стороны клиентских инструментов. Любой инструмент может работать с MOLAP, даже тот, разработчики которого и не думали о такой возможности.

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

В случае каких-то других СУБД, не Oracle, действительно, особых альтернатив MOLAP серверам для аналитики нет. Но в случае Oracle не все так однозначно.

Как я уже написал, MOLAP сервера возникли в те времена, когда процессоры были слабыми, памяти было мало, диски были небольшими по объему и медленными. Необходимы были специальные методы работы с данными, чтобы обеспечить быстрый отклик на запросы при таких ограничениях. Наверное тогда и возник стереотип – хранение это реляционка, а аналитика – это отдельный OLAP сервер.

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

Кроме того, в самой СУБД Oracle появилось множество возможностей, присущих раньше только MOLAP серверам:

• Материализованные представления и переписывание запросов (Materialized Views и Query Rewrite) – возможность обсчитывать, хранить и автоматически обновлять агрегаты в дополнительных таблицах (материализованных представлениях) , при этом при запросе к изначальной таблице, оптимизатор определяет, что агрегированные данные можно получить не обсчетом данных из исходной таблицы, а взять из предварительно обсчитанной таблицы-хранилища агрегатов или даже из нескольких таких таблиц. При этом, запрос будет автоматически переписан и использовано нужное представление.
• Секционирование (Partitioning) – возможность разбить большую таблицу на части, каждая отдельная часть будет вести себя как маленькая таблица, в том числе иметь свои собственные локальные индексы. При этом при запросе к большой таблице, оптимизатор сам разбирается к каким секциям нужно обращаться, чтобы сделать выборку.
• Bitmap-индексы. Специальный тип индексов, очень эффективных при запросах, когда нужно отфильтровать данные по маскам. Чаще всего используются в хранилищах данных.
• Star Transformation – еще один метод переписывания запросов, для таблиц организованных по схеме \”звезда\”. При выборке по какому то атрибуту в словарной таблице, запрос будет переписан так, чтобы заменить фильтр по атрибуту, на фильтр по набору ID, а затем по этому набору ID легко сделать фильтр с BITMAP индексом. Например если у нас есть словарь товаров, а нам нужно сделать выборку по группе товара \”Хлебобулочные изделия\”, запрос будет переписан таким образом, что сначала будет сделана выборка всех ID товаров, относящихся к этой группе и из фактической таблицы фильтрация будет происходить уже по этой группе ID.
• Аналитические функции – расширения SQL, позволяющие выполнять в SQL такие вычисления, как ранжирование, нарастающие итоги, скользящие средние и проч. Если SQL в СУБД этого не поддерживает, то такие вычисления становятся большой проблемой.
• SQL MODEL – расширение SQL, позволяющее работать с выборкой в OLAP-подобном стиле, то есть рассматривать ее как многомерное пространство. Например:

  SELECT SUBSTR(country, 1, 20) country,
SUBSTR(product, 1, 15) product, year, sales
FROM sales_view
WHERE country IN (\'Italy\', \'Japan\')
MODEL
PARTITION BY (country) DIMENSION BY (product, year)
MEASURES (sales sales)
RULES
(sales[\'Bounce\', 2002] = sales[\'Bounce\', 2001] + sales[\'Bounce\', 2000],
sales[\'Y Box\', 2002] = sales[\'Y Box\', 2001],
sales[\'All_Products\', 2002] = sales[\'Bounce\', 2002] + sales[\'Y Box\', 2002])
ORDER BY country, product, year;

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

Как видите, как минимум на примере Oracle (в других СУБД это часто не так) в реляционной СУБД появляются возможности, существовавшие раньше только у MOLAP серверов. И теперь уже не всегда легко сделать выбор будущей архитектуры OLAP. Конечно, у MOLAP есть свои преимущества и для каких-то задач они проявляются ярко.

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

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

Наверное, из прагматических соображений, в начале проекта создания аналитической системы на платформе Oracle, сначала стоит изучить как можно лучше все современные возможности Oracle для хранилищ данных и только уже четко представляя каких возможностей там нет, имеет смысл погружаться в MOLAP. Тем более что такие инструменты как OBI EE делают возможным использование OLAP незаметным для пользователя. (Агрегаты могут быть в OLAP, а детальные данные в реляционке, и при этом пользователь не замечает перехода между OLAP и детальными данными) И OLAP при необходимости можно подключить и потом.

Вообще, развитие реляционных СУБД и в частности Oracle показывает, что происходит его сближение с MOLAP, и в будущем, наверное, эта интеграция будет еще более тесной. И тогда, возможно, вообще не будет возникать вопроса какую архитектуру выбирать. По крайней мере, хотелось бы, чтобы так было.

__________________________________

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

• Впечатления от Oracle OLAP 11g. Часть 1.
• OLAP View Generator для AWM
• Впечатления от Oracle OLAP 11g. Часть 2.
• На OTN появился BI EE плагин для AWM
• Что такое OLAP?

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

Trackback This Post | Subscribe to the comments through RSS Feed