Специфичный для домена язык для выполнения извлечения и преобразования данных в конвейере ETL

#sql #etl #data-warehouse #dsl

#sql #etl #хранилище данных #dsl

Вопрос:

Есть ли какой-либо из специфичных для домена языков (DSL), которые облегчают извлечение и преобразование данных в рамках конвейера извлечения-преобразования-загрузки (ETL)?

Я хотел бы извлечь данные из сторонней базы данных SQL и преобразовать данные в уже определенный формат JSON, чтобы сохранить их в моем приложении. Существует множество различных возможных схем базы данных для извлечения данных, поэтому мне было интересно, есть ли уже способ настроить это с помощью (обычно используемого) языка извлечения (в идеале этот язык также не зависит от других источников данных, таких как веб-службы и т. Д.).

Я осмотрелся, но, кроме нескольких исследовательских работ, я не смог найти много с точки зрения согласованных стандартов для ETL (за вычетом «L», который я рассмотрел), и я не хочу изобретать велосипед.

Я был бы признателен за любые указания в правильном направлении.

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

1. Просто мое мнение, но, предполагая решение любого нетривиального размера, я бы всегда использовал специальный инструмент ETL / ELT и никогда не писал бы код для выполнения функций ETL — я полагаю, когда вы говорите о языках, вы имеете в виду языки кодирования? Подход к кодированию быстро становится очень сложным / невозможным для поддержки и обслуживания — отсюда необходимость в специальных инструментах ETL

Ответ №1:

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

И ETL «без навыков программирования», как пытается сделать эта исследовательская статья, будет бороться с беспорядком очистки и согласования разрозненных исходных систем.

Использование языка общего назначения само по себе, конечно, возможно, но требует очень много времени из-за низкого уровня абстракции и всего кода инфраструктуры, который вам придется реализовать.

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

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

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

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

Приветствия, Кристиан

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

1. Спасибо, что поделились своим мнением. Я наткнулся на это etl.linkedpipes.com который выглядит довольно гибким. Что вы думаете?

2. Почти со всеми графическими инструментами ETL вы выигрываете в визуализации (хорошо) и интерактивности (личные предпочтения), но теряете в возможности повторного использования, инкапсуляции и множестве других вещей (плохо). Очевидно, что лучше всего попробовать его и оценить, насколько хорошо (или нет) он будет работать в ваших различных полноразмерных проектах. Ознакомьтесь с техническим документом «Тринадцать факторов, снижающих производительность ETL», в котором actionETL сравнивается с SSIS — графические инструменты ETL имеют большинство общих черт: envobi.com/resources

3. Еще раз спасибо, что поделились своими соображениями.