В конце 2006 года корпорация Oracle купила компанию Sunopsis и естественным образом продукты вновь приобретенного актива стали являться ИТ-общественности под брендом Oracle и новыми названиями. Так появился и «новый» интеграционный продукт Oracle Data Integrator, ранее известный как Sunopsis Data Conductor. В этой статье мы рассмотрим архитектуру, основные функции и возможности этого продукта, пока малоизвестного российским специалистам.
Введение
Компания Sunopsis, основанная в 1998 году во Франции Аланом Думасом, ориентировалась в первую очередь на создание инструментов для интеграции данных и приложений в гетерогенных средах. Она завоевала лидерство в этой области и явилась, по сути, основоположником нового подхода к интеграции данных - ELT (Extract, Load-Transform; Извлечь, Загрузить-Преобразовать), который пришел на смену традиционному подходу - ETL (Extract, Transform-Load; Извлечь, Преобразовать-Загрузить).
Oracle Data Integrator (ODI) был включен корпорацией Oracle в семейство продуктов промежуточного слоя Oracle Fusion Middleware. ODI представлен специалистам как ключевой инструмент интеграции различных источников данных в корпоративной ИТ-среде, предназначенный для решения таких задач как создание хранилищ данных, консолидация и синхронизация приложений, управление мастер-данными (MDM - Master Data Management), мониторинга активности бизнеса (BAM - Business Activity Monitoring) и т. д. Главная особенность этого продукта заключается в возможности извлекать данные из разнородных источников и загружать их также в разнородные базы данных. При этом поддержка большого числа источников возможна именно благодаря его ELT-архитектуре, когда все преобразования данных выполняются либо на стороне источника, либо на стороне получателя, а также благодаря тому, что ODI позволяет разделять схемы отображения или мэппинга данных (data mappings) на бизнес-правила (business rules) и специфические для платформ и процессов загрузки (platform/load-type specifics) части. Также возможности продукта расширяемы благодаря поддержке модулей знаний (knowledge modules), которые позволяют хранить специфические конструкции - SQL-шаблоны, выполняющие определенные функции.
История ELT
Построение любого крупного ИТ-решения является сложной и серьезной задачей и для его реализации необходимо выбрать подходящие технологии и инструменты. Практически всегда в таком решении присутствует в той или иной степени интеграция данных и/или построение «хранилища данных» в широком смысле. Для решения этой задачи рядом компаний были предложены специальные продукты, определенные как ETL-сервер. Этот сервер извлекает информацию из всевозможных источников - баз данных, офисных систем, файлов и т. д., преобразует ее и загружает в хранилище данных, то есть реализует ETL-подход к интеграции данных.
К основным недостаткам этого подхода можно отнести достаточно низкую производительность из-за обработки данных «строка за строкой» и общую высокую стоимость решения, которая складывается из затрат на аппаратное и программное обеспечение, стоимости разработки ETL-процессов и сложности обучения специалистов. Однако с ростом производительности и возможностей СУБД акцент в преобразовании данных все более смещался в сторону серверов СУБД. Возможности языка SQL и его расширений кардинально выросли за последние 20 лет и современные СУБД могут быть отличными платформами для решения самых сложных задач интеграции данных. Все это создало предпосылки для появления нового подхода к интеграции данных - ELT, когда данные извлекаются из источников, загружаются в результирующие базы данных и уже там, «на месте», средствами СУБД преобразуются. Главными преимуществами такого подхода являются более высокая производительность всего процесса интеграции данных, тогда как архитектура этого процесса получается более простой из-за отсутствия ETL-сервера, а общая стоимость снижается, опять таки прежде всего из-за отсутствия ETL-сервера (и необходимости подготовки и содержания специалистов по нему).
Рисунок 1. Схемы интеграции данных по ETL и ELT.
Следует также упомянуть и технологию интеграции корпоративных приложений (EAI, Enterprise Application Integration). Поначалу EAI и интеграция данных с ETL-подходом занимали разные ниши, каждая решала свои задачи. Однако со временем, в том числе с появлением ELT, обе эти технологии значительно сблизились. В современных ELT-продуктах появилась поддержка web-сервисов, очередей сообщений и многих других «чисто» EAI-функций. Наметилась тенденция создания единых интеграционных систем, которые используют всю мощь задействованных технологий интеграции. Эта тенденция во многом стала возможной благодаря принятию общих стандартов. Постепенно рынок интеграции становится более систематизированным и логичным.
Архитектура Oracle Data Integrator
Продукт ODI, являясь родоначальником ELT-подхода, сам не производит преобразований данных. Вместо этого он хранит только метаописания преобразований, по которым генерирует оптимизированный код в диалекте языка SQL (или его расширений - PL/SQL, T-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-управление.
Графические компоненты
Теперь посмотрим на то, какие графические модули входят в состав нового решения и какие функции они выполняют. Их всего четыре: дизайнер (designer), оператор (operator), топология (topology manager) и безопасность (security manager).
Рисунок 2. Графические компоненты и репозиторий ODI.
- Designer определяет декларативные правила (declarative rules) для преобразования данных и обеспечения их целостности (data integrity). Именно здесь проявляется оригинальность подхода в мэппинге данных, когда происходит разделение правил трансформации (transformation rules) и интеграции данных (data integrity), то есть четко разделяются бизнес-правило «что делать» и имплементация этого правила - «как делать». Вся разработка проекта происходит в этом модуле, именно здесь определяются и импортируются метаданные баз данных и приложений. Дизайнер использует метаданные и правила генерации сценариев для производственной среды. Этот модуль является ключевым для разработчиков и администраторов метаданных. Следует отметить, что единый репозиторий метаданных и оригинальный инструментарий мэппинга данных позволяют многократно использовать процессы преобразования и проверки данных. Можно отдельно хранить бизнес-правила, которые могут быть одним и теми же для разных баз данных и их конкретные имплементации, учитывающие особенности источника информации. Получается, что конкретные особенности базы данных проявляются на более поздних этапах разработки и в какой-то степени они отвязаны от бизнес-логики процесса интеграции. В целом такой подход проявляется во многих системах, когда создаются шаблоны преобразований и составные операторы, которые потом применяются последовательно друг над другом, постепенно усложняя логику работы.
- Operator управляет и наблюдает за производственной средой. Он разработан для администраторов системы и показывает журналы исполнения (execution logs) с подсчетом ошибок, выводом типов ошибок, числом отработанных строк, статистикой исполнения, кодом, который исполняется в данных момент, и так далее. На этапе проектирования разработчики могут использовать его для целевой отладки.
- Topology manager определяет физическую и логическую архитектуру инфраструктуры. Серверы, схемы и агенты регистрируются в главном (master) репозитории через этот модуль. Такой принцип работы отражает описанный выше принцип разделения логики и конкретной имплементации процедур обработки.
- Security manager управляет профилями пользователей и привилегиями их доступа, он также назначает привилегии доступа к объектам и функциям.
Компоненты времени выполнения
К компонентам времени выполнения относится планировщик (Scheduler Agent), который координирует исполнение сценариев. Исполнение может быть запущено одним из графических модулей, либо встроенным обработчиком расписаний (build-in sheduler), либо внешним обработчиком расписаний (third-party scheduler). В рамках архитектуры E-LT планировщик редко выполняет какие-либо преобразования. Он выбирает код из репозитория исполнения (execution repository) и затем запрашивает серверы баз данных, операционные системы. Когда исполнение завершено, планировщик изменяет журналы исполнения (execution logs) в репозитории и затем формирует отчеты с сообщениями об ошибках и статистикой исполнения. Пользователи могут просматривать журналы исполнения из модуля, Operator или Web-интерфейса Metadata Navigator. Важно отметить, что хотя планировщик может действовать как «двигатель» преобразований, он редко используется с этой целью.
Рисунок 3. Компоненты времени выполнения.
Репозитории
Архитектура репозиториев ODI построена следующим образом: существует главный (или мастер) репозиторий и несколько рабочих. Эти репозитории размещаются в произвольной базе данных, поддерживающей стандарт ISO-92. Все объекты, которые с применением модулей конфигурируются, разрабатываются или используются, хранятся в одном из этих репозиториев и доступны в режиме клиент-сервер для различных компонентов архитектуры. Главный репозиторий содержит информацию в целом о системе: о безопасности (пользовательские профили и привилегии), топологическую информацию (определения технологий и серверов) и версии объектов. Для ведения информации, хранимой в главном репозитории, используются Topology Manager и Security Manager.
Рисунок 4. Репозитории ODI.
Объекты проектов хранятся в рабочих репозиториях. Несколько рабочих репозиториев могут сосуществовать на одной и той же установке. Это полезно для ведения отдельных сред или отображения особенных версий жизненного цикла - например, среды разработки (development), квалифицирования (qualification) и производства.
Рабочий репозиторий хранит информацию по следующим объектам
- Модели (Models) - включая области хранения данных (datastores), колонки (columns), ограничения целостности данных (data integrity constraints), перекрестные ссылки (cross references) и происхождение данных (data lineage);
- Проекты (Projects) - включая декларативные правила, пакеты (packages), процедуры, папки, модули знаний (knowledge modules) и переменные (variables);
- Информация времени выполнения (Runtime information) - включая сценарии, информацию расписаний и журналы.
Metadata Navigator
Metadata Navigator - это приложение для среды Java 2 Enterprise Edition (J2EE), которое обеспечивает доступ через Web к репозиториям. Оно позволяет пользователям просматривать объекты, включая проекты, модели и журналы исполнения. Metadata Navigator может быть установлен на любой сервер приложений, поддерживающий J2EE, например Oracle Container for Java (OC4J) или Apache Tomcat. Бизнес-пользователи, разработчики, операторы и администраторы могут использовать Metadata Navigator через Web-браузер. Через Web-интерфейс этого приложения пользователи могут увидеть карты потоков (flow maps), найти источники всех данных и даже «опуститься» (drill down) до исходного уровня (field level), чтобы понять преобразования, используемые для построения этих данных. Они могут также запускать сценарии и следить за ними из Web-браузера через 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) для внедрения асинхронной, управляемой событиями (eventdriven) интеграционной архитектур
Заключение
В целом Oracle Data Integrator производит положительное впечатление. Его основные плюсы - архитектура ELT и мощный и эффективный движок генерации кода для преобразования данных, оригинальный инструментарий управления бизнес-правилами, поддержка большого числа источников, включая JMS-очереди, Web-сервисы, XML-файлы, мощный и удобный интерфейс. Все это выгодно выделяет его среди других подобных средств. Этот продукт могут использовать практически все разработчики, независимо от СУБД, с которыми они работают.
Что же касается Oracle, то наличие такого продукта, как ODI, позволит корпорации предложить своим клиентам полный спектр инструментов для интеграции данных и приложений. «Старый» же продукт Oracle класса ETL - Oracle Warehouse Builder - теперь занимает нишу инструментов для интеграции данных исключительно в среде СУБД Oracle.