Il falso problema del formato

La domanda “lakehouse o warehouse?” viene spesso posta come se riguardasse il formato di archiviazione. Non è così. In Microsoft Fabric entrambi gli artifact materializzano i dati come Delta table in OneLake, entrambi espongono un SQL analytics endpoint interrogabile in T-SQL, ed entrambi alimentano un semantic model in Direct Lake. Un report Power BI costruito su un lakehouse non è “meno veloce” per definizione di uno costruito su un warehouse.

La vera discriminante è come si scrivono i dati e quale modello di sviluppo adotta il team:

Aspetto Lakehouse Warehouse
Scrittura Spark (PySpark, Scala, Spark SQL), pipeline, dataflow, shortcut T-SQL DML: INSERT, UPDATE, DELETE, CREATE TABLE AS SELECT, COPY INTO
SQL analytics endpoint Read-only Lettura e scrittura
Transazioni multi-table No (Delta garantisce ACID sulla singola tabella) Sì, transazioni ACID cross-table
Dati non strutturati Sì, sezione Files (PDF, immagini, JSON grezzo, CSV) No, solo tabelle relazionali
Skill richieste Python/Spark, data engineering T-SQL, data warehousing classico
Direct Lake Supportato Supportato
Cross-database query Consuma altri artifact via endpoint Query cross-warehouse e cross-lakehouse native

Criteri di scelta operativi

Scegli il lakehouse quando

  • Il team lavora in PySpark/Python e usa notebook come strumento primario.
  • Devi ingerire dati non strutturati o semi-strutturati prima di modellarli: la sezione Files accetta qualunque cosa, poi la promuovi a Delta table.
  • Usi shortcut verso ADLS Gen2, Amazon S3, Google Cloud Storage o altri lakehouse per evitare la copia fisica dei dati.
  • Hai bisogno di feature Spark-native: streaming strutturato, MLflow, librerie Python di trasformazione.

Scegli il warehouse quando

  • Il team è composto da sviluppatori T-SQL senza competenze Spark.
  • Servono transazioni multi-table: aggiornare fact e dimension in un’unica unità atomica con BEGIN TRAN / COMMIT.
  • Vuoi scrivere trasformazioni interamente in T-SQL, senza notebook.
  • Stai migrando un data warehouse esistente (Azure Synapse dedicated SQL pool, SQL Server) e vuoi riusare le stored procedure.
  • Ti servono chiavi primarie ed esterne dichiarate (non enforced, ma utili al modello semantico e all’optimizer).

Il vincolo che decide quasi sempre

Se il requisito dice “gli sviluppatori devono aggiornare i dati con T-SQL”, la risposta è warehouse. Punto. Il SQL analytics endpoint del lakehouse permette SELECT e la creazione di viste e stored procedure, ma non INSERT/UPDATE/DELETE/MERGE sulle tabelle. Per modificare una tabella del lakehouse serve Spark, una pipeline o un dataflow.

L’architettura mista: il pattern reale

Nella pratica non si sceglie uno contro l’altro. L’architettura medallion tipica in Fabric distribuisce i layer:

  • Bronze — lakehouse. Landing zone dei dati grezzi, spesso via shortcut per non duplicare storage. File di ogni tipo, nessuna trasformazione.
  • Silver — lakehouse. Dati puliti, deduplicati, tipizzati, materializzati come Delta table. Trasformazioni in Spark o dataflow.
  • Gold — warehouse. Modello dimensionale (star schema) esposto al business, con relazioni dichiarate, viste, stored procedure di aggiornamento incrementale in T-SQL, e semantic model in Direct Lake sopra.

Il collante è il SQL analytics endpoint: dal warehouse gold puoi eseguire query T-SQL che uniscono le sue tabelle a quelle di un lakehouse silver aggiunto allo stesso workspace, con notazione a tre parti database.schema.tabella. Le cross-database query funzionano in lettura su lakehouse e in lettura/scrittura sul warehouse locale.

Trappole tipiche d’esame

  • Scenario: il team di sviluppo conosce solo T-SQL e deve aggiornare le tabelle gold. → Risposta: warehouse. Il lakehouse richiede Spark per la scrittura; il suo endpoint SQL è read-only.
  • Scenario: bisogna ingerire file PDF e immagini insieme a CSV in una landing zone. → Risposta: lakehouse (sezione Files). Il warehouse gestisce solo tabelle relazionali.
  • Scenario: un processo deve aggiornare fact e dimension in un’unica transazione atomica, con rollback in caso di errore. → Risposta: warehouse. Il lakehouse offre ACID solo a livello di singola Delta table.
  • Scenario: “quale opzione garantisce le prestazioni Direct Lake migliori?” con lakehouse e warehouse come alternative. → Risposta: attenzione, entrambi supportano Direct Lake perché entrambi scrivono Delta in OneLake. La scelta va motivata sul modello di scrittura, non sulle prestazioni del semantic model.
  • Scenario: serve leggere dati che vivono in Amazon S3 senza copiarli in Fabric. → Risposta: lakehouse con shortcut. Il warehouse non supporta shortcut verso storage esterno.