Привет всем Хаброрезидентам!

Открываем блог компании РДТЕХ первым постом с лайф-хаками для разработчиков. Надеемся, что кто-нибудь из читателей ими воспользуется.

Лайф-хаки были придуманы в ходе работы над проектом по переливке данных из одной системы в другую для последующего построения отчётов в одном из ведущих банков РФ.

Используемые технологии:

Система источник данных – RDBMS Oracle (версия 11.2.0.4.0)
Система приёмник данных – RDBMS Oracle (версия 11.2.0.4.0)
Интеграционная шина – Informatica (версия 10.1.1)

В ходе реализации крупного интеграционного проекта мы столкнулись со следующими проблемами:

1. Неэффективное использование SQ [Source Qualifier] в Informatica Power Center

При использовании SQ [Source Qualifier] в Informatica Power Center выявилось ограничение на количество вводимых символов. Максимально допустимое количество символов — 32767. Пример нерационального использования Source Qualifier указан на рисунке ниже:


Рисунок 1 Скриншот из SQ Informatica Power Center

Данный скриншот показывает, что пробелы съедают символьное пространство, вследствие чего сложные SQL-запросы полностью не вписываются (т.е. они обрезаются при их вставке в Source Qualifier).

На рисунке ниже представлено корректное использование Source Qualifier (изменения выделены красным маркером):


Рисунок 2 Скриншот из SQ Informatica Power Center с изменённым запросом

Переход на следующую строку и выравнивание стоило N-е количество символов, убрав которые, мы смогли уместить весь SQL-код.

2. Некорректное преобразование бесконечно больших чисел

Бесконечно большие числа прогружались в базу Oracle в следующем формате:

1267650600228230000000000000000

А должны были загружаться в формате:

1267650600228229401496703205376
Т.е. значения округлялись, начиная с определённого разряда числа.

Мы предлагаем следующее решение:

В ходе разработки маппингов в Informatica Power Center формат поля (например, string) сразу проставляется на определенном этапе для значений, которые точно будут приходить большими, при этом:

• Если мы используем формат decimal и если значения у нас могут иметь до 28 символов, то нужно в свойствах workflow в Workflow Manager включить Properties > «Enable high precision» > «Yes».
• Если мы используем формат double, при этом в данный атрибут могут приходить значения, превышающие 15 символов (например, 20), то значение будет обрываться до 15 значащих цифр и проставлять ноль (0) в остальные (т.е. последние 5 символов будут нулевые). В таком случае лучше проставлять формат string и увеличить размер до нужного (например, string20).

Если подводить итог об использовании инструмента, то можно выделить следующие плюсы:

1. инструмент удобен для переливки большого объёма данных, исчисляемого терабайтами (например, до 25-30 tb), особенно если требуется их переложить с минимальным количеством преобразований (практически один-в-один);
2. возможность автоматической «протяжки» атрибутов (опция Propagate Attributes), а также «подсветки» внутри маппинга (откуда и куда тянутся данные);
3. возможность выбора режима работы как ETL-инструмента, так и ELT-инструмента (зависит от конкретного IT-проекта).

И немного минусов для объективности картины:

1. отсутствие «сложной» логики преобразования данных;
2. с точки зрения support-а самого инструмента и понимания логики работы отдельных трансформаций он уступает некоторым конкурентам (например, Oracle Data Integrator).