Nel DP-700 la scelta tra Lakehouse e Warehouse è una decisione architetturale ricorrente: entrambi vivono dentro un workspace di Microsoft Fabric, entrambi persistono i dati in formato Delta Lake su OneLake, ma differiscono radicalmente per motore di scrittura, superficie T-SQL e profilo di team a cui si rivolgono. Capire chi scrive, come scrive e con quali garanzie transazionali è ciò che guida la risposta corretta.

Lakehouse: il mondo Spark-first

Il Lakehouse è pensato per team di data engineer che lavorano con Spark. La scrittura avviene tramite:

  • Notebook (PySpark, Spark SQL, Scala, R)
  • Dataflow Gen2 e Data pipeline (copy activity)
  • Shortcut verso dati esterni (ADLS Gen2, S3, ecc.) senza duplicazione

I dati risiedono come tabelle Delta nella zona Tables (managed, schema-enforced) o come file grezzi nella zona Files (utile per staging, formati misti, dati semi-strutturati). Questa dualità rende il Lakehouse la scelta naturale per pattern medallion (bronze/silver/gold), ingestion di grandi volumi e trasformazioni complesse che sfruttano il parallelismo Spark.

Il SQL analytics endpoint è in sola lettura

Ogni Lakehouse espone automaticamente un SQL analytics endpoint: una superficie T-SQL read-only che permette di interrogare le tabelle Delta con SELECT, creare view, definire stored procedure di lettura e gestire la sicurezza (GRANT/DENY, object-level, row-level, column-level security, dynamic data masking).

Il punto chiave: non consente DML T-SQL. INSERT, UPDATE, DELETE, MERGE da T-SQL sull’endpoint del Lakehouse falliscono. Se devi modificare i dati di un Lakehouse, lo fai a monte con Spark/notebook, non con comandi T-SQL. L’endpoint serve a consumare i dati (per Power BI in Direct Lake, per analisti SQL, per tool esterni via connection string), non a mutarli.

Warehouse: il mondo T-SQL completo

Il Warehouse è pensato per sviluppatori SQL e per chi arriva dal mondo SQL Server / Synapse dedicated pool. Offre la superficie T-SQL completa:

  • DML transazionale: INSERT, UPDATE, DELETE, MERGE
  • Transazioni multi-tabella con BEGIN TRANSACTION / COMMIT / ROLLBACK
  • Garanzie ACID su operazioni che toccano più tabelle contemporaneamente
  • DDL completo, stored procedure con logica di scrittura, CREATE TABLE AS SELECT (CTAS)

Anche il Warehouse persiste in Delta su OneLake, ma il motore di scrittura è nativo T-SQL, non Spark. Questo lo rende la scelta obbligata quando servono aggiornamenti transazionali, dimensioni a lenta variazione (SCD) implementate in SQL, o quando il team non conosce Spark e vuole operare interamente in T-SQL.

Come scegliere nello scenario d’esame

Ragiona su tre assi:

  • Profilo del team: data engineer con competenze Spark/Python → Lakehouse; sviluppatori SQL puri → Warehouse.
  • Requisiti di scrittura: ingestion massiva e trasformazioni Spark → Lakehouse; scritture e aggiornamenti transazionali via T-SQL → Warehouse.
  • Interoperabilità: puoi mescolare i due. Un Warehouse può leggere in cross-query le tabelle di un Lakehouse (e viceversa via shortcut/endpoint), quindi un pattern comune è Lakehouse per bronze/silver Spark + Warehouse per il gold layer serving con logica T-SQL.

Non lasciarti confondere dal fatto che entrambi “sono Delta su OneLake”: la differenza decisiva è quale motore scrive e se serve DML/transazioni T-SQL.

Trappole tipiche d’esame

  • Scenario: un analista deve fare UPDATE/DELETE in T-SQL sulle tabelle → risposta giusta: Warehouse. Sul SQL analytics endpoint del Lakehouse la DML T-SQL è read-only e fallisce.
  • Scenario: transazione che aggiorna più tabelle atomicamente (BEGIN TRAN … COMMIT) → Warehouse. Il Lakehouse non offre transazioni multi-tabella T-SQL.
  • Scenario: il team è composto da data engineer che ingeriscono TB di dati via notebook Spark e pipeline → Lakehouse, con scrittura via Spark, non tramite l’endpoint SQL.
  • Scenario: serve modificare i dati di un Lakehouse ma vieta l’uso di Spark → attenzione, l’endpoint SQL non basta; occorre riprogettare (notebook/dataflow) oppure spostare il carico su un Warehouse.
  • Scenario: Power BI in Direct Lake deve leggere tabelle solo in query → sia Lakehouse (via endpoint) sia Warehouse vanno bene per la lettura; la discriminante resta esclusivamente il requisito di scrittura transazionale T-SQL.