Alle grandi organizzazioni non mancano i dati: manca l'accesso ai dati. Ogni unità estrae i propri report dal proprio database, il team di analisi deve ottenere autorizzazioni ed estrazioni da più responsabili dei dati per ogni nuova domanda, e quando due report mostrano numeri diversi per la stessa metrica, servono settimane per capirne il motivo. Il data warehouse tradizionale ha risolto parte del problema, ma per dati semi-strutturati, eventi dei sensori, immagini e testo, o per i carichi di lavoro di machine learning, la sua struttura rigida e i suoi costi diventano l'ostacolo.
L'importanza si è moltiplicata con l'arrivo dell'IA nelle imprese. I modelli hanno bisogno di dati storici e diversificati di qualità nota e devono poter accedere ai dati grezzi, non solo ai riepiloghi dei report. I requisiti di audit e responsabilità impongono inoltre che un'organizzazione sappia dire da quale fonte, tramite quale trasformazione e in quale momento sia stato prodotto un numero in un report. Un data lake, costruito correttamente, risponde a entrambe le esigenze: ampio accesso per l'analisi e la modellazione, e lineage chiaro per la fiducia.
Un data lake moderno è solitamente progettato in più zone successive. La zona raw conserva i dati esattamente come sono arrivati dalla fonte, tramite caricamento batch o flusso di eventi. La zona cleansed ricostruisce i dati con uno schema esplicito, tipi standard e chiavi di riferimento come l'identificativo golden del soggetto. La zona curated costruisce modelli di dati orientati al tema, come cliente, transazione o campo agricolo, destinati ad analisi, dashboard e modelli. Accanto a queste, un catalogo dati registra dataset, responsabili, qualità e lineage, mentre un livello di accesso applica le autorizzazioni in base al ruolo.
La prima considerazione pratica riguarda titolarità e qualità. Ogni dataset nel lake deve avere un responsabile designato nel business, che risponde della sua definizione, qualità e ciclo di vita. Le regole di qualità, come completezza, univocità e intervalli ammessi, dovrebbero essere eseguite automaticamente a ogni caricamento, con l'esito pubblicato nel catalogo. Ad esempio, se il caricamento giornaliero delle transazioni arriva improvvisamente con la metà del volume abituale, il sistema dovrebbe generare un allarme prima dell'aggiornamento delle dashboard, anziché lasciare che i manager scoprano un numero errato al mattino.
La seconda considerazione riguarda il collegamento con l'anagrafica master dei soggetti e con gli eventi. Un lake che conserva i dati con gli identificativi locali di ciascun sistema ha semplicemente raccolto la frammentazione in un unico luogo. Il valore reale emerge quando, nella zona cleansed, ogni record è collegato all'identificativo condiviso della persona, del prodotto o del luogo. Alimentare il lake tramite la piattaforma di eventi, anziché estrarre direttamente dai database operativi, riduce inoltre il carico su quei sistemi e porta l'aggiornamento dei dati da notturno a quasi in tempo reale, cambiando ciò per cui il lake può essere utilizzato.
La terza considerazione riguarda il consumo. Un data lake utilizzato solo dal team dati ha fallito. Il livello di erogazione deve fornire dashboard e report ai manager, query interattive agli analisti e accesso programmatico a data scientist e modelli, il tutto su un'unica definizione condivisa delle metriche. Un livello semantico che conserva la definizione ufficiale di ciascuna metrica impedisce che lo stesso concetto venga calcolato in modo diverso in luoghi diversi ed elimina alla radice la discussione su quale report riporti il numero corretto.
Le insidie più comuni sono note. Primo, la palude di dati: riversare tutto senza catalogo, responsabili o regole di qualità, finché nessuno sa più cosa si trovi dove né di cosa ci si possa fidare. Secondo, costruire il lake come progetto IT senza un caso d'uso di business specifico, che si conclude dopo un anno con una massa di dati e nessun consumatore. Terzo, trascurare il controllo degli accessi a livello di colonna e di riga, trasformando il lake nel principale punto di fuga di dati sensibili dell'organizzazione. Quarto, ignorare i costi di archiviazione ed elaborazione, che senza una policy di conservazione crescono senza limiti.
In Niadad, la piattaforma Darya («دریا») è il data lake aziendale: zone raw, cleansed e curated, un catalogo dati con responsabili e lineage, regole di qualità automatizzate e un collegamento alla piattaforma di eventi per un'alimentazione quasi in tempo reale. Binesh («بینش») è il livello di business intelligence che fornisce dashboard, report e analisi interattive su Darya con definizioni condivise delle metriche. Le due piattaforme sono utilizzate nel progetto di agricoltura intelligente di Niadad per combinare letture dei sensori, dati meteorologici e registri agronomici, e la stessa architettura ricorre nei progetti bancari e urbani di Niadad.
Un data lake diventa un asset quando possiede tre elementi contemporaneamente: governance, collegamento a un'identità condivisa e consumatori reali. Senza governance è una palude; senza identità condivisa è un magazzino di frammentazione; senza consumatori è un costo. Con tutti e tre, è la base su cui si costruiscono l'analisi, l'IA e la responsabilità dell'organizzazione.