Come identificare e controllare il giorno di riferimento dei dati all’interno dei flussi di alimentazione di un Data Warehouse

1. Come identificare e controllare il giorno di riferimento dei
dati all’interno dei flussi di alimentazione
di un Data Warehouse.
Micro ETL Foundation

2. INTRODUZIONE
 In una presentazione di qualche tempo fa [1], avevo evidenziato l’importanza del controllo fra il giorno
di riferimento atteso e quello caricato. Vista l’importanza del tema, desidero approfondire ulteriormente
sia il significato del controllo, che quello del giorno di riferimento del dato.
 Questo argomento può sembrare ostico, o troppo tecnico, principalmente per chi non è molto esperto
di Data Warehouse o è alla sua prima esperienza. Proverò a semplificarlo il più possibile, perché è un
esempio molto utile per comprendere le insidie nascoste nel processo di caricamento ETL.
ESEMPIO
 Per comprendere bene il problema, ipotizziamo un esempio analogo di vita pratica. Supponiamo che
voi ricevete tutte le mattine, dalla vostra banca, via email, la lista dei vostri movimenti di conto
corrente. Ricevete quindi giornalmente un foglio excel con i movimenti del giorno precedente. Il giorno
di riferimento dei movimenti, è situato nell’oggetto della email, per esempio: “Movimenti del
2015.03.12”.
 Ovviamente voi non verificate tutte le mattine la email della banca: avete creato un automatismo che
apre la email e carica giornalmente i movimenti, con la data indicata nell’oggetto della email, nel
database delle vostre spese di casa. Solo all’inizio del mese iniziate a fare le vostre analisi sul mese
precedente. La domanda è:
 Quali garanzie avete che la email vi è arrivata tutti i giorni ?
 Quale garanzia avete che la data nell’oggetto della email faccia sicuramente riferimento al giorno
prima ?
.
2Micro ETL Foundation

3. L’IMPORTANZA DEL CONTROLLO
 Se non siamo in grado di rispondere alle domande precedenti, non abbiamo nessuna garanzia sulla
validità delle nostre analisi. Questo è il motivo perché il controllo è importante. Ecco perché dobbiamo
essere assolutamente certi che il giorno che stiamo caricando è esattamente quello che ci
aspettavamo. E, prima ancora, dobbiamo verificare che quello che ci aspettavamo è arrivato.
 Non dobbiamo dare per scontato che tutto sia corretto, perché è sempre possibile che si verifichi una
anomalia. Sia nei sistemi alimentanti che nei nostri sistemi.
 Non dimentichiamo, che a fronte di un problema, siamo sempre noi, inteso come il Data Warehouse
team, I primi interlocutori, le prime persone a cui si richiede una spiegazione. In pratica, agli occhi
degli utenti finali, siamo la causa del problema. Quelli che dovevano controllare e non l’hanno fatto.
 Ecco due esempi che si possono verificare. (e in realtà si sono proprio verificati)
PROBLEMA 1
 Nel Sistema alimentante c’è stato qualche revisione o cambiamento nei programmi di estrazione
(nessuno è tenuto ad avvisarvi), per cui si verifica un errore nel filtro dei dati.
 Conseguenza: il flusso viene generato giornalmente correttamente, ma la data di riferimento all’interno
del flusso è sbagliata. La causa non la conosciamo. Essa può rimanere fissa, indietro di un giorno,
uguale alla data di sistema, o si riferisce a un campo diverso da quello precedente.
 Solo se controlliamo il giorno di riferimento con il giorno atteso possiamo accorgerci dell’errore.
3Micro ETL Foundation

4. PROBLEMA 2
 Il processo ETL, tramite ftp, copia il file di alimentazione da una cartella host a una cartella locale per
elaborarlo. Supponete che la cartella host di alimentazione, che è una cartella utilizzata anche da altri
sistemi, per motivi di manutenzione o spazio, a partire da un certo giorno, non venga più alimentata,
sostituita da un’altra cartella.
 Nessuno vi avvisa, la vecchia cartella rimane comunque visibile, e il Data Warehouse, il giorno dopo
lo scambio, continua ad alimentarsi dalla vecchia cartella. Anche in questo caso, avere un controllo
immediato del giorno di riferimento è fondamentale.
 Oltretutto, se i dati che state caricando erroneamente sempre per lo stesso giorno, si mescolano ad
altri dati che invece cambiano giornalmente, scoprire questo genere di errore può non essere
immediato e può richiedere diversi giorni.
LA SOLUZIONE
 La soluzione prospettata nella presentazione già citata, per controllare la congruenza fra il giorno di
riferimento del dato e il giorno atteso nel flusso, era molto minimale, secondo le regole di una visione
“agile” per la costruzione di un Data Warehouse [2]. Erano sufficienti una tabella di metadati e una
tabella di log.
 La sua logica la possiamo rappresentare nella figura seguente. In pratica possiamo utilizzare una
