Oracle data integrator что это

Обновлено: 06.07.2024

[ От редакции Oracle Magazine/RE : Интеграционный продукт Oracle Data Integrator, ранее известный как Sunopsis Data Conductor, отличается от Oracle Warehouse Builder тем, что функционирует в среде Fusion Middleware/SOA Suite, а не СУБД Oracle. Этот продукт реализует извлечение данных из разнородных источников и их загрузку также в разнородные базы данных. Он разработан для среды SOA, позволяет разделять схемы отображения данных (data mappings) на бизнес-правила (business rules) и специфические для платформ и процессов загрузки (platform/load-type specifics) части. Возможности этого продукта расширяемы благодаря использованию модулей знаний ("knowledge modules"). Подобно Oracle Warehouse Builder, он построен с применением Java и использует сервер целевой базы данных как ETL-движок, преобразуя данные после их извлечения и загрузки, при этом используя, когда это возможно, наборы операций (set-based operations). ]

Продукт Oracle Data Integrator состоит из нескольких компонент, работающих с единым централизованным репозиторием метаданных (metadata repository). Эти компоненты - графические модули (graphical modules), компоненты времени выполнения (runtime components) и Web-интерфейс - вместе с другими продвинутыми функциями и делают Oracle Data Integrator "легкой" (lightweight), свободной от атавизмов (legacy-free), совершенной интеграционной платформой.

В этом кратком техническом обзоре представлена архитектура Oracle Data Integrator.

Архитектура Oracle Data Integrator организована вокруг модульного репозитория, который доступен компонентам, графическим модулям и агентам исполнения (execution agents), целиком написанным на Java, в режиме клиент-сервер. Эта архитектура также включает Web-приложение - Metadata Navigator, которое позволяет пользователям получать доступ к информации (репозитория) через Web-интерфейс.

Графических модулей четверо: Designer, Operator, Topology Manager и Security Manager. Эти модули могут быть установлены на любой графической платформе, которая поддерживает Java Virtual Machine 1.5 (J2SE), а это Windows, Linux, HP-UX, Solaris, AIX, Mac OS и другие.


Рисунок 1: Графические модули и репозиторий

  • Designer определяет декларативные правила (declarative rules) для преобразования данных и обеспечения их целостности (data integrity).

Вся разработка проекта происходит в этом модуле; именно здесь определяются и сюда импортируются метаданные баз данных и приложений. Модуль Designer использует метаданные и правила для генерации сценариев для производственной среды. Этот модуль является ключевым для разработчиков и администраторов метаданных;

  • Operator управляет и наблюдает за производственной средой. Он разработан для операторов этой среды и показывает журналы исполнения (execution logs) с подсчетом ошибок, числом обработанных строк, статистикой исполнения, кодом, который исполняется в данный момент, и так далее. На этапе проектирования (design time) разработчики могут использовать модуль Operator для целей отладки;
  • Topology Manager определяет физическую и логическую архитектуру инфраструктуры. Серверы, схемы и агенты регистрируются в главном (master) репозитории через этот модуль, как правило, администраторами инфраструктуры или проекта;
  • Security Manager управляет профилями пользователей и привилегиями их доступа. Security Manager также назначает привилегии доступа к объектам и функциям (features). Этот модуль обычно используется администраторами безопасности.

Все модули хранят свою информацию в централизованном репозитории.

Компоненты времени выполнения

Во время выполнения Scheduler Agent координирует исполнение сценариев.

Scheduler Agent может быть установлен на любой платформе, которая поддерживает Java Virtual Machine (J2SE), а это Windows, Linux, HP-UX, Solaris, IBM AIX, iSeries/AS400, zSeries/OS/390. Исполнение может быть запущено из одного из графических модулей либо встроенным обработчиком расписаний (built-in scheduler) либо внешним обработчиком расписаний (thirdparty scheduler).


Рисунок 2: Компоненты времен выполнения.

Репозиторий состоит из главного (или мастер-, master) репозитория и нескольких рабочих (work) репозиториев. Эти репозитории являются базами данных, управляемыми средствами реляционных СУБД. Все объекты, которые c применением модулей конфигурируются, разрабатываются или используются, хранятся в одном из этих репозиториев и доступны в режиме клиент-сервер для различных компонентов архитектуры.

Обычно есть один главный репозиторий, который содержит информацию о безопасности (пользовательские профили и привилегии), топологическую информацию (определения технологий и серверов) и версии объектов. Для ведения информации, хранимой в главном репозитории, используются Topology Manager и Security Manager. Все модули имеют доступ к главному репозиторию, так как все они сохраняют информацию о топологии и безопасности в нем.


Рисунок 3: Главный репозиторий и рабочие репозитории.

