Quando lavori con i dati su Azure, una delle prime decisioni riguarda come archiviarli e in quale formato. La scelta del formato del file influenza direttamente costi, velocità di query e facilità di integrazione. In questa unità confrontiamo i formati testuali con quelli ottimizzati per l’analisi e vediamo la differenza fondamentale tra archiviare i dati in un file system e in un database.
Formati testuali (human-readable)
I formati testuali memorizzano i dati come testo semplice, sono leggibili da una persona e universalmente supportati. Sono ideali per scambio dati, importazioni ed esportazioni, ma poco efficienti su grandi volumi.
- CSV (Comma-Separated Values): dati tabellari separati da virgola. Compatto, semplice, perfetto per esportazioni e fogli di calcolo. Non descrive i tipi di dato.
- TSV (Tab-Separated Values): come il CSV ma con separatore di tabulazione, utile quando i valori contengono virgole.
- JSON: struttura a coppie chiave-valore, gerarchica e annidata. È il formato tipico dei dati semi-strutturati e delle API REST.
- XML: struttura gerarchica basata su tag, più verboso del JSON, storico ma ancora usato in sistemi legacy e configurazioni.
CSV e TSV rappresentano dati strutturati (tabellari, righe e colonne), mentre JSON e XML gestiscono bene i dati semi-strutturati, dove ogni record può avere campi diversi.
Formati ottimizzati per l’analisi
Questi formati sono binari (non leggibili a occhio) e progettati per i workload analitici su big data. Comprimono i dati e memorizzano lo schema internamente.
- Parquet: formato columnar (orientato alle colonne). Standard de facto per data lake e analytics.
- ORC (Optimized Row Columnar): anch’esso columnar, molto usato in ambienti Hive/Hadoop.
- Avro: formato row-based (orientato alle righe) con schema incorporato. Ottimo per la scrittura, lo streaming e lo scambio di messaggi (es. eventi in ingresso).
Perché il columnar è efficiente per l’analisi
Nei formati columnar come Parquet i valori di una stessa colonna sono memorizzati insieme. Questo porta due grandi vantaggi:
- Compressione elevata: valori simili vicini si comprimono molto meglio, riducendo costi di storage e I/O.
- Column pruning: una query analitica che aggrega poche colonne (es.
SUM(vendite)) legge solo quelle colonne, ignorando le altre. Meno dati letti dal disco significa query più veloci.
I formati row-based (CSV, Avro) sono invece più adatti quando devi scrivere o leggere interi record — come nelle applicazioni transazionali o nell’ingestione di eventi.
Due grandi tipi di data store
A livello concettuale i dati si archiviano in due modi:
- File system / data lake: i dati vivono come file in un object storage. Su Azure il servizio è Azure Data Lake Storage Gen2 (basato su Azure Blob Storage). È lo store ideale per dati grezzi, di qualsiasi formato e volume, con approccio schema-on-read (lo schema si applica al momento della lettura). Economico e scalabile, è il cuore di soluzioni come Microsoft Fabric.
- Database: i dati sono organizzati e gestiti da un motore, con schema-on-write (lo schema è imposto in scrittura), transazioni e query ottimizzate. Comprende sia i database relazionali (es. Azure SQL) sia quelli NoSQL (es. Azure Cosmos DB).
In pratica, un data lake conserva grandi quantità di file (spesso Parquet) a basso costo, mentre un database garantisce coerenza, integrità e query strutturate su dati già modellati.
Trappole tipiche d’esame
- Scenario: devi archiviare grandi volumi di dati per query analitiche efficienti in un data lake → risposta: usa Parquet (columnar, compresso, veloce sulle aggregazioni), non CSV.
- Scenario: devi esportare una tabella per aprirla in Excel o passarla a un altro sistema in modo leggibile → risposta: usa CSV, non Parquet o Avro.
- Scenario: ricevi dati annidati e a schema variabile da un’API REST → risposta: è formato semi-strutturato, tipicamente JSON.
- Scenario: devi scrivere/ingerire flussi di eventi record per record con schema incorporato → risposta: Avro (row-based), non un formato columnar.
- Scenario: serve archiviare file grezzi di qualsiasi tipo a basso costo, applicando lo schema solo alla lettura → risposta: un data lake (Azure Data Lake Storage Gen2), non un database relazionale.