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

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

Итак, представьте себе, что на одном из проектов получилось так, что часть ETL разрабатывалась другой командой, и, по несчастливой случайности, оказалось, что настройки технологии Oracle у этих двух команд отличались.

Отличались они в одной не очень большой, но весьма важной, части, которая описывает правила задания порядка соединения нескольких таблиц. Ниже, на рисунке, можно увидеть три варианта, которые существуют в 10 версии ODI для технологии Oracle. Собственно, эти три варианта могут быть настроены для любой технологии, которая поддерживает работу с данными через использование команд Select и Where.

В версии ODI 11g этот момент изменили, так что теперь выбор у нас несколько расширился, судя по следующему рисунку:

Итак, напомню, было два раздельных проекта, в одном из которых технология Oracle использовала Not-ordered режим, а во-втором, соответственно, совсем даже наоборот, самый что ни есть Ordered.

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

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

Посмотрим для начала на то, как выглядит неупорядоченный вариант на диаграмме интерфейса:

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

Результирующий запрос выглядит следующим образом:

...
FROM db_snpm.dbo.SNP_USER as SNP_USER, db_snpm.dbo.SNP_MTXT as SNP_MTXT, db_snpm.dbo.SNP_OPEN_TOOL as SNP_OPEN_TOOL, db_snpm.dbo.SNP_SOLUTION as SNP_SOLUTION, db_snpm.dbo.SNP_LOOKUP as SNP_LOOKUP
WHERE (1=1)
AND (SNP_USER.PASS = SNP_MTXT.ENC_KEY)
AND (SNP_MTXT.I_TXT = SNP_OPEN_TOOL.I_TXT_CLASS_NAME)
AND (SNP_SOLUTION.EXT_VERSION=SNP_LOOKUP.I_LOOKUP)
AND (SNP_MTXT.I_TXT_ORIG=SNP_SOLUTION.SOL_NAME)

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

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

Результирующий запрос с использованием Ordered Join выглядит так:

...
FROM (db_snpm.dbo.SNP_MTXT as SNP_MTXT INNER JOIN db_snpm.dbo.SNP_SOLUTION as SNP_SOLUTION ON SNP_MTXT.I_TXT_ORIG = SNP_SOLUTION.SOL_NAME) INNER JOIN db_snpm.dbo.SNP_LOOKUP as SNP_LOOKUP ON SNP_SOLUTION.EXT_VERSION=SNP_LOOKUP.I_LOOKUP, db_snpm.dbo.SNP_USER as SNP_USER, db_snpm.dbo.SNP_OPEN_TOOL as SNP_OPEN_TOOL
WHERE (1=1)
AND (SNP_USER.PASS = SNP_MTXT.ENC_KEY)
AND (SNP_MTXT.I_TXT = SNP_OPEN_TOOL.I_TXT_CLASS_NAME)

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

Не совсем понятно описал, я попробую привести еще один пример. Итак, на следующем слайде видно, что все таблицы соединяются между собой упорядоченными соединениями.

Последовательность соединения - 4я и 5я таблицы, затем результат соединяется с третьей таблицей, результат предыдущего с таблицей номер 1 и, в конце концов, все это соединяется с таблицей номер 2.

Посмотрим, какой SQL код получился в итоге:

...
FROM (db_snpm.dbo.SNP_USER as SNP_USER INNER JOIN (db_snpm.dbo.SNP_MTXT as SNP_MTXT INNER JOIN (db_snpm.dbo.SNP_SOLUTION as SNP_SOLUTION INNER JOIN db_snpm.dbo.SNP_LOOKUP as SNP_LOOKUP ON SNP_SOLUTION.EXT_VERSION = SNP_LOOKUP.I_LOOKUP) ON SNP_MTXT.I_TXT_ORIG = SNP_SOLUTION.SOL_NAME) ON SNP_USER.PASS = SNP_MTXT.ENC_KEY) INNER JOIN db_snpm.dbo.SNP_OPEN_TOOL as SNP_OPEN_TOOL ON SNP_MTXT.I_TXT = SNP_OPEN_TOOL.I_TXT_CLASS_NAME
WHERE (1=1)

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

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

Они сделали ...


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

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

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

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

При этом все объекты, которыми оперирует разработчик ETL, все интерфейсы, пакеты, процедуры, функции, модели и модули знаний физически размещались в одном рабочем репозитории.

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

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

Вот такая вот получилась длинная история. Потому-то и название такое было. Соответствующее.

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