Oracle Data Integrator — интеграция по-новому

В конце 2006 г. корпорация Oracle купила компанию Sunopsis, после чего естественным образом продукты вновь приобретенного актива стали представляться ИТ-общественности под брэндом Oracle и новыми названиями. Так появился на рынке и «новый» интеграционный продукт Oracle Data Integrator, ранее известный как Sunopsis Data Conductor. В этой статье мы рассмотрим архитектуру, основные функции и возможности этого продукта, пока малоизвестного российским специалистам.

Компания Sunopsis, основанная в 1998 г. во Франции Аланом Думасом, ориентировалась в первую очередь на создание инструментов для интеграции данных и приложений в гетерогенных средах. Завоевав лидерство в этой области, она стала, по сути, основоположником нового подхода к интеграции данных — ELT (Extract, Load, Transform — извлечь, загрузить, преобразовать), который пришел на смену традиционному подходу ETL (Extract, Transform, Load — извлечь, преобразовать, загрузить).

Корпорация Oracle включила Oracle Data Integrator (ODI) в семейство продуктов промежуточного слоя Oracle Fusion Middleware, представив его специалистам как ключевой инструмент интеграции различных источников данных в корпоративной ИТ-среде, предназначенный для решения таких задач, как создание хранилищ данных, консолидация и синхронизация приложений, управление мастер-данными (Master Data Management, MDM), мониторинг активности бизнеса (Business Activity Monitoring, BAM) и т. д.

Главная особенность ODI — возможность извлекать данные из разнородных источников и загружать их в разнородные же базы данных. Поддержка большого числа источников обеспечивается именно за счет ELT-архитектуры продукта, когда все преобразования данных выполняются либо на стороне источника, либо на стороне получателя, а также благодаря тому, что ODI позволяет разделять схемы отображения, или мэппинга данных (data mappings) на бизнес-правила (business rules) и специфические для платформ и процессов загрузки (platform/load-type specific) части. Кроме того, возможности продукта расширяются за счет поддержки модулей знаний (knowledge modules), позволяющих хранить специфические конструкции — SQL-шаблоны, выполняющие определенные функции.

История ELT

Построение любого крупного ИТ-решения — серьезная задача, и для ее реализации необходимо выбрать подходящие технологии и инструменты. Практически всегда в таком решении в той или иной степени присутствует интеграция данных и/или построение «хранилища данных» (в широком смысле). Для этих целей ряд компаний предлагает специальные продукты, определенные как ETL-сервер. Этот сервер извлекает информацию из всевозможных источников — баз данных, офисных систем, файлов и т. д., преобразует ее и загружает в хранилище данных, т. е. реализует ETL-подход к интеграции.

К основным недостаткам этого подхода относят довольно низкую производительность из-за обработки данных «строка за строкой» и общую высокую стоимость решения, которая складывается из затрат на аппаратное и программное обеспечение, стоимости разработки ETL-процессов и обучения специалистов.

Однако с ростом производительности и расширением возможностей СУБД акцент в преобразовании данных стал смещаться в сторону серверов СУБД. Возможности языка SQL и его расширений за последние 20 лет кардинально выросли, и современные СУБД служат отличными платформами для решения самых сложных задач интеграции данных. Все это создало предпосылки для появления нового подхода к интеграции данных — ELT, в соответствии с которым данные извлекаются из источников, загружаются в результирующие базы данных и уже там, «на месте», преобразуются средствами СУБД. Главные преимущества такого подхода — более высокая производительность всего процесса интеграции данных, при том что архитектура этого процесса из-за отсутствия ETL-сервера получается более простой, а общая стоимость снижается — опять-таки по причине отсутствия ETL-сервера и, следовательно, необходимости подготовки и содержания специалистов по нему.

Рис. 1. Схемы интеграции данных — подход ETL и ELT.

