In Microsoft Fabric ogni tabella dei lakehouse è, per impostazione predefinita, una tabella Delta Lake. Comprendere come è fatta e perché è il formato che unifica tutti i motori di calcolo è il punto di partenza per progettare una piattaforma dati senza duplicazioni.

Anatomia di una tabella Delta

Una tabella Delta non è un formato proprietario: è una cartella su OneLake che contiene due elementi.

  • File di dati Parquet: colonnari, compressi, immutabili. Contengono i record effettivi.
  • Cartella _delta_log: una serie di file JSON (più checkpoint Parquet periodici) che costituiscono il transaction log. Ogni commit è un file numerato in modo crescente (00000000000000000000.json, ...001.json) che registra quali file Parquet vengono aggiunti o rimossi.

Il punto chiave è che i dati non vengono mai modificati sul posto: un UPDATE o DELETE scrive nuovi file Parquet e aggiorna il log indicando i file logicamente attivi. Lo stato “corrente” della tabella è la somma delle operazioni nel log, non i file fisici presenti nella cartella.

Il formato comune di OneLake

Poiché Delta è uno standard aperto costruito su Parquet, lo stesso set di file è leggibile — senza copie né conversioni — da tutti i motori di Fabric:

  • Spark (notebook, Spark job) legge e scrive Delta nativamente.
  • Il SQL analytics endpoint espone la stessa tabella in T-SQL in sola lettura.
  • Direct Lake in Power BI carica i file Parquet direttamente in memoria, senza import né query DirectQuery.

Questo è il valore architetturale: un unico dato fisico, molti motori. Nessuna pipeline di sincronizzazione tra data lake e data warehouse.

Transazioni ACID e versioning

Il transaction log garantisce proprietà ACID anche su storage object-based:

  • Atomicità: un commit riesce completamente o non lascia traccia.
  • Isolamento: letture e scritture concorrenti non vedono stati parziali grazie allo snapshot isolation.
  • Ogni commit produce una versione numerata della tabella.

Questa cronologia abilita il time travel: interrogare la tabella com’era in un momento precedente.

SELECT * FROM vendite VERSION AS OF 12;
SELECT * FROM vendite TIMESTAMP AS OF '2026-07-01T00:00:00';

In Spark si usa .option("versionAsOf", 12) o timestampAsOf. La disponibilità delle versioni passate dipende dalla retention del log e dai file non ancora rimossi da un’operazione di VACUUM.

Casi d’uso del time travel

  • Rollback: ripristinare la tabella dopo un caricamento errato con RESTORE TABLE ... TO VERSION AS OF.
  • Audit: ricostruire chi/cosa è cambiato confrontando versioni consecutive.
  • Riproducibilità: rieseguire un training di modello o un report su uno snapshot fisso, ottenendo risultati identici nel tempo.

V-Order

V-Order è un’ottimizzazione di scrittura specifica di Fabric: applica ordinamento, encoding e compressione ai file Parquet in modo compatibile con lo standard, migliorando drasticamente le velocità di lettura, in particolare per Direct Lake e il SQL endpoint. I file restano Parquet validi per qualsiasi lettore. È attivo di default; può essere disabilitato per workload write-intensive dove il costo di scrittura pesa più del vantaggio in lettura.

Managed vs external table

La distinzione riguarda chi possiede i dati:

  • Managed table: i file Parquet risiedono nell’area Tables/ gestita dal lakehouse. Fabric controlla ciclo di vita e storage; un DROP TABLE elimina anche i dati.
  • External (unmanaged) table: la definizione punta a una location esterna (un percorso in Files/ o un altro storage). Un DROP rimuove solo i metadati, non i file.

Le external table si usano quando i dati sono condivisi con altri sistemi, già presenti in un percorso specifico, o non devono essere cancellati insieme alla tabella. Le managed sono la scelta predefinita per pipeline interamente gestite dentro Fabric.

Trappole tipiche d’esame

  • Scenario: un notebook Spark e un report Power BI devono usare gli stessi dati senza copie → Direct Lake su una tabella Delta in OneLake; nessuna duplicazione né import.
  • Scenario: un MERGE notturno ha corrotto la tabella e serve tornare allo stato di ieri → RESTORE / time travel con VERSION AS OF o TIMESTAMP AS OF, non ricaricare da sorgente.
  • Scenario: il time travel su una versione vecchia fallisce → probabile VACUUM ha rimosso i file di quella versione; è un limite di retention, non un bug.
  • Scenario: query Direct Lake lente su tabella appena scritta → verificare che sia applicato V-Order; disabilitarlo solo se il collo di bottiglia è la scrittura.
  • Scenario: DROP TABLE deve preservare i file fisici perché condivisi con altri sistemi → definirla come external table, non managed.