Come affrontare una missione ETL?

StackOverflow https://stackoverflow.com/questions/440346

Domanda

Dovrei eseguire ETL dove source è un database sql 2k grande e mal progettato e un database sql 2k5 meglio progettato. Penso che SSIS sia la strada da percorrere. Qualcuno può suggerire un elenco di cose da fare o un elenco di controllo o cose a cui fare attenzione in modo da non dimenticare nulla? Come dovrei avvicinarmi a questo in modo che non mi morda nella parte posteriore in seguito.

È stato utile?

Soluzione

Beh, sto sviluppando un ETL per l'azienda in cui mi trovo.

Stiamo lavorando con SSIS. Uso di api per generare e creare i nostri pacchetti dtsx.

SSIS non è amichevole per la gestione degli errori. A volte ricevi un "Errore OleDb" che potrebbe avere molti significati diversi a seconda del contesto.

Leggi la documentazione API (non dicono molto).

Alcuni link per aiutarti a partire da lì: http://technet.microsoft.com/de-de /library/ms135932(SQL.90).aspx

http://msdn.microsoft.com/en-us/library /ms345167.aspx

http://msdn.microsoft.com/en-us/library /ms403356.aspx

http://www.codeproject.com/KB/database/SSISProgramming.aspx?display=PrintAll&fid=382208&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr = 26 & amp; selezionare = 2.551.674

http://www.codeproject.com/KB/database/foreachadossis.aspx

http://wiki.sqlis.com/default.aspx/SQLISWiki /ComponentErrorCodes.html

http: // www.new.facebook.com/inbox/readmessage.php?t=1041904880323#/home.php?ref=logo

http://technet.microsoft.com/en-us/library /ms187670.aspx

http: // msdn .microsoft.com / ja-jp / library / microsoft.sqlserver.dts.runtime.foreachloop.foreachenumerator.aspx

http: // www .sqlis.com / post / Uso-diverso-row-tipi-in-the-same-file.aspx

http://technet.microsoft.com/ it-it / library / ms135967 (SQL.90) .aspx

http://msdn.microsoft.com/ it-it / library / ms137709 (SQL.90) .aspx

http://msdn.microsoft.com/ it-it / library / ms345164 (SQL.90) .aspx

http://msdn.microsoft.com/en-us/library /ms141232.aspx

http://www.microsoft.com/technet/prodtechnol /sql/2005/ssisperf.mspx

http://www.ivolva.com/ssis_code_generator.html

http://www.ivolva.com/ssis_wizards.html

http://www.codeplex.com/MSFTISProdSamples

http:

Altri suggerimenti

Alcuni suggerimenti ETL generali

  1. Valuta di organizzarlo per destinazione (ad esempio, tutto il codice per produrre il cliente dimensione vive nello stesso modulo, indipendentemente dalla fonte). Questo è talvolta noto come ETL orientato al soggetto. Esso rende trovare cose molto più facili e volontà aumentare la manutenibilità del tuo codice.

  2. Se il database SQL2000 è un casino, probabilmente troverai questo SSIS i flussi di dati sono un modo maldestro di trattare con i dati. Di norma, strumenti ETL ridimensionare male con complessità; qualcosa come la metà di tutti i dati progetti di magazzino in finanza le aziende hanno finito con il deposito codice di procedura come esplicito decisione architettonica - proprio per questo motivo. Se hai per inserire una grande quantità di codice sprocs, considera l'idea di mettere tutto del file codice in sprocs.
    Per un sistema che coinvolge molte operazioni di lavaggio o trasformazione complesse, un approccio sproc al 100% è molto più gestibile in quanto è l'unico modo fattibile per mettere tutte le trasformazioni e la logica aziendale in un unico posto. Con i sistemi misti ETL / sproc, devi cercare in più punti per tracciare, risolvere i problemi, eseguire il debug o modificare l'intera trasformazione.

  3. Il punto debole degli strumenti ETL è nei sistemi in cui si dispone di un numero maggiore di origini dati con trasformazioni relativamente semplici.

  4. Rendi il codice testabile, così puoi smontare i componenti e testare in isolamento. Il codice che può essere eseguito solo all'interno di un flusso di dati complesso in uno strumento ETL è molto più difficile da testare.

  5. Rendi i dati estratti stupidi con no logica aziendale e copia in a area di sosta. Se hai affari logica diffusa attraverso l'estratto e trasforma i livelli, avrai trasformazioni che non possono essere testate in isolamento e renderlo difficile rintracciare i bug. Se la trasformazione è correndo da un'area di stadiazione ridurre la forte dipendenza dal sistema di origine, ancora una volta migliorando verificabilità. Questa è una vittoria particolare sulle architetture basate su Sproc in quanto consente una base di codice quasi completamente omogenea.

  6. Crea un generico che cambia lentamente gestore delle dimensioni o utilizzare una delle opzioni scaffale se disponibile. Questo lo rende più facile da testare questo funzionalità. Se questo può essere unità testato, il test di sistema no deve testare tutti i casi angolari, semplicemente se i dati presentati è corretto. Non è così complesso come sembra - L'ultimo che ho scritto è stato di circa 600 o 700 righe di codice T-SQL. Lo stesso vale per qualsiasi funzione di lavaggio generico.

  7. Se possibile, caricare in modo incrementale.

  8. Strumenta il tuo codice: fai in modo che inserisca le voci del registro, possibilmente registrando la diagnostica come il totale dei controlli o i conteggi. Senza questo, la risoluzione dei problemi è quasi impossibile. Inoltre, il controllo delle asserzioni è un buon modo di pensare alla gestione degli errori per questo (la riga conta in una riga uguale conta in b, la relazione A: B è in realtà 1: 1).

  9. Usa i tasti sintetici. L'uso di chiavi naturali dai sistemi di origine collega il sistema alle origini dati e rende difficile l'aggiunta di ulteriori fonti. Le chiavi e le relazioni nel sistema devono sempre allinearsi, senza valori nulli. Per gli errori "non registrati", inserire una specifica "errore" o "non registrati" nella tabella delle dimensioni e abbinarli.

  10. Se si crea un archivio dati operativo (oggetto di molte guerre di religione) non riciclare le chiavi ODS negli schemi a stella. Certamente unisci le chiavi ODS per costruire le dimensioni, ma abbina una chiave naturale. Ciò consente di eliminare e ricreare arbitrariamente l'ODS, possibilmente modificandone la struttura, senza disturbare gli schemi a stella. Avere questa capacità è una vera vittoria per la manutenzione, in quanto è possibile modificare la struttura ODS o eseguire una reimplementazione di ODS a forza bruta in qualsiasi momento.

