Feed on Posts or Comments

BI EE &BI Server EE &Ликбез Андрей Пивоваров on 06 Jan 2007 03:52 pm

Что такое Oracle BI Enterprise Edition? Часть 1.

Всех с наступившим Новым Годом!

Как я уже писал раньше, у Oracle в BI существует несколько линеек. Основная и самая большая называется Oracle Business Intelligence Enterprise Edition. Так как, это новый набор продуктов у Oracle, о нем часто спрашивают и я попытаюсь коротко объяснить что же это такое и из чего состоит.

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

Итак, как уже упоминалось Oracle BI Enterprise Edition появился в Oracle после приобретения компании Siebel. В Siebel этот пакет назвался Siebel Business Analytics (SBA) и использовался, в основном, для создания систем бизнес анализа для пользователей Siebel CRM. Но сама эта платформа не заточена именно под CRM, а может быть использована для создания произвольных систем бизнес-анализа.

В прошлогоднем отчете Gartner по платформам для бизнес анализа Siebel Business Analytics был даже назван самой технологически продвинутой платформой, обогнавшей всех конкурентов.
Из чего же состоит эта платформа?

В основе всего лежит аналитический сервер, Siebel Business Analytics Server или Oracle BI Server EE, как он сейчас называется. В этой части, я расскажу об этом аналитическом сервере.

Этот сервер, во-первых, хранит описание различных источников данных. В качестве источников данных могут быть практически любые СУБД (Oracle, Microsoft SQLServer, Microsoft Analysis Services (да, в качестве истоника может быть MS AS или SAP BW), IBM DB2 и т.д.), ODBC источники, текстовые файлы и т.д.

Во-вторых, на сервере в репозитории хранится бизнес-модель данных, построенная над физическими источниками данных. Бизнес модель описывает данные в понятиях: словарь, таблица фактов, измерение, иерархии и т.д. В общем в терминах, испоьзуемых при проектировании и построении хранилищ данных. Там же описывается, каким образом данные из физических источников, соответствуют бизнес-модели. Это не описание ETL процессов, как в Oracle Warehouse Builder, это просто правила отображения.

Третий логический слой (после физического и бизнес модели) – это, так называемый, презентационный слой. Проще всего объяснить, что это такое, по аналогии. Бизнес модель – это структура всего хранилища данных, а презентационный уровень – это витрины данных. Одно и тоже понятие бизнес модели для финансиста и продавца может иметь разный смысл и название.
Да и понятия, с которыми работают разные типы пользователей, включают в себя разный набор показателей и атрибутов.

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

Тут важно сделать замечание, так как часто возникает недопонимание. Siebel Analytics Server не является сервером СУБД. Это не СУБД и не OLAP сервер, хотя со стороны кажется именно так. Это, по сути своей, сервер приложений, который по запросу вычисляет, какие данные нужны, в каком физическом источнике они находятся и делает запрос к соответствующему источнику или источникам (один запрос может возвращать данные из нескольких разных источников одновременно), после чего, сервер собирает, при необходимости агрегирует или производит дополнительные вычисления и возвращает результат.

С другой стороны, аналитический сервер сам виден в сети как ODBC источник и позволяет делать к себе запросы с помощью любого инструмента или программы, работающей с ODBC. При этом этот сервер остается виртуальным, так как данные на нем не хранятся, а собираются в момент запроса.

Зачем делать запрос к промежуточному серверу, когда можно сделать запрос непосредственно к источникам данных?

Дело в том, что сервер, как было сказано, хранит бизнес-модель данных и правила извлечения данных из источников. Логика извлечения данных может быть достаточно сложной. Структура данных в источниках тоже. Инструмент, обращающийся к серверу, видит только бизнес-модель (а вернее сказать \”витрину данных\” из презентационного слоя), например, в схеме \”звезда\”, запросы к которой пишутся на порядок проще и все сложности извлечения, также скрыты и прописываются один раз, в момент создания бизнес модели.

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

