In Power BI kun je data laden op verschillende manieren, waaronder via de bekende Import- en Direct Query-modus en de nieuwe Direct Lake-modus. Direct Lake werd geïntroduceerd met de Microsoft Fabric-updates, maar is nog steeds een bron van verwarring voor veel organisaties en hun teams. In dit artikel leggen we de verschillen uit tussen Direct Lake, Direct Query en Import, en wanneer je welke optie zou moeten kiezen.

TL;DR: De belangrijkste conclusies eerst

• Queries in Import-modus zijn vaak sneller dan in Direct Lake-modus. Direct Lake kan soms vergelijkbare prestaties bieden, maar is vaak iets trager.
• Direct Lake werkt niet als je Fabric capacity gepauzeerd is, import wel. Omdat Direct Lake direct je Delta Parquets leest (in je OneLake) en geen data importeert, kunnen je rapporten en datasets geen data raadplegen in de service of de desktop editor.
• Direct Lake vervangt niet de Import modus of Direct Query. Het is een extra optie in specifieke scenario’s. Import is nodig als je bijvoorbeeld data alleen op bepaalde tijden wilt verversen en verder je Direct Lake wilt pauzeren. Direct Query blijft nodig voor (near)-realtime scenario’s.
• Direct Lake en Import verbruiken hetzelfde geheugen tijdens query’s. Beide laden alleen de kolommen in het geheugen die voor de query nodig zijn.
• Direct Lake heeft beperkingen tijdens modelleren vergeleken met Import. Je kunt geen calculated columns of tables gebruiken, bepaalde hiërarchieën zijn ook niet beschikbaar wat vooral gevolgen heeft voor de Excel-integratie in Power BI.
• Direct Lake werkt niet met views. Data moet gematerialiseerd zijn in het Delta Lakehouse om gebruik te kunnen maken van Direct Lake. Openrowset views zorgen ervoor dat Direct Lake terugvalt op Direct Query met alle beperkingen die bij Direct Query komen kijken.
• Technische vaardigheden zijn nodig voor optimale compressie in Direct Lake. In tegenstelling tot Import, waarbij VertiPaq automatisch compressie optimaliseert, vereist Direct Lake handmatige fine-tuning om vergelijkbare resultaten te bereiken.

Direct Lake is geen vervanging voor import

Direct Lake vervangt de importfunctie in Power BI niet, omdat beide technologieën verschillende benaderingen bieden voor het verwerken en benaderen van data, en ieder zijn eigen sterktes heeft afhankelijk van de situatie. In de Import-modus wordt data vooraf volledig in het geheugen geladen, waardoor gebruikers supersnelle query’s kunnen draaien zonder dat er verdere verwerking nodig is tijdens het opvragen van de data. Dit maakt Import-modus uitermate geschikt voor scenario’s waarbij snelheid van cruciaal belang is, zoals in rapporten met complexe berekeningen en grote hoeveelheden gegevens. De data is volledig beschikbaar in het VertiPaq-formaat, wat geoptimaliseerd is voor hoge prestaties en compressie. Hierdoor kunnen gebruikers met minimale wachttijd werken, zelfs bij omvangrijke datasets.

Direct Lake daarentegen biedt een andere aanpak door data dynamisch vanuit een data lake naar het geheugen te laden en vervolgens te verwerken. Dit betekent dat de eerste keer dat een query wordt uitgevoerd, de data eerst moet worden geconverteerd naar het VertiPaq-formaat. Dit conversieproces introduceert een zekere vertraging, waardoor Direct Lake in de meeste gevallen niet dezelfde snelheid kan bieden als de Import-modus. Bovendien is Direct Lake ontworpen om meer flexibiliteit te bieden in near-real-time scenario’s waarbij de data niet volledig in het geheugen past, of waar continue dataveranderingen plaatsvinden. Dit maakt het handig voor specifieke toepassingen waar datavolumes te groot zijn voor volledige import, maar voor traditionele datamodellen die geoptimaliseerd zijn voor snelle rapportages blijft de Import-modus de beste keuze.

Daarnaast kent Direct Lake beperkingen in modellering en flexibiliteit, zoals het ontbreken van ondersteuning voor berekende kolommen en tabellen, wat in veel scenario’s essentieel is om complexe berekeningen en logica binnen een rapport te kunnen toepassen. Deze beperkingen maken het minder geschikt voor modellen die intensieve datatransformaties nodig hebben binnen Power BI zelf. Daardoor kan Direct Lake, ondanks zijn voordelen in specifieke situaties, niet de rol van de Import-modus overnemen in scenario’s die vragen om hoge prestaties en uitgebreide modelleeropties.

Direct Lake is geen vervanging voor Direct Query

