Oversikt over Direct Lake
Direct Lake er et alternativ for lagringsmodus for tabeller i en semantisk Power BI-modell som er lagret i et Microsoft Fabric-arbeidsområde. Den er optimalisert for store mengder data som raskt kan lastes inn i minnet fra Delta-tabeller, som lagrer dataene i Parquet-filer i OneLake – det eneste lageret for alle analysedata. Når den er lastet inn i minnet, aktiverer den semantiske modellen spørringer med høy ytelse. Direct Lake eliminerer det langsomme og kostbare behovet for å importere data til modellen.
Du kan bruke Lagringsmodus for Direct Lake til å koble til tabellene eller utsikten over et enkelt fabric lakehouse eller Fabric-lager. Begge disse Fabric-elementene og Direct Lake-semantiske modellene krever en fabric-kapasitetslisens.
På noen måter ligner en semantisk direct lake-modell på en semantisk importmodell. Det er fordi modelldata lastes inn i minnet av VertiPaq-motoren for rask spørringsytelse (bortsett fra når det gjelder DirectQuery-tilbakefall, som forklares senere i denne artikkelen).
En semantisk direct lake-modell skiller seg imidlertid fra en semantisk importmodell på en viktig måte. Det er fordi en oppdateringsoperasjon for en semantisk direct lake-modell er helt forskjellig fra en oppdateringsoperasjon for en semantisk importmodell. For en semantisk Direct Lake-modell innebærer en oppdatering en innrammingsoperasjon (beskrevet senere i denne artikkelen), noe som kan ta noen sekunder å fullføre. Det er en rimelig operasjon der den semantiske modellen analyserer metadataene til den nyeste versjonen av Delta-tabellene og oppdateres for å referere til de nyeste filene i OneLake. For en semantisk importmodell produserer en oppdatering derimot en kopi av dataene, noe som kan ta lang tid og bruke betydelige datakilde- og kapasitetsressurser (minne og CPU).
Merk
Trinnvis oppdatering for en semantisk importmodell kan bidra til å redusere oppdateringstid og bruk av kapasitetsressurser.
Når bør du bruke Direct Lake-lagringsmodus?
Det primære brukstilfellet for en Direct Lake-lagringsmodus er vanligvis for IT-drevne analyseprosjekter som utnytter innsjøsentriske arkitekturer. I dette scenarioet har du – eller forventer å akkumulere – store mengder data i OneLake. Rask innlasting av disse dataene i minnet, hyppige og raske oppdateringsoperasjoner, effektiv bruk av kapasitetsressurser og rask spørringsytelse er viktig for dette brukstilfellet.
Merk
Import- og DirectQuery-semantiske modeller er fortsatt relevante i Fabric, og de er det riktige valget av semantisk modell for enkelte scenarier. Importlagringsmodus fungerer for eksempel ofte bra for en selvbetjent analytiker som trenger frihet og smidighet til å handle raskt, og uten avhengighet av IT for å legge til nye dataelementer.
OneLake-integrering skriver også automatisk data for tabeller i importlagringsmodus til Delta-tabeller i OneLake uten å involvere overføringsinnsats. Ved å bruke dette alternativet kan du forstå mange av fordelene med Fabric som gjøres tilgjengelig for import av semantiske modellbrukere, for eksempel integrering med lakehouses gjennom snarveier, SQL-spørringer, notatblokker og mer. Vi anbefaler at du anser dette alternativet som en rask måte å høste fordelene av Fabric uten nødvendigvis eller umiddelbart re-designe eksisterende datalager og / eller analysesystem.
Direct Lake-lagringsmodus er også egnet for å minimere ventetiden for data for raskt å gjøre data tilgjengelig for forretningsbrukere. Hvis Delta-tabellene endres midlertidig (og forutsatt at du allerede har gjort dataforberedelser i datasjøen), kan du stole på automatiske oppdateringer for å omforme dette som svar på disse endringene. I dette tilfellet vil spørringer som sendes til den semantiske modellen, returnere de nyeste dataene. Denne funksjonen fungerer bra i samarbeid med funksjonen for automatisk sideoppdatering i Power BI-rapporter.
Husk at Direct Lake er avhengig av at dataforberedelser gjøres i datasjøen. Dataforberedelse kan gjøres ved hjelp av ulike verktøy, for eksempel Spark-jobber for Fabric Lakehouses, T-SQL DML-setninger for Fabric-varehus, dataflyter, rørledninger og andre. Denne fremgangsmåten bidrar til å sikre at logikken for dataforberedelse utføres så lavt som mulig i arkitekturen for å maksimere gjenbruk. Hvis den semantiske modellforfatteren ikke har mulighet til å endre kildeelementet, for eksempel når det gjelder en selvbetjent analytiker som kanskje ikke har skrivetillatelser på et lakehouse som administreres av IT, kan import av lagringsmodus være et bedre valg. Det er fordi den støtter klargjøring av data ved hjelp av Power Query, som er definert som en del av semantisk modell.
Pass på å ta hensyn til gjeldende fabric-kapasitetslisens og fabric-kapasitetsrekkverk når du vurderer Direct Lake-lagringsmodus. Også faktor i hensyn og begrensninger, som er beskrevet senere i denne artikkelen.
Tips
Vi anbefaler at du produserer en prototype – eller konseptbevis (POC)– for å finne ut om en semantisk direct lake-modell er den riktige løsningen, og for å redusere risikoen.
Slik fungerer Direct Lake
Vanligvis håndteres spørringer som sendes til en semantisk Direct Lake-modell fra en minnehurtigbuffer for kolonnene som er hentet fra Delta-tabeller. Den underliggende lagringsplassen for en Delta-tabell er én eller flere Parquet-filer i OneLake. Parquet-filer organiserer data etter kolonner i stedet for rader. Semantiske modeller laster inn hele kolonner fra Delta-tabeller i minnet etter hvert som de kreves av spørringer.
En Direct Lake semantisk modell kan også bruke DirectQuery fallback, som innebærer sømløst å bytte til DirectQuery-modus. DirectQuery-tilbakefall henter data direkte fra SQL Analytics-endepunktet til lakehouse eller lageret. For eksempel kan tilbakefall oppstå når en Delta-tabell inneholder flere rader med data enn det som støttes av Fabric-kapasiteten (beskrevet senere i denne artikkelen). I dette tilfellet sender en DirectQuery-operasjon en spørring til endepunktet for SQL-analyse. Tilbakefallsoperasjoner kan føre til langsommere spørringsytelse.
Diagrammet nedenfor viser hvordan Direct Lake fungerer ved hjelp av scenarioet til en bruker som åpner en Power BI-rapport.
Diagrammet viser følgende brukerhandlinger, prosesser og funksjoner.
| Element | Bekrivelse |
|---|---|
 |