Объекты проектов хранятся в рабочих репозиториях. Несколько рабочих репозиториев могут сосуществовать на одной и той же установке. Это полезно для ведения отдельных сред или отображения особенных версий жизненного цикла - например, среды разработки (development), квалифицирования (qualification) и производственная среда.

  • Модели (Models) - включая области хранения данных (datastores), колонки (columns), ограничения целостности данных (data integrity constraints), перекрестные ссылки (cross references) и происхождение данных (data lineage);
  • Проекты (Projects) - включая декларативные правила, пакеты (packages), процедуры, папки, модули знаний (knowledge modules) и переменные (variables);
  • Информация времени выполнения (Runtime information) - включая сценарии, информацию расписаний и журналы.

Пользователи работают с контентом рабочего репозитория, используя модули Designer и Operator. Рабочие репозитории также доступны во время выполнения агентам.

Когда рабочий репозиторий используется только для хранения информации, необходимой для исполнения (как правило, это имеет место для производственных сред), он называется репозиторием исполнения (execution repository). Этот репозиторий жлступен во время выполнения агентам и через интерфейс модуля Operator. Важно помнить, что все рабочие репозитории всегда подсоединены к одному и только одному главному репозиторию.

Metadata Navigator (Навигатор метаданных ) - это приложение для среды Java 2 Enterprise Edition (J2EE), которое обеспечивает доступ через Web к репозиториям. Оно позволяет пользователям просматривать объекты, включая проекты, модели и журналы исполнения. Metadata Navigator может быть установлен на сервер приложений, такой как Oracle Container for Java (OC4J) или Apache Tomcat. Бизнес-пользователи, разработчики, операторы и администраторы могут использовать Metadata Navigator через Web-браузер. Через Web-интерфейс этого приложения пользователи могут увидеть карты потоков (flow maps), найти источники всех данных и даже "просверлиться" (drill down) до уровня показателя (field level), чтобы понять преобразования, используемые для построения этих данных. Они могут также запускать сценарии и следить за ними из Web-браузера через Metadata Navigator.


Рисунок 4: Используя Metadata Navigator, пользователи могут получать доступ к метаданным и выполнять их из Web-браузера.

Другие компоненты и функции

Oracle Data Integrator - это "легкая", свободная от атавизмов, совершенная интеграционная платформа. Все компоненты могут выполняться независимо на любой совместимой с Java системе.

Благодаря свой свободной от атавизмов архитектуре, Oracle Data Integrator устанавливается в течение минут на любой платформе.

О работе в Oracle Data Integrator (ODI) и других захватывающих вещах из мира BI.

  • О блоге
  • Поиск по ODI блогам
  • Инсталляция
  • Пожелания и ошибки
  • Патчи
  • Документация по ODI
  • ODI 11g FAQ
  • ODI Experts
  • BI-Quotient
  • John Goodwin

ODI 11g FAQ

Что такое Oracle Data Integrator (ODI)?
Oracle Data Integrator это всеобъемлющая интеграционная платформа, удовлетворяющая всем требованиям интеграции данных различных типов: от тяжелых, высокопроизводительных пакетных загрузок, до сложных событийных систем загрузки данных из разнородных источников и сервисов данных использующих SOA.

  • Проекты интеграции данных
  • Бизнес-аналитика и хранилища данных
  • Проекты по модернизации
  • Проекты по миграции и консолидации
  • Проекты с использованием SOA
  • Проекты по ведению НСИ (нормативно-справочная информация, MDM)

Данные каких технологических систем могут быть интегрированы с помощью ODI?
Список технологий для систем источников и приемников данных поддерживаемых Oracle Data Integrator включен в документ Системные требования для ODI и список поддерживаемых платформ.

Где можно найти документацию по Oracle Data Integrator?
Документация для ODI может быть найдена в библиотеке документации по платформе Oracle Fusion Middleware.

Доступна ли демо версия для Oracle Data Integrator?
Да, найти документ с описанием начала работы с ODI и загрузить демо версию можно со страницы Oracle Data Integrator на OTN.

Где скачать Oracle Data Integrator?
ODI 11g доступен для скачивания на странице OTN, а также на сайте eDelivery в разделе Oracle Fusion Middleware > Oracle Fusion Middleware 11g Media Pack.

Где скачать утилиту создания репозиториев (RCU)?
RCU 11.1.1.3.x может быть загружена со страницы загрузки Oracle Data Integrator на сайте OTN, а также с сайта eDelivery в разделе Oracle Fusion Middleware > Oracle Fusion Middleware 11g Media Pack.

Для моей платформы нет инсталлятора. Возможно ли проинсталлировать ODI вручную?
Да, дополнительный инсталляционный диск для Oracle Data Integrator содержит все файлы необходимые для проведения ручной инсталляции ODI. Процесс ручной инсталляции и необходимые конфигурационные шаги описаны в документации по Oracle Data Integrator.

Где найти информацию о принципах работы и архитектуре Oracle Data Integrator?
Эта информация доступна как часть документации, смотрите Введение в Oracle Data Integrator.

Где найти информацию о решениях с высокой надежностью для Oracle Data Integrator?
Вы можете найти эту информацию в документации - Fusion Middleware High Availability Guide.

