Direct Lake

Wat is Direct Lake?

Direct Lake is een opslagmodus voor semantische modellen in Microsoft Fabric. Een rapport leest er rechtstreeks uit Delta-tabellen in OneLake, zonder dat je eerst data moet importeren en zonder dat elke query naar het bronsysteem gestuurd wordt.

Waar Import een volledige kopie in het geheugen van je capaciteit zet en DirectQuery elke vraag doorstuurt naar SQL, pakt Direct Lake het anders aan. Alleen de kolommen en rijen die een visual nu echt nodig heeft, worden op dat moment uit de Parquet-bestanden in OneLake geladen. Dat gaat snel, want de VertiPaq-engine die Power BI al gebruikt voor Import, leest dezelfde kolomindeling.

Je kan het vergelijken met een bibliotheek die pas een boek binnenhaalt als iemand het wil lezen, maar die wel de volledige catalogus klaar heeft staan. Geen nachtelijk refresh-venster, geen "data is 12 uur oud", en toch geen trage SQL-round-trip voor elk scherm dat een gebruiker opent.

Waarom bestaat Direct Lake?

Wie grote volumes in Power BI wil rapporteren, botst altijd op dezelfde afweging.

Import is snel maar zwaar
Je laadt alle data in één keer in het geheugen. Je capaciteit moet groot genoeg zijn, je refresh-venster vraagt tijd en de gebruikers zien pas de volgende ochtend de nieuwe cijfers.

DirectQuery is live maar traag
Elke klik stuurt een query naar de bron. Als dat een SQL-warehouse is, hou je gewicht uit het Power BI-geheugen maar geef je het door aan de SQL-engine, met alle risico's op trage response in reports.

Microsoft bouwde Direct Lake om die afweging te omzeilen in een Fabric-stack. De data ligt toch al in OneLake in Delta-formaat. VertiPaq kan Parquet rechtstreeks lezen. Een extra import-copy is dan overbodig.

Hoe werkt Direct Lake?

Framing in plaats van refresh
Een klassieke Import-refresh kopieert alle rijen naar het model. Een Direct Lake-refresh vernieuwt enkel de metadata: welke Parquet-bestanden horen nu bij welke tabel? Die operatie heet framing en duurt seconden, niet uren.

Transcoding on demand
Op het moment dat een visueel of DAX-query een kolom aanspreekt, wordt die kolom uit het Parquet-bestand in het VertiPaq-formaat gezet. Eenmaal geladen blijft de kolom in het geheugen tot de capaciteit plaats nodig heeft voor iets anders.

Delta-tabellen als basis
Direct Lake werkt alleen met tabellen in Delta-formaat. Daardoor krijg je meteen de transactielogs, schema-garanties en time travel van Delta Lake bij elk rapport.

Automatische updates
Zodra de onderliggende Delta-tabel verandert (nieuwe rij, geüpdatete dimensie), detecteert Direct Lake dat en zorgt het dat de volgende query de nieuwe versie ziet. Je kan die updates automatisch laten gebeuren of programmatisch sturen.

Wanneer kies je voor Direct Lake?

1. Grote volumes in een lakehouse-architectuur. Je hebt gouden Delta-tabellen in Fabric en wil die rechtstreeks rapporteren zonder aparte ETL naar een Power BI-dataset.

2. Near-real-time vereisten zonder DirectQuery-pijn. Je wil dat een nieuwe rij binnen minuten in het rapport verschijnt, maar zonder SQL-queries op elke klik.

3. IT-geleide projecten met een warehouse of lakehouse in Fabric. Microsoft tipt Direct Lake expliciet als keuze voor de gold-laag in een medaillon-architectuur.

4. Capaciteit sparen op refresh-cycles. Een import-refresh van miljarden rijen vraagt CPU en geheugen. Framing doet hetzelfde in seconden.

Direct Lake op OneLake versus Direct Lake op SQL

Er zijn twee varianten en die werken anders.

Direct Lake op OneLake
Leest rechtstreeks uit Delta-tabellen in OneLake, zonder omweg via SQL. Geen fallback naar DirectQuery: als een query niet kan, krijg je een foutmelding. Composite models zijn wel toegelaten, dus je kan Direct Lake-tabellen combineren met Import-tabellen in hetzelfde model. Dit is de richting waar Microsoft naartoe stuurt.

Direct Lake op SQL-endpoint
Gaat via het SQL-endpoint van een lakehouse of warehouse. Ondersteunt fallback naar DirectQuery wanneer een tabel een SQL-view is of wanneer SQL-gebaseerde beveiliging actief is. Composite models met andere storage-modi worden niet ondersteund. Biedt wel betere integratie met SQL-RLS en object-level security.

Vergelijking met Import en DirectQuery

Import blijft de logische keuze voor kleinere self-service-datasets en voor bronnen die niet in OneLake liggen. Je hebt er geen Fabric-capaciteit voor nodig.

DirectQuery past bij scenario's waar je echt per query de brondatabase wil bevragen (bijvoorbeeld voor live operationele dashboards op OLTP-systemen) of waar je de data om compliance-redenen niet mag kopiëren.

Direct Lake is de standaardkeuze voor analytische rapporten bovenop een Fabric-lakehouse of -warehouse wanneer je volume hebt dat te groot is voor Import. Je combineert Import-performance met DirectQuery-versheid.

Valkuilen

Fabric-capaciteit is vereist
Direct Lake draait alleen op een F- (of legacy P-) SKU. Een Pro-only organisatie heeft er niks aan.

Grenzen op rijen en modelgrootte per SKU
Op een F2 tot F32 mag een tabel maximaal 300 miljoen rijen en een model tussen 10 en 40 GB op schijf beslaan. Overschrijd je dat, dan faalt de query of valt hij terug op DirectQuery bij Direct Lake op SQL. Grote modellen vragen minimaal F64, dat ontgrendelt ongelimiteerde modelgrootte en 1,5 miljard rijen per tabel.

Geen berekende kolommen, geen complexe Delta-types
Calculated columns worden niet ondersteund op Direct Lake-tabellen. Binary- en GUID-kolommen moet je naar string casten. Doe je transformaties upstream in Spark, SQL of een Dataflow, niet in het model.

Delta-tabellen moeten goed onderhouden zijn
Te veel kleine Parquet-bestanden of slecht gestructureerde row groups verslechten de performance. Draai periodiek OPTIMIZE en V-Order op je tabellen.

Geen cross-region
Het semantisch model moet in dezelfde Fabric-regio draaien als de lakehouse of warehouse waaruit het leest. Wie meerdere regio's moet overbruggen, werkt met shortcuts of aparte modellen.

Object- en row-level security gedragen zich anders
Op Direct Lake op OneLake wordt SQL-gebaseerde RLS niet toegepast; je moet RLS definiëren in het semantisch model zelf. Op Direct Lake op SQL werkt RLS via het SQL-endpoint maar valt de query dan terug op DirectQuery, wat de performance beïnvloedt.