OneLake er en datainnsjø som lagrer analysedata i Parquet-format. Dette filformatet er optimalisert for lagring av data for semantiske modeller i Direct Lake. |
 |
Et Fabric lakehouse- eller Fabric-lager finnes i et arbeidsområde som er på Fabric-kapasitet. Lakehouse har et SQL Analytics-endepunkt, som gir en SQL-basert opplevelse for spørring. Tabeller (eller visninger) gir et middel til å spørre deltatabellene i OneLake ved hjelp av Transact-SQL (T-SQL). |
 |
Det finnes en semantisk direct lake-modell i et stoffarbeidsområde. Det kobles til tabeller eller utsikt i enten lakehouse eller lager. |
 |
En bruker åpner en Power BI-rapport. |
 |
Power BI-rapporten sender DAX-spørringer (Data Analysis Expressions) til semantisk direct lake-modell. |
 |
Når det er mulig (og nødvendig), laster den semantiske modellen kolonner inn i minnet direkte fra Parquet-filene som er lagret i OneLake. Spørringer oppnår ytelse i minnet, noe som er veldig raskt. |
 |
Den semantiske modellen returnerer spørringsresultater. |
 |
Power BI-rapporten gjengir visualobjektene. |
 |
I visse tilfeller, for eksempel når den semantiske modellen overskrider rekkverket til kapasiteten, faller semantiske modellspørringer automatisk tilbake til DirectQuery-modus. I denne modusen sendes spørringer til SQL Analytics-endepunktet for lakehouse eller warehouse. |
 |
