Еще совсем недавно аналитики Gartner включали платформу Siebel Analytics в группу «провидцы». Отмечая ее технологические достоинства, они невысоко оценивали стратегию компании Siebel Systems по продвижению платформы, однако после ее покупки корпорацией Oracle аналитики поменяли свое мнение. Насколько заслуженно Oracle Business Intelligence Suite Enterprise Edition оказалась, по оценке Gartner, в числе лидеров?

Архитектура аналитических платформ определяется способами доступа к источникам данных — в соответствии с используемыми способами все аналитические платформы делятся на две группы. Платформы первой группы ориентированы на работу с выделенными источниками данных — хранилищами и витринами данных, которые специально сформированы для аналитической обработки, что выражается и в особых структурах и моделях данных этих источников. Сегодня наибольшее признание получила многомерная модель, которая может быть реализована средствами реляционных и многомерных СУБД. Эффективность и удобство выполнения анализа при использовании последних значительно выше, поэтому серверы оперативной аналитической обработки (OnLine Analytical Processing, OLAP) являются ядром аналитических платформ первой группы, в которую входят аналитические платформы от Microsoft и Hyperion Solutions, Oracle («старая» платформа, которая теперь называется Oracle Business Intelligence Suite Standard Edition) и некоторые другие.

Платформы второй группы, которую образуют продукты Business Objects, Cognos, Microstrategy и ряда других компаний, разработаны для более широкого круга источников. В их число помимо хранилищ и витрин данных, входят «обычные» базы данных, создаваемые транзакционными системами, и другие источники данных — XML-файлы, плоские файлы, файлы Microsoft Excel и т.д. Можно сказать, что эти платформы «равноудалены» от различных источников данных. В состав платформ второй группы не входят OLAP-серверы и другие средства непосредственного доступа к источникам данных. Для этого в таких платформах используются в основном стандартные интерфейсы к соответствующим серверам: ODBC/JDBC для доступа к реляционным и MDX (MultiDimensional eXpressions — язык запросов для простого и эффективного доступа к многомерным структурам данных, наподобие SQL) для доступа к многомерным базам и хранилищам данных. Кроме того, в некоторых платформах используются и «родные» для конкретных источников интерфейсы, например OCI (Oracle Call Interface) для доступа к базам данных Oracle, интерфейс XMLA (XML for Analysis) для доступа к многомерным хранилищам SAP BI/BW, интерфейсы к базам данных популярных пакетов. Платформа Oracle BI Suite EE по способам доступа к данным относится ко второй группе.

Архитектура Oracle BI Suite EE

В архитектуре платформы Oracle BI Suite EE (рис. 1) центральное место занимает аналитический сервер Oracle BI Server, через который реализуется весь доступ к разнообразным источникам данных. Его называют аналитическим сервером приложений (business intelligence application server). Он поддерживает интерфейсы к реляционным и многомерным базам (ODBC, OCI, MDX, CLI), а также к плоским файлам, XML-документам, таблицам Excel, базам данных популярных приложений наподобие SAP R/3, mySAP, Oracle e-Business Suite, J.D. Edwards Enterprise One, Peoplesoft Enterprise, Oracle Siebel CRM, а также играет роль интегратора, которая традиционно была прерогативой промежуточного хранилища данных. Oracle BI Server обладает необходимой серверной инфраструктурой, включая управление сеансами, запросами, отменами и блокировками, ведением журналов и мониторингом активности, балансировкой нагрузки на сервер, и, самое главное, системой кэширования запросов и их результатов. Oracle BI Server также централизованно хранит метаданные об источниках данных и бизнес-объектах в своем репозитарии, доступном всем инструментам платформы Oracle BI Suite EE. Ее основными архитектурными компонентами, помимо Oracle BI Server, являются Oracle BI Web и Oracle Delivers Server.

Рис. 1. Архитектура платформы Oracle BI Suite EE 

