Data Warehouse - Micro ETL Foundation - Quello che sapete sul processo ETL è falso

Il titolo che avete appena letto è volutamente provocatorio. Certamente non tutto è falso. La mia intenzione è quella di provare a vedere le cose sotto un altro punto di vista; non dare niente per scontato e provare a verificare in modo più critico certi assiomi tipici del mondo del Data Warehouse. Poiché i produttori di soluzioni informatiche che vendono tool per il caricamento dati sono sempre più numerosi, e i loro prodotti sempre più complessi, cercherò di fornire una visione diversa della realtà, mettendo in discussione le singole lettere del paradigma ETL.

Non dimentichiamo che  l’obiettivo della Micro ETL Foundation (MEF) è quello di fornire idee e soluzioni semplici, facilmente implementabili senza dover acquistare tool costosi e complessi. E’ quindi necessario approfondire più in dettaglio il significato del processo ETL.

Il processo ETL

Possiamo trovare molte definizioni di processo ETL. In generale, è un’espressione che si riferisce al processo di estrazione (Extract), trasformazione (Transform) e caricamento (Load) dei dati in un sistema di sintesi (data warehouse, data mart...). Questa è una definizione molto generica, che non aiuta a comprendere il lavoro che dobbiamo affrontare.  Un semplice disegno può aiutare a capire il processo. 

I dati presenti nelle strutture dei Sistemi Operazionali (OLTP) vengono estratti, trasformati e caricati nelle strutture del Data Warehouse.

Il processo ELT

Negli ultimi anni si è imposta anche un’altra definizione di processo di caricamento. La sua differenza è l’inversione della “L” con la “T”, cioè l’implementazione della fase di trasformazione DOPO la fase di estrazione.  Questa tendenza è legata alla necessità di caricare quantità di dati sempre più consistenti, e sulle capacità dei tool automatici di ETL di poterli trattare. Su molti dati, le trasformazioni, eseguite magari “al volo”, cioè in memoria o con l’aiuto di tabelle temporanee, possono essere problematiche. Risulta meno problematico caricare il flusso,così com’è, in una tabella di Staging e su questa applicare poi le trasformazioni.

Meglio ETL o ELT ?

Nell’ambito del progetto MEF, l’approccio ELT è quello più  in linea con la sua filosofia. Deve esistere uno stretto rapporto fra il flusso di alimentazione e la tabella di Staging. Questo rapporto deve essere 1:1 e il flusso deve essere il più completo possibile.

I limiti dei processi ETL ed ELT

Nonostante l’approccio ELT sia migliore, questo non significa che sia quello corretto.  Ovviamente in Internet potete trovare vari articoli e commenti relativi ai pro e contro i due approcci. A mio avviso, però, la realtà dei fatti è diversa. Il problema non è decidere se fare le trasformazioni prima o dopo il caricamento. Il problema è che entrambi i processi devono essere rivisti. Questo perché, nella pratica:

1.       Non esiste  la fase di estrazione 

2.       Non è presente la fase di configurazione e acquisizione

3.       Non è conveniente la fase di trasformazione

4.       Non è chiaro dove eseguire  il caricamento e quanti  ne eseguo.

Quindi, nonostante possiamo continuare a parlare genericamente di ETL (o di ELT), in fondo è un acronimo universalmente conosciuto da anni, dobbiamo essere consapevoli che tale nome è fuorviante nel caso in cui si voglia impostare un piano in cui siano presenti le tre fasi in un Gantt di progetto con delle stime associate.

Vediamo quindi di giustificare le 4 affermazioni precedenti.

Non esiste  la fase di estrazione 

Esiste veramente una attività di estrazione in capo al team di sviluppo del DWH ? Nella maggior parte dei casi, i sistemi alimentanti sono sistemi esterni che risiedono su server, magari con sistemi operativi diversi, e con Database e linguaggi di programmazione propri. La fase di estrazione, La E di extract, è sempre in carico al sistema alimentante, che sa come produrre il flusso. Quello di cui noi ci dobbiamo occupare realmente è eventualmente l’attività di Acquisizione o di Transfer, cioè il posizionamento e il salvataggio dei flussi di input in cartelle ben definite del server del DWH. Il tutto con una naming convention prestabilita.

La relazione con i sistemi esterni tramite ricezione di flussi è utilizzata dalla maggior parte dei progetti di Data Warehouse.

I casi di CDC (Change Data Capture) non sono così frequenti e comunque non coprono tutta la fase di alimentazione. Sono rari anche i casi in cui sia il DWH a costruire lo statement di estrazione del flusso e lo lanci direttamente in esecuzione tramite un database link.

Questo non viene fatto per motivi di sicurezza, per motivi di performance (chi conosce la struttura di indicizzazione dei sistemi esterni ?) e per motivi di responsabilità (se il dato non viene caricato, dove risiede il problema ?). E anche per motivi di scalabilità. In tempi di riduzione del budget,è sempre più comune la possibilità di cambio dei sistemi operazionali o di parte dei sistemi sorgente. Avere un tracciato che rimane stabile a cui i sistemi esterni si devono adattare è sicuramente una scelta che mantiene la stabilità.

Definizione e configurazione

