2017-02-16 37 views
1

Я сделал много исследований по разработке ETL, и я пришел к выводу, что лучший подход к ETL является декларативным (с поддержкой пользовательских императивных блоков/функций). В частности, декларативные подходы позволяют визуализировать преобразования, которые могут значительно облегчить обсуждение преобразований с экспертами в области бизнеса/домена. Также не следует игнорировать тот факт, что декларативные подходы часто более компактны и удобны в обслуживании.Какие библиотеки/инструменты существуют для разработки и выполнения преобразований (как в ETL) декларативно?

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

Действительно ли XSLT является единственной или лучшей игрой в городе для декларативных преобразований?

Я сделал некоторые исследования сегодня, и единственные альтернативы, которые я нашел, как представляется, в значительной степени Abandonware:

Любые указатели на варианты или общую мудрость были бы высоко оценены!

ответ

0

Я также считаю, что декларативный подход работает очень хорошо (как я объяснил в статье here). Я говорю об этом, так как я поддерживаю декларативный ETL на основе кода за последние 10 лет, сначала используя теперь незанятый activewarehouse-etl, а с 2015 года используя Kiba ETL, который я написал и открыл с открытым исходным кодом.

Я уверен, что существуют другие декларативные кодовые ETL!

2

ATL определенно не мертв, вы можете увидеть последние данные here. Но в настоящее время они работают над улучшением производительности своего механизма выполнения. ATL - это, в основном, декларативный язык, вдохновленный QVTr.

QVTr не полностью мертв, и Eclipse QVTd project активно работает над предоставлением механизма выполнения QVTr. Я не уверен, что в конечном итоге они будут поддерживать редактор для визуального синтаксиса. Если они это сделают, я думаю, что план заключается в поддержке UMLX.

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

IMHO, ATL и ETL являются более чем достойными декларативными языками преобразования.

Что касается визуального синтаксиса, я бы предположил, что вы можете нарушить свою собственную нотацию и уклониться от редактора, поддерживающего его, используя Sirius. Оттуда вы можете использовать трансформацию модели для создания эквивалентного кода ETL/ATL, а затем запустить это :) (либо модель-модель, чтобы создать AST, либо модель-код для генерации сценария). Преимущество определения собственного визуального синтаксиса заключается в том, что вы можете адаптировать его под свою аудиторию, чтобы помочь вам обсудить трансформацию с ними.