Существует ли стандартный язык / интерфейс для программного ETL в SQL Server?

В настоящее время я нахожусь в процессе создания ETL для нашего хранилища данных. Мы используем SSIS 2008, но у нас возникают проблемы, самая большая из которых - это проблема повторного использования компонентов. У нас есть отдельные пакеты для каждой таблицы, и каждый пакет принимает в качестве входных данных несколько переменных из родительского пакета. Когда мы вносим изменения в эти входные переменные, мы должны входить в каждый пакет (у нас их 15 или около того, но это число будет значительно расти) и модифицировать пакет, чтобы справиться с этими изменениями. Есть и другие проблемы, в том числе невозможность запустить произвольный SQL для нашего извлечения, плохие возможности ведения журналов и т. Д.

Весь этот процесс был бы гораздо более надежным, если бы существовал способ разработки наших ETL в коде, позволяющий повторное использование кода, общие библиотеки, улучшенные модульные тесты и т. Д. Существует ли де-факто стандартный язык / API ETL для SQL Server? Я стараюсь избегать инструментов GUI, насколько это возможно.

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

Вот одна из наших задач. Мы используем один пакет служб SSIS для загрузки каждой таблицы на нашем складе. Каждый пакет фактов и пакет измерений, как правило, одинаковы, они отличаются только

• Извлечения из исходной базы данных
• Манипуляции в потоке данных
• Сливается в таблицу назначения

Что я хотел бы иметь возможность делать (что мне трудно сделать в SSIS)

• Загрузите запрос извлечения из текстового файла. Когда разработчики пишут и тестируют свои запросы на извлечение, мне не нужно каким-либо образом манипулировать их запросом перед тем, как SSIS его выполнит, и мне не нужно было вырезать и вставлять запрос в объект-источник БД.
• Проверьте каждый компонент в отдельности. Я должен быть в состоянии проверить весь процесс ETL для отдельной таблицы изолированно, независимо от других нагрузок таблицы.
• Вносите изменения в общую логику в одном месте, не нужно редактировать каждый отдельный пакет. Каждый пакет загружает данные в таблицы аудита одним и тем же способом. Если я хочу изменить загруженные данные аудита, мне не нужно редактировать все 15 пакетов (это число будет значительно увеличиваться со временем).

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

Существует инструмент, который позволяет это - http://www.varigence.com/products/biml.html

Есть коммерческая версия, но мы также включили некоторые функции BIML в бесплатный инструмент BIDS Helper. http://bidshelper.codeplex.com/

Я рад ответить на любые вопросы, которые у вас могут возникнуть по этому поводу.

Это инструмент, который предоставляет моя компания.

Прочитав это, я сразу подумал о том, чтобы порекомендовать инструменты Varigence. Однако я вижу, что один из главных архитекторов Varigence, Джон Уэлч, оказался здесь до меня.

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

Думайте об этом как о динамическом SQL для пакетов служб SSIS. С графическим интерфейсом. Действительно очень круто.

Я пытался использовать SSIS несколько раз и отказался от него. ИМО гораздо проще просто сделать все что мне нужно в C #. Служба SSIS слишком сложна, в ней слишком много ошибок, и она того не стоит. Гораздо лучше тратить больше времени на улучшение навыков C #, чем тратить столько же времени на изучение SSIS - вы получите гораздо больше отдачи от обучения. Мне не нужно вдаваться в подробности - Айенде написала отличное резюме, мне нечего добавить .

Также найти и поддерживать функциональность в решении VS намного проще. Модульное тестирование с VS легко. Все, что мне нужно сделать, это проверить источник в Subversion и проверить, как он загружен. Модульное тестирование пакетов SSIS очень мягко сказано.

Кроме того, были ситуации, когда службам SSIS молча не удавалось заполнить некоторые столбцы в некоторых строках, просто пропуская их, не вызывая исключений. Мы потратили много времени на поиск неисправностей и выяснение того, что происходит. Разработка альтернативного решения на C # заняла менее часа и работает без проблем в течение двух лет.

Также Rhino ETL, кажется, действительно крутой.

Было несколько аналогичных обсуждений на stackoverflow .

Лично я обрабатываю как можно больше процессов ETL в SQL. Я использую SSIS для импорта из странных источников данных, таких как FTP-сайты или Excel, но это просто для того, чтобы получить необработанные данные в базу данных, где остальное делает SQL.

Моя текущая ситуация относительно проста: большая часть данных находится в других базах данных MS SQL, с помощью которых я могу настроить связанные серверы. Если вам нужно подключиться к другим платформам, я рекомендую использовать OPENQUERYи BULK INSERT. При необходимости они могут быть построены программно, и между ними они могут подключаться к большинству типов данных.

Я использую SQL, потому что это то, что я знаю лучше, но у него есть некоторые объективные преимущества. В частности, он уже используется: нет необходимости изучать или платить за новый инструмент. Это широко доступный навык, который должен иметь значение для вашего босса, если не для вас. Поскольку он работает в базе данных, ведение журнала легко. Он основан на простом текстовом коде, поэтому его легко искать и хорошо работать с исходным кодом. Он очень стабилен, с очень малой вероятностью того, что поставщик что-то изменит и нарушит обратную совместимость. Это, вероятно, по крайней мере так же быстро, как любой язык RBAR.

Если вам нужно больше, я рекомендую .NET, хотя бы потому, что он используется в SSIS и SQLCLR. Я использую приложения на C # для управления всем процессом ETL - запуска подэтапов, отслеживания их вывода, отправки электронной почты. Но почти все это можно сделать с помощью агента SQL, dbmail и т. Д.

Есть ли причина, по которой вы не можете использовать SQL для своего ETL? Что он не смог сделать для вас?