Многотабличность интерфейсов ODI.

Один из поисковых запросов, по которым попал в этот блог кто-то из наших коллег, звучал так - odi многотабличные интерфейсы.

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

Если порассуждать, какие могут быть варианты многотабличности? Я вот приведу несколько возможных вариантов.

Один маппинг - несколько целевых таблиц. Примерно так, как происходит у меня на текущем проекте с использованием OWB. Что это дает помимо того, что с первого взгляда не разберешься из какого места поток данных начинает идти, и в какое место он приходит?

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

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

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

Потери производительности в этом случае заключаются в том, что преобразованные данные будут один раз записываться на диск, затем читаться из временной таблицы в память СУБД дважды, и дважды же писаться на диск в целевые таблицы. В случае же использования ETL средств стандартной архитектуры (Информатика), преобразованные данные будут находиться в памяти ETL сервера, и лишь дважды будут записываться в целевые таблицы.

Итого имеем экономию в одну запись в СУБД и два чтения. Но тут необходимо учитывать следующие моменты:

1. Не для всех задач возможно выделить столько свободной памяти на ETL сервере чтобы уместить в ней большие объемы временно преобразованных данных.
2. Скорость передачи, т.е. занесения данных в целевые таблицы, с другого сервера наверняка будет ниже, чем скорость занесения данных из памяти СУБД в память на диск.
3. Удобство отладки. В случае временных таблиц ODI мы имеем возможность проверить всю совокупность данных во временной таблице в случае каких-либо ошибок, и этот подход может быть более удобен чем построчная отладка процесса ETL в Информатике.

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

Именно такой пример мы рассматривали на курсах по Информатике. При этом, например, таблица для вставки, обновления или удаления была, скорее всего, одна, а таблица для сохранения отклоненных строк - другая.

Но, на самом деле, ODI исповедует практически тот же подход. И, в действительности, интерфейсы ODI являются многотабличными, так как кроме целевой таблицы интерфейс также взаимодействует со временной (I$_) таблицей, которая используется, в большинстве стандартных модулей знаний, как раз для разделения множества строк на те, которые необходимо добавить (Insert), изменить (Update), удалить (Delete) или отклонить (Reject).

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

Также шаги по вставке-изменению могут быть в модуле знаний как разделены на обособленные этапы, когда в СУБД будут посылаться две команды, одна на Insert, вторая на Update, так и объединены, когда СУБД поддерживает какой-то вариант команды MERGE.

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

Ну и последняя мысль по этому поводу. Если все же делать интерфейсы ODI многотабличными, когда и как это реализовывать?

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

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

Ну и делались все эти дополнительные настройки путем модификации существующих стандартных модулей знаний.

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

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

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

Вот примерно такие идеи пришли в голову. Многое я слишком упростил, так что, если есть что рассказать по этому поводу - милости просим в комментарии.

Ссылки в блоге:
Один из вариантов организации обратной идеи, когда разные интерфейсы загружают данные в одну и ту же таблицу из разных источников.