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 for 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 tabellerne eller visningerne af en enkelt Fabric lakehouse- eller Fabric Warehouse-. Både 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 handling (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).
Seddel
trinvis opdatering for 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-lagertilstand er typisk for it-drevne analyseprojekter, der bruger 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.
Seddel
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 til tabeller i importlagringstilstand for at Delta-tabeller, der i OneLake, uden at det kræver 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 jævne mellemrum (og hvis du allerede har forberedt data i datasøen), kan du være afhængig af, automatiske opdateringer omformulere 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 automatisk sideopdatering funktion 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. hvis en selvbetjeningsanalytiker ikke har skrivetilladelser til et lakehouse, der administreres af it-virksomheden, 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 aktuelle Fabric-kapacitetslicens og Fabric-kapacitetsbeskyttere, når du overvejer Direct Lake-lagertilstand. Faktoren i de overvejelser og begrænsninger, som beskrives senere i denne artikel.
Drikkepenge
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- eller lageret. Fallback kan f.eks. forekomme, 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.
| Vare | 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 gelændere af kapaciteten, 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 med at indlæse 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. Alle kolonner, der bruges direkte af forespørgslen, er nødvendige og også kolonner, der kræves af relationer og målinger. Det antal kolonner, der skal bruges til at oprette et forespørgselsresultat, er typisk betydeligt mindre end det antal kolonner, der er defineret i den semantiske model.
Når den forstår, hvilke kolonner der er behov for, 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 hurtig handling, men det kan afhænge af faktorer som kardinaliteten af data, der er gemt i kolonnerne.
Kolonner, der indlæses i hukommelsen, derefter 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 blev opdateret efter en deltatabelopdatering ved kilden (se Framing i næste afsnit).
- Kolonnen blev ikke brugt i nogen 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 under Fabric-kapacitetsafskærmninger 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 i de fleste tilfælde tager det kun 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 indramning finder sted, fjernes residente tabelkolonnesegmenter og ordbøger muligvis fra hukommelsen, hvis de underliggende data er ændret, og tidspunktet for opdateringen bliver den nye grundlinje for alle fremtidige transkodningshændelser. Fra dette tidspunkt overvejer Direct Lake-forespørgsler kun data i Delta-tabellerne fra tidspunktet for den seneste indramning. Derfor sendes der en forespørgsel til Direct Lake-tabeller om at returnere data baseret på tilstanden for deltatabellen på tidspunktet for den seneste indramning. Dette tidspunkt er ikke nødvendigvis den seneste tilstand for Delta-tabellerne.
Bemærk, at den semantiske model analyserer Delta-loggen for hver Delta-tabel under indramningen for kun at slippe de berørte kolonnesegmenter og genindlæse nyligt tilføjede data under omkodning. En vigtig optimering er, at ordbøger normalt ikke vil blive droppet, når trinvis indramning træder i kraft, og der føjes nye værdier til de eksisterende ordbøger. Denne trinvise indramning hjælper med at reducere belastningsbyrden for forespørgsler og fordele ved forespørgselsydeevne. I det ideelle tilfælde, hvor en Delta-tabel ikke modtog nogen opdateringer, er det ikke nødvendigt at genindlæse kolonner, der allerede er placeret i hukommelsen, og forespørgsler viser langt mindre påvirkning af ydeevnen efter indramning, fordi trinvis indramning grundlæggende gør det muligt for den semantiske model at opdatere betydelige dele af de eksisterende in-memory-data på plads.
I følgende diagram kan du se, hvordan Direct Lake-indramning fungerer.
Diagrammet viser følgende processer og funktioner.
| Vare | 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 omkodning hæ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 sidste indramningshandling. |
|
|
En senere indramningshandling omfatter Parquet-filer, der er tilføjet efter 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 i Opdater semantiske Direct Lake-modeller.
Du kan få flere oplysninger om versionsstyring og indramning af Delta-tabeller under Forstå lagring af semantiske Direct Lake-modeller.
Automatiske opdateringer
Der er en semantisk indstilling på modelniveau, der automatisk opdaterer Direct Lake-tabeller. Den er aktiveret som standard. 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 .
Drikkepenge
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 altid falde tilbage, når den semantiske model forespørger en visning i SQL-analyseslutpunktet eller en tabel i SQL-analyseslutpunktet, der gennemtvinger sikkerhed på rækkeniveau.
En forespørgsel kan også falde tilbage, når den semantiske model overskrider gelænderne for kapaciteten.
Vigtig
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 i 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.
Vigtig
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) | Maksimal 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 maks. hukommelse den øvre grænse for hukommelsesressourcer for, hvor mange data der kan sideinddeles. 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 på disk/OneLake overskrides, medfører, at alle forespørgsler til den semantiske model går tilbage til DirectQuery-tilstand. Alle andre gelændere, der vises i tabellen, evalueres pr. forespørgsel. Det er derfor vigtigt, at du optimere dine Delta-tabeller og semantiske Direct Lake-model 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 gælde 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.
Seddel
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-parametreog feltparametre).
- Beregnede kolonner og beregnede tabeller, der refererer til kolonner eller tabeller i Direct Lake-lagringstilstand, understøttes ikke. beregningsgrupper, what if-parametreog feltparametre, som 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.
- Publicer på internettet fra Power BI-, der bruger en tjenesteprincipal, understøttes kun, når du bruger en fast identitet for den semantiske Direct Lake-model.
- I webmodelleringsoplevelseer 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, skal du se finde 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.
- Integrering af rapporter kræver et V2-integreringstoken.
- Direct Lake understøtter ikke tjenesteprincipalprofiler til godkendelse.
- Brugerdefinerede semantiske Direct Lake-modeller, der er oprettet af tjenesteprincipalen og seer med tjenesteprincipal, understøttes, men standard semantiske Direct Lake-modeller understøttes ikke.
Sammenligning med andre lagringstilstande
I følgende tabel sammenlignes Lagringstilstanden Direct Lake med lagringstilstanden Import og DirectQuery.
| Kapacitet | Direct Lake | Import | 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 | Ingen 1 | Ja – kan kombineres med DirectQuery- eller Dual-lagringstilstandstabeller | Ja – kan kombineres med tabeller i import- eller dual-lagringstilstand |
| Enkeltlogon (SSO) | Ja | Ikke relevant | Ja |
| Beregnede tabeller | Nej – undtagen beregningsgrupper, what if-parametreog feltparametre, som 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 manuelt oprettet ved hjælp af XMLA-slutpunktet | Nej |
| 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 identitet cloudforbindelse | 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 genfragmentering. men dataforberedelse skal udføres opstrøms først | Nej | Ja |
| Power BI Embedded | Ja 2 | Ja | Ja |
1 Du kan ikke kombinere Direct Lake-lagertilstandstabeller med DirectQuery- eller Dual-lagringstilstandstabeller, der er 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.
2 kræver et V2-integreringstoken. Hvis du bruger en tjenesteprincipal, skal du bruge en fast identitet cloudforbindelse.