Immagina di dover raccogliere ogni giorno terabyte di dati eterogenei: log di applicazioni in formato JSON, file CSV esportati da gestionali, immagini, tracciati IoT, tabelle relazionali. Se dovessi decidere a priori uno schema rigido per ciascuna fonte, l’ingestione diventerebbe lenta e costosa. È qui che entra in gioco il concetto di data lake.
Che cos’è un data lake
Un data lake è un repository centralizzato che archivia grandi volumi di dati nel loro formato grezzo (raw), senza imporre una struttura al momento della scrittura. Accetta dati di qualsiasi natura:
- strutturati (tabelle con righe e colonne)
- semi-strutturati (JSON, XML, Parquet, Avro)
- non strutturati (immagini, video, documenti, audio)
Il principio chiave è lo schema-on-read: lo schema viene applicato solo quando i dati vengono letti ed elaborati, non quando vengono scritti. Questo lo distingue nettamente dal data warehouse.
Data lake vs data warehouse
| Aspetto | Data lake | Data warehouse |
|---|---|---|
| Schema | schema-on-read | schema-on-write |
| Tipo di dati | grezzi, di ogni tipo | curati, strutturati |
| Costo storage | basso | più elevato |
| Utenti tipici | data scientist, data engineer | analisti BI |
| Uso | esplorazione, ML, big data | reportistica, dashboard |
Il data warehouse (in Azure, tipicamente Azure Synapse Analytics o oggi Microsoft Fabric) richiede che i dati siano puliti, trasformati e modellati prima del caricamento (schema-on-write) e serve analisi affidabili e ripetibili. Il data lake, invece, privilegia flessibilità e scalabilità a basso costo, ideale per conservare “tutto” ora e decidere dopo come interrogarlo. Nella pratica moderna le due architetture convivono spesso nel modello lakehouse.
Azure Data Lake Storage Gen2
Azure Data Lake Storage Gen2 (ADLS Gen2) non è un servizio separato: è un insieme di capacità costruite sopra Azure Blob Storage. Si abilita creando uno storage account con l’opzione hierarchical namespace attiva.
Il valore dell’hierarchical namespace
Il Blob Storage standard usa un namespace piatto: i “percorsi” con le barre sono in realtà solo prefissi nei nomi dei blob, non vere cartelle. L’hierarchical namespace (HNS) aggiunge invece una struttura reale di directory e file, e questo porta vantaggi decisivi per i workload analitici:
- Operazioni atomiche a livello di directory (rinominare o spostare una cartella è un’unica operazione, non milioni di copie)
- Performance migliori per i motori big data (Spark, Hadoop, Databricks) che navigano gerarchie
- Sicurezza granulare tramite ACL POSIX su file e cartelle, oltre al RBAC di Microsoft Entra ID
- Compatibilità con il driver ABFS (
abfss://) usato dagli strumenti di analytics
In sintesi: Blob Storage è ottimo per storage a oggetti generico; ADLS Gen2 è Blob Storage ottimizzato per l’analitica grazie all’HNS.
Perché Parquet nel data lake
I dati nel lake vengono spesso salvati in Apache Parquet, un formato colonnare (columnar), diverso dai formati per riga come CSV o JSON. I motivi:
- Compressione efficiente: valori simili nella stessa colonna si comprimono molto bene, riducendo costi di storage
- Query più veloci: leggendo solo le colonne necessarie si riduce l’I/O (column pruning)
- Schema incorporato: il file porta con sé i tipi di dato, ideale per lo schema-on-read
- È lo standard de facto per Spark, Microsoft Fabric, Synapse e Databricks
Altri formati comuni sono Avro (orientato alla riga, buono per scritture/streaming) e ORC, ma per le letture analitiche Parquet è la scelta prevalente.
Trappole tipiche d’esame
- Devi archiviare grandi volumi di dati grezzi ed eterogenei (immagini, JSON, tabelle) senza definire prima uno schema → data lake / ADLS Gen2 (schema-on-read), non un data warehouse.
- Ti serve reportistica BI affidabile su dati puliti e strutturati con schema definito in anticipo → data warehouse (schema-on-write), es. Microsoft Fabric/Synapse.
- Vuoi abilitare workload analitici su Blob Storage con vere directory, rinominazioni atomiche e ACL granulari → attiva l’hierarchical namespace = ADLS Gen2, non Blob Storage standard.
- Formato da usare nel lake per query analitiche veloci e compressione ottimale → Parquet (colonnare), non CSV o JSON riga-per-riga.
- “Schema-on-read” è la caratteristica del data lake, mentre “schema-on-write” identifica il data warehouse: se lo scenario cita uno dei due termini, associa subito il servizio corretto.