Чи є стандартний мова / інтерфейс для програмного ETL в SQL Server?


10

На даний момент я створюю ETL для нашого сховища даних. Ми використовуємо SSIS 2008, але ми стикаємося з проблемами, найбільшою з яких є складність у повторному використанні компонентів. У нас є окремі пакети для кожної таблиці, і кожен пакунок бере як вхід ряд змінних з батьківського пакету. Коли ми вносимо зміни до цих змінних вхідних даних, від нас вимагається перейти до кожного пакету (у нас 15 чи більше, але це число значно зросте) та змінити пакет для усунення цих змін. Є й інші проблеми, зокрема неможливість запуску довільного SQL для нашого видобутку, погані можливості ведення журналу тощо.

Весь цей процес був би набагато більш надійним, якби існував спосіб розробити наші ETL в коді, що дозволить повторно використовувати код, загальні бібліотеки, краще тестування одиниць тощо. Чи існує фактично стандартна мова / API ETL для SQL Server? Я намагаюсь максимально уникати інструментів GUI.

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


Ось одне із наших завдань. Ми використовуємо єдиний пакет SSIS для завантаження кожної таблиці на нашому складі. Кожен пакунок Факт і Пакет розмірів, як правило, однакові, вони лише відрізняються

  • Витяги з вихідної бази даних
  • Маніпуляції в потоці даних
  • Зливається в таблицю призначення

Що я хотів би зробити (що мені здається складно зробити в SSIS)

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

Увесь процес відчуває, що це було б набагато простіше у виконанні та більш надійним, якщо це зробити програмно при правильному використанні спільного коду.


4
Я НЕ дуже великий користувач SSIS, але можу зрозуміти сприйняття крутої кривої навчання тут. Я закликаю вас переглянути деякі відео / блоги про Енді Леонарда, Джеймі Томпсона, Брайана Найта, які є експертами в цій галузі та мають певний напрямок. Подивіться на веб-сайті sqlpass.org безкоштовні відео проходження саміту & sqlblog.com, pragmaticworks.com
Sankar Reddy

Я не вірю, що крива навчання є проблемою. Я знаю, як виконувати завдання, які я хочу зробити в SSIS. Я розглядаю новий процес, тому що знайдені нами рішення повторювані, неміцні та непотрібні.
кубі

Kubi, Якщо ви можете додати детальну інформацію про компоненти, на які ви посилаєтесь, я приведу когось, хто зможе відповісти на це за вас. Як зараз, ваше запитання занадто широке, щоб відповісти.
Санкар Редді

4
@kubi - ви торкнулися одного з брудних маленьких секретів BI-галузі. Інструменти ETL дуже і дуже бідні на абстракцію та багаторазову логіку. Як наслідок, вони зростають дуже погано зі збільшенням складності домену.
ЗанепокоєнийOffTunbridgeWells

1
Я маю на увазі досить хороший авторитет, що приблизно половина клієнтів певного галузевого вертикального продукту для банківської справи та страхування (зроблені компанією, про яку ви чули і про яку зазвичай посилається конкретний колір) приймають явне технічне рішення будувати свої Обробка ETL у збереженій процедурі, саме з цієї причини.
ЗанепокоєнийOfTunbridgeWells

Відповіді:


6

Є інструмент, який це дозволяє - http://www.varigence.com/products/biml.html

Існує комерційна версія, але ми також включаємо деякі функції BIML в BIDS Helper, безкоштовний інструмент. http://bidshelper.codeplex.com/

Я радий відповісти на будь-які питання, які у вас можуть виникнути з цього приводу.

Це інструмент, який надає моя компанія.


6

Прочитавши це, я одразу подумав рекомендувати інструменти Varigence. Однак я бачу, що один з головних архітекторів Varigence Джон Уелч потрапив сюди до мене.

Інструменти Varigence - це шар абстракції над SSIS. Перевага, що надається, - це можливість визначати багаторазові "речі", забезпечуючи таким чином послідовність у кількох пакетах. Ви визначаєте, як пакунки повинні бути структуровані та як вони різняться на індивідуальній основі - "складені" результати з інструментів Varigence - це пакети SSIS.

Подумайте про це як про динамічний SQL для пакетів SSIS. З графічним інтерфейсом. Дійсно дійсно круто.


3

Я кілька разів намагався використовувати SSIS і відмовився від нього. ІМО набагато простіше просто зробити все, що мені потрібно в C #. SSIS занадто складний, у нього занадто багато гатчів, і це просто не варто. Набагато краще витратити більше часу на вдосконалення навичок C #, ніж витратити той же час на вивчення SSIS - ви отримаєте набагато більше прибутку від свого навчання. Тут мені не потрібно детально розбиратись - Ейнде написала чудовий конспект, до якого мені нічого додати .

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

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

Також Rhino ETL здається справді крутим.

Було кілька подібних дискусій щодо стакового потоку .


2

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

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

Я використовую SQL, тому що це те, що я найкраще знаю, але воно має деякі об'єктивні переваги. Найголовніше, що він уже використовується: не потрібно вчитися чи платити за новий інструмент. Це широкодоступний навик, який повинен мати значення для вашого начальника, якщо не для вас. Оскільки він працює в базі даних, ведення журналів є простим. Він заснований на простому текстовому коді, тому його легко шукати і добре працює з контролем джерела. Це дуже стабільно, з дуже невеликим шансом постачальник змінити речі і порушити сумісність. Це, мабуть, принаймні так швидко, як і будь-яка мова RBAR.

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

Чи є причина, що ви не можете використовувати SQL для свого ETL? Що ви не змогли зробити для вас?


Дійсно, ми використовуємо SSIS для скидання необроблених даних у Temp DB, тоді ми використовуємо TSQL визначаємо, як ми хочемо T та L.
Павло
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.