Про Oracle Business Intelligence

В конце 2006 года, примерно в октябре-ноябре месяце, Oracle приобрел компанию Sunopsis. Приобретение было сделано из-за продукта, который назывался Sunopsis Data Conductor.

Этот продукт был довольно мало известен в России, но занимал определенную нишу в мире. После приобретения, Sunopsis Data Conductor был переименован в Oracle Data Integrator. Самое интересное было в том, что этот продукт до приобретения Oracle был прямым конурентом Oracle Warehouse Builder. И, конечно, интересно, что между ними общего и чем они отличаются.

И ODI и OWB – это так называемые, ETL (Extract Transform Load) инструменты.

Два слова об этом. Если вы строите хранилище данных или просто хотите перекачать данные из одной СУБД в другую, то у вас, в основном, два пути:

1. Написать скрипты по перекачке вручную.
Это самый простой путь и часто самый быстрый. При этом у вас есть полный контроль за тем, что происходит при перекачке и т.д.

2. Использовать ETL инструмент.
На первый взгляд, преимущества использования ETL не очевидны. Руками написать все чаще проще и быстрее. Но если проект большой, то количество скриптов быстро начинает превосходить возможности одного человека помнить в каком из них что и как делается. Более того, если программистов несколько, то разобраться в скрипте другого вообще может быть очень сложной задачей.
Поэтому приходит осознание, что нужна некая система, которая помогает держать в порядке всю логику преобразований. И плюс дает массу преимуществ, вроде контроля влияния (какой объект влияет на другой, какие объекты будут затронуты, при уничтожении какой-то колонки в источнике данных)

Я не хочу здесь долго описывать преимущества ETL. Тема это не новая, к тому же довольно-таки понятная.

Вернемся к ODI. У ODI есть несколько отличительных особенностей, на которых имеет смысл остановиться.

E-LT технология.
Sunopsis придумал это словосочетание, чтобы подчеркнуть свое отличие от \”традиционных\” ETL инструментов, которые работают по схеме \”черного ящика\”.

Существует специальный выделенный сервер, который выкачивает строчку за строчкой в себя все записи из источника(ов) данных (Extract в ETL), производит внутри себя преобразования, трансформации (Transform) и затем результаты загружает построчно в хранилище (Load). Черный ящик тут в том, что разработчик весьма ограниченно контролирует, что проиходит внутри выделенного, трансформирующего сервера. То есть, он, конечно, задает параметры и логику обработки, но физическая реализации этой трансформации находится вне его досягаемости.

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

В Sunopsis-е рассудили следующим образом. Традиционные ETL средства создавались в те время, когда серверное железо было дорогое и, по современным меркам, слабое. К тому же, в существующих тогда СУБД не было возможностей, упрощающих ETL процессы.

С тех пор прошло много времени и стало возможным вместо того, чтобы делать специализированный промежуточный сервер, использовать возможности самих СУБД и железа, на котором они крутятся. В этом случае, ETL процесс будет \”размазан\” между источником и приемником данных. А E-LT здесь в том, что, как один из вариантов, можно извлечь данные из источника, загрузить их в хранилище, и уже внутри хранилища осуществлять преобразования.

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

В этой архитектуре агент ODI занимается только оркестровкой процесса – говорит что делать (генерирует и запускает код) на источнике, что делать на приемнике, при этом вся нагрузка ложится непосредственно на сервера источники и приемники.

Те, кто знаком с OWB, могут заметить, что OWB тоже использует в качестве трансформирующего движка возможности самого сервера хранилища данных. Это действительно так. Но ключевое отлчичие ODI тут в том, что он никак не привязан именно к СУБД Oracle, и может работать даже в архитектуре где серверов Oracle нет вообще. И в OWB сложнее сделать \”размазывание\” процесса между серверами.

Модули знаний. (Knowledge Modules)
Вторая и, наверное, самая интересная особенность, – это модули знаний или Knowledge Modules. Эта фича как раз и борется с черными ящиками.

Компания Sunopsis возникла, когда в конце 90х годов группа консультантов делала множество BI проектов, причем перекачки данных в этих проектах они писали руками. Со временем они поняли, что в любом проекте возникает масса похожих, шаблонных, действий которые неплохо было бы автоматизировать. Таким образом, возникла идея создать GUI-фреймворк для автоматизации типовой разработки ETL скриптов. Так и возник ODI-Data Conductor.

И они заметили, например, что загрузку данных в Oracle оператором INSERT, можно разбить на ряд стандартных шагов, типа: открыть соединение по dblink-у с удаленной базой; выполнить INSERT, который имеет стандартный синтаксис но в который нужно подставить имена колонок и таблиц; после загрузки закрыть линк и сделать COMMIT.

Само описание шаблона INSERT-а может выглядеть например так:

insert into <%=snpRef.getTable(\"L\", \"COLL_NAME\", \"W\")>
(
<=snpRef.getColList(\"\", \"[CX_COL_NAME]\", \",\\n\\t\", \"\",\"\")>
)
values
(
<=snpRef.getColList(\"\", \":[CX_COL_NAME]\", \",\\n\\t\", \"\",\"\")>
)

Собственно идея тут в том, что любое действие, которое производит ODI может быть описано шаблоном-модулем знаний, который можно использовать для одного и того же логического описания действия. Причем шаблон будет использовать особенности и синтакис той платформы, где код будет запущен.

Например, текстовый файл можно загрузить в Oracle при помощи SQL*Loader, а можно при помощи External Table.

Забрать данные из удаленной базы можно через цепочку построчных Select-Insert (что неэффективно, но бывает, что это единственный вариант), а можно через DBLINK. Можно даже пойти еще дальше – можно выгрузить данные на удаленном сервере в текст, передать его по FTP и загрузить SQL*Loader-ом в хранилище.

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

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

Если у вас есть приложение, которые умеет отдавать данные только через консоль, – можно написать модуль, который будет забирать данные так.

В поставке с ODI идет более 100 готовых модулей, так что, для начала должно хватить.

Плюс к этим возможностям добавить, что ODI умеет работать с XML, вебсервисами (причем может как брать данные через вебсвервисы, так и публиковать вебсвервисы) и т.д.

ODI может работать не только как ETL средство, но и, например, как платформа для построения HUB архитектуры.

Плюс, что интересно, он может продаваться в качестве платнйо опции к Oracle BI EE.

Возникает естественный вопрос, раз ODI так хорош, то что будет с OWB?

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

Если посмотреть внимательно, то можно увидеть, что OWB очень силен как ETL инструмент для построения хранилищ на платформе Oracle. В нем можно сделать автоматически многие вещи, которые в ODI в лучшем случае требуют переделки модулей знаний.

Вместе с тем, ODI силен именно своей гетерогенностью, непривязанностью к конкретной платформе. Поэтому на текущий момент, никто из них не является основным инструментом. У каждого есть преимущества в определенных условиях.

Что еще почитать на эту тему?

Здесь находится основная страница Oracle Data Integrator.

Тут можно скачать ODI.
Кстати, там внутри есть сконфигуренный пример, и можно посмотреть как ODI работает живьем.

А тут проходилка к этому примеру.

__________________________________

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

• Еще про Resource Description Framework
• Семинар для партнеров о возможностях Oracle для ХД
• Проблема с созданием Data Profile в OWB 10.2
• Про будущее Oracle Warehouse Builder
• Про ошибки nQSError 15001 и 15013 или как построить отчет на одной таблице

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

Trackback This Post | Subscribe to the comments through RSS Feed