Power BI Direct Lake uitgelegd: zo werkt het in de praktijk
Ik krijg vaak de vraag of ik Power BI Direct Lake uitgelegd kan geven in gewone-mensentaal. Dat doe ik graag, want Direct Lake verandert de manier waarop ik rapporten bouw voor grote en snel veranderende datasets. In deze gids laat ik zien wat het is, hoe het werkt, waarin het verschilt van Import en DirectQuery, en wanneer ik het adviseer. Ik onderbouw mijn keuzes met wetenschappelijke bronnen en officiële Microsoft-documentatie en ik geef concrete stappen en tips uit mijn eigen praktijk.
Power BI Direct Lake uitgelegd: wat het écht is
Direct Lake is een opslagmodus voor Power BI-semantic models waarbij ik rechtstreeks lees uit Delta Lake-tabellen in OneLake, zonder een aparte data-import en zonder de latentie en beperkingen van DirectQuery. Microsoft beschrijft het als near-import performance met near-real-time data, omdat de VertiPaq-engine kolomsegmenten on-demand uit Delta-bestanden in het geheugencache kan laden en hergebruiken (Microsoft, Direct Lake-overzicht). Direct Lake is ingebed in Microsoft Fabric en werkt het best als mijn brontabellen in Delta-indeling staan en geoptimaliseerd zijn voor analytische scans. Wil je meer context over het platform eromheen, dan raad ik je aan mijn uitleg over Fabric te lezen via Microsoft Fabric uitgelegd: de complete gids.
De kern is dat ik geen aparte importklad van data in een dataset opsla. In plaats daarvan gebruikt VertiPaq rechtstreeks de kolomgebaseerde opslag uit het datameer. Daardoor kan ik vrijwel onmiddellijk nieuwe of gewijzigde rijen zien zodra ze in Delta zijn gecommitteerd en geoptimaliseerd. Als een query of functie niet geschikt is voor Direct Lake, of als er geheugen- of bestandsbeperkingen zijn, kan de engine selectief terugvallen op DirectQuery om het ontbrekende stukje toch uit te voeren (Microsoft, fallback-gedrag).
Direct Lake versus Import en DirectQuery: de echte verschillen
In mijn trajecten kies ik bewust tussen drie smaken: Import, DirectQuery en Direct Lake. Bij Import laad ik data periodiek in het VertiPaq-geheugenmodel. Dat is snel, maar niet altijd actueel en het vergroot mijn beheerlast door refresh-windows. DirectQuery laat data in de bron staan en stuurt per interactie SQL- of andere broncommando’s; dat is actueel, maar vaak traag en afhankelijk van de brondatabasecapaciteit. Direct Lake pakt het tussenvak: de data blijft in OneLake als Delta Parquet, maar VertiPaq leest kolomsegmenten direct, met caching waar mogelijk. Microsoft geeft aan dat dit import-achtige prestaties kan halen met een versheid die in de buurt komt van DirectQuery (Direct Lake-overzicht).
In de praktijk zie ik de grootste winst bij feiten-tabellen van tientallen miljoenen tot miljarden rijen die voortdurend aangevuld worden. Met Import loop ik dan tegen refreshvensters, gateway-belasting en wachttijden op. Met DirectQuery loop ik aan tegen variërende responstijden, locking in de bron of krappe SLA’s. Met Direct Lake krijg ik consistente, voorspelbare prestaties zolang mijn Delta-tabellen goed geoptimaliseerd zijn. Twijfel je nog tussen Import en DirectQuery, lees dan mijn afwegingen in Power BI import vs DirectQuery: zo kies je slim; Direct Lake vult precies de leemte die ik daar vaak beschrijf.
Architectuur onder de motorkap: OneLake, Delta en VertiPaq
De reden dat Direct Lake werkt, zit in de architectuur. OneLake is de centrale datahub in Microsoft Fabric. Het biedt een uniforme namespace en maakt het delen van opslag en shortcuts naar verschillende bronnen mogelijk (Microsoft, OneLake-overzicht). Mijn tabellen staan in Delta Lake-indeling, een open tabelprotocol op kolomgebaseerde bestandsformaten met ACID-transacties en snapshot isolation (VLDB: Delta Lake paper). De fysieke bestanden zijn Parquet, een kolomgebaseerd bestandsformaat met compressie, statistieken en predicate pushdown (Apache Parquet docs). VertiPaq, de analytische engine in Power BI, is eveneens kolomgebaseerd. Kolomgebaseerde opslag sluit aantoonbaar beter aan op analytische workloads dan rijgebaseerde opslag, omdat het slechts de benodigde kolommen scant en agressieve compressie en vectorisatie kan toepassen (C-Store: column-oriented DBMS).
In Direct Lake leest VertiPaq segmenten rechtstreeks uit de Delta-Parquetbestanden. Als ik een slicer wijzig of een visueel object filtert, worden alleen de relevante segmenten in geheugen gebracht. Bij herhaalde interacties hergebruikt de engine deze segmenten. Microsoft raadt aan om Delta-tabellen in V-Order te optimaliseren, een lay-out die de I/O-paden van VertiPaq maximaliseert en segmentgrenzen gunstig plaatst (Microsoft, V-Order-optimalisatie). Die optimalisatie reduceert leesoperaties en versnelt volledig of gedeeltelijk scans, waardoor ik het “near-import” gevoel krijg zonder import.
Prestaties onder de loep: waarom het zo snel voelt
Als ik prestaties analyseer, let ik op scan-snelheid, selectiviteit van filters, cardinaliteit en compressie. Kolomgebaseerde compressie werkt het best als kolommen lage tot middelhoge cardinaliteit hebben en datatypes strak gekozen zijn. VertiPaq benut dictionary encoding en run-length encoding, vergelijkbaar met principes die in de literatuur zijn beschreven voor column-stores (C-Store paper). Parquet-bestanden bevatten bovendien statistieken per row group waarmee onnodige leesacties worden overgeslagen (Parquet docs). Dat verklaart waarom een goed gestructureerd Direct Lake-model in de praktijk binnen enkele honderden milliseconden tot een paar seconden kan reageren, zelfs op miljoenen rijen, zolang aggregates en relaties efficiënt zijn opgezet. Microsoft nuanceert dat Direct Lake bij ongunstige bewerkingen of geheugenlimieten automatisch kan terugvallen op DirectQuery, met bijbehorende latentie (Direct Lake-overzicht). In mijn eigen metingen zie ik dat het vermijden van hoge-cardinaliteitsdimensionen in visuals en het verplaatsen van complexe rijenlogica naar de ETL-lagen structureel de responstijd verbetert.
Een tweede factor is data-actualiteit. Omdat ik niet op een dataset-refresh wacht, zie ik vrijwel direct transacties die in Delta zijn gecommitteerd. De effectieve latentie wordt bepaald door de snelheid waarmee mijn pipeline data naar Delta schrijft en of een optimalisatiejob (zoals V-Order) draait. In streaming- of microbatch-scenario’s levert dat een near-real-time ervaring op, zonder de querystorm op bronsystemen die ik bij DirectQuery vaak zag.
Datamodelleren en semantiek: zo haal ik maximale kwaliteit
Direct Lake is geen vrijbrief om een rommelig model te draaien. Integendeel, een strak stermodel is cruciaal. Ik ontwerp eerst een centrale feitentabel met meetwaarden en verwijs daarvan naar compacte dimensies met attributen en hiërarchiën. Deze aanpak minimaliseert joincomplexiteit en maximaliseert compressie en scan-efficiëntie. Microsoft adviseert hetzelfde in haar richtlijnen voor het stermodel (Power BI guidance). Als je precies wilt weten hoe ik dat stap voor stap opbouw, lees dan mijn uitleg in Power BI stermodel uitleg: de complete gids.
Ik vermijd calculated columns die rijenlogica bevatten die niet nodig is in het semantische model. Zulke logica hoort thuis in de data-engineeringlaag, zodat de Delta-tabellen schoon en compact blijven. Measures schrijf ik in DAX en let erop dat ze gebruikmaken van snelle aggregaties, expliciete filtercontext en zo min mogelijk iteratorfuncties tenzij noodzakelijk. Relaties definieer ik eenduidig, idealiter één-op-veel met directionele filtering vanaf dimensies naar feiten. Die patronen verkleinen de kans op DirectQuery-fallback en houden de cache coherent.
Beveiliging, governance en RLS in Direct Lake
In bedrijfsomgevingen moet ik zekerheid hebben over governance en beveiliging. Direct Lake respecteert rolgebaseerde beveiliging op het semantische model; ik kan dus Row-Level Security (RLS) en eventueel Object-Level Security (OLS) toepassen. Microsoft beschrijft dat RLS op Direct Lake semantic models wordt afgedwongen binnen de VertiPaq-executie, met dezelfde semantiek als bij Import, en dat sommige scenario’s die niet in de cache passen naar DirectQuery kunnen uitwijken (Microsoft, beveiliging en fallback). In mijn ontwerpen definieer ik RLS-regels zo simpel mogelijk en baseer ik ze op dimensietabellen, niet op de feitentabel, zodat de filters selectief en performant zijn. Wil je praktisch zien hoe ik RLS inricht, lees dan mijn gids Power BI Row Level Security: complete gids.
Governance-wise vertrouw ik op OneLake-toegangsbeheer, workspaces en Fabric-capaciteiten. Ik dwing databron-eigenaarschap, naming standards en lifecycle-afspraken af. Daarbij hoort ook het beheer van shortcuts en lineage, zodat ik weet welke delta-tabellen door wie worden gevoed en hoe vaak optimalisaties draaien. Dit verkleint de kans dat ik onverwacht op DirectQuery-fallback stuit door versnipperde of niet-geoptimaliseerde datasets.
Beperkingen en valkuilen waar ik op let
Geen technologie is zonder randen. Een Direct Lake-model draait op een Fabric- of Power BI Premium-capaciteit; zonder die capaciteit kan ik de modus niet gebruiken (Microsoft, vereisten). Verder is de prestatiekwaliteit sterk afhankelijk van de fysieke organisatie van Delta-bestanden: veel kleine files, ontbreken van V-Order en het ontbreken van Z-Ordering of partitionering waar logisch, verhogen de I/O en verminderen cache-hit-ratio’s (Microsoft, delta-optimalisaties). Ik heb ook geleerd dat sommige DAX-functies, zeer complexe berekende tabellen of cross-filtering over veel-op-veel-relaties tot fallback kunnen leiden. Microsoft geeft aan dat het systeem automatisch schakelt als een bewerking niet in Direct Lake kan worden uitgevoerd, maar dat betekent mogelijk meer latentie (Direct Lake-overzicht).
Een tweede valkuil is dat ik de verantwoordelijkheid voor “almost real-time” vaak onderschat. Delta-tabellen zijn actueel als mijn pipelines betrouwbaar en frequent schrijven. Zonder degelijke data-engineeringpraktijk blijft elke gebruikerservaring suboptimaal. Ik bouw daarom monitoring op inserts/updates, check de Delta-log voor commitfrequentie en draai geplande optimalisatie-jobs buiten kantooruren of kortcyclisch op incrementele partities.
Wanneer kies ik voor Direct Lake en wanneer niet?
Ik kies voor Direct Lake als ik drie vinkjes kan zetten: het datavolume is groot en groeit snel, de data verandert frequent genoeg om een traditionele refresh onhandig te maken, en ik bouw mijn model bovenop Delta in OneLake. Past jouw scenario hierin, dan levert Direct Lake meestal een betere balans op tussen performance en actualiteit dan Import of DirectQuery. Speelt actualiteit minder en is de dataset bescheiden, dan is Import eenvoudiger te beheren. Als je bron buiten Fabric staat en Delta/OneLake geen optie is, dan is DirectQuery of een goed ontworpen ingestie naar Import logischer. Over refreshinstellingen en hun trade-offs heb ik apart geschreven in Power BI refresh instellen: complete gids; Direct Lake vermindert je refreshbehoefte, maar neemt data-engineering niet weg.
Een praktisch heuristiek die ik hanteer: als ik meer dan enkele tientallen miljoenen rijen per maand toevoeg, of als mijn business tophandhaving <15 minuten data-latentie vraagt, is Direct Lake vrijwel altijd mijn eerste keus. Bij sterk transactionele, relationele queries met veel small lookups kan een datawarehouse-warehouse in Fabric met materialized views en een gemengde aanpak ook passend zijn.
Stap voor stap: zo bouw ik een Direct Lake-rapport
Ik start met een Lakehouse of Warehouse in Fabric en maak of ontvang Delta-tabellen voor mijn kernentiteiten. Als de data nog niet in Delta staat, zet ik een pipeline of notebook op om brontabellen als Delta te schrijven. Ik controleer datatypekeuzes (integers voor sleutels, decimaal voor geldbedragen met passende precisie, datums in een consistente kalender) en ik verwijder overbodige kolommen vroeg in de keten voor maximale compressie.
Vervolgens optimaliseer ik Delta. Ik cluster of partitioneer op logische sleutels of datums, en ik draai een V-Order-optimalisatiejob om de fysieke ordening van kolommen en segmenten te verbeteren (Microsoft, V-Order). Bij zeer grote tabellen consolideer ik kleine files periodiek, omdat te veel kleine bestanden de I/O-overhead vergroten. Ook let ik op het consistent bijwerken van statistieken en beperk ik schema-drift, zodat Visuals en DAX stabiel blijven.
Daarna maak ik in Power BI Service een semantisch model op basis van het Lakehouse of Warehouse en kies ik voor de Direct Lake-modus. Ik definieer relaties, stel datatypen in en maak de eerste measures. Denk aan Total Sales, Margin en actieve klanten. Ik vermijd calculated tables voor transformaties; die voer ik upstream uit, zodat het model licht blijft. In Desktop verbind ik live met het semantische model, ontwikkel ik visuals en test ik intensief met filters en slicers om na te gaan of er fallback optreedt. Bij onverklaarbare vertraging controleer ik in de querydiagnostiek en in de Fabric monitoring welke queries DirectQuery raken en optimaliseer ik daarop de Delta-lay-out en DAX.
Ik sluit af met governance: RLS-regels per rol, beschrijvingen bij tabellen en kolommen, datacertificering, en documentatie van lineage en SLA’s. Daarna publiceer ik naar een workspace op de juiste capaciteit. De eindgebruikers merken vervolgens vooral dat hun dashboards rap reageren en tegelijk dichter op de werkelijkheid zitten dan ze van traditionele datasets gewend zijn.
Licenties en capaciteit: wat heb ik nodig?
Voor Direct Lake heb ik een Microsoft Fabric-capaciteit (F-SKU) of Power BI Premium-capaciteit (P-SKU) nodig, omdat de engine en OneLake-functies capaciteit-gebonden zijn (Microsoft, vereisten). De keuze hangt af van je bestaande licentie en workloads. In mijn berekeningen kijk ik naar gelijktijdigheid, datasetgrootte, piekvragen en het aantal actieve rapporten. Ik reserveer capaciteit voor optimalisatie-jobs en zorg dat piekmomenten niet samenkomen met ETL-schrijfbatches. Capacity metrics in de Power BI Admin Portal en Fabric Monitoring helpen mij om bottlenecks vroeg te zien en op te schalen of te herplannen.
Concrete tips die mij keer op keer tijd en geld besparen
Mijn eerste tip is om cardinaliteit te temmen. Converteer high-cardinality tekstkolommen naar surrogate keys in dimensies en gebruik die in de feitentabel. Houd dimensies smal en informatief. Mijn tweede tip is om measures expliciet te definiëren en ze te testen op filtercontext. Als ik een measure niet kan verklaren met CALCULATE, SUMX en contexttransities, is de kans groot dat ik te veel rij-iteraties doe.
Derde tip: beheers je Delta-lifecycle. Automatiseer compaction en V-Order, en monitor de Delta-loggrootte en file counts. Vierde tip: modelleer eenduidig. Eén-op-veel-relaties met single direction filtering zijn de veilige default. Vijfde tip: vermijd uitgebreide calculated columns en berekende tabellen; schuif die logica naar upstream, omdat ze vaak de cache- en opslagvoordelen van Direct Lake omzeilen. Zesde tip: test met realistische filterpatronen. Ik bouw testpagina’s die de zwaarste scenario’s simuleren, zodat ik fallback vroeg ontdek.
Conclusie: Power BI Direct Lake uitgelegd en toegepast
Als ik alles samenvat, dan is Power BI Direct Lake uitgelegd in één zin: het combineert de snelheid van kolomgeheugen met de actualiteit van data in je lake. Door Delta in OneLake slim te organiseren, een strak stermodel te bouwen en je DAX meetbaar en zuiver te houden, krijg je import-achtige prestaties zonder traditionele refresh-windows en met actuele inzichten. Met de bronnen en data die ik hier aanhaal, kun je gefundeerd kiezen of Direct Lake voor jouw scenario de juiste zet is. En als dat zo is, levert het een merkbare stap vooruit op in gebruikservaring en beheerbaarheid.
Veelgestelde vragen
Heb ik altijd een Fabric-capaciteit nodig voor Direct Lake?
Ja, Direct Lake vereist een Microsoft Fabric- of Power BI Premium-capaciteit omdat de engine rechtstreeks met OneLake en Delta integreert. Zonder capaciteit is de modus niet beschikbaar.
Kan ik gemengde modellen gebruiken met Direct Lake?
Ja, je kunt combineren met andere bronnen, maar ongeschikte bewerkingen of bronnen kunnen tot DirectQuery-fallback leiden. Ik raad een helder stermodel aan om fallback te minimaliseren.
Hoe snel zijn updates zichtbaar in een Direct Lake-rapport?
Gewoonlijk vrijwel direct na het committen in Delta, afhankelijk van je pipelinefrequentie en optimalisatiejobs zoals V-Order. Er is geen aparte dataset-refresh nodig.
Werkt Row-Level Security hetzelfde als bij Import?
Functioneel wel. RLS wordt op het semantische model afgedwongen. Complexe scenario’s of geheugenlimieten kunnen deelqueries via DirectQuery uitvoeren, wat invloed heeft op latentie.
Wanneer is Import toch beter dan Direct Lake?
Bij kleine, weinig veranderende datasets of wanneer Delta/OneLake geen optie is, is Import eenvoudiger te beheren en vaak snel genoeg, zonder afhankelijkheid van Fabric-capaciteit.
Wil je deze aanpak stap voor stap leren toepassen en direct waarde halen uit je data? Schrijf je dan in voor onze Power BI cursus en ga met mijn begeleiding in korte tijd van basis naar professioneel niveau.
