Одна из самых главных рекомендаций при разработке своих собственных модулей знаний заключаются в том, что вам никогда не нужно начинать разработку с нуля. 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 процесса, которая будет применяться во многих преобразованиях. И в ней необходимо быть полностью уверенным.
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.