Che differenza c'è tra data warehouse e data lake?

Data warehouse e data lake incarnano due filosofie opposte di gestione del dato. Il warehouse impone la struttura prima della scrittura: schema definito, dati puliti, query SQL veloci per report e BI. Il lake ribalta l'approccio: accoglie file grezzi in qualsiasi formato (tabelle, log, documenti, immagini) su storage economico, e la struttura si applica solo nel momento in cui i dati vengono letti. La scelta tra i due non è mai puramente tecnica: riflette chi userà i dati e per fare cosa, un analista che scrive query SQL su numeri già puliti oppure un data scientist che ha bisogno di accedere a log grezzi e file non strutturati per addestrare un modello. Per anni molte aziende hanno tenuto entrambi i sistemi in parallelo, con pipeline di sincronizzazione dedicate solo a tenerli allineati, un costo silenzioso che si è visto solo quando i due numeri, quello del warehouse e quello del lake, hanno smesso di coincidere durante un controllo.

Punti di forza e limiti

Il warehouse dà dati affidabili e coerenti: è il posto giusto per i numeri ufficiali dell'azienda. Il prezzo è un modello più stretto: i warehouse cloud interrogano ormai anche JSON e semi-strutturato senza modellazione a monte, ma restano fatti per dati tabellari e chiedono comunque una decisione esplicita su come rappresentare ogni nuova sorgente. I file veri e propri, immagini, audio, PDF, continuano a stare meglio su object store, dove costano meno e non vincolano il formato. Il lake costa poco e accoglie tutto subito, ed è l'habitat naturale della data science e dei dati non strutturati che alimentano l'AI. Il rischio è speculare: senza disciplina la flessibilità degenera nel data swamp, la palude di file che nessuno sa più interpretare né vuole toccare. La differenza si riflette anche sui profili: il warehouse parla la lingua degli analisti SQL, il lake quella dei data engineer e dei data scientist.

Perché la dicotomia si sta dissolvendo

Per anni la risposta standard è stata "entrambi", con pipeline di sincronizzazione nel mezzo, doppi costi e numeri che non tornano mai del tutto tra i due sistemi. Il data lakehouse è nato per chiudere quella forbice: storage da lake con garanzie da warehouse, ed è la direzione verso cui convergono Databricks, Snowflake, BigQuery e Microsoft Fabric. La scelta secca ha ancora senso ai margini: se il tuo fabbisogno è quasi solo BI su dati strutturati, un warehouse classico resta la soluzione più semplice da governare; un lake puro, da solo, si giustifica raramente, perché prima o poi qualcuno vorrà interrogarlo con garanzie da warehouse. La domanda giusta oggi non è "warehouse o lake", ma quali parti della tua piattaforma richiedono quali garanzie, e a quale costo.