Следует также упомянуть технологию интеграции корпоративных приложений (Enterprise Application Integration, EAI). Поначалу EAI и интеграция данных с ETL-подходом занимали разные ниши, решая каждая свои задачи. Однако позже, в том числе с появлением ELT, обе эти технологии заметно сблизились. В современных ELT-продуктах появилась поддержка Web-сервисов, очередей сообщений и многих других функций, относимых ранее к «чистой» EAI. Наметилась тенденция создания единых интеграционных систем, которые используют всю мощь задействованных технологий интеграции. Эта тенденция во многом стала возможной благодаря принятию общих стандартов. Таким образом, постепенно рынок интеграции становится более систематизированным и логичным.

Архитектура Oracle Data Integrator

Продукт ODI, будучи родоначальником ELT-подхода, сам не проводит преобразований данных; вместо этого он хранит только метаописания преобразований, по которым генерирует оптимизированный код в диалекте языка SQL (или его расширений — PL/SQL, T-SQL и т. д.) конкретного источника/получателя данных. При этом используются все возможности и особенности языка SQL для построения быстрого и эффективного кода, создаются условия для того, чтобы ELT-процессы выполнялись в пакетном режиме, выполняется распараллеливание обработки данных и обеспечивается автоматическая проверка их качества. Отметим, что ODI не использует промежуточного слоя для преобразования данных, т. е. область обработки данных (staging area) может находиться в базе данных как источника, так и получателя.

Продукт ODI работает в разнородных средах и поддерживает широкий набор источников, включая различные реляционные базы данных, бизнес-приложения, плоские файлы, XML-файлы, JMS-очереди, многомерные базы данных и многое другое. Он состоит из нескольких компонентов, работающих с единым централизованным репозиторием метаданных (metadata repository). Эти компоненты — графические модули (graphical modules), компоненты времени выполнения (runtime components) и Web-интерфейс — вместе с другими развитыми функциями делают его «легкой» интеграционной платформой.

Ядро архитектуры ODI — модульный репозиторий, который доступен компонентам, графическим модулям и агентам исполнения (execution agents), целиком написанным на Java, в режиме клиент-сервер. ODI представляет собой «чистое» Java-приложение, работающее на любой платформе, которая поддерживает JVM 1.5 (J2SE), включая такие популярные системы, как Windows, Linux, HP-UX, Solaris, AIX, Mac OS и другие. Кроме того, архитектура ODI включает Web-приложение Metadata Navigator, с помощью которого можно получать доступ к информации, в том числе к репозиторию, через Web-интерфейс. Это позволяет проводить аудит, контроль и администрирование всего процесса загрузок данных, а также обеспечивает runtime-управление.

Графические компоненты

В состав нового решения входят четыре графических модуля (рис. 2): Designer (дизайнер), Operator (оператор), Topology manager (топология) и Security manager (безопасность).

Рис. 2. Графические компоненты и репозиторий ODI.

Designer определяет декларативные правила (declarative rules) для преобразования данных и обеспечения их целостности (data integrity). Именно здесь проявляется оригинальность подхода — в мэппинге данных, когда происходит разделение правил трансформации (transformation rules) и интеграции данных (data integrity), т. е. четко разделяются бизнес-правило — «что делать» и имплементация этого правила — «как делать».

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

Operator наблюдает за производственной средой и управляет ею. Он предназначен для администраторов системы и показывает журналы исполнения (execution logs) с подсчетом ошибок, выводом типов ошибок, числом отработанных строк, статистикой исполнения, кодом, который исполняется в данный момент, и т. д. На этапе проектирования разработчики могут использовать его для целевой отладки.

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

Security manager управляет профилями пользователей и привилегиями их доступа; он также назначает привилегии доступа к объектам и функциям.

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