Net zoals Azure Direct Lake geen vervanging is voor de Import-modus in Power BI, is het ook geen vervanger voor DirectQuery. Hoewel Direct Lake enkele kenmerken deelt met DirectQuery, zijn de verschillen in functionaliteit en toepassingsgebieden groot genoeg dat Direct Lake niet als een volwaardige vervanger kan worden beschouwd.

DirectQuery staat erom bekend dat het directe verbindingen legt met externe databases, zonder dat er een volledige dataset in het geheugen hoeft te worden geladen. Dit maakt het ideaal voor real-time scenario’s, waarbij data direct en zonder vertraging wordt opgehaald vanuit de onderliggende bron. Elke query die wordt uitgevoerd, haalt op dat moment de meest actuele gegevens op uit de database, wat cruciaal is voor toepassingen die met continu veranderende informatie werken, zoals dashboards die real-time bedrijfsprestaties monitoren.

Direct Lake werkt anders. Hoewel het ook toegang biedt tot data zonder dat alles vooraf in het geheugen hoeft te worden geladen, gebeurt dit in een near-real-time context. In Direct Lake wordt de data eerst naar het geheugen gehaald en geconverteerd naar VertiPaq-formaat voordat het verder wordt gebruikt. Dit betekent dat, ondanks dat het sneller kan zijn dan DirectQuery in sommige situaties waar de data beschikbaar is in het geheugen, Direct Lake altijd een minimale vertraging introduceert wanneer data voor het eerst moet worden verwerkt. Bovendien is Direct Lake afhankelijk van periodieke updates van het semantisch model, wat ervoor zorgt dat wijzigingen in de onderliggende data niet direct zichtbaar zijn. In DirectQuery is deze vertraging er niet; elke query haalt altijd de laatste versie van de data op.

Dit maakt Direct Lake beter geschikt voor situaties waarin snelle toegang tot grote hoeveelheden data nodig is, zonder dat dit per se in real-time hoeft te gebeuren, zoals bij analytische rapporten die met frequent, maar niet continue veranderende data werken. DirectQuery blijft echter de optimale keuze wanneer real-time datatoegang essentieel is, zoals bij systemen waar geen enkele vertraging acceptabel is.

Daarnaast komt DirectQuery met minder beperkingen wat betreft modellering. DirectQuery ondersteunt bijvoorbeeld het gebruik van berekende kolommen en tabellen, en biedt meer flexibiliteit in de manier waarop data wordt gemanipuleerd en getoond binnen het model. Direct Lake is daarentegen meer beperkt, wat betekent dat voor bepaalde complexe rapportages DirectQuery eenvoudiger te implementeren en te onderhouden is. Kortom, Direct Lake en DirectQuery bedienen verschillende behoeften: Direct Lake optimaliseert near-real-time prestaties met data die naar het geheugen wordt geladen, terwijl DirectQuery real-time toegang biedt met de volledige flexibiliteit die nodig is voor continue dataverandering.

Serieuze beperkingen in modellering. Niet alleen op technisch gebied

Een van de meest opvallende beperkingen van Direct Lake in Power BI is het gebrek aan ondersteuning voor berekende kolommen, berekende tabellen, en MDX-gebruikershiërarchieën. Deze elementen zijn vaak cruciaal voor het bouwen van geavanceerde datamodellen, vooral wanneer je werkt met complexe berekeningen die niet direct in de onderliggende dataset beschikbaar zijn. Dit probleem wordt vooral gevoeld door gebruikers die Power BI combineren met Excel, aangezien MDX-gebruikershiërarchieën een belangrijk onderdeel vormen van de manier waarop Excel met Power BI-modellen werkt. Wanneer deze hiërarchieën ontbreken, kan dit de gebruikerservaring binnen Excel aanzienlijk beïnvloeden, vooral bij het verkennen van data via draaitabellen of andere Excel-rapportagefunctionaliteiten.

Minder flexibele modelleerervaring

Berekende kolommen en tabellen spelen een belangrijke rol in het uitbreiden van de functionaliteit van een model binnen Power BI. Ze stellen gebruikers in staat om nieuwe gegevens af te leiden op basis van bestaande informatie, zonder dat ze wijzigingen hoeven aan te brengen in de brondata. In een typisch Power BI-rapport kan een berekende kolom bijvoorbeeld worden gebruikt om aangepaste categorieën, samenvattingen, of rangordes te maken, die dynamisch worden bijgewerkt wanneer het onderliggende model verandert. Hetzelfde geldt voor berekende tabellen, die handig zijn voor het maken van nieuwe dataviews op basis van bestaande tabellen. In Direct Lake zijn deze functies niet beschikbaar, wat betekent dat elke extra datamanipulatie of transformatie moet plaatsvinden buiten Power BI, bijvoorbeeld in het data lake zelf. Dit leidt tot een minder flexibele modelleerervaring en kan de ontwikkelcyclus aanzienlijk verlengen, omdat data engineers vooraf alle benodigde berekeningen moeten inbouwen.

