Czy w SQL Server istnieje standardowy język / interfejs dla programistycznego ETL?

Obecnie jestem w trakcie tworzenia ETL dla naszej hurtowni danych. Używamy SSIS 2008, ale napotykamy problemy, z których największą jest trudność w ponownym użyciu komponentów. Mamy osobne pakiety dla każdej tabeli i każdy pakiet przyjmuje jako dane wejściowe pewną liczbę zmiennych z pakietu nadrzędnego. Gdy wprowadzamy zmiany do tych zmiennych wejściowych, musimy wejść do każdego pakietu (mamy już około 15, ale liczba ta znacznie wzrośnie) i zmodyfikować pakiet, aby poradzić sobie z tymi zmianami. Istnieją również inne problemy, w tym niemożność uruchomienia dowolnego kodu SQL w celu wyodrębnienia, słabe możliwości rejestrowania itp.

Cały ten proces byłby o wiele bardziej niezawodny, gdyby istniał sposób opracowania naszych ETL w kodzie, umożliwiając ponowne użycie kodu, wspólne biblioteki, lepsze testy jednostkowe itp. Czy istnieje de facto standardowy język / API ETL dla SQL Server? Staram się unikać narzędzi GUI w jak największym stopniu.

Edycja: Powinienem wspomnieć o moim pochodzeniu. Nie jestem DBA i nie mam formalnego (lub nieformalnego) szkolenia DBA, w zasadzie zorientowałem się, jak to postępowałem, więc istnieje prawdopodobieństwo, że próbuję robić niewłaściwe rzeczy z SSIS lub zbliżam się do ETL projekt pod niewłaściwym kątem. Ponadto jestem obecnie zatrudniony w rządzie stanowym, więc wszelkie rozwiązania wymagające zakupu nowego pakietu oprogramowania nie wchodzą w zakres możliwości.

Oto jedno z naszych zadań. Używamy jednego pakietu SSIS do załadowania każdego stołu w naszym magazynie. Każdy pakiet faktów i pakiet wymiarów są ogólnie takie same, różnią się tylko

• Wyciągi ze źródłowej bazy danych
• Manipulacje w przepływie danych
• Scala się z tabelą docelową

Co chciałbym być w stanie zrobić (co wydaje mi się trudne w SSIS)

• Załaduj zapytanie dotyczące wyodrębnienia z pliku tekstowego. Gdy programiści piszą i testują swoje zapytania dotyczące wyodrębniania, nie powinienem w żaden sposób manipulować ich zapytaniem przed uruchomieniem go przez SSIS i nie powinienem wycinać i wklejać zapytania do obiektu źródłowego DB.
• Przetestuj każdy element indywidualnie. Powinienem być w stanie przetestować cały proces ETL dla pojedynczej tabeli w izolacji, niezależnie od innych obciążeń tabeli.
• Dokonaj modyfikacji wspólnej logiki w jednym miejscu, bez konieczności edytowania poszczególnych pakietów. Każdy pakiet ładuje dane do tabel audytu w ten sam sposób, jeśli chcę zmienić ładowane dane poddane audytowi, nie chcę edytować wszystkich 15 pakietów (liczba ta z czasem będzie znacznie większa).

Cały proces wydaje się łatwiejszy do zaimplementowania i bardziej niezawodny, jeśli zostanie wykonany programowo przy odpowiednim użyciu współdzielonego kodu.

Istnieje narzędzie, które to umożliwia - http://www.varigence.com/products/biml.html

Istnieje wersja komercyjna, ale uwzględniamy także niektóre funkcje BIML w BIDS Helper, darmowym narzędziu. http://bidshelper.codeplex.com/

Z przyjemnością odpowiem na wszelkie pytania, które możesz mieć na ten temat.

To narzędzie zapewnia moja firma.

Po przeczytaniu tego od razu pomyślałem o poleceniu narzędzi Varigence. Widzę jednak, że jeden z głównych architektów Varigence, John Welch, przybył tu przede mną.

