Overzicht van Direct Lake
Direct Lake is een opslagmodusoptie voor tabellen in een semantisch Power BI-model dat is opgeslagen in een Microsoft Fabric-werkruimte. Het is geoptimaliseerd voor grote hoeveelheden gegevens die snel in het geheugen kunnen worden geladen vanuit Delta-tabellen, die hun gegevens opslaan in Parquet-bestanden in OneLake-, het enige archief voor alle analysegegevens. Zodra het in het geheugen is geladen, maakt het semantische model query's met hoge prestaties mogelijk. Direct Lake elimineert de trage en kostbare noodzaak om gegevens in het model te importeren.
U kunt de Direct Lake opslagmodus gebruiken om verbinding te maken met de tabellen of weergaven van één Fabric Lakehouse of Fabric Warehouse. Voor beide Fabric-items en Direct Lake-semantische modellen is een Fabric-capaciteitslicentievereist.
Op sommige manieren is een semantisch model van Direct Lake vergelijkbaar met een import-semantisch model. Dat komt doordat modelgegevens in het geheugen worden geladen door de VertiPaq-engine voor snelle queryprestaties (behalve in het geval van DirectQuery-terugval, wat verderop in dit artikel wordt uitgelegd).
Een semantisch Direct Lake-model verschilt echter van een import-semantisch model op een belangrijke manier. Dat komt doordat een vernieuwingsbewerking voor een semantisch Direct Lake-model conceptueel verschilt van een vernieuwingsbewerking voor een semantisch importmodel. Voor een semantisch model van Direct Lake houdt een vernieuwing een framebewerking in (zoals verderop in dit artikel beschreven), hetgeen enkele seconden kan duren om te voltooien. Het is een goedkope bewerking waarbij het semantische model de metagegevens van de nieuwste versie van de Delta-tabellen analyseert en wordt bijgewerkt om te verwijzen naar de meest recente bestanden in OneLake. Voor een semantisch importmodel produceert een vernieuwing daarentegen een kopie van de gegevens, wat veel tijd kan duren en aanzienlijke gegevensbron- en capaciteitsbronnen (geheugen en CPU) kan verbruiken.
Notitie
Incrementele vernieuwing van een semantisch importmodel kan de vernieuwingstijd en het gebruik van capaciteit helpen verminderen.
Wanneer moet u de Direct Lake-opslagmodus gebruiken?
De primaire use case voor een Direct Lake-opslagmodus is doorgaans bedoeld voor IT-gestuurde analyseprojecten die gebruikmaken van meergerichte architecturen. In dit scenario hebt u grote hoeveelheden gegevens in OneLake( of verwacht u deze te verzamelen). Het snel laden van die gegevens in het geheugen, frequente en snelle vernieuwingsbewerkingen, efficiënt gebruik van capaciteitsresources en snelle queryprestaties zijn allemaal belangrijk voor deze use-case.
Notitie
Import- en DirectQuery-semantische modellen zijn nog steeds relevant in Fabric en zijn de juiste keuze voor semantisch model voor sommige scenario's. De importopslagmodus werkt bijvoorbeeld vaak goed voor een selfserviceanalist die de vrijheid en flexibiliteit nodig heeft om snel te handelen en zonder afhankelijkheid van IT om nieuwe gegevenselementen toe te voegen.
Bovendien schrijft Integratie van OneLake automatisch gegevens voor tabellen in de importopslagmodus naar Delta-tabellen in OneLake zonder dat hiervoor migratie is vereist. Met deze optie kunt u veel van de voordelen van Fabric realiseren die beschikbaar worden gesteld voor gebruikers van het semantische model, zoals integratie met lakehouses met behulp van snelkoppelingen, SQL-query's, notebooks en meer. We raden u aan deze optie te beschouwen als een snelle manier om de voordelen van Fabric te benutten zonder dat u uw bestaande datawarehouse en/of analysesysteem onmiddellijk opnieuw hoeft te ontwerpen.
De Direct Lake-opslagmodus is ook geschikt voor het minimaliseren van de gegevenslatentie om gegevens snel beschikbaar te maken voor zakelijke gebruikers. Als uw Delta-tabellen af en toe worden gewijzigd (en ervan uitgaande dat u al gegevensvoorbereiding hebt uitgevoerd in de Data Lake), kunt u afhankelijk zijn van automatische updates om te herframen als reactie op deze wijzigingen. In dit geval retourneren query's die naar het semantische model worden verzonden de meest recente gegevens. Deze mogelijkheid werkt goed samen met de functie voor het automatisch vernieuwen van pagina's functie van Power BI-rapporten.
Houd er rekening mee dat Direct Lake afhankelijk is van gegevensvoorbereiding die wordt uitgevoerd in de data lake. Gegevensvoorbereiding kan worden uitgevoerd met behulp van diverse tools, zoals Spark-jobs voor Fabric lakehouses, T-SQL DML-instructies voor Fabric warehouses, dataflows, pipelines en anderen. Deze aanpak helpt ervoor te zorgen dat gegevensvoorbereidingslogica zo laag mogelijk wordt uitgevoerd in de architectuur om de herbruikbaarheid te maximaliseren. Als de auteur van het semantische model echter niet de mogelijkheid heeft om het bronitem te wijzigen, bijvoorbeeld als een selfserviceanalist geen schrijfmachtigingen heeft voor een lakehouse die wordt beheerd door IT, is importopslagmodus mogelijk een betere keuze. Dat komt doordat het ondersteuning biedt voor gegevensvoorbereiding met behulp van Power Query, die wordt gedefinieerd als onderdeel van het semantische model.
Zorg ervoor dat u rekening houdt met uw huidige Fabric-capaciteitslicentie en de Fabric-capaciteitsgrenzen wanneer u de Direct Lake-opslagmodus overweegt. Houd ook rekening met de overwegingen en beperkingen, die verderop in dit artikel worden beschreven.
Fooi
U wordt aangeraden een prototype te produceren(of proof of concept) om te bepalen of een Direct Lake-semantisch model de juiste oplossing is en om risico's te beperken.
Hoe Direct Lake werkt
Query's die naar een semantisch Direct Lake-model worden verzonden, worden doorgaans verwerkt vanuit een cache in het geheugen van de kolommen die afkomstig zijn uit Delta-tabellen. De onderliggende opslag voor een Delta-tabel is een of meer Parquet-bestanden in OneLake. Parquet-bestanden organiseren gegevens op kolommen in plaats van rijen. Semantische modellen laden volledige kolommen uit Delta-tabellen in het geheugen, omdat ze vereist zijn voor query's.
Een semantisch Direct Lake-model kan ook gebruikmaken van DirectQuery-terugval, waarbij naadloos wordt overgeschakeld naar DirectQuery-modus. Met DirectQuery-terugval worden gegevens rechtstreeks opgehaald uit het SQL Analytics-eindpunt van het Lakehouse- of het warehouse. Terugval kan bijvoorbeeld optreden wanneer een Delta-tabel meer rijen met gegevens bevat dan wordt ondersteund door uw Fabric-capaciteit (verderop beschreven in dit artikel). In dit geval verzendt een DirectQuery-bewerking een query naar het SQL-analyse-eindpunt. Terugvalbewerkingen kunnen leiden tot tragere prestaties van query's.
In het volgende diagram ziet u hoe Direct Lake werkt met behulp van het scenario van een gebruiker die een Power BI-rapport opent.
In het diagram ziet u de volgende gebruikersacties, processen en functies.
| Artikel | Beschrijving |
|---|---|
|
OneLake is een data lake waarin analysegegevens in Parquet-indeling worden opgeslagen. Deze bestandsindeling is geoptimaliseerd voor het opslaan van gegevens voor semantische Direct Lake-modellen. |
|
Er bestaat een Fabric Lakehouse of Fabric warehouse in een werkruimte met Fabric capaciteit. Het Lakehouse heeft een SQL-analyse-eindpunt, dat een SQL-ervaring biedt voor het uitvoeren van query's. Tabellen (of weergaven) bieden een middel om een query uit te voeren op de Delta-tabellen in OneLake met behulp van Transact-SQL (T-SQL). |
|
Er bestaat een semantisch Direct Lake-model in een Fabric-werkruimte. Het maakt verbinding met tabellen of uitzichten in het lakehouse of magazijn. |
|
Een gebruiker opent een Power BI-rapport. |
|
Het Power BI-rapport verzendt DAX-query's (Data Analysis Expressions) naar het semantische Direct Lake-model. |
|
Indien mogelijk (en nodig) laadt het semantische model kolommen rechtstreeks vanuit de Parquet-bestanden die zijn opgeslagen in OneLake. Queries behalen prestaties binnen het geheugen, wat erg snel is. |
|
Het semantische model retourneert de queryresultaten. |
|
Het Power BI-rapport geeft de visuals weer. |
|
In bepaalde gevallen, zoals wanneer het semantische model de kaders overschrijdt van de capaciteit, vallen semantische modelquery's automatisch terug naar de DirectQuery-modus. In deze modus worden query's verzonden naar het SQL-analyse-eindpunt van het lakehouse of warehouse. |
|
DirectQuery-query's die naar het SQL-analyse-eindpunt zijn verzonden, voeren op hun beurt een query uit op de Delta-tabellen in OneLake. Daarom kunnen de prestaties van query's langzamer zijn dan die van query's die in het geheugen worden uitgevoerd. |
In de volgende secties worden Direct Lake-concepten en -functies beschreven, waaronder het laden van kolommen, lijsten, automatische updates en DirectQuery-terugval.
Kolom laden (transcodering)
Semantische Direct Lake-modellen laden alleen gegevens uit OneLake als en wanneer er voor het eerst query's worden uitgevoerd op kolommen. Het proces van het laden van gegevens op aanvraag vanuit OneLake wordt transcoderinggenoemd.
Wanneer het semantische model een DAX-query (of multidimensionale expressies— MDX) ontvangt, wordt eerst bepaald welke kolommen nodig zijn om een queryresultaat te produceren. Elke kolom die rechtstreeks door de query wordt gebruikt, is nodig en ook kolommen die vereist zijn voor relaties en metingen. Normaal gesproken is het aantal kolommen dat nodig is om een queryresultaat te produceren aanzienlijk kleiner dan het aantal kolommen dat is gedefinieerd in het semantische model.
Zodra het begrijpt welke kolommen nodig zijn, bepaalt het semantische model welke kolommen zich al in het geheugen bevinden. Als kolommen die nodig zijn voor de query zich niet in het geheugen bevinden, worden alle gegevens voor deze kolommen uit OneLake geladen door het semantische model. Het laden van kolomgegevens is doorgaans een snelle bewerking, maar dit kan afhankelijk zijn van factoren zoals de kardinaliteit van gegevens die zijn opgeslagen in de kolommen.
Kolommen die in het geheugen worden geladen, zijn vervolgens aanwezig in het geheugen. Toekomstige query's waarbij alleen resident kolommen betrokken zijn, hoeven geen extra kolommen in geheugen te laden.
Een kolom blijft in het geheugen aanwezig totdat er een reden is om deze te verwijderen (uitgewist). Redenen waarom kolommen mogelijk worden verwijderd, zijn onder andere:
- Het model of de tabel is ververst na een update van de Delta-tabel bij de bron (zie Framing in de volgende paragraaf).
- Al enige tijd heeft geen enkele query de kolom gebruikt.
- Andere redenen voor geheugenbeheer, waaronder geheugendruk in de capaciteit vanwege andere, gelijktijdige bewerkingen.
Uw keuze van Fabric SKU bepaalt het maximaal beschikbare geheugen voor elk Direct Lake-semantisch model binnen de capaciteit. Zie verderop in dit artikel bij Fabric-capaciteitsrichtlijnen en beperkingen voor meer informatie over resource guardrails en maximale geheugenlimieten.
Framing
Framing biedt modeleigenaren op een bepaald moment controle over welke gegevens in het semantische model worden geladen. Framen is een Direct Lake-bewerking die wordt geactiveerd door een vernieuwing van een semantisch model, en in de meeste gevallen duurt het slechts een paar seconden om te voltooien. Dat komt doordat het een goedkope bewerking is waarbij het semantische model de metagegevens van de nieuwste versie van de Delta Lake-tabellen analyseert en wordt bijgewerkt om te verwijzen naar de nieuwste Parquet-bestanden in OneLake.
Wanneer framing optreedt, kunnen de kolomsegmenten en woordenlijsten van de tabel uit het geheugen worden verwijderd als de onderliggende gegevens zijn gewijzigd en het moment van vernieuwing de nieuwe basislijn wordt voor alle toekomstige transcoderingsgebeurtenissen. Vanaf dit moment worden bij Direct Lake-zoekopdrachten uitsluitend gegevens in de Delta-tabellen in beschouwing genomen die geldig zijn op het moment van de meest recente framebewerking. Daarom worden Direct Lake-tabellen opgevraagd om gegevens te retourneren op basis van de status van de Delta-tabel op het moment van de meest recente framebewerking. Die tijd is niet noodzakelijkerwijs de meest recente status van de Delta-tabellen.
Houd er rekening mee dat het semantische model het Delta-logboek van elke Delta-tabel analyseert tijdens het frame om alleen de betrokken kolomsegmenten te verwijderen en om zojuist toegevoegde gegevens opnieuw te laden tijdens transcodering. Een belangrijke optimalisatie is dat woordenlijsten meestal niet worden verwijderd wanneer incrementele framing van kracht wordt en nieuwe waarden worden toegevoegd aan de bestaande woordenlijsten. Deze incrementele framingbenadering helpt de herlaadbelasting te verminderen en de prestaties van queries te verbeteren. In het ideale geval, wanneer een Delta-tabel geen updates heeft ontvangen, is er geen herlaadbewerking nodig voor kolommen die al in het geheugen aanwezig zijn en query's veel minder invloed hebben op de prestaties na het inlijsten, omdat incrementele frames het semantische model in feite in staat stelt om aanzienlijke delen van de bestaande in-memory gegevens bij te werken.
In het volgende diagram ziet u hoe Direct Lake-framingbewerkingen werken.
In het diagram ziet u de volgende processen en functies.
| Artikel | Beschrijving |
|---|---|
|
|
Er bestaat een semantisch model in een Fabric-werkruimte. |
|
|
Framebewerkingen vinden periodiek plaats en stellen de basislijn in voor alle toekomstige transcodering gebeurtenissen. Framebewerkingen kunnen automatisch, handmatig, volgens schema of programmatisch worden uitgevoerd. |
|
|
In OneLake worden metagegevens en Parquet-bestanden opgeslagen, die worden weergegeven als Delta-tabellen. |
|
|
De laatste kaderbewerkingen omvatten Parquet-bestanden met betrekking tot de Delta-tabellen, en specifiek de Parquet-bestanden die zijn toegevoegd vóór de laatste kaderbewerking. |
|
|
Een latere kaderbewerking bevat Parquet-bestanden die zijn toegevoegd na de laatste kaderbewerking. |
|
|
Lokale kolommen in het semantische Direct Lake-model kunnen worden verwijderd uit het geheugen en het tijdstip van de vernieuwing wordt de nieuwe basislijn voor alle toekomstige transcoderingsgebeurtenissen. |
|
|
Volgende gegevenswijzigingen, vertegenwoordigd door nieuwe Parquet-bestanden, zijn pas zichtbaar als de volgende framebewerking plaatsvindt. |
Het is niet altijd wenselijk om gegevens te hebben die de meest recente status van een Delta-tabel vertegenwoordigen wanneer er een transcoderingsbewerking plaatsvindt. Houd er rekening mee dat framelijsten u kunnen helpen bij het bieden van consistente queryresultaten in omgevingen waarin gegevens in Delta-tabellen tijdelijk zijn. Gegevens kunnen om verschillende redenen tijdelijk zijn, zoals wanneer langlopende ETL-processen (extract, transformatie en belasting) plaatsvinden.
Vernieuwen voor een Direct Lake-semantisch model kan handmatig, automatisch of programmatisch worden uitgevoerd. Voor meer informatie, zie Direct Lake-semantische modellen vernieuwen.
Zie Inzicht in opslag voor semantische Direct Lake-modellenvoor meer informatie over versiebeheer en framelijsten van Delta-tabellen.
Automatische updates
Er is een instelling op semantisch modelniveau om Direct Lake-tabellen automatisch bij te werken. Deze functie is standaard ingeschakeld. Het zorgt ervoor dat gegevenswijzigingen in OneLake automatisch worden doorgevoerd in het semantische Direct Lake-model. Schakel automatische updates uit wanneer u wijzigingen in gegevens wilt beheren door middel van framelijsten. Dit is uitgelegd in de vorige sectie. Zie Semantische direct lake-modellen beherenvoor meer informatie.
Fooi
Je kunt automatische paginavernieuwing instellen in je Power BI-rapporten. Het is een functie die automatisch een specifieke rapportpagina vernieuwt, mits het rapport verbinding maakt met een Direct Lake-semantisch model (of andere typen semantisch model).
DirectQuery-terugval
Een query die naar een semantisch Direct Lake-model wordt verzonden, kan terugvallen op DirectQuery-modus. In dit geval worden gegevens rechtstreeks opgehaald uit het SQL-analyse-eindpunt van het lakehouse of warehouse. Dergelijke query's retourneren altijd de meest recente gegevens omdat ze niet zijn beperkt tot het tijdstip van de laatste framebewerking.
Een query altijd terugvalt wanneer het semantische model een weergave opvraagt in het SQL Analytics-eindpunt of een tabel in het SQL Analytics-eindpunt dat beveiliging op rijniveau (RLS) afdwingt.
Een query kan ook terugvallen wanneer het semantische model de kaders van de capaciteitoverschrijdt.
Belangrijk
Indien mogelijk moet u altijd uw oplossing ontwerpen (of uw capaciteit vergroten) om DirectQuery-terugval te voorkomen. Dat komt doordat dit kan leiden tot tragere queryprestaties.
U kunt de terugval van semantische modellen van Direct Lake beheren door de DirectLakeBehavior-eigenschap in te stellen. Voor meer informatie, zie De eigenschap Direct Lake-gedrag instellen.
Kaders en beperkingen voor capaciteit van infrastructuur
Direct Lake-semantische modellen vereisen een Fabric-capaciteitslicentie. Er zijn ook capaciteitsgrenzen en -beperkingen die van toepassing zijn op uw Fabric-capaciteitsabonnement (SKU), zoals wordt weergegeven in de volgende tabel.
Belangrijk
De eerste kolom in de volgende tabel bevat ook Power BI Premium-capaciteitsabonnementen (P-SKU's). Houd er rekening mee dat Microsoft aankoopopties consolideert en de Power BI Premium-SKU's per capaciteit buiten gebruik stelt. Nieuwe en bestaande klanten moeten overwegen om in plaats daarvan F-SKU's (Fabric-capaciteitsabonnementen) aan te schaffen.
Zie Belangrijke update beschikbaar voor Power BI Premium-licenties en Power BI Premium-voor meer informatie.
| Stof-SKU | Parquet-bestanden per tabel | Rijgroepen per tabel | Rijen per tabel (miljoenen) | Maximale modelgrootte op schijf/OneLake (GB) | Maximaal geheugen (GB) 1 |
|---|---|---|---|---|---|
| F2 | 1,000 | 1,000 | 300 | 10 | 3 |
| F4 | 1,000 | 1,000 | 300 | 10 | 3 |
| F8 | 1,000 | 1,000 | 300 | 10 | 3 |
| F16 | 1,000 | 1,000 | 300 | 20 | 5 |
| F32 | 1,000 | 1,000 | 300 | 40 | 10 |
| F64/FT1/P1 | 5,000 | 5,000 | 1,500 | Onbegrensd | 25 |
| F128/P2 | 5,000 | 5,000 | 3,000 | Onbegrensd | 50 |
| F256/P3 | 5,000 | 5,000 | 6,000 | Onbegrensd | 100 |
| F512/P4 | 10.000 | 10.000 | 12,000 | Onbegrensd | 200 |
| F1024/P5 | 10.000 | 10.000 | 24,000 | Onbegrensd | 400 |
| F2048 | 10.000 | 10.000 | 24,000 | Onbegrensd | 400 |
1 Voor semantische Direct Lake-modellen vertegenwoordigt Max Memory het maximale geheugenlimiet voor de hoeveelheid gegevens die in het geheugen kunnen worden geladen. Daarom is het geen kader omdat het overschrijden ervan niet resulteert in een terugval naar de DirectQuery-modus; Het kan echter een invloed hebben op de prestaties als de hoeveelheid gegevens groot genoeg is om overmatige paging in en uit de modelgegevens van de OneLake-gegevens te veroorzaken.
Als dit wordt overschreden, zorgt de maximale modelgrootte op schijf/OneLake ervoor dat alle query's naar het semantische model terugvallen naar de DirectQuery-modus. Alle andere kaders die in de tabel worden weergegeven, worden per query geëvalueerd. Het is daarom belangrijk dat u uw Delta-tabellen en semantisch Direct Lake-model optimaliseert om te voorkomen dat u onnodig omhoog moet schalen naar een hogere Fabric-SKU (wat resulteert in hogere kosten).
Daarnaast zijn capaciteitseenheid en maximaal geheugen per query limieten geldig voor semantische Direct Lake-modellen. Zie capaciteiten en SKU'svoor meer informatie.
Overwegingen en beperkingen
Direct Lake-semantische modellen bieden enkele overwegingen en beperkingen.
Notitie
De mogelijkheden en functies van semantische Direct Lake-modellen worden steeds verder ontwikkeld. Controleer regelmatig of u de meest recente lijst met overwegingen en beperkingen bekijkt.
- Wanneer een semantische Direct Lake-modeltabel verbinding maakt met een tabel in het SQL Analytics-eindpunt waarmee beveiliging op rijniveau (RLS) wordt afgedwongen, vallen query's met die modeltabel altijd terug naar de DirectQuery-modus. De prestaties van query's kunnen trager zijn.
- Wanneer een semantische Direct Lake-modeltabel verbinding maakt met een weergave in het SQL-analyse-eindpunt, vallen query's met die modeltabel altijd terug naar de DirectQuery-modus. De prestaties van query's kunnen trager zijn.
- Samengestelde modellering wordt niet ondersteund. Dat betekent dat semantische tabellen van Direct Lake-modellen niet kunnen worden gecombineerd met tabellen in andere opslagmodi, zoals Importeren, DirectQuery of Dual (met uitzondering van speciale gevallen, waaronder berekeningsgroepen, wat-als-parametersen veldparameters).
- Berekende kolommen en berekende tabellen die verwijzen naar kolommen of tabellen in de Direct Lake-opslagmodus, worden niet ondersteund. Berekeningsgroepen, wat-als-parametersen veldparameters, die impliciet berekende tabellen maken en berekende tabellen die niet verwijzen naar Direct Lake-kolommen of -tabellen, worden ondersteund.
- Tabellen in de Direct Lake-opslagmodus bieden geen ondersteuning voor complexe deltatabelkolomtypen. Binaire en GUID-semantische typen worden ook niet ondersteund. U moet deze gegevenstypen converteren naar tekenreeksen of andere ondersteunde gegevenstypen.
- Voor tabelrelaties moeten de gegevenstypen van gerelateerde kolommen overeenkomen.
- Eenzijdige relatiekolommen moeten unieke waarden bevatten. Query's mislukken als dubbele waarden worden gedetecteerd in een kolom met één zijde.
- Automatische gegevens- en tijdsintelligentie in Power BI Desktop wordt niet ondersteund. Het markeren van uw eigen datumtabel als een datumtabel wordt ondersteund.
- De lengte van tekenreekskolomwaarden is beperkt tot 32.764 Unicode-tekens.
- De drijvende-kommawaarde NaN- (geen getal) wordt niet ondersteund.
- Publiceren op internet vanuit Power BI met behulp van een service-principal wordt alleen ondersteund wanneer u een vaste identiteit gebruikt voor het semantische Direct Lake-model.
- In de webmodelleringservaringis validatie beperkt voor semantische Direct Lake-modellen. Gebruikersselecties worden verondersteld correct te zijn en er worden geen query's uitgegeven om kardinaliteit of kruisfilterselecties voor relaties te valideren, of voor de geselecteerde datumkolom in een gemarkeerde datumtabel.
- In de Fabric-portal worden op het tabblad Direct Lake in de vernieuwingsgeschiedenis alleen fouten met betrekking tot Direct Lake-gerelateerde vernieuwingen weergegeven. Geslaagde vernieuwingsbewerkingen (framebewerkingen) worden niet vermeld.
- Uw Fabric-SKU bepaalt het maximale beschikbare geheugen per semantisch Direct Lake-model voor de capaciteit. Wanneer de limiet wordt overschreden, kunnen query's naar het semantische model langzamer zijn vanwege overmatige paginering in en uit modelgegevens.
- Het maken van een semantisch Direct Lake-model in een werkruimte die zich in een andere regio van de gegevensbronwerkruimte bevindt, wordt niet ondersteund. Als het Lakehouse zich bijvoorbeeld in VS - west-centraal bevindt, kunt u alleen semantische modellen maken van dit Lakehouse in dezelfde regio. Een tijdelijke oplossing is het maken van een Lakehouse in de werkruimte van de andere regio en snelkoppeling naar de tabellen voordat u het semantische model maakt. Zie uw Fabric-thuisregio vindenom te ontdekken in welke regio u zich bevindt.
- U kunt een aangepast Direct Lake-semantisch model maken en weergeven met behulp van een service-principal-identiteit, maar het standaard semantische Direct Lake-model biedt geen ondersteuning voor service-principals. Zorg ervoor dat verificatie van de service-principal is ingeschakeld voor Fabric REST API's in uw tenant en geef de service-principal de machtigingen van Bijdrager of hoger aan de werkruimte van uw Direct Lake-semantisch model.
- Voor het insluiten van rapporten is een V2-insluittoken vereist.
- Direct Lake biedt geen ondersteuning voor service-principalprofielen voor verificatie.
- Aangepaste semantische Direct Lake-modellen die zijn gemaakt door service-principal en viewer met service-principal, worden ondersteund, maar standaard semantische Direct Lake-modellen worden niet ondersteund.
Vergelijking met andere opslagmodi
De volgende tabel vergelijkt de Direct Lake-opslagmodus met import- en DirectQuery-opslagmodi.
| Vermogen | Direct Lake | Importeren | DirectQuery |
|---|---|---|---|
| Licentieverlening | Alleen fabric-capaciteitsabonnement (SKU's) | Een Fabric- of Power BI-licentie (inclusief gratis licenties voor Microsoft Fabric) | Een Fabric- of Power BI-licentie (inclusief gratis licenties voor Microsoft Fabric) |
| Gegevensbron | Alleen lakehouse- of magazijntabellen (of weergaven) | Elke connector | Elke connector die ondersteuning biedt voor de DirectQuery-modus |
| Verbinding maken met eindpuntweergaven van SQL Analytics | Ja, maar wordt automatisch teruggezet naar de DirectQuery-modus | Ja | Ja |
| Samengestelde modellen | Geen 1 | Ja: kan worden gecombineerd met tabellen in de DirectQuery- of Dual-opslagmodus | Ja: kan worden gecombineerd met tabellen in de import- of dual-opslagmodus |
| Eenmalige aanmelding (SSO) | Ja | Niet van toepassing | Ja |
| Berekende tabellen | Nee, behalve berekeningsgroepen, wat-als-parametersen veldparameters, die impliciet berekende tabellen maken | Ja | Nee: berekende tabellen maken gebruik van de opslagmodus Importeren, zelfs wanneer ze verwijzen naar andere tabellen in de DirectQuery-modus |
| Berekende kolommen | Nee | Ja | Ja |
| Hybride tabellen | Nee | Ja | Ja |
| Model tabel partities | Nee, maar partitionering kan worden uitgevoerd op Deltatabelniveau | Ja: automatisch gemaakt door incrementeel vernieuwen of handmatig gemaakt met behulp van het XMLA-eindpunt | Nee |
| Door de gebruiker gedefinieerde aggregaties | Nee | Ja | Ja |
| Beveiliging op objectniveau van SQL Analytics-eindpunt of beveiliging op kolomniveau | Ja, maar query's vallen terug in de DirectQuery-modus en kunnen fouten veroorzaken wanneer de machtiging wordt geweigerd | Ja, maar de machtigingen moeten worden gedupliceerd met beveiliging op objectniveau binnen het semantische model. | Ja, maar query's kunnen fouten opleveren wanneer de machtiging wordt geweigerd |
| Beveiliging op rijniveau van SQL Analytics-eindpunt (RLS) | Ja, maar query's worden teruggezet naar de DirectQuery-modus | Ja, maar moet machtigingen dupliceren met semantische model-RLS | Ja |
| Beveiliging op rijniveau van Semantisch model (RLS) | Ja, maar het wordt sterk aanbevolen om een vaste identiteit te gebruiken cloudverbinding | Ja | Ja |
| Beveiliging op objectniveau van het semantische model (OLS) | Ja | Ja | Ja |
| Grote gegevensvolumes zonder vernieuwingsvereiste | Ja | Minder geschikt: een grotere capaciteitsgrootte is mogelijk vereist voor het uitvoeren van query's en vernieuwen | Ja |
| Gegevenslatentie verminderen | Ja, wanneer automatische updates is ingeschakeld of er sprake is van programmatische herschikking; moet gegevensvoorbereiding echter eerst voorafgaand in de keten worden uitgevoerd. | Nee | Ja |
| Power BI Embedded | Ja 2 | Ja | Ja |
1 U kunt tabellen in de Direct Lake-opslagmodus niet combineren met DirectQuery- of Dual-opslagmodustabellen in hetzelfde semantische model. U kunt Power BI Desktop echter gebruiken om een samengesteld model te maken op een semantisch Direct Lake-model en dit vervolgens uit te breiden met nieuwe tabellen (met behulp van de Import-, DirectQuery- of Dual-opslagmodus) of berekeningen. Zie Een samengesteld model bouwen op een semantisch modelvoor meer informatie.
2 Vereist een V2-insluittoken. Als u een service-principal gebruikt, moet u een vaste identiteit cloudverbinding gebruiken.