Alleen gematerialiseerde tabellen

Een ander belangrijk knelpunt is dat Direct Lake alleen fysieke tabellen ondersteunt, wat betekent dat views (een veelgebruikte techniek in datamodellering) niet optimaal werken in deze modus. In veel gevallen gebruiken Power BI-ontwikkelaars views om logische lagen aan te brengen bovenop de onderliggende data. Bijvoorbeeld, een view kan worden gebruikt om complexe berekeningen te vereenvoudigen of om data voor te bereiden op een manier die gemakkelijker te verwerken is in rapporten. Echter, wanneer een view wordt gebruikt in Direct Lake, dwingt dit Power BI om terug te vallen op DirectQuery, wat de prestaties drastisch kan verminderen. DirectQuery maakt immers directe query’s naar de onderliggende data zonder deze eerst in het geheugen te laden, wat handig is voor real-time updates, maar doorgaans veel trager is dan de snelheid van modellen die volledig in het geheugen zijn geladen zoals in de Import-modus.

Extra datakopieën

Om de modelleervereisten te kunnen vervullen zonder de prestaties te degraderen, kan het nodig zijn om fysieke kopieën van de data te maken die direct compatibel zijn met Direct Lake. Dit betekent dat je mogelijk extra datakopieën in je lakehouse moet aanmaken om aan specifieke rapportagevereisten te voldoen. Zo’n proces verhoogt niet alleen de complexiteit van de datamodellering, maar kan ook leiden tot duplicatie van data, wat weer extra opslagruimte en beheer vereist. Bovendien vereist dit vaak samenwerking met data-engineers die de verantwoordelijkheid dragen om de data op de juiste manier te transformeren en klaar te maken voor gebruik in Power BI. Deze extra stap kan de ontwikkelcyclus vertragen en meer middelen vereisen om de gewenste resultaten te bereiken.

Het ontbreken van ondersteuning voor views en berekende tabellen maakt Direct Lake dus minder flexibel dan Import-modus of zelfs DirectQuery, die beide wel deze mogelijkheden bieden. Gebruikers die gewend zijn om snelle iteraties uit te voeren op hun datamodellen, bijvoorbeeld door eenvoudig een nieuwe berekende kolom toe te voegen of een view te gebruiken om data voor te bereiden, zullen merken dat ze in Direct Lake beperkt worden. Dit kan vooral problematisch zijn in omgevingen waar data snel verandert en aanpassingen aan het model vaak nodig zijn om bij te blijven met de bedrijfsbehoeften.​

Het gebruik van geheugen in de Vertipaq engine

Het geheugengebruik van Direct Lake en Import-modus in Power BI lijkt in eerste instantie vergelijkbaar, omdat beide alleen de benodigde kolommen in het geheugen laden tijdens het uitvoeren van een query. Deze manier van on-demand laden, waarbij alleen de data die daadwerkelijk nodig is wordt opgehaald, zorgt ervoor dat beide modi efficiënt omgaan met geheugenruimte. Dit kan met name belangrijk zijn bij grote datasets, waar het laden van onnodige kolommen en rijen het geheugengebruik zou kunnen opblazen en de prestaties zou kunnen verminderen.

Vertipaq bij import

In Import-modus wordt de volledige dataset, of op zijn minst de relevante kolommen, vooraf in het geheugen geladen en gecomprimeerd via de VertiPaq-engine, wat zorgt voor geoptimaliseerde prestaties bij het uitvoeren van queries. Dit betekent dat zodra de data eenmaal in het geheugen zit, Power BI hier razendsnel toegang toe heeft, zonder dat er verdere data van schijven of databases hoeft te worden opgehaald. Echter, deze modus heeft één belangrijk nadeel: als het beschikbare geheugen van de machine niet voldoende is om de vereiste dataset te laden, krijg je een out-of-memory error. In dat geval stopt het model met werken en wordt het rapport niet geladen, wat problematisch kan zijn in scenario’s met zeer grote datasets die niet goed passen binnen het geheugenlimiet van de machine.

Vertipaq bij Direct Lake

Bij Direct Lake is het gedrag anders. Direct Lake probeert eveneens zoveel mogelijk relevante data in het geheugen te laden voor snelle verwerking, maar als het beschikbare geheugen vol raakt, schakelt Direct Lake automatisch over op DirectQuery. In plaats van een foutmelding zoals bij Import-modus, probeert het systeem dan de query uit te voeren door direct toegang te krijgen tot de brondata in het data lake. Hoewel dit voorkomt dat een query helemaal faalt, heeft deze fallback naar DirectQuery aanzienlijke prestatiegevolgen. DirectQuery voert namelijk de query’s rechtstreeks uit op de onderliggende opslag, wat doorgaans veel langzamer is omdat de data telkens opnieuw moet worden opgehaald en verwerkt in plaats van dat deze al beschikbaar is in het geheugen.

