ODI 12c, Часть 2.

Перевод второй части заметок Jérôme Françoisse о новшествах Oracle Data Integrator-а облачной версии 12c. Оригинал находится здесь. Использованы скриншоты из оригинальных заметок.

---

WebLogic Management Framework

Другое большое новшество в этом релизе это то, что инфраструктура управления WebLogic сервера используется для контроля агентов ODI вместо ранее использовавшегося OPMN сервера. Теперь агенты управляются тем же образом, что и остальные компоненты промежуточного ПО Fusion Middleware и для настройки используется специальный мастер - Fusion Middleware Configuration Wizzard.

ETL в картинках.

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

Доступ к собственному репозиторию из сценария.

Приветствую коллеги.

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

Кстати, для тех, кто пока не считает себя великим ODI гуру - крайне полезно будет пройти по всем записям этого блога за 2010 год, начиная прямо с июля месяца. Я уверен, вы найдете там массу интересного.

Пример был работающий, но его применимость была несколько ограниченной. Объясню почему. У нас на проекте настройка контекстов, например, DEV и TEST была, в основном, связана с взаимоувязкой физической схемы дев источника данных с физической схемой приемника данных опять же на дев сервере. Тоже самое касалось контекста TEST, где связывались между собой две физических схемы на том же сервере: тест-источник <-> тест приемник.

Что такое модули знаний реверса (RKM) и зачем они нужны?

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

Другими словами, то, что JDBC драйвер получить не может, модуль знаний реверса получить сможет. Должен смочь.

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

Не все то хорошо, что новая версия.

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

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

Попробуем пройтись по списку найденного.
Все это лучше было бы смотреть на видео, но, пока, до видео руки не дошли.

ODI 11g. Некоторые ограничения планов загрузки.

Продолжаем.

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

---

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

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

В примере ниже, мы загружаем две таблицы фактов. Факт 1 зависит от таблиц справочников 1 и 2, тогда как Факт 2 зависит только от таблицы Справочника 2.

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

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

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

Другая возможность, которой не хватает - это ограничение количества одновременно запущенных сессий. Например, у вас может быть 10 сценариев, выполняющихся параллельно, но СУБД ограничивает вас только пятью одновременными подключениями. И когда один из выполняющихся 5-ти сценариев завершится, необходимо запустить очередной сценарий на выполнение.

Так что мы пока остаемся на своем собственном варианте организации загрузки зависимых таблиц.

---

Рисунки я взял у автора, сам в этот раз не проверял как работают планы загрузки, так как никак не доберусь до инсталляции 11g.

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

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

Один сценарий ODI - одна сессия в СУБД Oracle.

Предыдущий пост, посвященный получению в переменную ODI результата выполнения некоторой PL/SQL процедуры через значение переменной модуля(Oracle package) натолкнул меня на мысль проверить, как этот механизм будет работать при одновременном выполнении нескольких сценариев.

Если исходить с точки зрения того, как механизм использования модулей реализован в СУБД Oracle, то получалось, что, в случае выделения каждому сценарию своей собственной сессии, для каждого сценария мы будем иметь отдельную область памяти, в которую конкретизируется (instantiated) модуль, и, таким образом, в каждом модуле мы получим свое значение переменной.

Добавляем keywords-ы к дочерним сессиям.

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

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

Для добавления тэгов к запускаемым сценариям необходимо выполнить следующие шаги:

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

Все - таки, при достаточно большом количестве сессий, которые необходимо проанализировать (проверить время выполнения, например), пользоваться клиентским приложением, даже с использованием кнопки Back, достаточно затратно по времени.

Хорошо, если у разработчика или администратора ETL процесса есть доступ на чтение из таблиц репозитория ODI.

Получение текста ошибки при неправильном выполнении любого объекта ODI внутри пакета

Сегодня хочу опубликовать перевод вот этой статьи, авторства Kshitiz Devendra и Cezar Santos, которая освещает вопрос получения текстов ошибок при выполнении сценариев.

-= Начало перевода =-
Когда мы имеем несколько интерфейсов, переменных и других объектов в дочернем сценарии, и когда, при этом, дочерний сценарий завершается с ошибкой, в главном сценарии нам возвращается ошибка: "Сценарий не завершился должным образом". Чтобы узнать, что произошло, нам необходимо смотреть в Оператор.