Можно ли сделать апгрейд с предыдущих версий на версию ODI 11g?
Да, предыдущие версии могут быть обновлены на Oracle Data Integrator 11g. Детали находятся в документации ODI в документе Руководство по обновлению.

Где увидеть информацию о текущих клиентах и процессе внедрения ODI?
Вы можете найти эту информацию в документе Oracle Data Integration Successes.

Включает ли Oracle Data Integrator 11g также и WebLogic Server?
Нет, лицензия на Oracle Data Integrator 11g не включает в себя лицензию на WebLogic Server. Оба продукта должны инсталлироваться раздельно.

  • Oracle Data Integrator Enterprise Edition. Включает в себя объединение двух продуктов в одно предложение:
    • Oracle Data Integrator
    • Oracle Warehouse Builder

    ODI также встроен в некоторые другие продукты Oracle такие как Business Activity Monitoring, Complex Event Processing, Hyperion Planning, Hyperion Financial Management и т.п.

    Ссылки в блоге:
    Заметки с ярлыком Ликбез.
    А также описание курсов от компании РДТех

    Где найти адаптеры для приложений используемые в Oracle Data Integrator?
    Адаптеры приложений (модули знаний) можно найти в папке xml-reference на дополнительном инсталляционном диске ODI. Этот диск можно загрузить со страницы загрузки Oracle Data Integrator на OTN или с сайта eDelivery (Oracle Fusion Middleware > Oracle Fusion Middleware 11g Media Pack)

    Где находится список известных проблем и описания их решений?
    Проблемы и методы их решения для различных платформ описаны в документе Примечания к релизу в библиотеке по Oracle Fusion Middleware.

    Где найти список всех кодов ошибок для Oracle Data Integrator?
    Описание ошибок ODI можно найти в документе Справочник по ошибкам Oracle Fusion Middleware 11g.

    Ссылки в блоге:
    Также можно попробовать почитать этот блог, задать автору вопрос, или поискать информацию через страницу поиска, которая настроена на поиск по сайтам, связанным с ODI.

    Oracle Data Integration, Cloud, Spatial and Analytics (GoldenGate, ODI, Cloud, Spatial, Exadata)

    Поскольку многие компании вложились в Oracle Warehouse Builder, было принято решение не бросать его разработку, а произвести постепенное слияние продуктов. Об этом достаточно подробно написано в блоге Андрея Пивоварова.

    E-LT и ETL. Меняется ли смысл от перестановки букв?

    Об этих двух подходах написано много. Каждый из них имеет свои плюсы и минусы.

    Подход ETL подразумевает порядок выгрузку данных в stage область, преобразование там этих данных, а затем загрузку данных в хранилище. Этот подход стар как мир и имеет большое количество инструментов, которые его поддерживают. Разработка концепции ETL подразумевала, что ни источники данных, ни хранилище данных неспособные самостоятельно преобразовать данные к нужному виду.

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

    E-LT подход хорош тем, что в хранилище данных мы можем отследить, откуда появились данные, т.е. имеем как преобразованные (агрегированные, отобранные, трансформированные) данные, так и исходные. Кроме того, мы можем допускать пользователя к исходным данные с минимальной агрегацией, что дает нам возможность строить операционные витрины данных и операционный BI. Делается это за счет применения CDC технологий (GoldenGate, Streams, triggers). Подробнее о построении операционных BI можно посмотреть в моей презентации.

    Если краткое, то отличие операционного BI от стратегического можно выразить следующей таблицей:

    Если подвести итог, то у E-LT подхода есть следующие плюсы:

    • совмещение промежуточной stage области и хранилища не замедляет передачу данных для анализа, давая проводить анализ в реальном времени
    • для получения доступа к нижнему уровню детализации не требует подключения к исходным системам
    • E-LT системы позволяют использовать знания администраторов, т.е. не требуется изучать отдельный сложный продукт, который управляет stage областью.

    Наличие плюсов, подразумевает наличие минусов:

    • E-LT подход относительно нов и не все ETL инструменты поддерживают его;
    • E-LT подход опирается на функциональность СУБД, поэтому не является независимым и самодостаточным.

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

    Подход компании Oracle был изначально направлен именно на использование возможностей базы данных. По сути с приобретением компании Sunopsis у Oracle появился инструмент TETLT, т.е. инструмент, который трансформирует данные в том месте, где это наиболее эффективно.

    Архитектура ODI

    Для того, чтобы эффективно использовать ODI необходимо понимать архитектуру комплекса.

    image

    image

    Комбинация этих модулей и позволяет задать процесс переноса данных в хранилище.

    Заключение

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

    Для ODI разработан целый ряд knowledge-модулей, которые позволяют извлекать и загружать данные практически в любую базу данных и информационную систему.

    В следующих постах я более подробно расскажу об использовании Oracle Data Inetegrator для построения ETL-решений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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