Översikt över Direct Lake
Direct Lake är ett lagringslägesalternativ för tabeller i en Power BI-semantisk modell som lagras på en Microsoft Fabric-arbetsyta. Den är optimerad för stora mängder data som snabbt kan läsas in i minnet från Delta-tabeller, som lagrar sina data i Parquet-filer i OneLake– det enda arkivet för alla analysdata. När den har lästs in i minnet möjliggör den semantiska modellen frågor med höga prestanda. Direct Lake eliminerar det långsamma och kostsamma behovet av att importera data till modellen.
Du kan använda lagringsläget Direct Lake för att ansluta till tabellerna eller vyerna i ett enda Fabric-lakehouse eller Fabric-lagerhus. Båda dessa Fabric-objekt och Direct Lake-semantiska modeller kräver en Fabric-kapacitetslicens.
På sätt och vis liknar en Direct Lake-semantisk modell en Import-semantisk modell. Det beror på att modelldata läses in i minnet av VertiPaq-motorn för snabba frågeprestandaer (förutom när det gäller DirectQuery fallback, som beskrivs senare i den här artikeln).
En Semantisk Direct Lake-modell skiljer sig dock från en importsemantisk modell på ett viktigt sätt. Det beror på att en uppdateringsåtgärd för en Direct Lake-semantisk modell skiljer sig konceptuellt från en uppdateringsåtgärd för en importsemantisk modell. För en Direct Lake-semantisk modell innebär en uppdatering en inramning åtgärd (beskrivs senare i den här artikeln), vilket kan ta några sekunder att slutföra. Det är en lågkostnadsåtgärd där den semantiska modellen analyserar metadata för den senaste versionen av Delta-tabellerna och uppdateras för att referera till de senaste filerna i OneLake. För en semantisk importmodell genererar en uppdatering däremot en kopia av data, vilket kan ta lång tid och förbruka betydande datakällor och kapacitetsresurser (minne och PROCESSOR).
Not
inkrementell uppdatering för en importsemantisk modell kan bidra till att minska uppdateringstiden och användningen av kapacitetsresurser.
När ska du använda Direct Lake-lagringsläge?
Det primära användningsfallet för ett Direct Lake-lagringsläge är vanligtvis för IT-drivna analysprojekt som använder sjöcentrerade arkitekturer. I det här scenariot har du – eller förväntar dig att ackumulera – stora mängder data i OneLake. Snabb inläsning av dessa data i minnet, frekventa och snabba uppdateringsåtgärder, effektiv användning av kapacitetsresurser och snabba frågeprestanda är alla viktiga för det här användningsfallet.
Not
Import- och DirectQuery-semantiska modeller är fortfarande relevanta i Fabric och är rätt val av semantisk modell för vissa scenarier. Till exempel fungerar importlagringsläget ofta bra för en självbetjäningsanalytiker som behöver friheten och flexibiliteten att agera snabbt och utan beroende av IT för att lägga till nya dataelement.
Dessutom skriver OneLake-integreringen automatiskt data från tabeller i importlagringsläge till Delta-tabeller i OneLake utan att någon migreringsinsats krävs. Med det här alternativet kan du förstå många av fördelarna med Fabric-plattformen som görs tillgängliga för användare av importerade semantiska modeller, till exempel integrering med lakehouses via genvägar, SQL-frågor, notebook-filer och mer. Vi rekommenderar att du ser det här alternativet som ett snabbt sätt att dra nytta av fördelarna med Fabric utan att nödvändigtvis eller omedelbart designa om ditt befintliga informationslager och/eller analyssystem.
Direct Lake-lagringsläget är också lämpligt för att minimera datafördröjningen för att snabbt göra data tillgängliga för företagsanvändare. Om dina deltatabeller ändras intermittent (och förutsatt att du redan har förberett data i datasjön) kan du lita på automatiska uppdateringar för att anpassa sig som svar på dessa ändringar. I det här fallet returnerar frågor som skickas till den semantiska modellen de senaste data. Den här funktionen fungerar bra i samarbete med funktionen för automatisk siduppdatering i Power BI-rapporterna.
Tänk på att Direct Lake är beroende av att dataförberedelser utförs i datasjön. Dataförberedelser kan göras med hjälp av olika verktyg, till exempel Spark-jobb för Fabric-lakehouses, T-SQL DML-instruktioner för Fabric-lager, dataflöden, pipelines och andra. Den här metoden hjälper till att säkerställa att dataförberedelselogik utförs så lågt som möjligt i arkitekturen för att maximera återanvändbarheten. Men om den semantiska modellförfattaren inte har möjlighet att ändra källobjektet, till exempel om en självbetjäningsanalytiker inte har skrivbehörighet på ett lakehouse som hanteras av IT, kan importlagringsläget vara ett bättre val. Det beror på att den stöder dataförberedelse med hjälp av Power Query, som definieras som en del av semantisk modell.
Tänk på att ta hänsyn till din aktuella Fabric-kapacitetslicens och Fabric-kapacitetsgränser när du överväger Direct Lake-lagringsläge. Ta också hänsyn till de överväganden och begränsningar, som beskrivs senare i den här artikeln.
Tips
Vi rekommenderar att du skapar en prototyp– eller konceptbevis (POC) – för att avgöra om en Direct Lake-semantisk modell är rätt lösning och för att minska risken.
Så här fungerar Direct Lake
Vanligtvis hanteras frågor som skickas till en Direct Lake-semantisk modell från en minnesintern cache av kolumnerna som kommer från Delta-tabeller. Den underliggande lagringen för en Delta-tabell är en eller flera Parquet-filer i OneLake. Parquet-filer organiserar data efter kolumner i stället för rader. Semantiska modeller läser in hela kolumner från Delta-tabeller i minnet eftersom de krävs av frågor.
En semantisk modell för Direct Lake kan också använda DirectQuery-övergång, vilket innebär att man smidigt byter till DirectQuery-läge. DirectQuery-återställning hämtar data direkt från SQL-analysslutpunkten för lakehouse- eller lagret. Återfall kan till exempel inträffa när en Delta-tabell innehåller fler rader med data än vad som stöds av din Fabric-kapacitet (beskrivs senare i den här artikeln). I det här fallet skickar en DirectQuery-åtgärd en fråga till SQL-analysslutpunkten. Återställningsåtgärder kan leda till långsammare frågeprestanda.
Följande diagram visar hur Direct Lake fungerar med scenariot för en användare som öppnar en Power BI-rapport.
Diagrammet visar följande användaråtgärder, processer och funktioner.
| Sak | Beskrivning |
|---|---|
|
OneLake är en datasjö som lagrar analysdata i Parquet-format. Det här filformatet är optimerat för lagring av data för Direct Lake-semantiska modeller. |
|
Det finns en Fabric-lakehouse eller ett Fabric-lager i en arbetsyta som är på Fabric-kapacitet. Lakehouse har en SQL-analysslutpunkt som ger en SQL-baserad upplevelse för frågor. Tabeller (eller vyer) ger ett sätt att köra frågor mot Delta-tabellerna i OneLake med hjälp av Transact-SQL (T-SQL). |
|
En Direct Lake-semantisk modell finns i en Fabric-arbetsyta. Den ansluter till tabeller eller vyer i antingen lakehouset eller datalagret. |
|
En användare öppnar en Power BI-rapport. |
|
Power BI-rapporten skickar DAX-frågor (Data Analysis Expressions) till Direct Lake-semantikmodellen. |
|
När det är möjligt (och nödvändigt) läser den semantiska modellen in kolumner i minnet direkt från Parquet-filerna som lagras i OneLake. Frågor uppnår minnesintern prestanda, vilket är mycket snabbt. |
|
Den semantiska modellen returnerar frågeresultat. |
|
Power BI-rapporten återger de visuella objekten. |
|
Under vissa omständigheter, till exempel när den semantiska modellen överskrider skyddsräcken av kapaciteten, återgår semantiska modellfrågor automatiskt tillbaka till DirectQuery-läge. I det här läget skickas frågor till SQL-analysslutpunkten för lakehouse eller datalager. |
|
DirectQuery-frågor som skickas till SQL-analysslutpunkten frågar i sin tur Delta-tabellerna i OneLake. Därför kan frågeprestanda vara långsammare än minnesinterna frågor. |
I följande avsnitt beskrivs Begrepp och funktioner i Direct Lake, inklusive kolumninläsning, inramning, automatiska uppdateringar och DirectQuery-återställning.
Kolumnladdning (omkodning)
Direct Lake-semantiska modeller läser bara in data från OneLake som och när kolumner efterfrågas för första gången. Processen för att läsa in data på begäran från OneLake kallas omkodning.
När den semantiska modellen tar emot en DAX-fråga (eller flerdimensionella uttryck – MDX) avgör den först vilka kolumner som behövs för att skapa ett frågeresultat. Alla kolumner som används direkt av frågan behövs, och även kolumner som krävs av relationer och mått. Vanligtvis är antalet kolumner som behövs för att skapa ett frågeresultat betydligt mindre än antalet kolumner som definierats i semantikmodellen.
När den förstår vilka kolumner som behövs avgör den semantiska modellen vilka kolumner som redan finns i minnet. Om några kolumner som behövs för frågan inte finns i minnet läser semantikmodellen in alla data för dessa kolumner från OneLake. Att läsa in kolumndata är vanligtvis en snabb åtgärd, men det kan bero på faktorer som kardinaliteten för data som lagras i kolumnerna.
Kolumner som läses in i minnet är sedan befintliga i minnet. Framtida frågor som endast omfattar residentkolumner behöver inte ladda fler kolumner i minnet.
En kolumn ligger kvar tills det finns anledning att ta bort den (avlägsnas) från minnet. Orsaker till att kolumner kan tas bort är:
- Modellen eller tabellen uppdaterades efter en deltatabelluppdatering vid källan (se Framing i nästa avsnitt).
- Ingen fråga använde kolumnen under en viss tid.
- Andra orsaker till minneshantering, inklusive minnesbelastning i kapaciteten på grund av andra samtidiga åtgärder.
Ditt val av Fabric SKU avgör det maximala tillgängliga minnet för varje semantisk modell för Direct Lake inom kapaciteten. Mer information om resursbegränsningar och maximala minnesgränser finns i Fabrikskapacitetens skyddsräcken och begränsningar senare i den här artikeln.
Inramning
Framing ger modellägare möjlighet till tidsspecifik kontroll över vilken data som läses in i semantikmodellen. Inramning är en Direct Lake-åtgärd som utlöses av en uppdatering av en semantisk modell, och i de flesta fall tar det bara några sekunder att slutföra. Det beror på att det är en lågkostnadsåtgärd där den semantiska modellen analyserar metadata för den senaste versionen av Delta Lake-tabellerna och uppdateras för att referera till de senaste Parquet-filerna i OneLake.
När inramningen inträffar kan kolumnsegment och ordlistor för intern tabell avlägsnas från minnet om underliggande data har ändrats och tidpunkten för uppdateringen blir den nya baslinjen för alla framtida transkodningshändelser. Från och med nu överväger Direct Lake-frågor endast data i Delta-tabellerna vid tidpunkten för den senaste inramningsåtgärden. Därför uppmanas Direct Lake-tabeller att returnera data baserat på tillståndet för Delta-tabellen vid tidpunkten för den senaste inramningsåtgärden. Den tidpunkten är inte nödvändigtvis den senaste statusen för delta-tabellerna.
Observera att den semantiska modellen analyserar Delta-loggen för varje Delta-tabell under inramningen för att endast släppa de berörda kolumnsegmenten och för att läsa in nyligen tillagda data under omkodningen. En viktig optimering är att ordlistor vanligtvis inte tas bort när inkrementell inramning börjar gälla och nya värden läggs till i de befintliga ordlistorna. Den här inkrementella inramningsmetoden hjälper till att minska omladdningsbelastningen och gynnar prestanda för frågor. I det idealiska fallet, när en Delta-tabell inte tog emot några uppdateringar, krävs ingen omläsning för kolumner som redan finns i minnet och frågor visar mycket mindre prestandapåverkan efter inramning eftersom inkrementell inramning i huvudsak gör det möjligt för den semantiska modellen att uppdatera betydande delar av befintliga minnesinterna data på plats.
Följande diagram visar hur frameringsoperationer för Direct Lake fungerar.
Diagrammet visar följande processer och funktioner.
| Sak | Beskrivning |
|---|---|
|
|
Det finns en semantisk modell i en Fabric-arbetsyta. |
|
|
Inramningsåtgärder utförs regelbundet och de anger baslinjen för alla framtida omkodning händelser. Inramningsåtgärder kan ske automatiskt, manuellt, enligt schema eller programmatiskt. |
|
|
OneLake lagrar metadata och Parquet-filer, som representeras som Delta-tabeller. |
|
|
Den senaste inramningsåtgärden innehåller Parquet-filer som är relaterade till Delta-tabellerna, och särskilt Parquet-filerna som lades till före senaste inramningsåtgärd. |
|
|
En senare inramningsåtgärd innehåller Parquet-filer som lagts till efter senaste inramningsåtgärd. |
|
|
Inhemska kolumner i Direct Lake-semantikmodellen kan avlägsnas från minnet och tidpunkten för uppdateringen blir den nya baslinjen för alla framtida omkodningshändelser. |
|
|
Efterföljande dataändringar, som representeras av nya Parquet-filer, visas inte förrän nästa inramningsåtgärd inträffar. |
Det är inte alltid önskvärt att ha data som representerar det senaste tillståndet för en Delta-tabell när en omkodningsåtgärd utförs. Tänk på att inramning kan hjälpa dig att ge konsekventa frågeresultat i miljöer där data i Delta-tabeller är tillfälliga. Data kan vara tillfälliga av flera orsaker, till exempel när långvariga processer för extrahering, transformering och inläsning (ETL) inträffar.
Uppdatering för en Direct Lake-semantisk modell kan göras manuellt, automatiskt eller programmatiskt. Mer information finns i Uppdatera Direct Lake-semantikmodeller.
Mer information om versionshantering och inramning av Delta-tabeller finns i Förstå lagring för Direct Lake-semantiska modeller.
Automatiska uppdateringar
Det finns en semantisk modellnivåinställning för att automatiskt uppdatera Direct Lake-tabeller. Den är aktiverad som standard. Det säkerställer att dataändringar i OneLake automatiskt återspeglas i Direct Lake-semantikmodellen. Du bör inaktivera automatiska uppdateringar när du vill styra dataändringar genom att rama in, vilket beskrevs i föregående avsnitt. Mer information finns i Hantera Direct Lake-semantikmodeller.
Tips
Du kan konfigurera automatisk siduppdatering i dina Power BI-rapporter. Det är en funktion som automatiskt uppdaterar en specifik rapportsida som anger att rapporten ansluter till en Direct Lake-semantisk modell (eller andra typer av semantisk modell).
DirectQuery-återställning
En fråga som skickas till en Direct Lake-semantisk modell kan återgå till DirectQuery-läge. I det här fallet hämtar den data direkt från SQL-analysslutpunkten för lakehouse eller datalager. Sådana frågor returnerar alltid de senaste data eftersom de inte är begränsade till tidpunkten för den senaste inramningsåtgärden.
En fråga alltid faller tillbaka när den semantiska modellen frågar en vy i SQL-analysslutpunkten eller en tabell i SQL-analysslutpunkten som framtvingar säkerhet på radnivå (RLS).
En fråga kan också falla tillbaka när den semantiska modellen överskrider skyddsräckena för kapaciteten.
Viktig
Om möjligt bör du alltid utforma din lösning – eller dimensionera din kapacitet – för att undvika DirectQuery-fallback. Det beror på att det kan leda till långsammare frågeprestanda.
Du kan styra ersättningen av Direct Lake-semantikmodellerna genom att ange dess DirectLakeBehavior-egenskap. För mer information, se Ställ in Direct Lake-beteendeegenskapen.
Kapacitetsgränser och begränsningar för nätverksinfrastruktur
Direct Lake-semantiska modeller kräver en Fabric-kapacitetslicens. Det finns också kapacitetsskydd och begränsningar som gäller för din Fabric-kapacitetsprenumeration (SKU), som visas i följande tabell.
Viktig
Den första kolumnen i följande tabell innehåller även Power BI Premium-kapacitetsprenumerationer (P SKU:er). Tänk på att Microsoft konsoliderar köpalternativen och drar tillbaka Power BI Premium per kapacitets-SKU:er. Nya och befintliga kunder bör överväga att köpa Fabric-kapacitetsprenumerationer (F SKU:er) i stället.
Mer information finns i Viktig uppdatering som kommer för Power BI Premium-licensiering och Power BI Premium.
| Nätverksstruktur-SKU | Parquet-filer per tabell | Radgrupper per tabell | Rader per tabell (miljoner) | Maximal storlek på modell på disk/OneLake (GB) | Maximalt minne (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 | Obegränsad | 25 |
| F128/P2 | 5,000 | 5,000 | 3,000 | Obegränsad | 50 |
| F256/P3 | 5,000 | 5,000 | 6,000 | Obegränsad | 100 |
| F512/P4 | 10 000 | 10 000 | 12,000 | Obegränsad | 200 |
| F1024/P5 | 10 000 | 10 000 | 24,000 | Obegränsad | 400 |
| F2048 | 10 000 | 10 000 | 24,000 | Obegränsad | 400 |
1 För Direct Lake-semantikmodeller representerar Maximalt minne den övre minnesresursgränsen för hur mycket data som kan sökas i. Därför är det inte ett skyddsräcke eftersom överskridandet inte resulterar i en återställning till DirectQuery-läge. Det kan dock ha en prestandapåverkan om mängden data är tillräckligt stor för att orsaka överdriven växling in och ut ur modelldata från OneLake-data.
Om den överskrids orsakar Max-modellstorlek på disken/OneLake att alla frågor till semantikmodellen övergår till DirectQuery-läge. Alla andra skyddsräcken som visas i tabellen utvärderas per fråga. Därför är det viktigt att du optimera deltatabellerna och Direct Lake-semantikmodellen för att undvika att behöva skala upp till en högre Fabric SKU i onödan (vilket resulterar i ökade kostnader).
Dessutom gäller kapacitetsenhet och maximalt minne per frågegräns för Direct Lake-semantiska modeller. Mer information finns i Kapaciteter och SKU:er.
Överväganden och begränsningar
Direct Lake-semantiska modeller innehåller vissa överväganden och begränsningar.
Not
Kapabiliteterna och funktionerna hos Direct Lake-semantiska modeller utvecklas. Kontrollera regelbundet för att granska den senaste listan över överväganden och begränsningar.
- När en semantisk modelltabell i Direct Lake ansluter till en tabell i SQL-analysslutpunkten som tillämpar säkerhet på radnivå (RLS), återgår frågor som involverar modelltabellen alltid tillbaka till DirectQuery-läge. Sökprestanda kan vara långsammare.
- När en semantisk modelltabell i Direct Lake ansluter till en vy i SQL-analysslutpunkten återgår frågor som involverar den modelltabellen alltid tillbaka till DirectQuery-läge. Sökprestanda kan vara långsammare.
- Sammansatt modellering stöds inte. Det innebär att semantiska direct lake-modelltabeller inte kan blandas med tabeller i andra lagringslägen, till exempel Import, DirectQuery eller Dual (förutom specialfall, inklusive beräkningsgrupper, konsekvensparametraroch fältparametrar).
- Beräknade kolumner och beräknade tabeller som refererar till kolumner eller tabeller i Direct Lake-lagringsläge stöds inte. Beräkningsgrupper, konsekvensparametraroch fältparametrar, som implicit skapar beräknade tabeller och beräknade tabeller som inte refererar till Direct Lake-kolumner eller -tabeller stöds.
- Direct Lake-lagringslägestabeller stöder inte komplexa deltatabellkolumntyper. Binära och GUID-semantiska typer stöds inte heller. Du måste konvertera dessa datatyper till strängar eller andra datatyper som stöds.
- Tabellrelationer kräver att datatyperna för relaterade kolumner matchar.
- Kolumner på en sida med relationer måste innehålla unika värden. Förfrågningar misslyckas om dubblettvärden upptäcks i en kolumn på ena sidan.
- Automatisk data-/tidsinformation i Power BI Desktop stöds inte. Det finns stöd för att markera din egen datumtabell som en datumtabell.
- Längden på strängkolumnvärden är begränsad till 32 764 Unicode-tecken.
- Flyttalsvärdet NaN- (inte ett tal) stöds inte.
- Publicera på webben från Power BI med tjänstens huvudnamn stöds endast när du använder en fast identitet för Direct Lake-semantikmodellen.
- I webbmodelleringär valideringen begränsad för Direct Lake-semantiska modeller. Användarval antas vara korrekta och inga frågor utfärdas för att verifiera kardinalitet eller korsfilterval för relationer, eller för den valda datumkolumnen i en markerad datumtabell.
- I Fabric-portalen visar fliken Direct Lake i uppdateringshistoriken endast uppdateringsfel relaterade till Direct Lake. Lyckade uppdateringsåtgärder (inramning) visas inte.
- Din Fabric SKU avgör det maximala tillgängliga minnet per Direct Lake-semantisk modell för kapaciteten. När gränsen överskrids kan frågor till den semantiska modellen vara långsammare på grund av att stora mängder data behöver läsas in och ut ur modellen.
- Det går inte att skapa en semantisk Direct Lake-modell på en arbetsyta som finns i en annan region i datakällans arbetsyta. Om Lakehouse till exempel finns i västra centrala USA, kan du bara skapa semantiska modeller från detta Lakehouse i samma region. En lösning är att skapa en Lakehouse i den andra regionens arbetsyta och genväg till tabellerna innan du skapar semantikmodellen. För att hitta vilken region du är i, se hitta din Fabric-hemregion.
- Du kan skapa och visa en anpassad Direct Lake-semantisk modell med hjälp av en tjänsthuvudnamnsidentitet, men standard-Direct Lake-semantikmodellen stöder inte tjänstens huvudnamn. Kontrollera att autentisering för service-principal är aktiverad för Fabric REST API:er i din klientorganisation och ge service-principal "Contributor"- eller högre behörighet till arbetsytan för din Direct Lake-semantikmodell.
- Inbäddning av rapporter kräver en V2-inbäddningstoken .
- Direct Lake stöder inte tjänstprincipalsprofiler för autentisering.
- Anpassade Direct Lake-semantiska modeller som skapats av tjänstens huvudnamn och visningsprogram med tjänstens huvudnamn stöds, men standardmässiga Direct Lake-semantiska modeller stöds inte.
Jämförelse med andra lagringslägen
I följande tabell jämförs Direct Lake-lagringsläget med lagringslägena Import och DirectQuery.
| Förmåga | Direct Lake | Import | DirectQuery |
|---|---|---|---|
| Licensiering | Endast prenumeration på fabric-kapacitet (SKU:er) | Alla Fabric- eller Power BI-licenser (inklusive kostnadsfria Microsoft Fabric-licenser) | Alla Fabric- eller Power BI-licenser (inklusive kostnadsfria Microsoft Fabric-licenser) |
| Datakälla | Endast tabeller eller vyer från lakehouse eller lager | Alla anslutningsappar | Vilken som helst anslutning som stöder DirectQuery-läge |
| Ansluta till SQL Analytics-slutpunktsvyer | Ja – men återgår automatiskt till DirectQuery-läge | Ja | Ja |
| Sammansatta modeller | Ingen 1 | Ja – kan kombineras med DirectQuery- eller dubbla lagringslägestabeller | Ja – kan kombineras med tabeller med import- eller dubbellagringsläge |
| Enkel inloggning (SSO) | Ja | Ej tillämpligt | Ja |
| Beräknade tabeller | Nej – förutom beräkningsgrupper, konsekvensparametraroch fältparametrarsom implicit skapar beräknade tabeller | Ja | Nej – beräknade tabeller använder importlagringsläge även när de refererar till andra tabeller i DirectQuery-läge |
| Beräknade kolumner | Nej | Ja | Ja |
| Hybridtabeller | Nej | Ja | Ja |
| Modelltabellpartitioner | Nej – men partitionering kan göras på deltatabellnivå | Ja – antingen skapas automatiskt genom inkrementell uppdatering eller skapas manuellt med hjälp av XMLA-slutpunkten | Nej |
| Användardefinierade sammansättningar | Nej | Ja | Ja |
| Säkerhet på slutpunktsobjektnivå för SQL-analys eller säkerhet på kolumnnivå | Ja – men frågor återgår till DirectQuery-läge och kan generera fel när behörighet nekas | Ja – men måste duplicera behörigheter med säkerhet på semantisk modell på objektnivå | Ja – men frågor kan generera fel när behörighet nekas |
| Säkerhet på radnivå för SQL-analysslutpunkt (RLS) | Ja – men frågorna återgår till DirectQuery-läge | Ja – men måste duplicera behörigheter med semantisk modell RLS | Ja |
| Säkerhet på radnivå för semantisk modell (RLS) | Ja – men vi rekommenderar starkt att du använder en fast identitet molnanslutning | Ja | Ja |
| Säkerhet på semantisk modell på objektnivå (OLS) | Ja | Ja | Ja |
| Stora datavolymer utan uppdateringskrav | Ja | Mindre anpassad – en större kapacitetsstorlek kan krävas för att fråga och uppdatera | Ja |
| Minska datafördröjningen | Ja – när automatiska uppdateringar är aktiverat eller programmatisk omformatering; dock måste dataförberedelse göras uppströms först | Nej | Ja |
| Power BI Embedded | Ja 2 | Ja | Ja |
1 Du kan inte kombinera Direct Lake-lagringslägestabeller med DirectQuery- eller dubbla lagringslägestabeller i samma semantiska modell. Du kan dock använda Power BI Desktop för att skapa en sammansatt modell på en Direct Lake-semantisk modell och sedan utöka den med nya tabeller (med hjälp av Import, DirectQuery eller Dubbla lagringslägen) eller beräkningar. Mer information finns i Skapa en sammansatt modell på en semantisk modell.
2 Kräver en V2-inbäddningstoken. Om du använder ett huvudnamn för tjänsten måste du använda en fast identitet molnanslutning.