Ö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 Direct Lake-lagringsläget för att ansluta till tabellerna eller vyerna för ett enda Fabric Lakehouse - eller Fabric-lager. Båda dessa Fabric-objekt och Direct Lake-semantiska modeller kräver en infrastrukturkapacitetslicens.
På sätt och vis liknar en Direct Lake-semantisk modell en importsemantisk modell. Det beror på att modelldata läses in i minnet av VertiPaq-motorn för snabba frågeprestanda (förutom när det gäller DirectQuery-återställning, vilket 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 inramningså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).
Kommentar
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 utnyttjar 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.
Kommentar
Import- och DirectQuery-semantiska modeller är fortfarande relevanta i Infrastrukturresurser, och de ä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-integrering automatiskt data för tabeller i Import storage mode to Delta tables in OneLake without involving any migration effort (Importera lagringsläge till Delta-tabeller i OneLake utan migrering). Med det här alternativet kan du inse många av fördelarna med infrastrukturresurser som görs tillgängliga för import av semantiska modellanvändare, till exempel integrering med lakehouses via genvägar, SQL-frågor, notebook-filer med mera. 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 Delta-tabeller ändras tillfälligt (och förutsatt att du redan har gjort dataförberedelser i datasjön) kan du vara beroende av automatiska uppdateringar för att omrama 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-rapporter.
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 Infrastrukturlager, 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 det gäller en självbetjäningsanalytiker som kanske inte har skrivbehörighet på ett sjöhus 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.
Se till att ta hänsyn till din aktuella fabric-kapacitetslicens och skyddsmekanismerna för infrastrukturresurser när du tänker på Direct Lake-lagringsläget . Ta också hänsyn till överväganden och begränsningar, som beskrivs senare i den här artikeln.
Dricks
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 Direct Lake-semantisk modell kan också använda DirectQuery-återställning, vilket innebär att du smidigt byter till DirectQuery-läge. DirectQuery-återställning hämtar data direkt från SQL-analysslutpunkten för lakehouse eller lagret. Återställning kan till exempel inträffa när en Delta-tabell innehåller fler rader med data än vad som stöds av din Infrastrukturkapacitet (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.
| Objekt | 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 ett Fabric Lakehouse- eller Fabric-lager på en arbetsyta som är på Infrastrukturkapacitet. 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 infrastrukturarbetsyta. Den ansluter till tabeller eller vyer i antingen sjöhuset eller lagret. |
 |
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 kapacitetens skyddsräcken, å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 informationslagret. |
 |
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.
Kolumninläsning (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 att läsa in data på begäran från OneLake kallas för transkodning.
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. Kolumner som behövs omfattar alla kolumner som används direkt av frågan 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 mycket mindre än antalet kolumner som definierats i den semantiska modellen.
När det är förstått 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 mycket 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 finns sedan kvar i minnet. Framtida frågor som endast omfattar inhemska kolumner behöver inte läsa in fler kolumner i minnet.
En kolumn förblir bosatt tills det finns anledning att ta bort den (avlägsnas) från minnet. Orsaker till att kolumner kan tas bort är:
- Modellen eller tabellen har uppdaterats (se Inramning i nästa avsnitt).
- Ingen fråga har använt 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 Direct Lake-semantisk modell på kapaciteten. Mer information om resursskyddsmekanismer och maximala minnesgränser finns i Skyddsmekanismer och begränsningar för infrastrukturkapacitet senare i den här artikeln.
Inramning
Inramning ger modellägare kontroll över vilka 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 sker kan inhemska kolumner tas bort från minnet och tidpunkten för uppdateringen blir den nya baslinjen för alla framtida omkodningshä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 efterfrågas Direct Lake-tabeller för att returnera data baserat på tillståndet för Delta-tabellen vid tidpunkten för den senaste inramningsåtgärden. Den tiden är inte nödvändigtvis det senaste tillståndet för Delta-tabellerna.
Följande diagram visar hur Direct Lake-inramningsåtgärder fungerar.
Diagrammet visar följande processer och funktioner.
| Objekt | beskrivning |
|---|---|
|
Det finns en semantisk modell i en infrastrukturarbetsyta. |
|
Inramningsåtgärder sker regelbundet och de anger baslinjen för alla framtida omkodningshä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 De Parquet-filer som lades till före den senaste inramningsåtgärden. |
|
En senare inramningsåtgärd innehåller Parquet-filer som lagts till efter den senaste inramningsåtgärden. |
|
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-semantiska modeller.
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. Som standard är den aktiverad. 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 semantiska Direct Lake-modeller.
Dricks
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 informationslagret. 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 faller alltid tillbaka när den semantiska modellen frågar en vy i SQL-analysslutpunkten eller en tabell i SQL-analysslutpunkten som tillämpar säkerhet på radnivå (RLS).
En fråga kan också falla tillbaka när den semantiska modellen överskrider kapacitetens skyddsräcken.
Viktigt!
Om möjligt bör du alltid utforma din lösning – eller ändra storlek på din kapacitet – för att undvika DirectQuery-återställning. Det beror på att det kan leda till långsammare frågeprestanda.
Du kan kontrollera återställningen av direct lake-semantikmodellerna genom att ange dess DirectLakeBehavior-egenskap . Mer information finns i Ange egenskapen För Direct Lake-beteende.
Skyddsräcken och begränsningar för infrastrukturresurser
Direct Lake-semantiska modeller kräver en infrastrukturkapacitetslicens. Det finns också kapacitetsskydd och begränsningar som gäller för din Fabric-kapacitetsprenumeration (SKU), som visas i följande tabell.
Viktigt!
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öpalternativ och drar tillbaka Power BI Premium per kapacitet-SKU:er. Nya och befintliga kunder bör överväga att köpa kapacitetsprenumerationer för Infrastrukturresurser (F SKU:er) i stället.
Mer information finns i Viktig uppdatering som kommer till Power BI Premium-licensiering och Power BI Premium.
| Infrastruktur-SKU | Parquet-filer per tabell | Radgrupper per tabell | Rader per tabell (miljoner) | Maximal modellstorlek 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änsat | 25 |
| F128/P2 | 5 000 | 5 000 | 3 000 | Obegränsat | 50 |
| F256/P3 | 5 000 | 5 000 | 6 000 | Obegränsat | 100 |
| F512/P4 | 10,000 | 10,000 | 12,000 | Obegränsat | 200 |
| F1024/P5 | 10,000 | 10,000 | 24,000 | Obegränsat | 400 |
| F2048 | 10,000 | 10,000 | 24,000 | Obegränsat | 400 |
1 För Direct Lake-semantiska modeller representerar Max 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 kommer maxmodellstorleken på disken/OneLake att leda till att alla frågor till den semantiska modellen återgå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 optimerar deltatabellerna och Direct Lake-semantikmodellen för att undvika att behöva skala upp till en högre Infrastruktur-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.
Beaktanden och begränsningar
Direct Lake-semantiska modeller innehåller vissa överväganden och begränsningar.
Kommentar
Funktionerna och funktionerna i 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. Frågeprestanda 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. Frågeprestanda 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 särskilda fall, inklusive beräkningsgrupper, konsekvensparametrar och 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, konsekvensparametrar och 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. Frågor misslyckas om dubblettvärden identifieras i en kolumn på en sida.
- Automatisk data-/tidsinformation i Power BI Desktop stöds inte. Det gå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.
- Inbäddningsscenarier som använder scenariot För kundanvändning stöds inte.
- Publicera på webben från Power BI stöds endast när du använder en fast identitet för Direct Lake-semantikmodellen.
- I webbmodelleringsupplevelsen ä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.
- På fabric-portalen visar fliken Direct Lake i uppdateringshistoriken endast Direct Lake-relaterade uppdateringsfel. 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 överdriven växling i och ut ur modelldata.
- 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 USA, västra centrala, kan du bara skapa semantiska modeller från denna 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. Information om vilken region du befinner dig i finns i hitta din infrastrukturresurs.
Jämförelse med andra lagringslägen
I följande tabell jämförs Direct Lake-lagringsläget med lagringslägena Import och DirectQuery.
| Kapacitet | Direct Lake | Importera | DirectQuery |
|---|---|---|---|
| Licensiering | Endast infrastrukturkapacitetsprenumeration (SKU:er) | Alla Fabric- eller Power BI-licenser (inklusive kostnadsfria Microsoft Fabric-licenser) | Alla Fabric- eller Power BI-licenser (inklusive kostnadsfria Microsoft Fabric-licenser) |
| Data source | Endast lakehouse- eller lagertabeller (eller vyer) | Alla anslutningsappar | Alla anslutningsappar som stöder DirectQuery-läge |
| Ansluta till SQL Analytics-slutpunktsvyer | Ja – men återgår automatiskt till DirectQuery-läge | Ja | Ja |
| Sammansatta modeller | Nr 1 | Ja – kan kombineras med DirectQuery- eller dubbla lagringslägestabeller | Ja – kan kombineras med tabeller med import- eller dubbellagringsläge |
| Enkel inloggning (SSO) | Ja | Inte aktuellt | Ja |
| Beräknade tabeller | Nej – förutom beräkningsgrupper, konsekvensparametrar och fältparametrar som 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 – partitionering kan dock 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 identitetsmolnanslutning | 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 aktiverade eller programmatisk omramning. Dataförberedelser måste dock göras uppströms först | Nej | 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.