I punti 1-2 e 4-5 indicano che è possibile creare un sistema in cui tutto del codice per un dato sottosistema (ad esempio un singolo dim

Ho esperienza con i processi ETL che raccolgono dati da oltre 200 database distribuiti in un database centrale su base giornaliera, settimanale, mensile e annuale. È un'enorme quantità di dati e ci sono molti problemi che abbiamo avuto specifici per la nostra situazione. Ma a mio modo di vedere, ci sono diversi elementi a cui pensare indipendentemente dalla situazione:

  • Assicurati di prendere in considerazione i blocchi dei file, sia sul lato di origine che su quello di destinazione. Accertarsi che altri processi non abbiano i file bloccati (e rimuovere quei blocchi se necessario e ha senso) è importante.

  • bloccando i file per te stesso. Assicurati, specialmente sulla fonte, di bloccare i file mentre estrai i dati in modo da non ottenere dati aggiornati a metà.

  • se possibile, estrarre delta, non tutti i dati. Ottieni una copia dei dati e poi tira solo le righe che sono cambiate invece di tutto. Più grande è il set di dati, più diventa importante. Guarda le riviste e i trigger se devi, ma poiché diventa più importante avere questi dati su una certa base, questo è probabilmente il consiglio numero uno che ti darei. Anche se aggiunge una notevole quantità di tempo al progetto.

  • registro di esecuzione. assicurati di sapere quando ha funzionato e quando non ha funzionato, e lanciare errori specifici nel processo può davvero aiutare nel debug.

  • documento, documento, documento. Se costruisci questo diritto, lo costruirai e poi non ci penserai a lungo. Ma puoi essere garantito, tu o qualcun altro dovrai tornare ad esso ad un certo punto per migliorarlo o fare una correzione di bug. La documentazione è fondamentale in queste situazioni.

HTH, aggiornerò male se penso ad altro.

Stiamo facendo un enorme ETL (spostando un client dalle app AS400 legacy a Oracle EBS), e in realtà abbiamo un processo che (con modifiche) posso consigliare:

  1. Identifica il target critico Tabelle / campi.
  2. Identifica il critico tabelle / campi di origine.
  3. Lavora con utenti aziendali a cui mappare la fonte di destinazione.
  4. Analizza i dati di origine per problemi di qualità.
  5. Determina chi è responsabile per problemi di qualità dei dati identificato.
  6. Avere parti responsabili ripulire i dati nella fonte.
  7. Sviluppa l'ETL effettivo in base al informazioni dai passaggi 1 - 3.

I passaggi più difficili sono 2 & amp; 3 nella mia esperienza - a volte è difficile indurre gli utenti aziendali a identificare correttamente tutti i bit di cui hanno bisogno in un unico passaggio e può essere ancora più difficile identificare correttamente da dove provengono i dati (sebbene ciò possa avere qualcosa a che fare con il criptico nomi di file e campi che vedo!). Tuttavia, questo processo dovrebbe aiutarti a evitare i maggiori incidenti.

Questo thread è vecchio, ma voglio attirare la tua attenzione sulla risposta di ConcernedOfTunbridgeWells. È un consiglio incredibilmente buono, su tutti i punti. Potrei ribadirne alcuni, ma ciò ridurrebbe il resto e tutti meritano uno studio approfondito.

Non affiliato a StackOverflow
scroll top