Lakehouse vs. Warehouse in Microsoft Fabric: Wanneer gebruik je welke?

Fabric geeft je twee opties voor het opslaan van gegevens: lakehouses en warehouses. Beide slaan tabellen op. Bij beide kun je queries uitvoeren met SQL. Maar ze zijn fundamenteel verschillend en het kiezen van de verkeerde optie kan later problemen veroorzaken.

Ik heb veel te veel tijd besteed aan het uitzoeken welke ik moest gebruiken. De Microsoft documentatie legt uit wat ze zijn, maar niet echt wanneer je welke moet gebruiken. Dit is wat ik heb geleerd door ze allebei daadwerkelijk te gebruiken.

Wat is een lakehouse in Fabric?

Een lakehouse slaat gegevens op als bestanden in OneLake met behulp van het delta format. Het geeft je zowel bestandstoegang als SQL query-toegang tot dezelfde gegevens.

Onder de motorkap:

• Gegevens opgeslagen als Parquet files, georganiseerd volgens het Delta Lake protocol
• Je krijgt automatisch een SQL endpoint voor queries
• Toegang via Spark (notebooks) of SQL (endpoint)
• Tabellen zijn delta tables met versioning en time travel

Zie het als een mappenstructuur met daarbovenop databasefunctionaliteit.

Wat is een warehouse in Fabric?

Een warehouse is een traditionele SQL database. Het slaat gegevens op in database pages, niet in bestanden.

Onder de motorkap:

• Traditionele relational database engine
• Toegang via T-SQL only
• Tabellen zijn SQL tables met indexes en constraints
• Opgeslagen in OneLake, maar als database files, niet als Parquet

Zie het als een Azure SQL database ingebouwd in Fabric.

Belangrijke verschillen die ertoe doen

Dit is wat er echt toe doet bij het kiezen tussen de twee:

Toegangsmethoden

Lakehouse:

• Spark notebooks (Python, Scala, R)
• SQL endpoint (alleen-lezen)
• Directe file access tot Parquet files
• Power BI Direct Lake mode

Warehouse:

• T-SQL only
• Lezen en schrijven via SQL
• Power BI DirectQuery of Import
• Geen directe file access

Als je Spark processing nodig hebt, heb je een lakehouse nodig. Als je alleen SQL gebruikt, kun je beide gebruiken.

Schrijfbewerkingen

Lakehouse: Je kunt niet schrijven naar lakehouse tables via de SQL endpoint. Deze is alleen-lezen.

Om gegevens te schrijven, moet je het volgende gebruiken:

• Notebooks met Spark
• Dataflows Gen2
• Data pipelines met copy activity

Warehouse: Volledige lees-/schrijftoegang via T-SQL. Je kunt insert, update, delete, merge uitvoeren, net als bij elke SQL database.

Dit is een groot punt. Als je workflow is opgebouwd rond SQL procedures en je gegevens moet schrijven via SQL statements, heb je waarschijnlijk een warehouse nodig.

Prestatiekenmerken

Lakehouse:

• Snel voor grootschalige scans (miljoenen rijen lezen)
• Geoptimaliseerd voor analytics en aggregations
• Langzamer voor lookups van één rij
• Geen traditionele indexes (gebruikt in plaats daarvan delta statistics)

Warehouse:

• Snel voor point queries (specifieke rijen vinden)
• Goed voor OLTP-achtige workloads
• Ondersteunt traditionele indexes en constraints
• Kan langzamer zijn voor volledige table scans op enorme datasets

Als je analytics doet (grote datasets samenvatten), is een lakehouse meestal sneller. Als je transactionele lookups doet, is een warehouse wellicht beter.

Dataformats

Lakehouse: Delta format. Elke tabel is een map met Parquet files plus een transaction log.

Voordelen:

• Time travel (eerdere versies opvragen)
• Schema evolution (kolommen toevoegen zonder problemen te veroorzaken)
• ACID transactions
• Merge en upsert operations

Warehouse: Traditionele database pages. Eigen opslagformaat.

Voordelen:

• Beter ruimtegebruik voor kleine tabellen
• Traditionele constraints en foreign keys
• Bekend voor SQL developers

Het Delta format in lakehouses is flexibeler, maar het warehouse format is bekender als je uit de SQL Server-wereld komt.

Wanneer een lakehouse te gebruiken

Gebruik een lakehouse wanneer:

Je Spark processing nodig hebt

Als een deel van je workflow Python, Scala, of Spark transformaties nodig heeft, heb je een lakehouse nodig. Warehouses ondersteunen geen notebooks.

Je Direct Lake mode wilt

Voor Power BI reports die grote datasets moeten bevragen zonder te importeren, werkt Direct Lake alleen met lakehouses.

Je een medallion architecture bouwt

Het bronze/silver/gold patroon werkt van nature goed met lakehouses. Ruwe bestanden in bronze, opgeschoonde delta tables in silver en gold.

