Esiste un linguaggio / un'interfaccia standard per ETL programmatico in SQL Server?

Sono attualmente in procinto di creare ETL per il nostro data warehouse. Stiamo utilizzando SSIS 2008, ma stiamo riscontrando problemi, il più grande dei quali è la difficoltà nel riutilizzo dei componenti. Abbiamo pacchetti separati per ogni tabella e ogni pacchetto prende come input un numero di variabili da un pacchetto padre. Man mano che apportiamo modifiche a queste variabili di input, ci viene richiesto di andare in ciascun pacchetto (ne abbiamo circa 15 ora, ma questo numero crescerà in modo significativo) e modificare il pacchetto per far fronte a tali cambiamenti. Ci sono anche altri problemi, tra cui l'impossibilità di eseguire SQL arbitrario per la nostra estrazione, scarse capacità di registrazione, ecc.

L'intero processo sarebbe molto più solido se esistesse un modo per sviluppare i nostri ETL nel codice, consentendo il riutilizzo del codice, librerie comuni, test unitari migliori, ecc. Esiste un linguaggio / API ETL standard di fatto per SQL Server? Sto cercando di evitare il più possibile gli strumenti della GUI.

Modifica: dovrei menzionare il mio background. Non sono un DBA e non ho una formazione DBA formale (o informale), ho praticamente capito queste cose mentre procedevo, quindi c'è ogni probabilità che sto tentando di fare cose inappropriate con SSIS o di avvicinarmi a questo ETL proiettare dall'angolazione sbagliata. Inoltre, sono attualmente impiegato nel governo dello stato, quindi tutte le soluzioni che richiedono l'acquisto di un nuovo pacchetto software non rientrano nel campo delle possibilità.

Ecco uno dei nostri compiti. Stiamo utilizzando un singolo pacchetto SSIS per caricare ogni tabella nel nostro magazzino. Ogni pacchetto Fact e pacchetto Dimension sono generalmente uguali, differiscono solo per

• Estrazioni dal database di origine
• Manipolazioni in un flusso di dati
• Si unisce alla tabella di destinazione

Cosa vorrei poter fare (che sto trovando difficile da fare in SSIS)

• Carica la query di estrazione da un file di testo. Quando gli sviluppatori stanno scrivendo e testando le loro query di estrazione, non dovrei dover manipolare la loro query in alcun modo prima che SSIS la esegua e non dovrei tagliare e incollare la query in un oggetto DB Source.
• Testare ciascun componente singolarmente. Dovrei essere in grado di testare l'intero processo ETL per una singola tabella in modo indipendente, indipendentemente dagli altri carichi della tabella.
• Apporta modifiche alla logica condivisa in un unico posto, non è necessario modificare ogni singolo pacchetto. Ogni pacchetto carica i dati nelle tabelle di controllo allo stesso modo, se voglio cambiare i dati caricati controllati, non voglio modificare tutti i 15 pacchetti (questo numero diventerà molto più grande nel tempo).

L'intero processo sembra che sarebbe molto più facile da implementare e più robusto se fatto in modo programmatico con un uso corretto del codice condiviso.

C'è uno strumento che lo abilita: http://www.varigence.com/products/biml.html

C'è una versione commerciale, ma includiamo anche alcune delle funzionalità BIML in BIDS Helper, uno strumento gratuito. http://bidshelper.codeplex.com/

Sono felice di rispondere a qualsiasi domanda tu possa avere al riguardo.

Questo è uno strumento fornito dalla mia azienda.

Dopo aver letto questo ho subito pensato di raccomandare gli strumenti di Varigence. Tuttavia, vedo che uno dei principali architetti di Varigence, John Welch, è arrivato qui prima di me.

Gli strumenti di Varigence sono uno strato di astrazione sopra SSIS. Il vantaggio che offre è la capacità di definire "elementi" riutilizzabili fornendo così coerenza tra più pacchetti. Definisci come devono essere strutturati i pacchetti e in che modo differiscono su base individuale: gli output "compilati" dagli strumenti di Varigence sono pacchetti SSIS.

Pensalo come SQL dinamico per i pacchetti SSIS. Con una GUI. Davvero fantastico.

Ho provato a utilizzare SSIS diverse volte e ho rinunciato. IMO è molto più semplice fare tutto ciò di cui ho bisogno in C #. SSIS è troppo complesso, ha troppi trucchi e non ne vale la pena. È molto meglio dedicare più tempo al miglioramento delle competenze in C # piuttosto che dedicare lo stesso tempo all'apprendimento del SSIS: otterrai molto più ritorno sulla tua formazione. Non ho bisogno di entrare nei dettagli qui - Ayende ha scritto un ottimo riassunto a cui non ho nulla da aggiungere .

Anche trovare e mantenere funzionalità in una soluzione VS è molto più semplice. Il test unitario con VS è semplice. Tutto quello che devo fare è controllare l'origine in Subversion e verificare come è stato caricato. I pacchetti SSIS di unit test sono molto coinvolti per dirla in modo lieve.

Inoltre, c'erano situazioni in cui SSIS non riusciva silenziosamente a popolare alcune colonne in alcune righe, saltandole senza sollevare eccezioni. Abbiamo impiegato molto tempo per la risoluzione dei problemi e per capire cosa sta succedendo. Lo sviluppo di una soluzione alternativa in C # ha richiesto meno di un'ora e funziona senza problemi per due anni.

Anche Rhino ETL sembra essere davvero bello.

Ci sono state alcune discussioni simili su StackOverflow .

Personalmente, gestisco il più possibile il processo ETL in SQL. Uso SSIS per importare da origini dati dispari come siti FTP o Excel, ma è solo per ottenere dati grezzi nel database in cui SQL fa il resto.

La mia situazione attuale è relativamente semplice in quanto la maggior parte dei dati si trova in altri database MS SQL, con i quali posso configurare server collegati. Se devi connetterti ad altre piattaforme, ti consiglio di usare OPENQUERYe BULK INSERT. Possono essere costruiti a livello di programmazione, se necessario, e tra i due possono connettersi alla maggior parte dei tipi di dati.

Uso SQL perché è quello che conosco meglio, ma presenta alcuni vantaggi oggettivi. In particolare, è già in uso: non è necessario imparare o pagare per un nuovo strumento. È un'abilità ampiamente disponibile, che dovrebbe importare al tuo capo se non a te. Poiché opera nel database, la registrazione è semplice. Si basa su un semplice codice di testo, quindi è facilmente ricercabile e funziona bene con il controllo del codice sorgente. È molto stabile, con pochissime possibilità che il venditore cambi cose e rompa la retrocompatibilità. Probabilmente è veloce almeno quanto qualsiasi linguaggio RBAR.

Se hai bisogno di più, ti consiglio .NET, se non altro perché viene utilizzato in SSIS e SQLCLR. Uso le app C # per gestire l'intero processo ETL: avvio di passaggi secondari, monitoraggio dell'output, invio di e-mail. Ma quasi tutto ciò potrebbe essere fatto con SQL Agent, dbmail, ecc.

C'è qualche motivo per cui non puoi usare SQL per il tuo ETL? Cosa non è stato in grado di fare per te?