DirectQuery-spørringer som sendes til SQL Analytics-endepunktet, spør i sin tur Delta-tabellene i OneLake. Av denne grunn kan spørringsytelsen være tregere enn spørringer i minnet. |
De følgende avsnittene beskriver Direct Lake-konsepter og -funksjoner, inkludert kolonneinnlasting, innramming, automatiske oppdateringer og DirectQuery-tilbakefall.
Kolonneinnlasting (transkoding)
Semantiske modeller i Direct Lake laster bare inn data fra OneLake som og når kolonner spørres for første gang. Prosessen med å laste inn data ved behov fra OneLake kalles transkoding.
Når den semantiske modellen mottar en DAX-spørring (eller flerdimensjonale uttrykk – MDX), bestemmer den først hvilke kolonner som kreves for å produsere et spørringsresultat. Kolonner som kreves inkluderer alle kolonner som brukes direkte av spørringen, og også kolonner som kreves av relasjoner og mål. Vanligvis er antall kolonner som kreves for å produsere et spørringsresultat mye mindre enn antall kolonner som er definert i den semantiske modellen.
Når det er forstått hvilke kolonner som trengs, bestemmer den semantiske modellen hvilke kolonner som allerede er i minnet. Hvis noen kolonner som kreves for spørringen ikke er i minnet, laster den semantiske modellen inn alle data for disse kolonnene fra OneLake. Innlasting av kolonnedata er vanligvis en svært rask operasjon, men det kan avhenge av faktorer som kardinaliteten til data som er lagret i kolonnene.
Kolonner som lastes inn i minnet, blir deretter bosatt i minnet. Fremtidige spørringer som bare involverer resident-kolonner, trenger ikke å laste inn flere kolonner i minnet.
En kolonne forblir bosatt til det er grunn til at den fjernes (utestenges) fra minnet. Årsaker til at kolonner kan bli fjernet inkluderer:
- Modellen eller tabellen er oppdatert (se Innramming i neste del).
- Ingen spørring har brukt kolonnen på en stund.
- Andre årsaker til minnebehandling, inkludert minnetrykk i kapasiteten på grunn av andre samtidige operasjoner.
Ditt valg av Fabric SKU bestemmer maksimalt tilgjengelig minne for hver Direct Lake semantisk modell på kapasiteten. Hvis du vil ha mer informasjon om ressursrekkverk og maksimal minnegrense, kan du se Fabric-kapasitetsrekkverk og begrensninger senere i denne artikkelen.
Innramming
Innramming gir modelleiere pek-i-tid kontroll over hvilke data som lastes inn i den semantiske modellen. Innramming er en Direct Lake-operasjon som utløses av en oppdatering av en semantisk modell, og det tar i de fleste tilfeller bare noen få sekunder å fullføre. Det er fordi det er en rimelig operasjon der den semantiske modellen analyserer metadataene til den nyeste versjonen av Delta Lake-tabellene og oppdateres for å referere til de nyeste Parquet-filene i OneLake.
Når innramming oppstår, kan residentkolonner bli kastet ut fra minnet, og tidspunktet for oppdateringen blir den nye grunnlinjen for alle fremtidige transkodingshendelser. Fra dette punktet vurderer Direct Lake-spørringer bare data i Delta-tabellene fra tidspunktet for den nyeste innrammingsoperasjonen. Av den grunn blir Direct Lake-tabeller bedt om å returnere data basert på tilstanden til Delta-tabellen på tidspunktet for den siste innrammingsoperasjonen. Den tiden er ikke nødvendigvis den siste tilstanden til Delta-tabellene.
Diagrammet nedenfor viser hvordan Direct Lake-innramming fungerer.
Diagrammet viser følgende prosesser og funksjoner.
| Element | Bekrivelse |
|---|---|
|
Det finnes en semantisk modell i et Fabric-arbeidsområde. |
|
Innrammingsoperasjoner finner sted med jevne mellomrom, og de angir grunnlinjen for alle fremtidige transkodingshendelser . Innrammingsoperasjoner kan skje automatisk, manuelt, etter planen eller programmatisk. |
|
OneLake lagrer metadata og Parquet-filer, som representeres som Delta-tabeller. |
|
Den siste innrammingsoperasjonen inkluderer Parquet-filer relatert til Delta-tabellene, og spesielt Parquet-filene som ble lagt til før den siste innrammingsoperasjonen. |
|
En senere innrammingsoperasjon inkluderer Parquet-filer som er lagt til etter den siste innrammingsoperasjonen. |
|
Resident kolonner i Direct Lake semantic modellen kan bli kastet ut fra minnet, og tidspunktet for oppdateringen blir den nye grunnlinjen for alle fremtidige transkoding hendelser. |
|
Etterfølgende dataendringer, representert ved nye Parquet-filer, er ikke synlige før neste innrammingsoperasjon inntreffer. |
Det er ikke alltid ønskelig å ha data som representerer den nyeste tilstanden til en Delta-tabell når en transkodingsoperasjon finner sted. Vurder at innramming kan hjelpe deg med å gi konsekvente spørringsresultater i miljøer der data i Delta-tabeller er forbigående. Data kan være midlertidige av flere årsaker, for eksempel når langvarige uttrekkings-, transformerings- og innlastingsprosesser (ETL) forekommer.
Oppdatering for en semantisk Direct Lake-modell kan gjøres manuelt, automatisk eller programmatisk. Hvis du vil ha mer informasjon, kan du se Oppdater semantiske modeller for Direct Lake.
Hvis du vil ha mer informasjon om versjonskontroll og innramming av Delta-tabeller, kan du se Forstå lagringsplass for semantiske modeller i Direct Lake.
Automatiske oppdateringer
Det finnes en semantisk innstilling på modellnivå for automatisk oppdatering av Direct Lake-tabeller. Den er aktivert som standard. Den sikrer at dataendringer i OneLake automatisk gjenspeiles i semantisk Direct Lake-modell. Du bør deaktivere automatiske oppdateringer når du vil kontrollere dataendringer ved innramming, som ble forklart i forrige del. Hvis du vil ha mer informasjon, kan du se Behandle semantiske modeller i Direct Lake.
Tips
Du kan konfigurere automatisk sideoppdatering i Power BI-rapportene. Det er en funksjon som automatisk oppdaterer en bestemt rapportside, slik at rapporten kobles til en semantisk modell i Direct Lake (eller andre typer semantisk modell).
DirectQuery-tilbakefall
En spørring som sendes til en semantisk Direct Lake-modell, kan falle tilbake til DirectQuery-modus. I dette tilfellet henter den data direkte fra SQL Analytics-endepunktet til lakehouse eller warehouse. Slike spørringer returnerer alltid de nyeste dataene fordi de ikke er begrenset til tidspunktet for den siste innrammingsoperasjonen.
En spørring faller alltid tilbake når den semantiske modellen spør etter en visning i endepunktet for SQL-analyse, eller en tabell i SQL Analytics-endepunktet som håndhever sikkerhet på radnivå (RLS).
En spørring kan også falle tilbake når den semantiske modellen overskrider rekkverket for kapasiteten.
Viktig
Hvis det er mulig, bør du alltid utforme løsningen – eller endre størrelsen på kapasiteten – for å unngå at DirectQuery faller tilbake. Det er fordi det kan føre til langsommere spørringsytelse.
Du kan kontrollere tilbakefall av semantiske direct lake-modeller ved å angi directlakebehavior-egenskapen . Hvis du vil ha mer informasjon, kan du se Angi virkemåten for Direct Lake.
Bevokting og begrensninger for stoffkapasitet
Semantiske modeller i Direct Lake krever en fabric-kapasitetslisens. Det finnes også kapasitetsrekkverk og begrensninger som gjelder for fabric-kapasitetsabonnementet (SKU), som vist i tabellen nedenfor.
Viktig
Den første kolonnen i tabellen nedenfor inkluderer også Power BI Premium-kapasitetsabonnementer (P SKU-er). Vær oppmerksom på at Microsoft konsoliderer kjøpsalternativer og trekker tilbake Power BI Premium per kapasitet sKU-er. Nye og eksisterende kunder bør vurdere å kjøpe Fabric-kapasitetsabonnementer (F SKU-er) i stedet.
Hvis du vil ha mer informasjon, kan du se Viktig oppdatering som kommer til Power BI Premium-lisensiering og Power BI Premium.
| Fabric SKU | Parquet-filer per tabell | Radgrupper per tabell | Rader per tabell (millioner) | Maksimal modellstørrelse på disk/OneLake (GB) | Maksimalt 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 | Ubegrenset | 25 |
| F128/P2 | 5 000 | 5 000 | 3 000 | Ubegrenset | 50 |
| F256/P3 | 5 000 | 5 000 | 6 000 | Ubegrenset | 100 |
| F512/P4 | 10,000 | 10 000 | 12,000 | Ubegrenset | 200 |
| F1024/P5 | 10,000 | 10,000 | 24,000 | Ubegrenset | 400 |
| F2048 | 10,000 | 10,000 | 24,000 | Ubegrenset | 400 |
1 For semantiske modeller i Direct Lake representerer Maksimalt minne den øvre minneressursgrensen for hvor mye data som kan sidees inn. Av denne grunn er det ikke et rekkverk fordi overskridelse av det ikke resulterer i et fallback til DirectQuery-modus; Det kan imidlertid ha en ytelseseffekt hvis datamengden er stor nok til å forårsake overdreven sideveksling inn og ut av modelldataene fra OneLake-dataene.
Hvis den overskrides, vil den maksimale modellstørrelsen på disk/OneLake føre til at alle spørringer til den semantiske modellen faller tilbake til DirectQuery-modus. Alle andre rekkverk som presenteres i tabellen, evalueres per spørring. Det er derfor viktig at du optimaliserer Delta-tabellene og Direct Lake-semantiske modellen for å unngå unødvendig å skalere opp til en høyere Fabric SKU (noe som resulterer i økte kostnader).
I tillegg gjelder kapasitetsenhet og maksimalt minne per spørringsgrenser for semantiske modeller i Direct Lake. Hvis du vil ha mer informasjon, kan du se Kapasiteter og SKU-er.
Hensyn og begrensninger
Direct Lake semantiske modeller presentere noen hensyn og begrensninger.
Merk
Funksjonene og funksjonene til Semantiske direct Lake-modeller utvikler seg. Pass på å sjekke tilbake med jevne mellomrom for å se gjennom den nyeste listen over hensyn og begrensninger.
- Når en semantisk tabell i Direct Lake kobles til en tabell i SQL Analytics-endepunktet som håndhever sikkerhet på radnivå (RLS), vil spørringer som involverer denne modelltabellen, alltid falle tilbake til DirectQuery-modus. Spørringsytelsen kan være tregere.
- Når en semantisk tabell i Direct Lake kobles til en visning i endepunktet for SQL-analyse, vil spørringer som involverer denne modelltabellen, alltid falle tilbake til DirectQuery-modus. Spørringsytelsen kan være tregere.
- Sammensatt modellering støttes ikke. Det betyr at semantiske tabeller i Direct Lake ikke kan blandes med tabeller i andre lagringsmoduser, for eksempel Import, DirectQuery eller Dual (med unntak av spesielle tilfeller, inkludert beregningsgrupper, hva-skjer-hvis-parametere og feltparametere).
- Beregnede kolonner og beregnede tabeller som refererer til kolonner eller tabeller i Direct Lake-lagringsmodus, støttes ikke. Beregningsgrupper, hva-skjer-hvis-parametere og feltparametere, som implisitt oppretter beregnede tabeller, og beregnede tabeller som ikke refererer til Direct Lake-kolonner eller -tabeller, støttes.
- Tabeller for lagringsmodus i Direct Lake støtter ikke komplekse kolonnetyper for Delta-tabeller. Binære og GUID-semantiske typer støttes også ikke. Du må konvertere disse datatypene til strenger eller andre datatyper som støttes.
- Tabellrelasjoner krever at datatypene for relaterte kolonner samsvarer.
- Kolonner på én side av relasjoner må inneholde unike verdier. Spørringer mislykkes hvis dupliserte verdier oppdages i en kolonne på én side.
- Automatisk data/tidsintelligens i Power BI Desktop støttes ikke. Merking av din egen datotabell som en datotabell støttes.
- Lengden på strengkolonneverdier er begrenset til 32 764 Unicode-tegn.
- Den flytende punktverdien NaN (ikke et tall) støttes ikke.
- Innebyggingsscenarioer som bruker scenarioet for kundebruk , støttes ikke.
- Publiser på nett fra Power BI støttes bare når du bruker en fast identitet for semantisk Direct Lake-modell.
- I nettmodelleringsopplevelsen er validering begrenset for semantiske modeller i Direct Lake. Brukervalg antas å være riktige, og ingen spørringer utstedes for å validere kardinalitet eller kryssfiltreringsvalg for relasjoner, eller for den valgte datokolonnen i en merket datotabell.
- Direct Lake-fanen i oppdateringsloggen viser bare Direkte lake-relaterte oppdateringsfeil i Stoff-portalen. Vellykket oppdatering (innramming) er ikke oppført.
- Fabric SKU bestemmer maksimalt tilgjengelig minne per semantisk Direct Lake-modell for kapasiteten. Når grensen overskrides, kan spørringer til den semantiske modellen være tregere på grunn av overdreven sideveksling inn og ut av modelldataene.
- Oppretting av en semantisk direct lake-modell i et arbeidsområde som er i et annet område av datakildearbeidsområdet, støttes ikke. Hvis Lakehouse for eksempel er i USA, vest-sentralt, kan du bare opprette semantiske modeller fra dette Lakehouse i samme område. En løsning er å opprette et Lakehouse i det andre områdets arbeidsområde og snarvei til tabellene før du oppretter den semantiske modellen. Hvis du vil finne ut hvilket område du befinner deg i, kan du se finne hjemområdet fabric.
Sammenligning med andre lagringsmoduser
Tabellen nedenfor sammenligner Lagringsmodus for Direct Lake med lagringsmodus for Import og DirectQuery.
| Funksjonalitet | Direct Lake | Importer | DirectQuery |
|---|---|---|---|
| Lisensiering | Bare abonnement på stoffkapasitet (SKU-er) | Enhver Fabric- eller Power BI-lisens (inkludert Microsoft Fabric Free-lisenser) | Enhver Fabric- eller Power BI-lisens (inkludert Microsoft Fabric Free-lisenser) |
| Datakilde | Bare lakehouse- eller lagertabeller (eller utsikt) | Alle koblinger | Alle koblinger som støtter DirectQuery-modus |
| Koble til endepunktvisninger for SQL-analyse | Ja – men vil automatisk falle tilbake til DirectQuery-modus | Ja | Ja |
| Sammensatte modeller | Nr . 1 | Ja – kan kombineres med Tabeller i DirectQuery- eller Dobbel lagringsmodus | Ja – kan kombineres med tabeller for import eller dobbel lagringsmodus |
| Enkel pålogging (SSO) | Ja | Gjelder ikke her | Ja |
| Beregnede tabeller | Nei – bortsett fra beregningsgrupper, hva-skjer-hvis-parametere og feltparametere, som implisitt oppretter beregnede tabeller | Ja | Nei – beregnede tabeller bruker importlagringsmodus selv når de refererer til andre tabeller i DirectQuery-modus |
| Beregnede kolonner | Nei | Ja | Ja |
| Hybridtabeller | Nei | Ja | Ja |
| Modelltabellpartisjoner | Nei – men partisjonering kan gjøres på Delta-tabellnivå | Ja – enten automatisk opprettet av trinnvis oppdatering, eller manuelt opprettet ved hjelp av XMLA-endepunktet | No |
| Brukerdefinerte aggregasjoner | Nei | Ja | Ja |
| Sikkerhet på objektnivå på SQL-analysenivå eller sikkerhet på kolonnenivå | Ja – men spørringer vil falle tilbake til DirectQuery-modus og kan føre til feil når tillatelsen nektes | Ja – men må duplisere tillatelser med sikkerhet på semantisk modellobjektnivå | Ja – men spørringer kan gi feil når tillatelse nektes |
| Sikkerhet på radnivå for SQL Analytics-endepunkt (RLS) | Ja – men spørringer vil falle tilbake til DirectQuery-modus | Ja – men må duplisere tillatelser med semantisk modell RLS | Ja |
| Sikkerhet på radnivå for semantisk modell (RLS) | Ja – men det anbefales på det sterkeste å bruke en fast identitetsskytilkobling | Ja | Ja |
| Sikkerhet på objektnivå for semantisk modell (OLS) | Ja | Ja | Ja |
| Store datavolumer uten oppdateringskrav | Ja | Mindre egnet – en større kapasitetsstørrelse kan være nødvendig for spørring og oppdatering | Ja |
| Redusere ventetid for data | Ja – når automatiske oppdateringer er aktivert, eller programmatisk reframing, må imidlertid dataforberedelse utføres oppstrøms først | Nei | Ja |
1 Du kan ikke kombinere direct lake-lagringsmodustabeller med DirectQuery- eller Dual Storage-modustabeller i samme semantiske modell. Du kan imidlertid bruke Power BI Desktop til å opprette en sammensatt modell på en semantisk direct lake-modell og deretter utvide den med nye tabeller (ved hjelp av Import, DirectQuery eller Dobbel lagringsmodus) eller beregninger. Hvis du vil ha mer informasjon, kan du se Bygge en sammensatt modell på en semantisk modell.