Инструменты ETL и инструменты сборки


Я знаком с программными средствами автоматизированной сборки (такими как Automated Build Studio). Теперь я смотрю на инструменты ETL.

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

Я прав?

5 2

5 ответов:

Правильно, что вы можете развернуть свои собственные сценарии ETL, написанные с помощью инструмента разработки по вашему выбору. Тем не менее, задания ETL часто велики (за неимением лучшего слова) и требуют значительного администрирования и внимания к мельчайшим деталям (например, программирование). Инструменты ETL позволяют разработчику сосредоточиться на задачах ETL - в отличие от написания и отладки кода, хотя это тоже часть его. Есть некоторые инструменты с открытым исходным кодом, так что вы можете получить представление о том, что такое средний инструмент делает это, прежде чем перейти к пользовательской разработке. Например, более дорогие инструменты предоставляют линейку данных, что означает, что вы можете (графически) отслеживать каждое поле в отчете до исходной таблицы через все преобразования (включая версии); после корпоративного слияния это довольно сложная задача.
Например: Pentaho имеет издание сообщества; Если у вас есть MS SQL Server, вы можете получить SSIS. Также смотрите, если вы можете найти здесь что-то есть.

Преимущество инструмента ETL максимизируется, если у вас есть много процессов для сборки (мне нравится пост-аналогия jsf80238 с забиванием 100 гвоздей). Ключевым преимуществом реальных инструментов ETL являются метаданные, которые они генерируют, и оперативная поддержка. Написание скриптов в Perl / Ruby / etc довольно легко, но ломается, когда нужно отследить проблемы или кто-то другой, кроме автора, должен выяснить, что не так.Возможность для админов / сотрудников службы поддержки быстро увидеть, что пошло не так-это то, что стоит платить деньги за это. Я использовал SSIS от Microsoft (2005-OK) и новейший Pentaho PDI (довольно хороший). Графический интерфейс Pentaho ETL используется бизнес-пользователями (без его поддержки в течение 99% времени) на моем рабочем месте и заменил путаницу сценариев SQL и электронных таблиц. Что бы вы ни говорили об остальном стеке Pentaho, но компонент ETL, на мой взгляд, является отличным "bang for buck".

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

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

Лично я думаю, что всегда проще написать собственный инструмент ETL на языке, подобном Perl. Просто напишите алгоритм государственной машины, чтобы скопировать исходные данные и преобразовать их в нужный формат. Я использую Perl для FTP в машины, чтения файлов, преобразования данных и затем загрузите его в базу данных. Это всегда превосходное решение и гораздо быстрее, если вы хорошо владеете Perl или подобными языками, или можете нанять кого-то, кто знает Perl.

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

Мне нравится ответ Дамира Сударевича, и я хотел бы добавить, что ваш выбор инструмента может также зависеть от того, сколько работы у вас впереди. Если у вас есть случайная задача ETL и вы уже знакомы с инструментом, который позволит вам выполнить эту задачу, используйте инструмент, который вы уже знаете (этот подход присваивает нулевое значение изучению нового инструмента, что, возможно, недооценивает новые знания). Если у вас есть много задач ETL, то первоначальные инвестиции в изучение нового инструмента могут очень хорошо окупиться прочь. Вы можете использовать плоскогубцы, чтобы вбить гвоздь, и если у вас есть только один гвоздь, вы можете использовать плоскогубцы. Если вам нужно вбить 100 гвоздей, возьмите себе молоток.

Вы также можете делать все, что ETL-инструменты могут делать с кодом. :- )

Обе упомянутые вами категории инструментов могут быть использованы для решения этой проблемы, но они оптимизированы для класса задач, которые они пытаются решить:

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