Data Warehouse - Micro ETL Foundation - Il caricamento flussi nel processo ETL

All’interno del processo ETL, il caricamento di un flusso sembra un’operazione abbastanza semplice. Scopriamo perchè non è così.


Drill 1

Il caricamento di un flusso lo possiamo rappresentare con il grafico della figura 1.   Un grafico di quel tipo sarà presente in quasi tutte le presentazioni di una soluzione di Data Warehouse e Business Intelligence. Magari sarà più generalizzato indicando un insieme di flussi, un processo elaborativo e delle tabelle finali di Staging Area. Comunque lo si voglia rappresentare è una piccola frazione del processo ETL  di  caricamento di un DWH. 

A guardarlo bene sembra banale:  c’è un flusso dati indicato come x.txt ( un’estensione di quel genere ci indica facilmente che è un flusso di testo ). C’è una tabella di Staging Area indicata come x_dat. E c’è la procedura P che si occuperà di caricare i dati del flusso di input nella tabella di Staging Area. Il caricamento del flusso X sarà sicuramente presente nel Gantt di progetto con associato un numero di giorni previsto. Quel numero di giorni moltiplicato per il numero di flussi darà una stima approssimativa dell’effort necessario per il caricamento della Staging Area. La stima unitaria probabilmente sarà un numero piccolo:  in fondo si tratta di creare una tabella e una procedura che la carica.  

Adesso però usciamo dal mondo ideale delle slides  tipico dell’ambito commerciale, ed entriamo nella realtà dei dati per scoprire  perché quella stima è sicuramente sbagliata. 

Nelle prossime considerazioni utilizzerò il concetto di external table di Oracle, cioè di una struttura dati che “ vede” un flusso di testo come fosse una tabella. Comunque anche altri database hanno concetti simili o riconducibili ad esso.

Drill 2

In questa figura notiamo la presenza della external table  x_ext. Quindi è necessario creare questa nuova struttura affinché la procedura di caricamento possa caricare la tabella di Staging Area. La tabella esterna è un concetto logico, non occupa spazio fisico, e deve essere costruita sulla base della struttura del flusso dati di input. La figura 1 quindi, si è un po’ complicata. Poca cosa, comunque, soltanto una struttura in più da prendere in considerazione. Vediamo ora perché anche questo disegno è incompleto.

Drill 3

Non è usuale che il flusso dati visto dalla external table  possa essere caricato direttamente, senza alcun ulteriore intervento, nella tabella finale. 

Forse può accadere per qualche semplice tabella descrittiva di due colonne, ma in genere, tutti i flussi di alimentazione importanti (per intenderci, quelli che diventeranno tabelle dimensionali o tabelle dei fatti) hanno bisogno di qualche intervento aggiuntivo. 

Ecco perché è necessaria, nella figura 3, una nuova struttura X_ENV. Essa è una vista che adatterà i dati secondo le regole e gli standard interni del Data Warehouse.

Un esempio semplice sono le date. Io consiglio che tutte le date siano sempre strutturate secondo un unico standard, cioè nel formato yyyymmdd. Nei flussi di input,  difficilmente sarà presente un formato di quel tipo. E’ molto più probabile che le date siano in altri formati,  per esempio dd-mm-yyyy, dd/mm/yyyy o yyyy-mon-dd:  in questi casi la vista effettuerà le trasformazioni necessarie. 

Un altro esempio può essere il formato di un codice, che nel flusso di input è un numero, ma nelle tabelle del  Data Warehouse deve essere un alfa numerico preceduto da tanti zeri per la lunghezza del codice. 

Queste piccole trasformazioni possono essere numerose, e la vista è un ottimo strumento per effettuarle, in quanto è anch’essa una struttura logica e quindi non occupa spazio fisico. Se siamo fortunati la figura 3 potrebbe essere quello definitiva, ma nella maggior parte dei casi anche essa sarà incompleta. Procediamo quindi con l’analisi.

Drill 4 

Molto spesso le informazioni presenti nel flusso di input non sono sufficienti per ottenere un dato utilizzabile. Facciamo qualche esempio. 

Un caso semplice può essere la descrizione di un codice. Nel flusso di input è presente il codice, ma la descrizione di quel codice è presente in una qualche tabella di lookup del Data Warehouse.  Poiché  nella tabella di Staging Area voglio avere sia il codice che la descrizione, sarà necessario costruire una ulteriore vista che metta in join quella vista nella figura 3 con la tabella di lookup. 