Oracle BI Web предоставляет интерфейсы для компонентов системы, используемых для визуализации данных. Он взаимодействует с Oracle BI Server и выполняет ряд важнейших функций — отвечает за авторизацию пользователей и персонализацию интерфейса для них, генерацию логических запросов к аналитическому серверу, хранение и администрирование метаданных (Web-каталог) для отчетов и интерактивных панелей, осуществляет дополнительную постобработку данных.

Oracle Delivers Server необходим для работы проактивного компонента платформы, позволяющего задавать модели выявления событий, фильтровать данные в соответствии с заданными правилами, уведомлять пользователей с использованием различных каналов коммуникаций (в том числе электронную почту и SMS), давать возможность пользователям принимать решение в ответ на оповещение. Основные функции Delivers Server — создание уведомлений и подписка на них, автоматическое оповещение и планировщики, администрирование каналов и учетных записей доставки.

Клиентские приложения

Большинство аналитических платформ предлагают относительно ограниченный набор приложений, состоящий из средств построения аналитических запросов, отчетов и неких панелей или книг для объединения связанных отчетов и представления их конечному пользователю. Если же платформа предоставляет более полный спектр аналитических возможностей, то часто у каждого ее компонента имеются свои метаданные. В отличие от этого в Oracle BI Suite EE все клиентские приложения и инструменты были изначально созданы для совместного использования одних и тех же метаданных, аналитического сервера приложений, инфраструктуры вычислений и инструментов администрирования, единой модели безопасности и управления привилегиями пользователей, что упрощает разработку и сопровождение аналитических приложений.

В состав платформы Oracle BI Suite EE входит следующий набор инструментов, реализованных как клиентские приложения:

  • BI Answers — инструмент для выполнения произвольных (ad hoc) запросов и анализа;
  • BI Interactive Dashboard — интерактивные приборные Web-панели, отображающие персонализированную информацию;
  • BI Publisher — масштабируемое средство формирования регламентированных отчетов в разных форматах на основе данных из множества источников и их рассылки по различным каналам;
  • BI Briefing Books — средство создания и просмотра «мгновенных снимков» приборных панелей;
  • BI Disconnected Analytics — средство доступа пользователей к возможностям BI Answers и BI Interactive Dashboard при работе в автономном режиме, предусматривает полную и инкрементальную синхронизацию данных мобильной среды с корпоративными источниками данных;
  • BI Office Plug-In — инструментарий работы с аналитическим сервером через такие приложения, как Microsoft Word, Excel и Powerpoint;
  • BI Delivers — механизм распространения по различным каналам сообщений о событиях.

Все клиентские приложения этой платформы реализованы в Web-среде на основе HTML, DHTML, JavaScript, поэтому пользователю не придется выполнять загрузку какого-либо клиента, применять программные расширения, элементы управления на базе ActiveX или Java-апплеты, можно работать с системой откуда угодно, имея лишь браузер.

Недавно было объявлено, что в Oracle BI Suite EE будет реализована интеграция с Oracle BPEL PM, а это открывает перед разработчиками широкие перспективы по включению инструмента бизнес-аналитики в бизнес-процессы компании, в числе которых организация корпоративного документооборота.

Метаданные

 представляет данные пользователям согласно логической бизнес-модели — корпоративной семантической модели (Enterprise Semantic Model). Она имеет три слоя (рис. 2):

  • физический, содержащий метаданные о физических источниках данных, имена таблиц, первичные и внешние ключи, статистики по количеству строк, правила доступа к таблицам, а также пул соединений;
  • бизнес-слой, содержащий описания измерений и иерархий, логические таблицы, правила выбора источников данных, правила построения вычислений, агрегаций и временного анализа, а также правила детализации;
  • слой представления — упрощенное, персонализированное представление данных, к которым ссылаются с применением «логического SQL».

Физический слой этой модели отвечает за физические соединения с источниками данных — реляционным и многомерным через SQL-представления или MDX (только к многомерным), XML или любым источником данных с ODBC-интерфейсом.

Рис. 2. Аналитический сервер Oracle BI Server