К компонентам времени выполнения относится планировщик (Scheduler Agent), который координирует исполнение сценариев (рис. 3). Исполнение может быть запущено одним из графических модулей, либо встроенным обработчиком расписаний (build-in sheduler), либо внешним обработчиком расписаний (third-party scheduler). В рамках архитектуры ELT планировщик редко выполняет какие-либо преобразования. Он выбирает код из репозитория исполнения (execution repository) и затем запрашивает серверы баз данных и ОС. Когда исполнение завершено, планировщик изменяет журналы исполнения (execution logs) в репозитории и затем формирует отчеты с сообщениями об ошибках и статистикой исполнения. Пользователи могут просматривать журналы исполнения из модуля Operator или Web-интерфейса Metadata Navigator. Важно отметить, что хотя планировщик может действовать как «двигатель» преобразований, он редко используется в этом качестве.

Рис. 3. Компоненты времени выполнения.

Репозитории

Архитектурно репозитории ODI (рис. 4) построены следующим образом: существует главный, или мастер-репозиторий, и несколько рабочих. Эти репозитории размещаются в произвольной базе данных, поддерживающей стандарт ISO-92. Все объекты, которые конфигурируются, разрабатываются или используются с помощью модулей, хранятся в одном из этих репозиториев и доступны в режиме клиент-сервер для различных компонентов архитектуры. Главный репозиторий содержит информацию о системе в целом: сведения о безопасности (пользовательские профили и привилегии), топологическую информацию (определения технологий и серверов) и версии объектов. Для ведения информации, хранимой в главном репозитории, используются Topology Manager и Security Manager.

Рис. 4. Репозитории ODI.

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

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

Metadata Navigator

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

Рис. 5. Взаимодействие пользователя с компонентами ODI.

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

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

Модули знаний (Knowledge modules) позволяют легко и быстро интегрировать технологии, базы данных и приложения. Они доступны для широкого диапазона платформ, включая Oracle, Teradata, Sybase IQ, Netezza, SAP/R3, Oracle Applications, Siebel, LDAP и XML.

Функция Advanced Parallel Option with Load Balancing, продвинутый параллельный режим с балансировкой загрузки, обеспечивает автоматическую обработку больших объемов данных с балансировкой рабочей загрузки между несколькими агентами.

Средство управления версиями (Advanced version management) предоставляет интерфейс для ведения, обеспечения защиты, периодических пересмотров (replicate revisions) фрагментов работы (units of work) даже в крупнейших средах разработки.

Функция Common Format Designer (CFD) позволяет быстро проектировать или собирать модель данных из других моделей данных и затем автоматически генерировать процессы загрузки и извлечения данных для этой модели. Пользователи могут, к примеру, применять Common Format Designer для создания операционных складов данных (operational datastores), витрин данных (datamarts) или мастер-данных (master data) канонического формата путем объединения разнородных источников. Эта функция также подходит для проектирования модели хранилища данных, например, по схеме «звезда» (Star), «снежинка» (Snowflake Schema), 3NF-схеме.

Функция Publish and Subscribe Changed Data Capture (CDC) отслеживает изменения в данных в источниках и сокращает объем обрабатываемых данных, выбирая (для обработки) только измененные данные.

Функция Publish and Subscribe Messaging обеспечивает использование ПО обработки сообщений промежуточного слоя (message-oriented middleware, MOM) для внедрения асинхронной, управляемой событиями интеграционной архитектуры.

***

В целом основные плюсы Oracle Data Integrator — архитектура ELT и мощный и эффективный движок генерации кода для преобразования данных, оригинальный инструментарий управления бизнес-правилами, поддержка большого числа источников (включая JMS-очереди, Web-сервисы, XML-файлы), мощный и удобный интерфейс. Все это выгодно выделяет ODI среди других подобных средств. Этот продукт могут использовать практически все разработчики, независимо от того, с какими СУБД они имеют дело.

Что же касается Oracle, то наличие такого продукта, как ODI, позволит корпорации предложить своим клиентам полный спектр инструментов для интеграции данных и приложений. «Старый» же продукт Oracle класса ETL — Oracle Warehouse Builder — теперь занимает нишу инструментов для интеграции данных исключительно в среде СУБД Oracle.