Является ли аналитический сервер заменой хранилищу данных? Ответ – нет. Хотя, в некоторых простых случаях, он действительно позволяет обойтись без хранилища. Например, когда данных немного и любой запрос можно обсчитать на лету.

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

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

Но у обычного хранилища есть один недостаток – данные попадают в хранилище периодически и в промежуток времени между загрузками данных, данные в хранилище отстают от OLTP системы. А, зачастую, необходим не только исторический анализ, но и анализ в реальном времени. Существуют подходы по созданию т.н. real-time хранилищ данных, но у них тоже есть свои недостатки.

Аналитический сервер позволят использовать хранилище как источник данных, одновременно с OLTP системами. А в бизнес-модели прописать, например, что если будет запрос к данным за вчера или за год назад, то есть, к тем данным, что есть в хранилище, то результат запроса будет возвращаться из хранилища. А если запрос идет к данным за сегодня, то есть к тем данным, которых в хранилище еще нет, они появятся там только завтра, то запрос будет идти к \”боевой\” системе. И даже в одном результате запроса могут совмещаться данные полученные как из хранилища, так и из \”боевой\” системы одновременно. При этом хранилище данных и OLTP система могут быть на разных платформах как ОС, так и СУБД.

Вот примерно, что делает аналитический сервер.

Другие интересные возможности аналитического сервера:

  • Гибкие возможности по разграничению прав доступа для пользователей. Можно настроить, например, какой пользователь в какое время имеет право обращаться к конкретной системе-источнику. Можно прописать, что если соединяется пользователь аналитического сервера Petrov, то запросы к системе продаж будут производиться под специальным пользователем СУБД с расширенными полномочиями, а все остальные пользователи будут получать результаты под другим пользователем СУБД по умолчанию.
    Можно, конечно сделать, чтобы запросы каждого к системам производились под персональными логинами и паролями, но в этом случае возможности кеширования результатов запроса аналитического сервера будут использованы в меньшей степени.
  • Использование пулинга сессий при доступе к источникам. Можно прописать, например, что к некоторой системе можно открыть одновременно не больше 5 соединений (чтобы не создавать лишнюю нагрузку на OLTP систему, например) И в том случае, если пользователей много и они будут делать к этой системе множество запросов – эти пользователи будут ставиться в очередь, в том случае, если все текущие соединения заняты.
  • Возможно создать в одной системе хранилище агрегатов данных, лежащих в другой системе. А при запросе будет автоматически вычисляться откуда брать данные – из хранилища агрегатов или из исходной системы. Если вы используете СУБД Oracle, то это можно сделать на уровне базы с помощью механизма материализованных представлений (materialized views) Но если ваша система таких возможностей не поддерживает их можно сэмулировать при помощи аналитического сервера. При дрилл-дауне, для пользователя будет не важно откуда в данный момент извлекаются данные
  • Использование родных (native) адаптеров для источников данных. Аналитический сервер, в зависимости от того, к какому источнику данных идет запрос, может создавать оптимизированные запросы на том диалекте SQL, который поддерживается этим сервером, для того, чтобы оптимально использовать его возможности. Например, если сервер поддерживает аналитические функции, то операция RANK будет обсчитана на стороне СУБД, а в случае если данная СУБД таких возможностей не подерживает, будет послан более простой запрос, а ранжироваться результаты будут средствами самого аналитического сервера

Это, конечно, не полный список, но то, что вспомнилось сразу.

В следующей части я постараюсь написать о других компонентах Oracle Business Intelligence Enterprise Edition.
Продолжение здесь.

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

One Response to “Что такое Oracle BI Enterprise Edition? Часть 1.”

  1. on 30 Apr 2008 at 4:45 pm 1.Что такое Oracle Business Intelligence? Часть 1. | Infology.Ru said …

    […] Андрей Пивоваров Источник: сайт OracleBI.Ru Читайте также: Совет №56. Многомерное моделирование […]

Trackback This Post | Subscribe to the comments through RSS Feed

Leave a Reply