Бизнес-слой обеспечивает уровень абстракции над физическими объектами и позволяет администратору группировать данные в логические тематические области (logical subject area). «Направления детализации» (drill path) могут быть установлены с учетом указанных размерностей и метрик данных и позволяют использовать преимущества встроенного «движка» вычислений (in-built calculation engine) в аналитическом сервере.

Слой представления определяет, что конечные пользователи увидят, когда они начнут выбирать данные в клиентском приложении. Это может быть полный набор данных в бизнес-слое или просто поднабор, можно применять фильтры и ограничения (scoping), так что отдельные департаменты и даже сотрудники увидят данные, предназначенные только им.

Доступ к данным и обработка запросов

Oracle BI Server в части обработки запросов выполняет две основные функции: компиляцию входящих запросов от пользователей в исполняемый код и исполнение этого кода. Разбор и компиляция запроса состоит из пяти основных стадий: синтаксического анализа, генерации логического запроса, навигации, переписывания и генерации конечного кода. При этом основной и самой важной является именно стадия переписывания, или оптимизации запросов. На этой стадии сервер занимается оптимизацией с учетом специфики каждого конкретного источника. Механизм объединения данных учитывает физическое расположение данных (таблица базы данных или, например, плоский файл), особенности функциональности SQL, поддерживаемого базой данных, а также аналитической сложности запроса.

В платформе Oracle BI Suite ЕЕ обработка запросов к данным максимально переносится, насколько это возможно, на серверы источников данных. Несмотря на то, что аналитический сервер может выполнять OLAP-вычисления и анализ, лучше все-таки использовать для этого выделенный OLAP-сервер, и, аналогично, при работе со сверхбольшими наборами данных лучше использовать высокопроизводительный сервер реляционной СУБД. Поэтому, когда возможно, для обработки используются именно эти технологии, а не аналитический сервер, роль которого в этом случае заключается в принятии запросов от инструмента (клиентского приложения) и их трансляции в предложения SQL (или MDX) к базам исходных данных. Когда эти базы возвращают результаты, аналитический сервер сводит данные, если нужно, сам выполняет некоторые вычисления, форматирует результаты и передает их клиентскому приложению.

Сгенерированные предложения SQL оптимизируются, чтобы использовать особенности базы данных источника. Ее сервер может получать доступ к данным в агрегированных таблицах (aggregate table), если он «знает» о таковых. Это может означать, например, что вы можете прямо отображать измерения на более высокий уровень агрегирования, до агрегированных таблиц в базе данных, которые можно использовать как замену для механизма перезаписи в запросе (query rewrite mechanism) в базе данных Oracle. Эту особенность можно задействовать, чтобы задать аналитическому серверу использование другого представления SQL для аналитического пространства (analytic workspace), если требуется агрегирование более высокого уровня.

Хранилища «виртуальные» и «реальные»

Предположим, что у заказчика в промышленной эксплуатации есть несколько транзакционных систем со своими базами данных (первичными источниками) и нужно получить консолидированную аналитическую отчетность на основе данных из этих баз. С помощью Oracle BI Server можно решить эту задачу без проектирования и построения классического хранилища данных. Фактически можно создать «виртуальное хранилище данных», которое для клиентских приложений будет выглядеть как независимый источник денормализованных данных (в привычных понятиях: анализируемые величины, аналитические разрезы, иерархии и т.д.). При обработке поступающих запросов аналитический сервер будет их транслировать к первичным источникам данных, в том числе транзакционным. Минусы такого решения — нагрузка на первичные источники и неэффективная для отчетов физическая модель данных в первичных источниках (в основном сильно нормализованная, распределенная структура). Для решения этих проблем и предлагается строить «настоящее» хранилище данных, а виртуальное рассматривать как быстрое и временное решение, чтобы потом перейти к полноценному хранилищу данных.

Антон Шмаков (a.shmakov@borlas.ru) — старший консультант отдела бизнес-анализа и хранилищ данных консалтинговой группы «Борлас» (Москва).