Je grootschalige analytics workloads hebt

Het scannen van miljarden rijen om gegevens te aggregeren presteert beter op lakehouse delta tables dan op warehouse tables.

Je time travel of versioning nodig hebt

Delta tables houden elke wijziging bij. Je kunt gegevens opvragen zoals ze gisteren of vorige week waren. Warehouses hebben dit niet ingebouwd.

Je gestructureerde en ongestructureerde gegevens wilt combineren

Lakehouses laten je bestanden (PDF's, afbeeldingen, JSON) naast delta tables op dezelfde locatie opslaan.

Wanneer een warehouse te gebruiken

Gebruik een warehouse wanneer:

Je alleen T-SQL kent

Als je team SQL experts zijn en niemand Spark wil leren, kun je met een warehouse in bekend terrein blijven.

Je volledige SQL write access nodig hebt

Als je processen afhankelijk zijn van SQL procedures, updates en deletes, geeft een warehouse je volledige DML access.

Je migreert vanaf SQL Server

Als je een SQL Server database lift en shift, komt een warehouse dichter in de buurt. Minder transformatie nodig.

Je traditionele database features nodig hebt

Zaken als foreign keys, check constraints, triggers werken in een warehouse, niet in een lakehouse.

Je high concurrency point queries hebt

Veel gebruikers die lookups doen op basis van ID of key? Warehouse indexes verwerken dit beter dan lakehouse scans.

Je datavolumes bescheiden zijn

Als je werkt met gigabytes, niet met terabytes, kan de eenvoud van het warehouse opwegen tegen de flexibiliteit van het lakehouse.

Kun je beide gebruiken?

Ja, en eerlijk gezegd doen de meeste echte projecten dat ook.

Veelvoorkomend patroon:

1. Lakehouse voor analytics data – jouw hoofd data platform, grote datasets, delta tables
2. Warehouse voor dimension tables – kleine referentietabellen, lookups, zaken die SQL updates nodig hebben
3. Cross-database queries – je kunt beide in dezelfde SQL statement bevragen

Voorbeeld:

-- query lakehouse and warehouse together
SELECT 
    f.sales_amount,
    d.product_name
FROM lakehouse_sales.dbo.fact_sales f
JOIN warehouse_ref.dbo.dim_product d
    ON f.product_id = d.product_id

De Fabric SQL endpoint laat je naadloos joinen over lakehouses en warehouses.

Opslag en kosten

Zowel lakehouses als warehouses slaan gegevens op in OneLake, dus de opslagkosten zijn vergelijkbaar.

Het echte kostenverschil zit in de compute:

Lakehouse compute:

• Spark notebooks verbruiken capacity tijdens het draaien
• SQL endpoint queries gebruiken capacity
• Geen kosten wanneer niet actief bevraagd wordt

Warehouse compute:

• Verbruikt altijd enige capacity, zelfs als het idle is
• Queries verbruiken extra capacity
• Meer zoals een traditionele database die altijd aan staat

Als je sporadische workloads hebt, is een lakehouse kosteneffectiever. Als je constant queries uitvoert, is het warehouse-kostenmodel wellicht logischer.

Beslissingskader voor de praktijk

Zo beslis ik daadwerkelijk bij nieuwe projecten:

Begin met deze vragen:

1. Heb ik Spark of notebooks nodig? Zo ja → lakehouse
2. Moet ik gegevens schrijven via SQL? Zo ja → warehouse
3. Wil ik Direct Lake mode? Zo ja → lakehouse
4. Is mijn team alleen SQL-gericht? Zo ja → warehouse
5. Werk ik met terabytes aan data? Zo ja → lakehouse

Als meerdere antwoorden verschillende kanten op wijzen:

• Standaard naar lakehouse, tenzij je een specifieke warehouse-vereiste hebt
• Je kunt altijd beide aanmaken en ze voor verschillende doeleinden gebruiken
• Later van een warehouse naar een lakehouse verhuizen is mogelijk, andersom is moeilijker

Veelvoorkomende fouten

Fout 1: Kiezen voor warehouse omdat SQL bekend is

Ik snap het, SQL is comfortabel. Maar als je Fabric gebruikt voor analytics workloads, beperk je jezelf. Neem een week de tijd om basis Spark te leren. Het is niet zo moeilijk en opent veel meer mogelijkheden.

Fout 2: Een lakehouse gebruiken en dan proberen rijen te updaten via SQL

De lakehouse SQL endpoint is alleen-lezen. Als je gegevens moet updaten, moet je notebooks gebruiken met merge operations. Ontwerp geen workflow die afhankelijk is van SQL updates en kies dan een lakehouse.

Fout 3: Een lakehouse kiezen zonder Delta te begrijpen

Delta tables zijn niet zomaar bestanden. Ze hebben transaction logs, versioning en optimalisatievereisten. Als je deze zaken negeert, zullen je queries langzaam zijn.

Fout 4: Beide aanmaken voor dezelfde data

Sla niet dezelfde gegevens op in zowel een lakehouse als een warehouse in de veronderstelling dat je het beste van twee werelden krijgt. Je krijgt dataduplicatie, synchronisatieproblemen en hogere kosten. Kies één als source of truth.

Data laadpatronen

Hoe je gegevens laadt, verschilt tussen de twee:

In een lakehouse:

• Dataflows Gen2 met lakehouse destination
• Notebooks die delta tables schrijven
• Copy activity in pipelines die landen in de files section
• Directe file upload voor kleine datasets

In een warehouse:

• Dataflows Gen2 met warehouse destination
• T-SQL insert/merge statements
• Copy activity met warehouse destination
• Bulk insert vanuit files

De meeste ETL tools in Fabric werken met beide, maar de patronen zijn iets anders.

Query patronen

Lakehouse SQL endpoint:

-- read only queries
SELECT * FROM bronze.raw_sales
WHERE sale_date >= '2024-01-01'

Lakehouse notebook:

# full read/write with spark
df = spark.table("bronze.raw_sales")
df = df.filter(df.sale_date >= "2024-01-01")

# write back to delta
df.write.format("delta").mode("append").saveAsTable("silver.sales")

Warehouse T-SQL:

-- full read/write
UPDATE dbo.customers
SET status = 'active'
WHERE last_purchase > DATEADD(month, -6, GETDATE())

-- insert/merge works too
MERGE INTO dbo.customers AS target
USING staging.customers AS source
ON target.customer_id = source.customer_id
WHEN MATCHED THEN UPDATE SET ...
WHEN NOT MATCHED THEN INSERT ...

Merk op dat het lakehouse-voorbeeld een notebook vereist voor schrijfbewerkingen. Een warehouse doet alles in SQL.

Power BI integratie

Dit is belangrijk als je, zoals de meeste lezers, uit de Power BI-wereld komt.

Lakehouse met Direct Lake mode:

• Semantic Model bevraagt delta tables direct
• Geen data import, altijd actueel
• Beste prestaties voor grote datasets
• Vereist Fabric capacity met voldoende rijlimieten

Warehouse met DirectQuery:

• Semantic Model stuurt SQL queries naar warehouse
• Geen data import, altijd actueel
• Prestaties afhankelijk van warehouse indexes en query complexiteit
• Werkt op elke capacity

Beide met Import mode:

• Standaard Power BI import
• Gegevens worden volgens schema ververst
• Werkt precies zoals traditionele Power BI
• Snelste query prestaties, maar verouderde gegevens

Voor nieuwe projecten, als je je richt op grote datasets, is Direct Lake met lakehouse de betere weg.

Migratiepad

Als je de verkeerde kiest, zit je er niet voor altijd aan vast.

Warehouse naar lakehouse:

1. Exporteer warehouse tables naar bestanden
2. Creëer lakehouse tables vanuit die bestanden
3. Herschrijf alle SQL procedures als notebooks
4. Schakel je Semantic Models en reports om

Gemiddelde moeilijkheidsgraad. De SQL naar Spark vertaling is het moeilijkste deel.

Lakehouse naar warehouse:

1. Kopieer delta tables naar staging
2. Creëer warehouse schema
3. Laad data via T-SQL
4. Herschrijf Spark notebooks als SQL procedures

Ook gemiddelde moeilijkheidsgraad. Je verliest Time travel en versioning features.

Geen van beide migraties is triviaal, maar beide zijn uitvoerbaar als je merkt dat je moet overstappen.

Definitieve beslissingsgids

Als je nog steeds twijfelt, kort samengevat:

Kies lakehouse als:

• Je Direct Lake mode wilt
• Je grootschalige analytics uitvoert
• Je Spark processing nodig hebt
• Je je comfortabel voelt met het leren van nieuwe tools
• Dit een nieuw project is

Kies warehouse als:

• Je alleen T-SQL gebruikt
• Je volledige SQL write access nodig hebt
• Je migreert vanaf SQL Server
• Je team weigert Spark te leren
• Je traditionele OLTP patterns hebt

Kies bij twijfel voor een lakehouse. Het is flexibeler en het is waar Microsoft de meeste ontwikkeling op richt.

Aan de slag

Welke je ook kiest:

1. Maak een test workspace aan
2. Maak één lakehouse of warehouse aan
3. Laad enkele sample data via een Dataflow Gen2
4. Probeer het op verschillende manieren te bevragen
5. Bouw er een eenvoudig Power BI report bovenop

Door ze een week daadwerkelijk te gebruiken, leer je meer dan door documentatie te lezen.

Als je nieuw bent met Fabric, begin dan met mijn introductiegids voor Power BI developers om eerst het algehele platform te begrijpen.

De lakehouse vs. warehouse beslissing is belangrijk, maar niet permanent. Kies er een op basis van je directe behoeften en schakel later over indien nodig. Blijf niet zo lang nadenken dat je nooit begint.