Zeer grote datasets

De impact hiervan wordt vooral duidelijk bij het werken met zeer grote datasets. In scenario’s waar de volledige dataset niet in het geheugen past, biedt Direct Lake theoretisch gezien een voordeel: het systeem crasht niet, maar de prestaties nemen wel drastisch af omdat elke query die een geheugendrempel overschrijdt, afhankelijk wordt van de snelheid van de onderliggende data-opslag en netwerkinfrastructuur. Dit betekent dat, hoewel Direct Lake gebruikers behoedt voor systeemfouten, de ervaring van gebruikers die gewend zijn aan de snelheid van volledig in-memory operaties, sterk kan worden beïnvloed.

Bovendien kan het fallback-mechanisme naar DirectQuery in Direct Lake onverwachte prestatieverschillen veroorzaken. Een query die aanvankelijk snel lijkt te verlopen doordat de data al in het geheugen zit, kan ineens aanzienlijk vertragen wanneer een nieuw element aan het rapport wordt toegevoegd dat een extra dataset vereist. Als deze nieuwe dataset niet in het geheugen past, wordt DirectQuery gebruikt, wat kan leiden tot prestatieverschillen van een compleet andere orde van grootte. In Import-modus wordt dit probleem niet ervaren, omdat het model vaststaat: als de data niet in het geheugen past, wordt dit direct aangegeven en kan het modelontwerp worden aangepast voordat er prestatieproblemen optreden.

Extra technische kennis en ervaring

Een ander belangrijk punt om te overwegen is dat het geheugenbeheer in Direct Lake afhankelijk is van de Parquet-bestanden die in het Delta-formaat worden opgeslagen. De manier waarop deze bestanden zijn gecomprimeerd en gepartitioneerd, speelt een grote rol in de efficiëntie van het geheugenverbruik. Als deze bestanden slecht zijn geoptimaliseerd, kan het geheugen snel vollopen, waardoor het systeem vaker moet terugvallen op DirectQuery. Dit vereist extra technische kennis en planning van de data-engineeringteams om ervoor te zorgen dat de bestanden zo zijn ingesteld dat ze optimaal gebruikmaken van het beschikbare geheugen zonder dat er onnodig wordt teruggevallen op tragere querymethoden.

In de praktijk betekent dit dat Direct Lake beter geschikt is voor near-real-time scenario’s, waarin data snel beschikbaar moet zijn, maar waar sommige vertragingen bij het ophalen van data acceptabel zijn. Voor zeer grote modellen die niet in hun geheel in het geheugen passen, kan Direct Lake een alternatief zijn dat meer flexibiliteit biedt dan Import-modus, omdat het niet vastloopt bij een geheugenoverschrijding. Echter, voor scenario’s waarin hoge prestaties en consistente querysnelheid essentieel zijn, blijft Import-modus de voorkeursoptie, vooral omdat de snelheid van Direct Lake onvoorspelbaar kan worden wanneer het model tegen de limieten van het beschikbare geheugen aanloopt.

Conclusie

Direct Lake biedt zeker voordelen in specifieke situaties, vooral wanneer je met zeer grote datasets werkt of near-real-time toegang tot data nodig hebt. Het kan een oplossing zijn voor modellen boven de 100/200 GB waar de Import-modus tegen grenzen aanloopt. Toch zijn de beperkingen op het gebied van modellering en prestaties duidelijk, en de fallback naar DirectQuery kan onverwachte vertragingen introduceren. Voor de meeste gebruikers blijft de Import-modus de betrouwbaarste en snelste optie, vooral als het model al goed presteert en stabiliteit belangrijk is.

Het is essentieel om Direct Lake niet te zien als een vervanger van de Import- of DirectQuery-modus, maar als een aanvullende optie voor zeer specifieke use cases. Succesvolle implementatie van Direct Lake vereist een goed begrip van de technische nuances, zoals het beheren van geheugen en datacompressie. Het vraagt ook om extra ontwikkeltijd en expertise om ervoor te zorgen dat de prestaties op niveau blijven.

Als je overweegt Direct Lake te implementeren of je huidige datamodel op de juiste manier wilt optimaliseren, maar niet precies weet waar je moet beginnen, dan staat ons team voor je klaar. Met onze ervaring kunnen we je begeleiden bij het maken van de juiste keuzes en helpen voorkomen dat je modelontwikkeling onnodig complex of inefficiënt wordt.