Oversigt over Direct Lake
Direct Lake er en lagringstilstand for tabeller i en semantisk Power BI-model, der er gemt i et Microsoft Fabric-arbejdsområde. Den er optimeret til store datamængder, der hurtigt kan indlæses i hukommelsen fra Delta-tabeller, som gemmer deres data i Parquet-filer i OneLake – det enkelte lager til alle analysedata. Når den semantiske model er indlæst i hukommelsen, aktiverer den forespørgsler med høj ydeevne. Direct Lake fjerner det langsomme og dyre behov for at importere data til modellen.
Du kan bruge Direct Lake-lagringstilstand til at oprette forbindelse til tabeller eller visninger af et enkelt Fabric lakehouse eller Fabric Warehouse. Begge disse Fabric-elementer og Direct Lake-semantiske modeller kræver en Fabric-kapacitetslicens.
På nogle måder ligner en semantisk Direct Lake-model en semantisk importmodel. Det skyldes, at modeldata indlæses i hukommelsen af VertiPaq-programmet for at opnå hurtig forespørgselsydeevne (undtagen i tilfælde af DirectQuery-fallback, hvilket forklares senere i denne artikel).
En semantisk Direct Lake-model adskiller sig dog fra en semantisk importmodel på en vigtig måde. Det skyldes, at en opdateringshandling for en semantisk Direct Lake-model er konceptuelt anderledes end en opdateringshandling for en semantisk importmodel. For en semantisk Direct Lake-model omfatter en opdatering en indramning (beskrevet senere i denne artikel), som kan tage et par sekunder at fuldføre. Det er en billig handling, hvor den semantiske model analyserer metadataene for den nyeste version af Delta-tabellerne og opdateres, så den refererer til de nyeste filer i OneLake. I modsætning hertil producerer en opdatering for en semantisk importmodel en kopi af dataene, hvilket kan tage lang tid og forbruge betydelige datakilde- og kapacitetsressourcer (hukommelse og CPU).
Bemærk
Trinvis opdatering af en semantisk importmodel kan hjælpe med at reducere opdateringstiden og brugen af kapacitetsressourcer.
Hvornår skal du bruge Direct Lake-lagringstilstand?
Den primære use case for en Direct Lake-lagringstilstand er typisk til it-drevne analyseprojekter, der udnytter lakecentrerede arkitekturer. I dette scenarie har du – eller forventer at akkumulere – store datamængder i OneLake. Hurtig indlæsning af disse data i hukommelsen, hyppige og hurtige opdateringshandlinger, effektiv brug af kapacitetsressourcer og hurtig forespørgselsydeevne er alt sammen vigtige for denne use case.
Bemærk
Semantiske import- og DirectQuery-modeller er stadig relevante i Fabric, og de er det rigtige valg af semantisk model til nogle scenarier. Importlagringstilstand fungerer f.eks. ofte godt for en selvbetjeningsanalytiker, der har brug for frihed og fleksibilitet til at handle hurtigt og uden at være afhængig af it til at tilføje nye dataelementer.
OneLake-integration skriver også automatisk data for tabeller i lagringstilstanden Import til Delta-tabeller i OneLake uden at involvere nogen overførselsindsats. Ved at bruge denne indstilling kan du realisere mange af fordelene ved Fabric, der er gjort tilgængelige for import af semantiske modelbrugere, f.eks. integration med lakehouses via genveje, SQL-forespørgsler, notesbøger med mere. Vi anbefaler, at du betragter denne indstilling som en hurtig måde at høste fordelene ved Fabric på uden nødvendigvis eller øjeblikkeligt at omdesigne dit eksisterende data warehouse og/eller analysesystem.
Direct Lake-lagringstilstand er også velegnet til at minimere dataventetid for hurtigt at gøre data tilgængelige for erhvervsbrugere. Hvis dine Delta-tabeller ændres med mellemrum (og hvis du allerede har foretaget dataforberedelse i datasøen), kan du være afhængig af, at automatiske opdateringer omrammer som svar på disse ændringer. I dette tilfælde returnerer forespørgsler, der sendes til den semantiske model, de nyeste data. Denne funktion fungerer godt sammen med funktionen til automatisk sideopdatering i Power BI-rapporter.
Husk, at Direct Lake afhænger af, at dataforberedelsen udføres i datasøen. Dataforberedelse kan udføres ved hjælp af forskellige værktøjer, f.eks. Spark-job til Fabric lakehouses, T-SQL DML-sætninger for Fabric-lagre, dataflows, pipelines og andre. Denne fremgangsmåde hjælper med at sikre, at dataforberedelseslogik udføres så lavt som muligt i arkitekturen for at maksimere genbrugsmuligheden. Men hvis den semantiske modelforfatter ikke har mulighed for at ændre kildeelementet, f.eks. i tilfælde af en selvbetjeningsanalytiker, der muligvis ikke har skriverettigheder til et lakehouse, der administreres af it, kan importlagringstilstand være et bedre valg. Det skyldes, at den understøtter dataforberedelse ved hjælp af Power Query, som er defineret som en del af semantisk model.
Sørg for at tage højde for din nuværende Fabric-kapacitetslicens og Fabric-kapacitetsafskærmningerne , når du overvejer Direct Lake-lagringstilstand. Du kan også tage højde for overvejelser og begrænsninger, som beskrives senere i denne artikel.
Tip
Vi anbefaler, at du opretter en prototype – eller blåstempling – for at afgøre, om en Semantisk Direct Lake-model er den rigtige løsning, og for at mindske risikoen.
Sådan fungerer Direct Lake
Forespørgsler, der sendes til en semantisk Direct Lake-model, håndteres typisk fra en cache i hukommelsen for de kolonner, der stammer fra Delta-tabeller. Det underliggende lager for en Delta-tabel er en eller flere Parquet-filer i OneLake. Parquetfiler organiserer data efter kolonner i stedet for rækker. Semantiske modeller indlæser hele kolonner fra Delta-tabeller i hukommelsen, da de kræves af forespørgsler.
En semantisk Direct Lake-model kan også bruge DirectQuery-fallback, hvilket omfatter problemfri skift til DirectQuery-tilstand. DirectQuery-fallback henter data direkte fra SQL Analytics-slutpunktet for lakehouse'et eller lageret. Der kan f.eks. opstå fallback, når en Delta-tabel indeholder flere rækker med data end understøttet af din Fabric-kapacitet (beskrevet senere i denne artikel). I dette tilfælde sender en DirectQuery-handling en forespørgsel til SQL-analyseslutpunktet. Fallback-handlinger kan resultere i langsommere forespørgselsydeevne.
I følgende diagram kan du se, hvordan Direct Lake fungerer ved hjælp af scenariet for en bruger, der åbner en Power BI-rapport.
Diagrammet viser følgende brugerhandlinger, processer og funktioner.
| Element | Beskrivelse |
|---|---|
|
OneLake er en datasø, der gemmer analysedata i Parquet-format. Dette filformat er optimeret til lagring af data til semantiske Direct Lake-modeller. |
|
Der findes et Fabric lakehouse- eller Fabric-lager i et arbejdsområde, der er på Fabric-kapacitet. Lakehouse har et SQL Analytics-slutpunkt, som giver en SQL-baseret oplevelse til forespørgsler. Tabeller (eller visninger) giver mulighed for at forespørge deltatabellerne i OneLake ved hjælp af Transact-SQL (T-SQL). |
|
Der findes en semantisk Direct Lake-model i et Fabric-arbejdsområde. Det opretter forbindelse til tabeller eller visninger i enten lakehouse eller warehouse. |
|
En bruger åbner en Power BI-rapport. |
|
Power BI-rapporten sender DAX-forespørgsler (Data Analysis Expressions) til den semantiske Direct Lake-model. |
|
Når det er muligt (og nødvendigt), indlæser den semantiske model kolonner i hukommelsen direkte fra de Parquet-filer, der er gemt i OneLake. Forespørgsler opnår ydeevne i hukommelsen, hvilket er meget hurtigt. |
|
Den semantiske model returnerer forespørgselsresultater. |
|
Power BI-rapporten gengiver visualiseringerne. |
|
I visse tilfælde, f.eks. når den semantiske model overskrider kapacitetens gelændere, går semantiske modelforespørgsler automatisk tilbage til DirectQuery-tilstand. I denne tilstand sendes forespørgsler til SQL Analytics-slutpunktet for lakehouse eller warehouse. |
|
DirectQuery-forespørgsler, der sendes til SQL-analyseslutpunktet, forespørger igen Delta-tabellerne i OneLake. Derfor kan forespørgselsydeevnen være langsommere end forespørgsler i hukommelsen. |
I følgende afsnit beskrives Begreber og funktioner i Direct Lake, herunder indlæsning af kolonner, indramning, automatiske opdateringer og DirectQuery-fallback.
Kolonneindlæsning (omkodning)
Semantiske Direct Lake-modeller indlæser kun data fra OneLake, når der forespørges om kolonner første gang. Processen til indlæsning af data on-demand fra OneLake kaldes omkodning.
Når den semantiske model modtager en DAX-forespørgsel (eller Flerdimensionelle udtryk – MDX), bestemmer den først, hvilke kolonner der skal bruges til at oprette et forespørgselsresultat. De kolonner, der skal bruges, omfatter alle kolonner, der bruges direkte af forespørgslen, samt kolonner, der kræves af relationer og målinger. Det antal kolonner, der skal bruges til at oprette et forespørgselsresultat, er typisk meget mindre end det antal kolonner, der er defineret i den semantiske model.
Når den semantiske model har forstået, hvilke kolonner der skal bruges, bestemmer den semantiske model, hvilke kolonner der allerede findes i hukommelsen. Hvis de kolonner, der er nødvendige for forespørgslen, ikke er i hukommelsen, indlæser den semantiske model alle data for disse kolonner fra OneLake. Indlæsning af kolonnedata er typisk en meget hurtig handling, men det kan afhænge af faktorer som kardinaliteten af data, der er gemt i kolonnerne.
Kolonner, der indlæses i hukommelsen, er derefter hjemmehørende i hukommelsen. Fremtidige forespørgsler, der kun involverer residente kolonner, behøver ikke at indlæse flere kolonner i hukommelsen.
En kolonne forbliver hjemmehørende, indtil der er grund til, at den fjernes (fjernes) fra hukommelsen. Årsager til, at kolonner kan blive fjernet, omfatter:
- Modellen eller tabellen er blevet opdateret (se Framing i næste afsnit).
- Ingen forespørgsel har brugt kolonnen i et stykke tid.
- Andre årsager til hukommelsesstyring, herunder hukommelsesforbrug i kapaciteten på grund af andre samtidige handlinger.
Dit valg af Fabric SKU bestemmer den maksimale tilgængelige hukommelse for hver semantiske Direct Lake-model i kapaciteten. Du kan få flere oplysninger om ressourcebeskyttere og maksimale hukommelsesgrænser i Fabric-kapacitetsgardelister og -begrænsninger senere i denne artikel.
Indramning
Framing giver modelejere kontrol over, hvilke data der indlæses i den semantiske model. Framing er en Direct Lake-handling, der udløses af en opdatering af en semantisk model, og som i de fleste tilfælde kun tager nogle få sekunder at fuldføre. Det skyldes, at det er en lavomkostningshandling, hvor den semantiske model analyserer metadataene for den nyeste version af Delta Lake-tabellerne og opdateres, så den refererer til de nyeste Parquet-filer i OneLake.
Når der foretages indramning, fjernes residente kolonner muligvis fra hukommelsen, og tidspunktet for opdateringen bliver den nye grundlinje for alle fremtidige omkodningshændelser. Fra dette tidspunkt overvejer Direct Lake-forespørgsler kun data i Delta-tabellerne fra tidspunktet for den seneste indramning. Derfor forespørges Direct Lake-tabeller om at returnere data baseret på tilstanden af Delta-tabellen på tidspunktet for den seneste indramning. Dette tidspunkt er ikke nødvendigvis den seneste tilstand for Delta-tabellerne.
I følgende diagram kan du se, hvordan Direct Lake-indramning fungerer.
Diagrammet viser følgende processer og funktioner.
| Element | Beskrivelse |
|---|---|
|
|
Der findes en semantisk model i et Fabric-arbejdsområde. |
|
|
Indramningshandlinger finder sted med jævne mellemrum, og de angiver den oprindelige plan for alle fremtidige omkodningshændelser . Indramning af handlinger kan ske automatisk, manuelt, efter tidsplan eller programmatisk. |
|
|
OneLake gemmer metadata og Parquet-filer, der repræsenteres som Delta-tabeller. |
|
|
Den sidste indramningshandling omfatter Parquet-filer, der er relateret til Delta-tabellerne, og især de Parquet-filer, der blev tilføjet før den sidste indramning. |
|
|
En senere indramningshandling omfatter Parquet-filer, der er tilføjet efter den sidste indramningshandling. |
|
|
Residente kolonner i den semantiske Direct Lake-model kan blive fjernet fra hukommelsen, og tidspunktet for opdateringen bliver den nye grundlinje for alle fremtidige transkodningshændelser. |
|
|
Efterfølgende dataændringer, der repræsenteres af nye Parquet-filer, er ikke synlige, før den næste indramningshandling finder sted. |
Det er ikke altid ønskeligt at have data, der repræsenterer den seneste tilstand af en Delta-tabel, når der udføres en omkodningshandling. Overvej, at indramning kan hjælpe dig med at levere ensartede forespørgselsresultater i miljøer, hvor data i Delta-tabeller er midlertidige. Data kan være midlertidige af flere årsager, f.eks. når der forekommer langvarige ekstrakt-, transformerings- og indlæsningsprocesser (ETL).
Opdatering af en semantisk Direct Lake-model kan udføres manuelt, automatisk eller programmatisk. Du kan få flere oplysninger under Opdater semantiske Direct Lake-modeller.
Du kan få flere oplysninger om deltatabelversioner og indramning under Forstå lager til semantiske Direct Lake-modeller.
Automatiske opdateringer
Der er en semantisk indstilling på modelniveau, der automatisk opdaterer Direct Lake-tabeller. Den er som standard aktiveret. Det sikrer, at dataændringer i OneLake automatisk afspejles i den semantiske Direct Lake-model. Du bør deaktivere automatiske opdateringer, når du vil styre dataændringer ved hjælp af indramning, hvilket blev forklaret i forrige afsnit. Du kan få flere oplysninger under Administrer semantiske Direct Lake-modeller.
Tip
Du kan konfigurere automatisk sideopdatering i dine Power BI-rapporter. Det er en funktion, der automatisk opdaterer en bestemt rapportside, hvis rapporten opretter forbindelse til en semantisk Direct Lake-model (eller andre typer semantisk model).
DirectQuery-fallback
En forespørgsel, der sendes til en semantisk Direct Lake-model, kan gå tilbage til DirectQuery-tilstand. I dette tilfælde hentes data direkte fra SQL-analyseslutpunktet for lakehouse eller warehouse. Sådanne forespørgsler returnerer altid de nyeste data, fordi de ikke er begrænset til tidspunktet for den sidste indramningshandling.
En forespørgsel falder altid tilbage, når den semantiske model forespørger en visning i SQL Analytics-slutpunktet eller en tabel i SQL Analytics-slutpunktet, der gennemtvinger sikkerhed på rækkeniveau.
En forespørgsel kan også falde tilbage, når den semantiske model overskrider kapacitetens gelændere.
Vigtigt
Hvis det er muligt, skal du altid designe din løsning – eller tilpasse størrelsen på din kapacitet – for at undgå DirectQuery-fallback. Det skyldes, at det kan resultere i langsommere forespørgselsydeevne.
Du kan styre fallback af dine semantiske Direct Lake-modeller ved at angive egenskaben DirectLakeBehavior . Du kan få flere oplysninger under Angiv egenskaben Direct Lake-funktionsmåde.
Struktur kapacitet gelændere og begrænsninger
Semantiske Direct Lake-modeller kræver en Fabric-kapacitetslicens. Der er også kapacitetsafskærmninger og begrænsninger, der gælder for dit Fabric-kapacitetsabonnement (SKU), som vist i følgende tabel.
Vigtigt
Den første kolonne i følgende tabel indeholder også Power BI Premium-kapacitetsabonnementer (P-SKU'er). Vær opmærksom på, at Microsoft konsoliderer købsmuligheder og udfaser Power BI Premium pr. kapacitets-SKU'er. Nye og eksisterende kunder bør overveje at købe Fabric-kapacitetsabonnementer (F SKU'er) i stedet.
Du kan få flere oplysninger under Vigtig opdatering, der kommer til Power BI Premium-licenser og Power BI Premium.
| Stof-SKU | Parquetfiler pr. tabel | Rækkegrupper pr. tabel | Rækker pr. tabel (millioner) | Maksimal modelstørrelse på disk/OneLake (GB) | Maks. hukommelse (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 | Ubegrænset | 25 |
| F128/P2 | 5.000 | 5.000 | 3.000 | Ubegrænset | 50 |
| F256/P3 | 5.000 | 5.000 | 6.000 | Ubegrænset | 100 |
| F512/P4 | 10,000 | 10,000 | 12,000 | Ubegrænset | 200 |
| F1024/P5 | 10,000 | 10,000 | 24,000 | Ubegrænset | 400 |
| F2048 | 10,000 | 10,000 | 24,000 | Ubegrænset | 400 |
1 For semantiske Direct Lake-modeller repræsenterer Maksimal hukommelse den øvre grænse for hukommelsesressourcer for, hvor mange data der kan sideinddeles i. Derfor er det ikke en gelænder, fordi overskridelse af den ikke resulterer i et fallback til DirectQuery-tilstand. Det kan dog have en indvirkning på ydeevnen, hvis mængden af data er stor nok til at forårsage overdreven sideinddeling af modeldataene fra OneLake-dataene.
Hvis den maksimale modelstørrelse overskrides på disken/OneLake , medfører det, at alle forespørgsler til den semantiske model vender tilbage til DirectQuery-tilstand. Alle andre gelændere, der vises i tabellen, evalueres pr. forespørgsel. Det er derfor vigtigt, at du optimerer dine Delta-tabeller og Direct Lake-semantiske modeller for at undgå unødigt at skulle skalere op til en højere Fabric SKU (hvilket medfører øgede omkostninger).
Derudover gælder kapacitetsenhed og maks. hukommelse pr. forespørgselsgrænser for semantiske Direct Lake-modeller. Du kan få flere oplysninger under Kapaciteter og SKU'er.
Overvejelser og begrænsninger
Semantiske Direct Lake-modeller præsenterer nogle overvejelser og begrænsninger.
Bemærk
Funktionerne og funktionerne i semantiske Direct Lake-modeller udvikler sig. Sørg for at vende tilbage med jævne mellemrum for at gennemse den seneste liste over overvejelser og begrænsninger.
- Når en semantisk Direct Lake-modeltabel opretter forbindelse til en tabel i SQL Analytics-slutpunktet, der gennemtvinger sikkerhed på rækkeniveau, vil forespørgsler, der involverer denne modeltabel, altid gå tilbage til DirectQuery-tilstand. Forespørgselsydeevnen kan være langsommere.
- Når en semantisk Direct Lake-modeltabel opretter forbindelse til en visning i SQL Analytics-slutpunktet, vender forespørgsler, der involverer denne modeltabel, altid tilbage til DirectQuery-tilstand. Forespørgselsydeevnen kan være langsommere.
- Sammensat udformning understøttes ikke. Det betyder, at semantiske Direct Lake-modeltabeller ikke kan blandes med tabeller i andre lagringstilstande, f.eks. Import, DirectQuery eller Dual (undtagen i særlige tilfælde, herunder beregningsgrupper, what if-parametre og feltparametre).
- Beregnede kolonner og beregnede tabeller, der refererer til kolonner eller tabeller i Direct Lake-lagringstilstand, understøttes ikke. Beregningsgrupper, what if-parametre og feltparametre, der implicit opretter beregnede tabeller, og beregnede tabeller, der ikke refererer til Direct Lake-kolonner eller -tabeller, understøttes.
- Direct Lake-lagertilstandstabeller understøtter ikke komplekse kolonnetyper i Delta-tabeller. Binære og GUID-semantiske typer understøttes heller ikke. Du skal konvertere disse datatyper til strenge eller andre understøttede datatyper.
- Tabelrelationer kræver, at datatyperne for relaterede kolonner stemmer overens.
- Ensidede kolonner med relationer skal indeholde entydige værdier. Forespørgsler mislykkes, hvis der registreres dubletværdier i en kolonne på én side.
- Automatisk data-/tidsintelligens i Power BI Desktop understøttes ikke. Markering af din egen datotabel som en datotabel understøttes.
- Længden af strengkolonneværdier er begrænset til 32.764 Unicode-tegn.
- Den flydende talværdi NaN (ikke et tal) understøttes ikke.
- Integreringsscenarier, der bruger scenariet For dit kundeforbrug , understøttes ikke.
- Publicer på internettet fra Power BI understøttes kun, når du bruger en fast identitet for den semantiske Direct Lake-model.
- I webmodelleringsoplevelsen er validering begrænset for semantiske Direct Lake-modeller. Brugervalg antages at være korrekte, og der udstedes ingen forespørgsler for at validere kardinalitet eller tværgående filtervalg for relationer eller for den valgte datokolonne i en markeret datotabel.
- På Fabric-portalen viser fanen Direct Lake i opdateringshistorikken kun Direct Lake-relaterede opdateringsfejl. Vellykkede opdateringshandlinger (indramning) vises ikke.
- Din Fabric SKU bestemmer den maksimale tilgængelige hukommelse pr. Semantisk Direct Lake-model for kapaciteten. Når grænsen overskrides, kan forespørgsler til den semantiske model være langsommere på grund af overdreven sideinddeling i og ud af modeldataene.
- Oprettelse af en semantisk Direct Lake-model i et arbejdsområde, der er i et andet område i datakildearbejdsområdet, understøttes ikke. Hvis Lakehouse f.eks. er i det vestlige centrale USA, kan du kun oprette semantiske modeller fra dette Lakehouse i det samme område. En løsning er at oprette et Lakehouse i det andet områdes arbejdsområde og genvej til tabellerne, før du opretter den semantiske model. Hvis du vil finde ud af, hvilket område du befinder dig i, kan du se dit Fabric-hjemmeområde.
- Du kan oprette og få vist en brugerdefineret semantisk Direct Lake-model ved hjælp af en tjenesteprincipalidentitet, men standarden for Direct Lake-semantisk model understøtter ikke tjenesteprincipaler. Sørg for, at godkendelse af tjenesteprincipal er aktiveret for Fabric REST API'er i din lejer, og tildel tjenesteprincipalen Bidragyder eller højere tilladelser til arbejdsområdet i din Semantiske Direct Lake-model.
- Direct Lake understøtter ikke tjenesteprincipalprofiler til godkendelse.
Sammenligning med andre lagringstilstande
I følgende tabel sammenlignes Lagringstilstanden Direct Lake med lagringstilstanden Import og DirectQuery.
| Egenskab | Direct Lake | Importér | DirectQuery |
|---|---|---|---|
| Licenser | Kun fabric-kapacitetsabonnementer (SKU'er) | Enhver Fabric- eller Power BI-licens (herunder gratis Microsoft Fabric-licenser) | Enhver Fabric- eller Power BI-licens (herunder gratis Microsoft Fabric-licenser) |
| Datakilde | Kun lakehouse- eller lagertabeller (eller visninger) | En hvilken som helst forbindelse | Alle forbindelser, der understøtter DirectQuery-tilstand |
| Opret forbindelse til SQL Analytics-slutpunktsvisninger | Ja – men vender automatisk tilbage til DirectQuery-tilstand | Ja | Ja |
| Sammensatte modeller | Nr. 1 | Ja – kan kombineres med DirectQuery- eller Dual-lagringstilstandstabeller | Ja – kan kombineres med tabeller i import- eller dual-lagringstilstand |
| Enkeltlogon (SSO - Single sign-on) | Ja | Ikke anvendelig | Ja |
| Beregnede tabeller | Nej – undtagen beregningsgrupper, what if-parametre og feltparametre, der implicit opretter beregnede tabeller | Ja | Nej – beregnede tabeller bruger lagringstilstanden Import, selvom de refererer til andre tabeller i DirectQuery-tilstand |
| Beregnede kolonner | Nej | Ja | Ja |
| Hybride tabeller | Nej | Ja | Ja |
| Partitioner i modeltabel | Nej – men partitionering kan udføres på Delta-tabelniveau | Ja – enten automatisk oprettet ved trinvis opdatering eller oprettet manuelt ved hjælp af XMLA-slutpunktet | Nr. |
| Brugerdefinerede sammenlægninger | Nej | Ja | Ja |
| SIKKERHED på objektniveau eller sikkerhed på kolonneniveau for SQL Analytics-slutpunkt | Ja – men forespørgsler vender tilbage til DirectQuery-tilstand og kan medføre fejl, når tilladelsen afvises | Ja – men skal duplikere tilladelser med sikkerhed på objektniveau for semantisk model | Ja – men forespørgsler kan medføre fejl, når tilladelsen afvises |
| Sikkerhed på rækkeniveau for SQL-analyseslutpunkt | Ja – men forespørgsler vender tilbage til DirectQuery-tilstand | Ja – men skal duplikere tilladelser med RLS for semantisk model | Ja |
| Sikkerhed på rækkeniveau for semantisk model (RLS) | Ja – men det anbefales på det kraftigste at bruge en fast identitetsskyforbindelse | Ja | Ja |
| Sikkerhed på objektniveau for semantisk model (OLS) | Ja | Ja | Ja |
| Store datamængder uden opdateringskrav | Ja | Mindre velegnet – det kan være nødvendigt med en større kapacitetsstørrelse for at forespørge og opdatere | Ja |
| Reducer dataventetid | Ja – når automatiske opdateringer er aktiveret, eller programmatisk reframing, skal dataforberedelsen dog udføres upstream først | Nej | Ja |
1 Du kan ikke kombinere Direct Lake-lagertilstandstabeller med DirectQuery- eller Dual-lagringstilstandstabeller i den samme semantiske model. Du kan dog bruge Power BI Desktop til at oprette en sammensat model på en Semantisk Direct Lake-model og derefter udvide den med nye tabeller (ved hjælp af import-, DirectQuery- eller Dual-lagringstilstand) eller beregninger. Du kan få flere oplysninger under Opret en sammensat model på en semantisk model.