Проект GETL

Привет.

Долго я вынашивал идею разработки open source ETL и вот эта идея стала приобретать очертания. Так зачем же еще один open source ETL? (про коммерческие молчу, еще один там явно не нужен). По моему мнению, все известные мне бесплатные и платные ETL продукты хромают в той или иной мере по трем позициям:

1.    ETL продукты чрезвычайно автономны и самодостаточны. На практике это означает то, что вам очень сложно управлять ETL продуктом из собственной программы и такое управление ограничено возможностями API этого ETL. Так же не менее сложным является использование в ETL Ваших и сторонних решений, приходится писать тучу кода и обвязок, чтобы их подружить. Все это касается и интеграции с системами автоматизированного тестирования. Конечно, современные ETL продукты в том или ином виде поддерживают тестирование, но максимально только на уровне работы самого job. Провести комплексное тестирование частей job или множества job для ETL по заранее заданному плану, интересная, но сложная задача для тестировщика.

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

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

Сейчас все основные работы по загрузке данных в хранилище я разрабатываю на Talend DataIntegrator. Этот продукт был выбран как наиболее универсальный и позволяющий легко расширять себя до необходимого функционала с помощью разработки собственных библиотек и компонент на Java. Talend имеет внушительный функционал по поддержке различных источников данных и методам работы с данными. Являясь кодогенератором, Talend генерирует по разработанным job код на Java, что обеспечивает отличную скорость обработки данных. Также этот сгенерированный код в виде классов Java можно использовать внутри собственных приложений или контейнера J2EE.

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

Часто получалось, что задачу не представляется возможным реализовать в виде одного job и приходилось часть действий выносить в подчиненные job, вызываемые с основного. Это размазывало логику загрузки и усложняло решение из-за организации взаимодействия таких job и передачей параметров между ними. Когда же дело доходило до обработки иерархических структур, таких как XML или JSON, Talend вообще пасовал, ибо описать на диаграмме загрузку иерархических данных в виде одного входящего потока и множества исходящих как основного и подчиненных просто не возможно. Здесь мне приходилось вообще брать дело в свои руки и писать код на Java, который решал задачи такого уровня.

Отдельно стоит упомянуть обработку ошибок. Да, она есть. Но если у вас сложный процесс и на диаграмме десятки компонент, то для перехвата ошибки у этих компонент требуется в диаграмме вынести от каждого потока или итерации связь перехвата ошибки на блок обработки ошибок. При этом, когда на схеме множество перекрывающих друг друга и компоненты стрелок, ее читабельность стремится к нулю. То же самое касается и документирования схемы job - вы не сможете разместить по ходу диаграммы пояснения, так как она станет слишком громоздкой. Значит, вам придется описывать принципы работы job где-то в отдельном месте и в случае модификации job идти по тексту документации и проверять где и что изменилось.

Вышеописанный поток моих претензий часто в той или иной мере озвучивают многие разработчики ETL при решении задач под разные отрасли. Здесь я просто все обобщил, добавив то, с чем столкнулся сам. Множество из описанного мной было успешно решено на Talend с помощью языка высокого уровня Groovy. Он полностью совместим с Java, но расширяет ее язык функционально, значительно уменьшая объем кодирования и увеличивая его читабельность. Так как Groovy все больше и чаще входит в код моих job, я решил на основе наработок с ним выделить все в отдельный framework на базе Groovy, назвав его GETL (Groovy Extract Transform Load framework). GETL будет возможным использовать как отдельную платформу для разработки job загрузки данных, так и как компонент, работающих в job Talend. Ну, и никто не мешает разработчикам Java интегрировать GETL в свои проекты как модуль и получить в свое распоряжение управляемую функциональность интеграции данных.

Чтобы быть интересным и перспективным для использования, помимо стандартного набора функционала ETL продукта GETL должен:

• Уметь работать с динамическими и неизвестными на момент разработки структурами, включая исследование метаданных используемых объектов
• Поддерживать разработку шаблонов загрузки и трансформации данных
• Обеспечивать проведение автоматизированного тестирования и поддерживать unit test
• Иметь управляемую многопоточность выполнения процессов
• Содержать прозрачную иерархию базовых классов для легкого расширения функциональности с помощью собственных классов
• Предоставить менеджер управления хранилищем временных файлов для проведения промежуточных операций над данными и менеджер хранения повторно используемых данных job на базе РСУБД

Компонентная схема GETL:

GETL не будет визуальным ETL, с поддержкой диаграмм, как это сейчас практикуют все современные продукты интеграции данных. Ему это просто не будет нужно - job будут описываться на базе интуитивно понятного языка Groovy, скрипты будут маленькими и внутри них будет возможно комментировать описанные алгоритмы прямо по месту. Основным плюсом визуальных ETL является упрощение описания правил маппинга, очистки и трансформации данных. В GETL будет возможность описать такие правила в коде job или через визуальный редактор, который сохранит их в области хранения повторно используемых данных, видимых далее в job. Механизм описания и выполнения таких правил будет инновационным и позволит оперировать как известными, так и не известными заранее структурами. Станет возможным описать правила маппинга без привязки к конкретным именам объектов, а так же определить набор правил очистки с определением условий, какое правило применять. Таким образом, GETL позволит описывать job как типовые шаблоны, которые смогут по однажды определенному алгоритму загружать множество разных источников данных. Нужно загрузить 100 справочников как SDT по единой схеме загрузки? Нет проблем – не нужно делать 100 job, достаточно сделать один и описать правила загрузки с учетом отличий справочников. Требуется разработать инкрементный расчет витрин хранилища данных по заданным SQL скриптам? Опять нет проблем - один job с прописанными алгоритмами, который будет можно вызвать для расчета каждой витрины.

Понятно, что GETL не сможет конкурировать с крупными и известными Enterprise продуктами. Но если у Вас нет денег на покупку дорогостоящего решения и обучение специалистов работы с ним или же у Вас нетривиальные задачи, которые не укладываются в просто схему «получил, обработал, загрузил», то, как вариант, можно будет воспользоваться этим решением. Так как я работаю в телекоммуникационной области, GETL будет иметь расширенную функциональность для типовых задач и форматов, применяемых в этой области.

Проект будет вестись по адресу: https://sourceforge.net/projects/getl

Идеи, пожелания и помощь в любом виде приветствуются.

До новых записей в блоге.