понедельник, 15 ноября 2010 г.

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

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


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

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

Распространенные ошибки:
  • Слишком много модулей знаний: Типичный проект использует не более 5 модулей!
  • Использование жестко заданных наименований серверов или схем СУБД: вместо этого вы должны использовать методы подстановки getTable(), getTargetTable(), getObjectName() и т.п.
  • Использование переменных в модуле знаний: лучше использовать опции или настраиваемые поля, чтобы получать информацию из интерфейса или модели, в которой применяется ваш модуль знаний.
  • Написание модуля полностью на Jython или Java: так стоит делать только если это единственно возможное решение. SQL намного проще для понимания и поддержки.
  • Избегайте использования условного выполнения в шаге модуля знаний (команда <%if%>), вместо нее используйте условное выполнение через опции модуля знаний.

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

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

Комментариев нет:

Отправить комментарий

Примечание. Отправлять комментарии могут только участники этого блога.