La vera prima fase di un processo di caricamento, è la definizione e configurazione dei flussi di input. La prima fase da prendere in considerazione (e non è semplice) è la fase di definizione dei flussi e la loro configurazione in tabelle di metadati. Sarà il sistema alimentante a fornirci le definizioni in documenti word,excel o pdf.

Si deve poi dare una identificazione univoca del flusso, non numerica, valida per tutti i sistemi alimentanti.

E’ importante l’univocità a livello enterprise. Se abbiamo un flusso di movimenti titoli, chiamiamolo TMOV.  Se abbiamo più flussi, per esempio giornaliero, mensile, trimestrale, chiamiamoli DTMOV, MTMOV, QTMOV. Se abbiamo due sistemi alimentanti che forniscono i giornalieri, chiamiamoli XDTMOV, YDTMOV, per distinguerli, ma sempre un nome univoco come riferimento e su cui costruiremo una chiave primaria.

In questa fase dovremo configurare tutte le caratteristiche dei flussi, non solo la loro struttura colonnare.

Non trasformazione ma arricchimento

Analizziamo ora la lettera T, cioè la componente Transform del processo. La mia opinione è che non dovremmo parlare di trasformazione ma di arricchimento del dato.

Trasformare il dato, significa renderlo diverso da quello originale: questo ha come conseguenza una difficoltà nel controllo del dato.

Dobbiamo essere sempre in grado di dimostrare che il dato che abbiamo ricevuto in input, è identico a quello che abbiamo caricato nel DWH. Subito dopo il passaggio in produzione, ci saranno sicuramente delle richieste di verifica a cui dovremo rispondere. Se il dato originale è stato trasformato, dovremo  perdere del tempo per cercare i flussi alimentanti (magari già archiviati su nastro) e rifare le verifiche.  Se invece conserviamo i dati originali e li arricchiamo con il risultato della trasformazione, saremo in grado di dare risposte in modo più, efficiente e veloce. Quindi il mio consiglio è:

1 – mantenere sempre il dato originale nella tabella di staging area (e ,se possibile anche dopo)

2 – non effettuare trasformazioni ai dati esistenti, ma aggiungere dei campi che contengano il risultato della trasformazione

3 – Arricchimento è la parola giusta: se l’arricchimento lo eseguo aggiungendo, trasformando o aggregando dati diversi è solo una conseguenza dei requisiti.

4 – Implementare la fase di arricchimento non come fase di staging, ma come fase successiva, solo dal termine dell’intera fase di staging. Questo perché spesso, l’arricchimento prevede l’utilizzo di dati provenienti da altre tabelle di staging area.Per evitare di implementare delle regole di precedenza o di controllo di arrivo, è senz’altro preferibile attendere il completamento di tutta la fase di staging.

Dove caricare

La fase di Load è molto generica, in quanto non dice dove caricare. Conviene fare mente locale e decidere da subito dove caricare, perché tale scelta determinerà quale dei due approcci fondamentali in ambito Data Warehouse verrà adottato. Sono passati molti anni, ma tale scelta continuerà a dividere la comunità internazionale. Approccio Innmon  o approccio Kimball ?

Vogliamo avere una architettura comprensiva di ODS (Operational Data Store) che conservi i dati di dettaglio più una architettura dimensionale per i dati di sintesi, o preferiamo avere una unica struttura dimensionale per entrambi ? Ognuno può decidere secondo la propria esperienza, le proprie tempistiche e il proprio badget. Non faccio mistero, avendo utilizzato entrambe le metodologie, della mia preferenza verso la validità del metodo Kimball.

Comunque, a prescindere dal metodo utilizzato, sicuramente la prima struttura da caricare è la Staging Area,che per prima, accoglierà i flussi di input. 

L’argomento Staging area è molto vasto. Solo qualche consiglio.

Staging load

Eseguire il caricamento della tabella di staging deve essere il più semplice possibile.Una inserzione netta dal flusso, intermediato eventualmente da qualche struttura logica, alla tabella finale. Qualche piccola trasformazione “sintattica” si può fare, ma deve essere di formato, non di sostanza.

Il load deve essere sempre preceduto dalla pulizia della tabella di staging. Evitate di accumulare sulla stessa tabella, più flussi dello stesso tipo che per qualche motivo non sono stati processati e si sono accumulati.

Se si può, processateli sempre uno per volta (fino alla fine dell’intero processo di caricamento del DWH) o, eventualmente, accumulateli, a mano o con un automatismo, in un unico flusso. Non dimentichiamo che dobbiamo eseguire dei controlli molto accurati su tali flussi. Quindi, anche un banale controllo sulla congruenza del numero di righe caricate e quelle presenti nel flusso, sarà molto più difficile se la tabella di staging contiene le righe di numerosi flussi di input.

Conclusione

Quindi, in conclusione, continuiamo pure a parlare di ETL, ma teniamo in mente che, nella pratica, esso nasconde un acronimo diverso che possiamo sintetizzare con: CALEL

1 - Configuration

2 - Aquisition

3 - Load (Staging Area)

4 - Enrichment

5 - Load (Data Warehouse)

Il tutto lo possiamo rappresentare graficamente in questo modo: