OneLake: il data lake logico del tenant

OneLake è il fondamento dell’archiviazione in Microsoft Fabric: un unico data lake logico, provisionato automaticamente e in modo univoco per ogni tenant, senza doverlo creare o gestire. L’analogia ufficiale è quella di “OneDrive dei dati”: come OneDrive è lo storage condiviso e trasparente per i file di produttività, OneLake lo è per i dati analitici dell’organizzazione. Tecnicamente è costruito sopra Azure Data Lake Storage Gen2 ed espone le stesse API compatibili ADLS Gen2, quindi qualsiasi strumento che parla il protocollo ADLS (incluso azcopy, Databricks o Spark esterno) può leggerlo e scriverlo.

La struttura gerarchica è: tenant → workspace → item (Lakehouse/Warehouse) → cartelle e file. I workspace fungono da confine di governance e collaborazione, mentre gli item organizzano i dati. Il punto chiave d’architettura è “one copy”: un’unica copia fisica del dato può essere consumata da più engine (SQL, Spark, Power BI in modalità Direct Lake) senza duplicazione né spostamento.

Formato nativo aperto: Delta e Parquet

Fabric adotta Delta Lake (con file Parquet sottostanti) come formato tabellare nativo e aperto. Ogni tabella creata da un Lakehouse o da un Warehouse viene materializzata in OneLake come tabella Delta-Parquet. Questo garantisce:

  • Interoperabilità: nessun formato proprietario, i dati restano leggibili da qualsiasi engine Delta-compatibile.
  • Direct Lake per Power BI: query dirette sui file Delta senza import né DirectQuery, con performance in-memory.
  • Transazioni ACID e time travel a livello di tabella.

Lakehouse vs Warehouse

Fabric offre due workload analitici distinti sopra OneLake:

Lakehouse

Ambiente schema-on-read, orientato a data engineer e data scientist. Ingestione e trasformazione tramite notebook Spark, pipeline e dataflow; supporta dati strutturati e non strutturati (sezione Files + sezione Tables). Include un SQL analytics endpoint in sola lettura per interrogare le tabelle Delta con T-SQL.

Warehouse

Data warehouse T-SQL completo, con lettura e scrittura transazionale via SQL (INSERT/UPDATE/DELETE, multi-table transactions). È la scelta per team SQL-first e carichi di data warehousing classici. Anch’esso persiste in OneLake in Delta-Parquet.

Criterio di scelta d’esame: se lo scenario richiede trasformazioni Spark, ML o dati non strutturati → Lakehouse; se richiede T-SQL con scritture transazionali complete e modellazione dimensionale → Warehouse.

Shortcut: virtualizzare senza copiare

Gli shortcut di OneLake sono riferimenti (pointer) a dati esterni che appaiono nel Lakehouse come se fossero locali, senza copiarli né spostarli. Sono la funzionalità chiave per superare i silos.

  • Shortcut interni: puntano ad altri percorsi OneLake (altri Lakehouse/Warehouse nello stesso o altro workspace), abilitando il pattern one copy riutilizzabile in modo cross-workspace.
  • Shortcut esterni: puntano a ADLS Gen2, Amazon S3, Google Cloud Storage, Dataverse e altre sorgenti. I dati restano nella sorgente d’origine.

Al momento della lettura, i dati sono acceduti on-the-fly dalla sorgente. Questo elimina duplicazione, costi di ETL e drift, ma introduce implicazioni di governance e sicurezza che sono il cuore delle domande d’esame.

Fabric rispetto a Synapse e Databricks (2026)

  • Azure Synapse Analytics è il predecessore: Fabric ne è l’evoluzione SaaS end-to-end, che unifica Data Factory, Synapse Engineering/Warehouse, Real-Time Intelligence, Power BI e Microsoft Purview per la governance in un’unica piattaforma a licenza capacity-based (SKU F). Nuovi progetti nel 2026 partono da Fabric, non da Synapse.
  • Azure Databricks resta un PaaS Spark/Lakehouse enterprise di riferimento; convive con Fabric grazie al formato Delta comune e agli shortcut, che permettono di condividere la stessa copia dei dati in OneLake tra i due mondi senza migrazione.

Trappole tipiche d’esame

  • Shortcut ADLS Gen2/S3 e permessi: scenario “voglio esporre dati S3 nel Lakehouse minimizzando copie e costi” → usa uno shortcut esterno, NON una copy pipeline. Ricorda che l’accesso usa le credenziali di connessione dello shortcut (delegated), non i permessi dell’utente sulla sorgente originale.
  • Shortcut ≠ copia (governance): se cancelli i dati nella sorgente esterna, lo shortcut si rompe (non c’è copia locale); una copy invece è indipendente e sopravvive. Scegli lo shortcut solo quando accetti la dipendenza dalla sorgente.
  • Permessi ereditati interni: uno shortcut interno eredita e rispetta i permessi del target OneLake; concedere accesso al Lakehouse che ospita lo shortcut non basta se manca l’accesso al percorso puntato.
  • Direct Lake vs import: per Power BI su tabelle Delta di grandi dimensioni con minima latenza e senza duplicare i dati → Direct Lake, non import né DirectQuery.
  • Lakehouse endpoint è read-only: se lo scenario richiede scritture T-SQL transazionali, il SQL analytics endpoint del Lakehouse non basta → serve un Warehouse.