ETL

ETL è l'acronimo di Extract, Transform, Load (estrazione, trasformazione, caricamento) e descrive il processo di prelievo dei dati dai sistemi di origine, la loro conversione in una struttura coerente e il loro caricamento in una destinazione, come ad esempio un data warehouse. Rappresenta l'infrastruttura alla base dell'analisi dei dati e la sua affidabilità determina se i report creati su di essa siano attendibili.

Ogni fase presenta difficoltà specifiche. L'estrazione deve acquisire dati da sistemi non progettati per essere interrogati esternamente, gestendo i limiti di frequenza delle API, il rilevamento incrementale delle modifiche e fonti che non offrono un metodo affidabile per identificare le modifiche apportate. La trasformazione deve conciliare formati incoerenti, identificatori diversi, definizioni contrastanti e valori mancanti. Il caricamento deve gestire volumi elevati, mantenere la cronologia e gestire i record che arrivano in ritardo o fuori ordine.

La variante ELT inverte le ultime due fasi, caricando i dati grezzi nella destinazione e trasformandoli lì. Questa pratica è diventata comune perché le moderne piattaforme di data warehouse dispongono di una capacità di elaborazione sufficiente a rendere efficiente la trasformazione in loco e perché la conservazione dei dati grezzi consente di rivedere e riapplicare le trasformazioni senza doverle estrarre nuovamente dalle sorgenti. Inoltre, significa che gli errori nella logica di trasformazione sono recuperabili anziché permanenti.

L'elaborazione incrementale è la necessità pratica che complica la maggior parte delle implementazioni. Rielaborare tutti i dati storici a ogni esecuzione è semplice, ma diventa impraticabile con l'aumentare del volume dei dati; pertanto, le pipeline devono identificare cosa è cambiato dall'ultima esecuzione. Fonti prive di timestamp di modifica affidabili, record aggiornati retroattivamente ed eliminazioni che non lasciano traccia rendono questo processo più difficile di quanto sembri, e una logica incrementale errata produce silenziosamente dati incompleti.

La gestione degli errori determina se una pipeline è adatta all'ambiente di produzione. Le pipeline si bloccano regolarmente perché i sistemi sorgente modificano i propri schemi, le credenziali scadono, i servizi a monte non sono disponibili o arrivano dati imprevisti. Le proprietà fondamentali sono che gli errori vengano rilevati immediatamente, che le esecuzioni parziali non lascino la destinazione in uno stato incoerente, che le riesecuzioni producano lo stesso risultato anziché duplicare i record e che qualcuno venga avvisato anziché scoprire l'errore solo quando un report appare errato.

La validazione della qualità dei dati dovrebbe essere effettuata all'interno del processo di elaborazione, non alla fine. Verificare il numero di righe rispetto alle aspettative, accertarsi che i campi chiave siano compilati, confermare che i valori rientrino in intervalli plausibili e testare la coerenza referenziale permette di individuare le anomalie fin dal punto di inserimento. Senza questi controlli, i dati errati si propagano nei report e nelle decisioni, e vengono in genere scoperti da qualcuno che nota una cifra non plausibile settimane dopo.

La pianificazione e la gestione delle dipendenze determinano la coerenza dell'output. Le pipeline raramente vengono eseguite in isolamento e un'attività a valle che inizia prima che la sua origine a monte sia terminata produce risultati parziali che sembrano completi. Esistono strumenti di orchestrazione per esprimere esplicitamente queste dipendenze e le pipeline concatenate in base a presupposti temporali piuttosto che a dipendenze dichiarate falliscono in modo intermittente e difficile da riprodurre.

La documentazione e la tracciabilità sono fondamentali perché i sistemi di elaborazione dati sopravvivono a chi li crea. Conoscere l'origine di ciascun campo, le trasformazioni applicate e le regole aziendali codificate è essenziale per rispondere a domande sul perché un dato numerico abbia un determinato aspetto e per valutare l'impatto di eventuali modifiche al sistema di origine. I sistemi di elaborazione dati non documentati diventano sistemi che nessuno osa modificare, ed è così che le organizzazioni si ritrovano con sistemi paralleli che producono risultati contrastanti.

Poiché l'affidabilità, piuttosto che la sofisticazione, determina il valore fornito, la disciplina ingegneristica applicata alle pipeline dovrebbe corrispondere a quella applicata al software di produzione. In pratica, le pipeline sono costruite e gestite da sviluppo del prodotto oppure Reparto IT, la codifica della logica di trasformazione delle definizioni aziendali è specificata con analisi dei datie le regole di validazione è meglio concordarle prima che venga costruita la prima pipeline, piuttosto che aggiungerle dopo il primo incidente.