tabella di configurazione di tipo “calendario”. In essa, per ogni giorno solare, si valorizza il giorno
atteso nel flusso giornaliero e il giorno di riferimento caricato.
 Una tabella di log mostra, alla fine del caricamento giornaliero, la congruenza delle due date. I nomi
fisici sono costruiti secondo i miei standard di Naming Convention [5].
4Micro ETL Foundation

5. 5Micro ETL Foundation

6. GLI ELEMENTI IN GIOCO
 Gli elementi in gioco in questo controllo sono quindi tre.
 Il primo è il giorno di calendario.
 Il secondo è il giorno atteso del flusso giornaliero. Questo lo dobbiamo configurare sulla base della
analisi dei flussi. Sappiamo la loro logica, per cui possiamo facilmente configurare il giorno atteso. Per
esempio, se il flusso non è previsto nel fine settimana, a fronte dei sabati e domeniche del giorno di
calendario, non sarà valorizzato il giorno atteso.
 Il terzo elemento in gioco è il giorno di riferimento del dato nel flusso giornaliero. Cioè il giorno da
confrontare con quello atteso per la verifica di congruenza.
IL GIORNO DI RIFERIMENTO DEL DATO
 Focalizziamo ora la nostra attenzione sul terzo elemento, cioè il giorno di riferimento dei dati. Dove si
trova questa informazione ?
 Sarebbe bello poter pensare che il giorno sia sempre presente direttamente come una colonna del
flusso. Questa dovrebbe essere una regola, una condizione di base.
 Purtroppo in un Data Warehouse, come al solito, niente è semplice, e il giorno di riferimento, il più
delle volte non è una colonna del flusso. La regola che abbiamo descritto, può valere solo se siamo
abbastanza fortunati da poter decidere noi i tracciati dei flussi.
 Il più delle volte, però, saremo costretti a riutilizzare (per risparmiare, ovviamente) flussi già
preesistenti, creati con regole diverse. Vediamo quali sono le situazioni che sicuramente dovremo
affrontare.
6Micro ETL Foundation

7.  Il giorno di riferimento è una colonna del flusso
 Il giorno di riferimento si trova nella testate del flusso di alimentazione
 Il giorno di riferimento si trova in coda al flusso di alimentazione
 Il giorno di riferimento si trova nel nome del flusso
 Il giorno di riferimento non c’è.
IL GIORNO DI RIFERIMENTO È UNA COLONNA DEL FLUSSO
 Questo è il caso più semplice e facilmente gestibile. La data è un campo chef a parte del flusso. Per
esempio una data di registrazione, una data di esecuzione di un ordine, una data fiscale.
 Tipicamente potete trovare questa situazione nei flussi che diventeranno, alla fine del processo ETL,
delle tabelle dei fatti.
7Micro ETL Foundation

8. IL GIORNO DI RIFERIMENTO SI TROVA IN TESTATA O IN CODA
 Tipicamente potete trovare questa situazione in flussi standardizzati, già presenti, generate, su
mainframe, da programmi in linguaggio cobol.
 Questi flussi possono avere varie righe di testate/coda con numerose informazioni in essa, compresa
la data di riferimento. In realtà, la data di riferimento presente in testata/coda, di solito, è la data di
creazione del flusso. Però, se i dati sono di tipo anagrafico, possiamo pensare che coincida con la
data di riferimento.
 Pensiamo a una anagrafica clienti. Se l’estrazione parte alle 22.00 del giorno 20150331, possiamo
pensare che congela la situazione della clientele al giorno 20150331, quindi la data di estrazione
coincide con la data di riferimento dei dati.
 Attenzione però ai casi in cui l’estrazione parte dopo la mezzanotte. In questo caso la data di
riferimento è uguale alla data di estrazione presente in testata/coda -1.
IL GIORNO DI RIFERIMENTO SI TROVA NEL NOME FLUSSO
 Questa è un caso abbastanza frequente, tipico sopra tutto per flussi di testo in formato csv.
IL GIORNO DI RIFERIMENTO NON C’È
 Dobbiamo considerare anche questo caso. A volte il flusso viene generato sempre con lo stesso
nome, (quindi escludiamo il caso precedente), forse ha una testata, ma senza l’informazione che ci
interessa. Possiamo solo affidarci alla data di sistema del server del Data Warehouse.
8Micro ETL Foundation

9. L’IMPORTANZA DEI METADATI
 Vediamo ora come fornire un metodo per gestire queste situazioni. Esso è facilmente implementabile
utilizzando esclusivamente un pò di linguaggio del Database (per esempio il pl/sql di Oracle, ma
queste tecniche si possono facilmente adattare a qualunque database) e un pò di metadati.
 I metadati, termine logico molto raffinato e intrigante, che nasconde quello che banalmente chiamiamo
