Una piattaforma SaaS unica, non tanti servizi da assemblare

Microsoft Fabric è una piattaforma di analytics end-to-end erogata come SaaS: a differenza del modello PaaS classico (dove componevi Azure Synapse, Data Factory, Databricks e Data Lake Storage separatamente), qui i workload vivono già integrati sopra una singola capacity. La capacity è l’unità di calcolo che acquisti (SKU F, es. F2, F64) e che alimenta tutti i workload in modo condiviso, senza provisioning di cluster o account storage dedicati per ciascun servizio.

Sopra la stessa capacity Fabric espone esperienze specializzate ma coese:

  • Data Engineering — Lakehouse, notebook Spark, pipeline di ingestion.
  • Data Warehouse — warehouse T-SQL con transazioni multi-tabella.
  • Real-Time Intelligence — Eventstream, Eventhouse/KQL per dati in streaming.
  • Data Science — esperimenti, modelli ML, integrazione MLflow.
  • Power BI — reporting e semantic model in modalità Direct Lake.

Il valore architetturale non è “avere tutti gli strumenti”, ma il fatto che condividono lo stesso storage e la stessa governance: niente copie tra sistemi, un solo modello di sicurezza, un solo layer di Microsoft Purview per lineage e sensitivity label.

OneLake: un solo data lake per tenant

OneLake è il fondamento dello strato di storage. La regola chiave: esiste un solo OneLake per tenant, provisionato automaticamente, che funge da “OneDrive per i dati”. Non lo acquisti a parte e non lo configuri: è incluso nella capacity e si popola man mano che crei item.

Caratteristiche architetturali da conoscere:

  • Lo storage fisico è Azure Data Lake Storage Gen2 sottostante, ma logicamente unificato: l’organizzazione avviene per workspace, non per account o container separati.
  • Il formato tabellare nativo e obbligatorio è Delta Lake (Parquet + transaction log). Che tu scriva da un Lakehouse Spark o da un Warehouse T-SQL, sotto trovi tabelle Delta. Questo è ciò che abilita Direct Lake in Power BI: il report legge i file Delta senza import né query passthrough.
  • OneLake è raggiungibile via OneLake API compatibili ADLS Gen2, quindi tool esterni (Azure Storage Explorer, abfss://) possono leggerlo come un normale filesystem.

Workspace e item

Il workspace è il contenitore di collaborazione e il confine di RBAC (ruoli Admin/Member/Contributor/Viewer). Ogni workspace mappa una cartella logica dentro l’unico OneLake. Dentro il workspace crei item: Lakehouse, Warehouse, Notebook, Pipeline, Eventhouse, Semantic model, Report. Ogni item è un oggetto governato singolarmente e riconducibile alla capacity che lo alimenta.

Shortcuts: virtualizzare, non copiare

Uno shortcut è un puntatore che espone dati residenti altrove come se fossero dentro il tuo Lakehouse, senza spostarli né duplicarli. È la leva architetturale per evitare pipeline di copia inutili.

  • Internal shortcut — riusa in un workspace dati di un altro Lakehouse/Warehouse dello stesso OneLake.
  • External shortcut — verso ADLS Gen2, Amazon S3, Google Cloud Storage, Dataverse o S3-compatibili.

I dati restano nella sorgente; Fabric legge on-demand. Usa shortcut quando la sorgente è già in Delta/Parquet e vuoi query immediate; scegli invece una pipeline/copy quando devi trasformare, deduplicare o cambiare formato.

Trappole tipiche d’esame

  • “Quanti OneLake servono per un tenant con 5 dipartimenti?” → Uno solo. OneLake è per-tenant; i dipartimenti si separano con workspace distinti, non con più data lake.
  • “Come ridurre i costi di storage di OneLake per il team analytics?” → OneLake non è un SKU separato: è incluso nella capacity. La domanda giusta punta a governare la capacity (F SKU) o a evitare copie, non a “comprare” o dimensionare OneLake a parte.
  • “Esporre dati di un bucket S3 in un Lakehouse senza duplicarli e senza pipeline giornaliera” → crea un external shortcut verso S3, non una Copy activity.
  • “Un report Power BI deve leggere le tabelle del Lakehouse con la massima freschezza e senza import” → usa Direct Lake sulle tabelle Delta; è possibile proprio perché tutti i workload condividono lo stesso formato in OneLake.
  • “Isolare l’accesso di un gruppo a un solo insieme di item” → agisci sui ruoli del workspace (confine RBAC), non provando a segmentare OneLake a livello di storage.