#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. Еще раз спасибо, что поделились своими соображениями.