tabelle di configurazione, sono fondamentali per gestire le casistiche che abbiamo descritto. I metadati
necessari per poter identificare ed estrarre la data di riferimento sono:
9Micro ETL Foundation

10.  row_num = con questo numero indichiamo l'offset di riga, a partire dall'inizio del flusso se si trova in
testata, in cui troviamo il giorno di riferimento. Il numero sarà negative nel caso in cui il giorno di
riferimento si trovi in coda.
 start_num = con questo numero indichiamo, all’interno del row_num, la posizione del carattere di
partenza del giorno di riferimento.
 size_num = con questo numero indichiamo la dimensione della data, se nel format YYYYMMDD sarà
8, nel format DD-MM-YYYY sarà 10. Evitate di usare I mesi in formato testo.
idf_txt = con questa stringa indichiamo il formato della data di riferimento. Per esempio
‘yyyy.MM.DD’.
 off_num = con questo numero indichiamo l'offset in giorni della data di riferimento. Questa
informazione è utile nel caso in cui la generazione del flusso e la sua elaborazione avvengono in
giorni differenti. Facciamo un esempio. Oggi è il giorno 14 e parte l'elaborazione del flusso. Il flusso è
stato generato ieri alle 22:00, in testata troviamo 13, e assumiamo che quello è il giorno di riferimento
dei dati. In questo caso off_num deve essere uguale a zero. Supponiamo ora che la generazione del
flusso dati avvenga dopo la mezzanotte per cui in testata troviamo 14. In questo caso off_num deve
essere impostato = -1, perché anche se la generazione e l'elaborazione del flusso è avvenuta dopo la
mezzanotte sicuramente i dati anagrafici fanno riferimento alla situazione del giorno 13. Questa, in
sintesi, è la necessità di questo campo.
 ref_day_cod = qui si inserisce, se c’è, il nome del campo del flusso che contiene il giorno di
riferimento.
10Micro ETL Foundation

11. 11Micro ETL Foundation

12. COME UTILIZARE I METADATI
 Definire i metadati, inserirli in una tabella di configurazione dei flussi e valorizzarne il contenuto, non è
una attività “passiva”. Cioè non serve solo a documentare la struttura dei flussi, ma è anche
informazione “attiva”, perché può essere utilizzata nei programmi di caricamento ETL.
 Facciamo un esempio concreto molto semplice. Un flusso di alimentazione, è solo una sequenza di
righe strutturate in colonne di dati. Possiamo rappresentarlo così:
 La prima cosa da fare per poter caricare un flusso è costruire una external table che “vede” il flusso,
con le stesse colonne e in più il campo tecnico <IO>_row_cnt che dà semplicemente un numero ad
ogni riga. <IO> è il codice del file di dati.
12Micro ETL Foundation

13.  La tabella di Staging Area deve avere ovviamente le stesse colonne della external table più il giorno di
riferimento DAY_COD. Se il giorno è già presente nel flusso, non importa. Inserite sempre una
colonna aggiuntiva DAY_COD.
 A questo punto, è possibile creare una funzione che, avendo come input il codice del flusso, entra
nella tabella di metadati ed estrae il valore del giorno di riferimento da inserire nella tabella di Staging
Area.
13Micro ETL Foundation

14. CONCLUSIONE
 Ho già avuto modo di sottolineare l’importanza del giorno di riferimento del dato. Un errore sulla sua
identificazione può compromettere la validità dell’intero Data Warehouse. Non dimentichiamo che:
 Sulla data di riferimento devono essere basate le politiche di versionamento delle dimensioni di
analisi (slowly changing dimension di tipo 2).
Sulla data di riferimento vengono partizionate le tabelle dei fatti. Un errore in fase iniziale può costare
molto caro nelle fasi successive del progetto.
 Quindi, al di là della soluzione tecnica, l’identificazione e il controllo del giorno di riferimento è un tema
molto importante in un progetto di Data Warehouse.
 La gestione della data di riferimento, esattamente come la gestione dei NULL [3] e come la
descrizione dei campi codice [4], di cui ho già parlato diffusamente, sembrano argomenti di poca
importanza e di scarso interesse.
 Ignorarli, però è molto pericoloso, e possono essere la causa di tanti fallimenti nel caso peggiore.
Oppure di pesanti ritardi nei tempi di messa in produzione nei casi più fortunati.
RIFERIMENTI
 [1] http://www.slideshare.net/jackbim/recipes-4-of-data-warehouse-staging-area-how-to-verify-the-reference-day
 [2] http://www.slideshare.net/jackbim/agile-data-warehouse-and-businness-intelligence
 [3] http://www.slideshare.net/jackbim/recipes-5-of-data-warehouse-the-null-values-management-in-the-etl-process
 [4] http://www.slideshare.net/jackbim/note-di-data-warehouse-e-business-intelligence-la-gestione-delle-descrizioni
 [5] http://www.slideshare.net/jackbim/tecniche-di-naming-convention-parte-1
14Micro ETL Foundation