Как разрабатывать свои модули знаний в ODI.

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

Одна из самых главных рекомендаций при разработке своих собственных модулей знаний заключаются в том, что вам никогда не нужно начинать разработку с нуля. Oracle Data Integrator поставляется с более чем сотней готовых модулей знаний. Поэтому рекомендуется ознакомиться с этими модулями знаний, даже если они и не написаны для вашей технологии. Чем больше у вас будет примеров, тем быстрее вы напишете свой собственный код.

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

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

Как напоминание:

LKMs созданы для загрузки данных из удаленных источников данных в область стейдж (в "C$" таблицы).
IKMs применяются для переноса (загрузки, интеграции) данных из стейдж области в целевую таблицу. Они берут данные из "C$" таблиц, преобразуют и соединяют их друг с другом и кладут результат в одну флоу таблицу ("I$"). Также эти модули знаний могут вызывать CKM модуль для проверки "I$" таблицы. Затем, этот модуль знаний записывает данные в целевую таблицу.
CKMs проверяют качество данных в модели или флоу таблице ("I$") исходя из заданных ограничений. Отклоненные строки сохраняются в таблице ошибок ("E$").
, используя при этом временные таблицы SNP_REV_xx.
JKMs ответственны за создание обвязки, занимающейся отслеживанием изменений данных в модели (Change Data Capture).

Распространенные ошибки:

Слишком много модулей знаний: Типичный проект использует не более 5 модулей!

Использование жестко заданных наименований серверов или схем СУБД: вместо этого вы должны использовать методы подстановки getTable(), getTargetTable(), getObjectName() и т.п.

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

Написание модуля полностью на Jython или Java: так стоит делать только если это единственно возможное решение. SQL намного проще для понимания и поддержки.

Избегайте использования условного выполнения в шаге модуля знаний (команда <%if%>), вместо нее используйте условное выполнение через опции модуля знаний.

Другие рекомендации, применимые к разработке модулей знаний:

Код должен иметь корректные отступы.

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

Ключевые слова SQL, такие как "select", "insert", и т.д. должны быть написаны в нижнем регистре для лучшей читабельности.

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

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

< Предыдущая		Следующая >

DeepEdit!

Как разрабатывать свои модули знаний в ODI.

Популярные