Narzędzia Varigence to warstwa abstrakcji powyżej SSIS. Zaletą tego jest możliwość definiowania „rzeczy” wielokrotnego użytku, zapewniając w ten sposób spójność wielu pakietów. Ty definiujesz, w jaki sposób powinny być zbudowane pakiety i jak różnią się one indywidualnie - „skompilowane” dane wyjściowe z narzędzi Varigence to pakiety SSIS.

Pomyśl o tym jak o dynamicznym SQL dla pakietów SSIS. Z GUI. Naprawdę bardzo fajnie.

Próbowałem używać SSIS kilka razy i zrezygnowałem z niego. IMO o wiele łatwiej jest zrobić wszystko, czego potrzebuję w C #. SSIS jest zbyt skomplikowany, ma zbyt wiele gotchas i po prostu nie jest tego wart. O wiele lepiej jest spędzać więcej czasu na doskonaleniu umiejętności C # niż spędzać ten sam czas na nauce SSIS - uzyskasz znacznie większy zwrot z treningu. Nie muszę tu szczegółowo wchodzić w szczegóły - Ayende napisała świetne podsumowanie, do którego nie mam nic do dodania .

Również znalezienie i utrzymanie funkcjonalności w rozwiązaniu VS jest o wiele łatwiejsze. Testowanie jednostkowe za pomocą VS jest łatwe. Wszystko, co muszę zrobić, to sprawdzić źródło w Subversion i sprawdzić, jak się ładuje. Testy jednostkowe pakietów SSIS są bardzo zaangażowane, delikatnie mówiąc.

Poza tym zdarzały się sytuacje, gdy SSIS po cichu nie wypełniał niektórych kolumn w niektórych wierszach, po prostu pomijając je bez zgłaszania wyjątków. Spędziliśmy dużo czasu na rozwiązywaniu problemów i ustalaniu, co się dzieje. Opracowanie alternatywnego rozwiązania w języku C # zajęło mniej niż godzinę i działa bez problemów przez dwa lata.

Także Rhino ETL wydaje się być naprawdę fajne.

Było kilka podobnych dyskusji na temat przepełnienia stosu .

Osobiście obsługuję jak najwięcej procesów ETL w SQL. Używam SSIS do importowania z nieparzystych źródeł danych, takich jak strony FTP lub Excel, ale to po prostu, aby uzyskać surowe dane do bazy danych, gdzie SQL zajmuje się resztą.

Moja obecna sytuacja jest stosunkowo prosta, ponieważ większość danych znajduje się w innych bazach MS SQL, z którymi mogę skonfigurować połączone serwery. Jeśli musisz połączyć się z innymi platformami, zalecamy użycie OPENQUERYi BULK INSERT. W razie potrzeby można je konstruować programowo, a między nimi mogą łączyć się z większością typów danych.

Używam SQL, ponieważ to, co wiem najlepiej, ale ma pewne obiektywne zalety. Co najważniejsze, jest już używany: nie trzeba się uczyć ani płacić za nowe narzędzie. Jest to powszechnie dostępna umiejętność, która powinna mieć znaczenie dla twojego szefa, jeśli nie dla ciebie. Ponieważ działa w bazie danych, logowanie jest łatwe. Opiera się na zwykłym kodzie tekstowym, więc można go łatwo wyszukiwać i działa dobrze z kontrolą źródła. Jest bardzo stabilny, z bardzo małą szansą na zmianę przez dostawcę i zerwanie wstecznej kompatybilności. Prawdopodobnie jest co najmniej tak szybki jak jakikolwiek język RBAR.

Jeśli potrzebujesz więcej, polecam .NET, choćby dlatego, że jest używany w SSIS i SQLCLR. Używam aplikacji C # do zarządzania całym procesem ETL - rozpoczynając podetapy, monitorując ich wyniki, wysyłając e-maile. Ale prawie wszystko to można zrobić za pomocą agenta SQL, dbmail itp.

Czy jest jakiś powód, dla którego nie można używać SQL do ETL? Czego ci nie udało się zrobić?