Un altro esempio tipico è la presenza di un codice esterno diverso dal codice interno di riferimento nel Data Warehouse . Prendiamo un codice di titolo finanziario. Spesso in una banca si utilizzano dei codici interni come riferimento titolo, ma il flusso di alimentazione, che magari arriva da una società di fondi, utilizza un codice internazionale (ISIN).  Anche in questo caso sarà necessario per mezzo della vista, recuperare il codice interno da qualche altra tabella di mapping, prima di caricare la tabella di Staging Area. 

Come potete vedere, al quarto passo cognitivo, la figura 1 si è sicuramente complicata: sono presenti più strutture e più logiche da considerare. Purtroppo non è finita qui.

Drill 5 

Come sappiamo, nella Staging Area, devono avvenire tutte le trasformazioni necessarie per avere un dato finale pulito e completo, affinché si possano successivamente caricare le strutture dimensionali tipiche di un Data Warehouse.   

Queste trasformazioni non sempre si riescono a espletare con delle semplici viste; spesso gli arricchimenti di dati, simili a quelli descritti nel Drill 4, sono più complicati. Richiedono elaborazioni anche più complesse che vi costringono, nel caso peggiore, a caricare tutto quello che è stato definito nel Drill 4 in una tabella temporanea di appoggio, su cui poi applicare queste ulteriori elaborazioni che porteranno al caricamento finale della tabella di Staging Area. 

Un esempio di queste situazioni è la mancanza di un codice importante, per esempio il codice NDG anagrafico di un cliente. Questo codice però deve essere presente nella tabella conclusiva. In questi casi sono necessarie elaborazioni particolari per desumere quel codice dagli altri codici presenti nel flusso o altrove, e inserirlo nella tabella temporanea. 

Tipico è il caso del flusso di saldo dei conti correnti, in cui sono presenti degli importi numerici e il codice conto, ma il codice cliente non è presente e deve essere cercato altrove. 

E’ vero che non tutti i flussi necessitano di elaborazioni così complesse, ma è anche vero che la necessità di post-elaborazioni emerge solo dopo avere fatto le stime, cioè dopo avere verificato nel dettaglio la qualità dei dati di input. 

Per cui è sempre meglio essere pessimisti. 

Se osserviamo la figura 5 attentamente, siamo sicuri di non avere dimenticato qualcosa ? La risposta è no. Abbiamo dimenticato di rappresentare nel disegno, la parte più importante del processo, cioè  la configurazione e il controllo della elaborazione.

Drill 6

In questa figura è stata aggiunta una tabella di configurazione X_CFT, che a mio avviso deve essere sempre presente per documentare nella base dati la struttura dei flussi esistenti, e una tabella di log X_LOG, anch’essa sempre presente, per indicare l’esito del “banale” caricamento indicato nella figura 1. 
Essa, per esempio, dovrà avere informazioni  relative al numero di righe elaborate, eventualmente scartate, la data in cui è avvenuto,ecc.
Ovviamente le tabelle di log potrebbero essere più di una. Per esempio potrebbe essere presente quella che fornisce il dettaglio delle singole elaborazioni p0 e p1, quali l’esito della elaborazione, il tempo impiegato dal processing, ecc. 
Abbiamo finalmente il disegno conclusivo ? 
Possiamo ora stimare con più attenzione il tempo necessario a costruire tutte le strutture e le componenti elaborative della figura 6 ? 
Anche in questo caso la risposta è nuovamente no.

Drill 7

 

Torniamo alla figura 1 e guardiamo il flusso di alimentazione. Pensate che esso si materializzi magicamente nel posto e con il nome che noi vogliamo ? 
Certe  volte accade, ma nel 90% dei casi non è così, e sarà necessaria una ulteriore elaborazione per gestire lo spostamento, il nome del flusso, ed eventualmente di quello di controllo a lui collegato. 
Questa nuova elaborazione p0 può essere complessa, perché collegata alla gestione files del sistema operativo. Inoltre il flusso di input, a prescindere che sia con colonne a lunghezza fissa o con terminatore di colonna, può avere una intestazione più o meno lunga, un record di coda contenente il numero di righe presenti nel flusso (che deve essere controllato in qualche modo). A volte il numero di righe viene fornito in un flusso separato: e anche in questo caso questa situazione deve essere gestita. 
Senza contare le situazioni in cui la data di riferimento dei dati  è presente nel nome del flusso stesso o in una riga dell’intestazione  e non come campo del flusso.

Conclusione

Con la Micro ETL Foundation, non si desidera solo fornire soluzioni o idee, ma desidero rendere consapevoli progettisti, capi progetto, commerciali  e utenti finali della complessità legata a una soluzione di Business Intelligence, e in particolare al processo di caricamento ETL di un Data Warehouse. Il drill-down di comlessità evidenziato man mano che si prende coscienza della realtà dei fatti, è straordinario e inaspettato.

Che mai più si dica  “è solo il caricamento di un flusso”