Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Войти как пользователь
Вы можете войти на сайт, если вы зарегистрированы на одном из этих сервисов:

DOCFLOW - теория и практика электронного документооборота. Все о ECM и СЭД (системы электронного документооборота), ЭП

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

Антон Шмаков — старший консультант-разработчик

Консалтинговая группа «Борлас» (Москва)

Публикуется по оригиналу на сайте компании «Борлас»

В конце 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-сервера (и необходимости подготовки и содержания специалистов по нему).

Следует также упомянуть и технологию интеграции корпоративных приложений (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).

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. Важно отметить, что хотя планировщик может действовать как «двигатель» преобразований, он редко используется с этой целью.

Репозитории

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

Объекты проектов хранятся в рабочих репозиториях. Несколько рабочих репозиториев могут сосуществовать на одной и той же установке. Это полезно для ведения отдельных сред или отображения особенных версий жизненного цикла — например, среды разработки (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.

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

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.

Поделиться:


Тэги: Web 2.0


КАЛЕНДАРЬ
ПОСЛЕДНИЕ НОВОСТИ
21.06.2019
TESSA 3.3 – новые горизонты СЭД
Компания Syntellect объявила о выпуске официального релиза СЭД TESSA версии 3.3.
В новой версии платформы расширены возможности легкого клиента, обеспечена поддержка разных часовых зон и внесено более сотни других улучшений.

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

28.03.2019
В ожидании цифрового прорыва
Как выбраться из «колеи», в которой, согласно институциональной теории, движется, увязнув всеми колесами, Россия? Ответ на этот вопрос эксперты ищут не первый год. Вряд ли есть одно решение, но, возможно, в этом стране помогут технологии: отечественная математическая школа всегда высоко ценилась во всем мире, да и IT-отрасль в России развита сильнее прочих. Во всяком случае, именно на их развитие делают ставку власти: от направления «Цифровые технологии» нацпроекта «Цифровая экономика» они ждут настоящего прорыва. Впрочем, его успех, по мнению экспертов, будет зависеть от синхронизации процесса цифровой трансформации во всех российских регионах.