Обзор системы
Oracle Business Intelligence Enterprise Edition (OBIEE, OBI) - программная платформа для решения задач бизнес-аналитики: интерактивных и публикуемых отчетов, мониторинга KPI и бизнес-процессов. Является потомком Siebel Analytics. Основные функциональные части, доступные пользователям:
- Answers (также называются Interactive Dashboards) - построение интерактивных отчетов, доступных для пользователей через веб-интерфейс OBIEE. Единицей отчетности является analysis - простой отчет, как правило, включающий в себя одно отображение (таблицу, график, диаграмму и т.п.). Analysis объединяются в информационные панели (Dashboards), с которыми работают конечные пользователи. Информационные панели также могут включать в себя приглашения (prompts) - элементы настройки, с помощью которых пользователь может взаимодействовать с панелью.
- Publisher (также иногда в него включают Delivers) - средство создания и рассылки статических отчетов. Т.к. publisher развился из отдельного продукта, то в нем есть возможность строить отчеты на собственной модели данных, независимой от модели данных OBI, однако можно использовать и общую модель. Также есть возможность рассылки существующих отчетов из answers.
- Action Framework - набор средств для выполнения каких-либо автоматизированных действий из OBIEE - например, рассылка отчетов по достижению показателем определенного значения, вызова внешних веб-служб, вызова java кода и т.п. Действия могут быть объединены в цепочки. Возможно настройка различных каналов оповещения пользователей - e-e-mail, sms, пейджер и т.п.
- Scorecard and Strategy Management - средства для отслеживания ключевых параметров производительности (KPI) и работы с системами показателей (Scorecard - http://en.wikipedia.org/wiki/Balanced_scorecard). Используются для наглядного отображения статуса выполнения целей (компании, проекта). Доступ пользователей, как и в случае с answers, осуществляется через веб-интерфейс.
- Marketing - средства интеграции с Siebel Marketing.
- Office Tools - средства интеграции с Microsoft Office.
Архитектура
OBIEE, по сути, является посредником между источниками данных и пользователями (пользовательскими отчетами). Система не хранит у себя данных (за исключением кэшей) - все отчеты строятся "на лету", путем выполнения запросов к источникам данных (картинки из книги OBI 11g Developer's Guide):
OBIEE поддерживает множество различных источников данных, среди которых реляционные базы, системы OLAP, файлы и apache hadoop. Система позволяет объединять в одном отчете данные из различных источников, объединяя их между собой по заданным правилам.
В центре системы находится единая модель данных (также называемая репозиторием) - описание логической модели бизнес-области и привязку ее к физическим источникам данных. Модель состоит из трех слоев - презентационного, бизнес и физического. В бизнес-слое описывается логическая модель (которая понятна конечным пользователям), в форме многомерной модели - фактов и измерений, а также описывается привязка логических атрибутов к физическим источникам. Презентационный позволяет разбить логическую модель на несколько предметных областей и ограничить доступ пользователей к различным показателям и атрибутам. Физический слой содержит описание источников данных - таблиц, полей, ключей, кубов данных. Создание модели данных (репозитория) выполняет разработчик с помощью специальной программы - Oracle BI Administration Tool.
Когда пользователь открывает отчет, сервер презентаций (Presentation Server) генерирует запрос на языке Logical SQL к серверу BI. Сервер BI разбирает запрос, и переводит его в запросы к источникам данных на их "родных" языках - sql, mdx и т.п. После получения данных от источников сервер объединяет их, проводит различные действия над данными (например, вычисляет агрегаты, если это необходимо), и возвращает результат серверу презентаций. Сервер презентаций, в свою очередь, отрисовывает полученные данные в веб-интерфейсе или генерирует статичный отчет.
Серверная часть OBIEE включает в себя несколько разрозненных компонентов, часть из которых управляется сервером приложений Weblogic, а другая часть существует как обычные (нативные) программы и управляется компонентом oracle process manager (opmn). Также OBIEE использует для хранения части служебных данных реляционную базу (Oracle, MS SQL, IBM DB2 или MySQL). Управление доменом OBIEE осуществляется с помощью веб-интерфейсов Weblogic Administration Console и Fusion Middleware Enterprise Management Console.
Как происходит работа с системой
Допустим, существует потребность бизнес-пользователей получать аналитическую информацию о состоянии какой-либо области деятельности компании (например, об объемах продаж в ритейлинговой сети магазинов). Как удовлетворить потребности пользователей с использованием OBIEE? Шаги будут примерно следующими (в данном случае речь об интерактивных отчетах Answers):
- Определение доступных данных для построения отчетности
У бизнеса может быть уже подготовленное и работающее хранилище данных для получения непротиворечивых и консолидированных данных. Тогда задача упрощается - мы берем данные из существующей витрины и напрямую обращаемся к ним из OBIEE. Другое дело - если ХД отсутствует, и имеются, например, данные из нескольких разрозненных систем. Как правило, такие данные находятся в нормализованном виде (3 НФ или выше), и очень детальны, что не есть хорошо для построения отчетности. В этом случае необходимо проектирование и построение витрины данных со схемой вида "звезда" или "снежинка" (или нескольких, в зависимости от сложности данных). Витрина может быть реализована в виде таблиц или, например, представлений (обычных или материализованных). Естественно, для этого нужна постоянно работающая СУБД, способная выдерживать достаточно большое количество запросов.
Также возможен вариант, когда данные доступны в виде OLAP - тогда, как правило, никакой доработки не требуется, т.к. это означает, что многомерная модель данных уже построена и функционирует. - Построение модели данных
Существующие данные необходимо описать и связать логические атрибуты (например, метрики объемов продаж) с физическими атрибутами в СУБД или сервере OLAP. На основе этих данных строится многомерная модель - описание данных в терминах фактов, измерений, атрибутов измерений и иерархий. - Создание репозитория
Теперь разработанную модель данных нужно перенести в репозиторий OBIEE. Это делается в Oracle BI Administration Tool (упоминавшейся чуть выше). Разработка проходит в три этапа - импорт метаданных источников, построение бизнес-слоя и построение презентационного слоя. Как правило, имеется только один источник данных, но могут быть и более сложные сценарии, например, с объединением данных из реляционной СУБД и OLAP, или объединение данных с разными уровнями гранулярности из нескольких СУБД. В этих случаях разработчик также должен правильно настроить "взаимоотношения" между источниками. Построение бизнес-слоя в основном состоит из переноса атрибутов физического слоя, описания иерархий, выбора типов агрегаций метрик и настройку источников для логических таблиц. Презентационный уровень, как правило, является отображением "1 в 1" бизнес-слоя, иногда разбитого на отдельные области (если, например, хочется разделить доступ пользователей к данным). Также стоит отметить, что OBIEE имеет некоторые средства для совместной разработки репозиториев - есть возможность их слияния из разных версий, а также репозиторий можно хранить в виде набора xml файлов, для удобства работы с системами контроля версий. - Разработка отчетов
После формирования репозитория и загрузки его на сервер начинается основная фаза - разработка отчетов. Сначала разрабатываются отдельные анализы, затем они интегрируются в информационные панели. Как правило, каждый разработчик работает над своим набором анализов и дашбордов, т.к. средств для совместной разработки нет (все происходит в веб-интерфейсе), и при одновременной правке один будет затирать работу другого:)
Немного из личного опыта
Здесь я постарался описать некоторые особенности системы, которые вызывали наибольшую фрустрацию при разработке. Список, конечно, далеко не полон, но, возможно, будет полезен при планировании архитектуры системы.
- OBIEE не всегда правильно работает со схемами типа "снежинка" в модели данных. Это значит, что не всегда генерируется правильный SQL запрос из отчета. По возможности нужно переводить такую схему в "звезду" на уровне бизнес-слоя. К примеру, если есть таблица "Клиент", которая ссылается на таблицу "Класс клиента" (физическое лицо, корпоративный клиент и т.п.), то в бизнес-слое их нужно свести в одну логическую таблицу "Клиент" с полным набором атрибутов. Ситуация усложняется, когда есть связи таблиц фактов через несколько таблиц измерений. В таких случаях нужно следить за правильностью генерации запросов.
- В OBIEE есть возможность составления анализов на основе прямых запросов к БД. Для этого требуется изменение конфигурационного файла NQSconfig.INI. Эта возможность часто упрощает жизнь, если нужно реализовать хитрую логику отображения, не усложняя без необходимости модель данных. Однако в этом случае надо помнить, к каким данным должны иметь доступ бизнес-пользователи, и не давать возможность выполнения запросов к базе всем подряд.
- Необходимо правильно настраивать кеширование данных таблиц. В том случае, если в данных планируются изменения в течение рабочего дня, которые пользователи должны видеть в отчетах - необходимо либо отключать кеширование, либо вручную (через WLST) обновлять кеш. Также хорошей практикой является "разогрев" (seeding) кеша перед началом рабочего дня пользователей, чтобы пользователи могли сразу полноценно пользоваться отчетами.
- Следует помнить, что функционал информационных панелей как веб-приложения сильно ограничен. Если требуется серьезная интерактивность взаимодействия пользователей с интерфейсом, то лучше смотреть в сторону других BI средств, например, стека MS. Все, что можно получить в OBIEE - это выбор фильтров, работа с данными в таблицах (сортировка, порядок столбцов, создание групп, добавление итогов и т.п.) и так называемые "master-detail" события - когда пользователь может нажать на ячейку в одной таблице, а в соседнем графике или таблице данные автоматически отфильтруются по выбранному значению в ячейке. Есть функционал действий (actions), но он тоже сильно ограничен - есть только переход по URL, вызов REST метода и переход к другой информационной панели.
Мобильная бизнес-аналитика
В арсенале OBIEE также есть средства для мобильной аналитики (с использованием мобильных устройств):
- Oracle BI Mobile - приложение для ios, которое позволяет просматривать контент информационных панелей и анализов на мобильном устройстве. Отображение производится почти без изменения внешнего вида отчетов, отчего все выглядит немного в стиле 90-x:)
- Oracle BI Moblie App Designer - приложение, интегрируемое в OBIEE, позволяет создавать отчеты на HTML5 с использованием модели данных из OBIEE или Publisher. Фактически, это генератор веб-приложений - каждый отчет состоит из нескольких страниц, с интерактивностью и переходами между ними. Плюсом такого решения является то, что приложения будут выглядеть одинаково в полноценном браузере и на устройстве, а также отсутствие необходимости установки отдельного приложения. Минус - то, что данные не кешируются на устройстве, соответственно, пользоваться им можно только при наличии интернет-соединения. Mobile App Designer был выпущен совсем недавно, и еще не включен в основную поставку OBIEE.