Del via

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 , der er gemt i OneLake – det enkelte lager til alle analysedata. Når den semantiske model er indlæst i hukommelsen, muliggør den interaktive analyse med høj ydeevne.

Diagram, der viser en semantisk Direct Lake-model, og hvordan den opretter forbindelse til Delta-tabeller i OneLake som beskrevet i forrige afsnit.

Direct Lake er ideel til semantiske modeller, der opretter forbindelse til store Fabric lakehouses, lagre og andre kilder med Delta-tabeller, især når det er udfordrende eller umuligt at replikere hele datamængden til en importmodel. Direct Lake-forespørgsler behandles, f.eks. importtilstand, af VertiPaq-forespørgselsprogrammet, mens DirectQuery sammenkæder forespørgsler til den underliggende datakilde. Det betyder, at Direct Lake-forespørgsler, f.eks. importtilstand, normalt overgår DirectQuery.

En Direct Lake adskiller sig dog fra en importtilstand på en vigtig måde: En opdateringshandling for en semantisk Direct Lake-model er konceptuelt anderledes end en opdateringshandling for en semantisk importmodel. Importtilstand replikerer dataene og opretter en hel cachelagret kopi af dataene for den semantiske model, mens en Opdatering af Direct Lake kun kopierer metadata (også kaldet indramning, som beskrevet senere i denne artikel), som kan tage et par sekunder at fuldføre. Opdateringen af Direct Lake er en omkostningskrævende handling, der 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 af import en kopi af dataene, hvilket kan tage lang tid og forbruge betydelige datakilde- og kapacitetsressourcer (hukommelse og CPU). Direct Lake flytter dataforberedelse til OneLake og bruger dermed hele bredden af Fabric-teknologier til dataforberedelse, herunder Spark-job, T-SQL DML-sætninger, dataflow, pipelines og meget mere.

Direct Lake-lagringstilstand giver følgende vigtige fordele:

  • På samme måde som med importtilstand behandles Direct Lake-forespørgsler af VertiPaq-programmet og leverer dermed forespørgselsydeevne, der kan sammenlignes med importtilstanden, uden at administrationsomkostningerne for dataopdateringscyklusser indlæser hele datamængden.
  • Bruger eksisterende Fabric-investeringer ved problemfri integration med store lakehouses, lagre og andre Fabric-kilder med Delta-tabeller. Direct Lake er f.eks. et ideelt valg til guldanalyselaget i medaljonens lakehouse-arkitektur.
  • Maksimerer investeringsafkast, fordi analyserede datamængder kan overskride kapacitetens maksimale hukommelsesgrænser, da det kun er de data, der er nødvendige for at besvare en forespørgsel, der indlæses i hukommelsen.
  • Minimerer datatidsintervaller ved hurtigt og automatisk at synkronisere en semantisk model med dens kilder, hvilket gør nye data tilgængelige for virksomhedsbrugere uden opdateringsplaner.

Hvornår skal du bruge Direct Lake-lagringstilstand?

Den primære use case for Direct Lake-lagringstilstand er typisk for it-drevne analyseprojekter, der bruger lakecentrerede arkitekturer. I sådanne scenarier har eller forventer du 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 for tabeller i lagringstilstanden Import til Delta-tabeller i OneLake uden at involvere nogen overførselsindsats, hvilket giver dig mulighed for at indse 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 denne mulighed 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 afhænger af, at der udføres dataforberedelse 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, dataflow, pipelines og andre, hvilket hjælper med at sikre, at logikken for dataforberedelse udføres upstream i arkitekturen for at maksimere genbrugsvenligheden. Men hvis den semantiske modelforfatter ikke har mulighed for at ændre kildeelementet, f.eks. hvis en selvbetjent analytiker ikke har skrivetilladelser til et lakehouse, der administreres af it-virksomheden, kan det være et godt valg at øge modellen med tabeller med importlagringstilstand, da importtilstand understøtter dataforberedelse ved hjælp af Power Query, som er defineret som en del af semantisk model.

Sørg for at overveje din aktuelle Fabric-kapacitetslicens og Fabric-kapacitetsgardestængerne , når du overvejer Direct Lake-lagringstilstand. Du kan også tage højde for 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.

Nøglebegreber og terminologi

Denne artikel forudsætter kendskab til følgende begreber:

  • Brugerne interagerer med visualiseringer i Power BI-rapporter, som genererer DAX-forespørgsler til den semantiske model.
  • Lagringstilstand: Den semantiske model behandler DAX-forespørgsler forskelligt afhængigt af den anvendte lagringstilstand. Eksempel:
    • Lagringstilstandene Import og Direct Lake bruger VertiPaq-programmet til at behandle DAX-forespørgsler og returnere resultater til Power BI-rapporten og -brugeren.
    • DirectQuery oversætter derimod DAX-forespørgsler til datakildens forespørgselssyntaks (typisk en form for SQL) og sammenkæder dem med den underliggende database. Forespørgselsprocessorer for kildedatabaser er ofte ikke gearet til BI-stil, aggregerede forespørgsler og resulterer derfor i langsommere ydeevne og reduceret brugerinteraktivitet sammenlignet med tilstandene Import og Direct Lake.

Lagringstilstand er en egenskab for en tabel i den semantiske model. Når en semantisk model indeholder tabeller med forskellige lagringstilstande, kaldes den en sammensat model. Du kan få flere oplysninger om lagringstilstande i Semantiske modeltilstande i Power BI-tjenesten.

  • Direct Lake-tilstand kan bruge to forskellige adgangsmetoder:

    • Direct Lake på OneLake afhænger ikke af SQL-slutpunkter og kan bruge data fra enhver Fabric-datakilde med Delta-tabeller. Direct Lake på OneLake går ikke tilbage til DirectQuery-tilstand.

    Seddel

    Direct Lake på OneLake er i øjeblikket en offentlig prøveversion.

    • Direct Lake på SQL-slutpunkter bruger SQL-slutpunktet for et Fabric lakehouse eller -lager til registrering og tilladelseskontrol af Delta-tabeller. Direct Lake på SQL-slutpunkter kan gå tilbage til DirectQuery-tilstand, når den ikke kan indlæse dataene direkte fra en Delta-tabel, f.eks. når datakilden er en SQL-visning, eller når lageret bruger SQL-baseret sikkerhed på rækkeniveau. Direct Lake på SQL-slutpunkter er generelt tilgængelig og understøttes fuldt ud i produktion.

Sammenligning af lagringstilstande

I følgende tabel sammenlignes Lagringstilstanden Direct Lake med lagringstilstanden Import og DirectQuery.

Kapacitet Direct Lake on OneLake Direct Lake på SQL-slutpunkter Importér DirectQuery
Licenser Kun fabric-kapacitetsabonnementer (SKU'er) 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 Tabeller med en hvilken som helst Fabric-datakilde, der understøttes af Delta-tabeller Kun lakehouse- eller lagertabeller (eller visninger) En hvilken som helst forbindelse Alle forbindelser, der understøtter DirectQuery-tilstand
Opret forbindelse til SQL Analytics-slutpunktsvisninger Nej Ja – men vender automatisk tilbage til DirectQuery-tilstand Ja Ja
Sammensatte modeller Nr . 1 Nr . 1 Ja – kan kombineres med DirectQuery- eller Dual-lagringstilstandstabeller Ja – kan kombineres med tabeller i import- eller dual-lagringstilstand
Enkeltlogon (SSO) Ja Ja Ikke relevant Ja
Beregnede tabeller Ja – men beregninger kan ikke referere til kolonner i tabeller i Direct Lake-tilstand. 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 Ja – men beregninger kan ikke referere til kolonner i tabeller i Direct Lake-tilstand. Nej Ja Ja
Hybride tabeller Nej Nej Ja Ja
Partitioner i modeltabel Nej – men partitionering kan udføres på Delta-tabelniveau 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 Nej
Brugerdefinerede sammenlægninger Nej Nej Ja – import af sammenlægningstabeller i DirectQuery-tabeller understøttes Ja
SIKKERHED på objektniveau eller sikkerhed på kolonneniveau for SQL Analytics-slutpunkt Nej Ja – men 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 Nej 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 – men det anbefales på det kraftigste at bruge en fast identitetsskyforbindelse Ja Ja
Sikkerhed på objektniveau for semantisk model (OLS) Ja Ja Ja Ja
Store datamængder uden opdateringskrav Ja Ja Nej Ja
Reducer dataventetid Ja – når automatiske opdateringer er aktiveret, eller programmatisk genfragmentering Ja – når automatiske opdateringer er aktiveret, eller programmatisk genfragmentering Nej Ja
Power BI Embedded Ja 2 Ja 2 Ja Ja

1 Når du bruger Direct Lake på SQL-slutpunkter, kan du ikke kombinere Direct Lake-lagertilstandstabeller med DirectQuery- eller Dual-lagertilstandstabeller 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 identitetsskyforbindelse .

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.

Direct Lake på OneLake er ikke kombineret med SQL-slutpunktet, der giver bedre integration med OneLake-funktioner, f.eks. OneLake-sikkerhed og mere effektive DAX-forespørgselsplaner, fordi det f.eks. ikke er nødvendigt at søge efter SQL-baseret sikkerhed. DirectQuery-fallback understøttes ikke af Direct Lake på OneLake.

Med Direct Lake på SQL-slutpunkter bruger en DAX-forespørgsel muligvis DirectQuery-reserve, hvilket omfatter problemfri skift til DirectQuery-tilstand. DirectQuery-fallback henter data direkte fra SQL Analytics-slutpunktet for lakehouse'et eller lageret. Fallback opstår f.eks., når SQL-baseret sikkerhed registreres i SQL-slutpunktet. 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 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. 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 , 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 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 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 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 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.

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.

Diagram, der viser, 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 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.

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

Når du bruger Direct Lake på SQL-slutpunkter, kan en forespørgsel, der sendes til en semantisk Direct Lake-model, gå tilbage til DirectQuery-tilstand , i hvilket tilfælde tabellen ikke længere fungerer i Direct Lake-tilstand. Den henter data direkte fra SQL Analytics-slutpunktet 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.

Når DirectQuery-fallback opstår, bruger en forespørgsel ikke længere Direct Lake-tilstand. En forespørgsel kan ikke udnytte Direct Lake-tilstand, 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 heller ikke udnytte Direct Lake-tilstand, når en Delta-tabel overskrider kapacitetens gelændere.

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 . Denne indstilling gælder kun for Direct Lake på SQL-slutpunkter. Direct Lake på OneLake understøtter ikke DirectQuery-reserve. Du kan få flere oplysninger under Angiv egenskaben Direct Lake-funktionsmåde.

Datasikkerhed og adgangstilladelser

Direct Lake bruger som standard enkeltlogon (SSO), hvilket betyder, at den identitet, der forespørger den semantiske model (ofte en rapportbruger), skal have tilladelse til at få adgang til dataene. Du kan også binde en Direct Lake-model til en SCC (sharable Cloud Connection) for at angive en fast identitet og deaktivere SSO. I dette tilfælde er det kun den faste identitet, der kræver læseadgang til dataene i kilden.

Tilladelser til stofelement

Semantiske Direct Lake-modeller overholder en lagdelt sikkerhedsmodel. De udfører kontrol af tilladelser for at afgøre, om den identitet, der forsøger at få adgang til dataene, har de nødvendige tilladelser til dataadgang i kildedataelementet og den semantiske model. Tilladelser kan tildeles direkte eller erhverves implicit ved hjælp af arbejdsområderoller i Microsoft Fabric.

Det er vigtigt at vide, at Direct Lake på OneLake og Direct Lake på SQL-slutpunkter udfører tilladelseskontrol anderledes.

  • Direct Lake på OneLake kræver tilladelsen Read og ReadAll på lakehouse/warehouse for at få adgang til Delta-tabeller.
  • Direct Lake på SQL-slutpunkter kræver læse - og ReadData-tilladelser på lakehouse/warehouse for at få adgang til data fra SQL Analytics-slutpunktet.

Seddel

Direct Lake på OneLake kræver, at brugerne har tilladelse til at læse Delta-tabeller i OneLake og ikke nødvendigvis SQL-slutpunktet. Dette gennemtvinger et centraliseret sikkerhedsdesign, hvor OneLake er den eneste kilde til adgangskontrol.

Direct Lake på SQL-slutpunkter kræver på den anden side, at brugerne har læseadgang til SQL-slutpunktet og ikke nødvendigvis til Delta-tabeller i OneLake. Det skyldes, at Fabric giver de nødvendige tilladelser til den semantiske model for at læse Delta-tabellerne og de tilknyttede Parquet-filer (for at indlæse kolonnedata i hukommelsen). Den semantiske model har også de nødvendige tilladelser til jævnligt at læse SQL Analytics-slutpunktet for at udføre kontrol af tilladelser for at bestemme, hvilke data den forespørgselsbruger (eller fast identitet) har adgang til.

Semantiske modeltilladelser

Ud over fabric-elementtilladelser skal du også give tilladelser til brugere, så de kan bruge eller administrere den semantiske Direct Lake-model. Rapportforbrugere skal kort sagt have tilladelsen Læs , og rapportoprettere skal have yderligere tilladelsen Opret . Semantiske modeltilladelser kan tildeles direkte eller erhverves implicit ved hjælp af arbejdsområderoller. Hvis du vil administrere indstillingerne for semantiske modeller (for opdatering og andre konfigurationer), skal du være ejeren af den semantiske model.

Tilladelseskrav

Overvej følgende scenarier og tilladelseskrav.

Scenarie Påkrævede tilladelser Kommentarer
Brugerne kan få vist rapporter Tildel tilladelsen Læs for rapporterne og tilladelsen Læs for den semantiske model.

Hvis den semantiske model bruger Direct Lake på SQL-slutpunkter, og cloudforbindelsen bruger SSO, skal du som minimum tildele tilladelserne Læs og ReadData til lakehouse eller warehouse.

Hvis den semantiske model bruger Direct Lake på OneLake, og cloudforbindelsen bruger SSO, skal du som minimum give tilladelsen Læs og LæsAlle for Delta-tabellerne i OneLake.		 Rapporter behøver ikke at tilhøre det samme arbejdsområde som den semantiske model. Du kan få flere oplysninger under Strategi for skrivebeskyttede forbrugere.
Brugerne kan oprette rapporter Tildel tilladelsen Opret for den semantiske model.

Hvis den semantiske model bruger Direct Lake på SQL-slutpunkter, og cloudforbindelsen bruger SSO, skal du som minimum tildele tilladelserne Læs og ReadData til lakehouse eller warehouse.

Hvis den semantiske model bruger Direct Lake på OneLake, og cloudforbindelsen bruger SSO, skal du som minimum give tilladelsen Læs og LæsAlle for Delta-tabellerne i OneLake.		 Du kan finde flere oplysninger under Strategi for indholdsoprettere.
Brugerne kan få vist rapporter, men de afvises ved at forespørge lakehouse-, SQL Analytics-slutpunktet eller Delta-tabeller i OneLake Tildel tilladelsen Læs for rapporterne og tilladelsen Læs for den semantiske model.

Giv ikke brugere tilladelse til tabellerne lakehouse, warehouse eller Delta.		 Kun egnet, når Direct Lake-modellen bruger en fast identitet via en cloudforbindelse med SSO deaktiveret.
Administrer den semantiske model, herunder opdateringsindstillinger Kræver semantisk modelejerskab. Du kan få flere oplysninger under Semantisk modelejerskab.

Vigtig

Du bør altid teste tilladelserne grundigt, før du frigiver din semantiske model og dine rapporter til produktion.

Du kan få flere oplysninger under Semantiske modeltilladelser.

Krav til strukturkapacitet

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). 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 på disken/OneLake overskrides, medfører det, 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 optimerer dine Delta-tabeller og Direct Lake-semantiske modeller for at undgå at skulle skalere unødigt op til en højere Fabric SKU.

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.

Seddel

Funktionerne og funktionerne i semantiske Direct Lake-modeller udvikler sig hurtigt. Sørg for at vende tilbage med jævne mellemrum for at gennemse den seneste liste over overvejelser og begrænsninger.

Overvejelse/begrænsning Direct Lake on OneLake Direct Lake på SQL (analyseslutpunkt)
Når SQL-analyseslutpunktet gennemtvinger sikkerhed på rækkeniveau, behandles DAX-forespørgsler forskelligt, afhængigt af den anvendte type Direct Lake-tilstand.

Når Direct Lake på OneLake anvendes, lykkes forespørgsler, og SQL-baseret sikkerhed på rækkeniveau anvendes ikke. Direct Lake på OneLake kræver, at brugeren har adgang til filerne i OneLake, som ikke overholder SQL-baseret sikkerhed på rækkeniveau.		 Forespørgslerne lykkes. Ja, medmindre fallback er deaktiveret, og i så fald mislykkes forespørgsler.
Hvis en tabel i den semantiske model er baseret på en (ikke-materialiseret) SQL-visning, behandles DAX-forespørgsler forskelligt, afhængigt af den anvendte type Direct Lake-tilstand.

Direct Lake på SQL-slutpunkter vil falde tilbage på DirectQuery i dette tilfælde.

Det understøttes ikke at oprette en Direct Lake på OneLake-tabel baseret på en ikke-materialiseret SQL-visning. Du kan i stedet bruge en lakehouse-materialiseret visning, fordi der oprettes Delta-tabeller. Du kan også bruge en anden lagringstilstand, f.eks. Import eller DirectLake, til tabeller, der er baseret på ikke-materialiserede SQL-visninger.		 Ikke relevant Ja, medmindre fallback er deaktiveret, og i så fald mislykkes forespørgsler.
Sammensat modellering understøttes ikke på nuværende tidspunkt, hvilket 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). Ikke understøttet Ikke understøttet
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. Ikke understøttet Ikke understøttet
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. Ikke understøttet Ikke understøttet
Tabelrelationer kræver, at datatyperne for relaterede kolonner stemmer overens. Ja Ja
Ensidede kolonner med relationer skal indeholde entydige værdier. Forespørgsler mislykkes, hvis der registreres dubletværdier i en kolonne på én side. Ja Ja
Automatisk dato-/klokkeslætsintelligens i Power BI Desktop for kun at oprette relationer ved hjælp af datodelen af en datetime-kolonne. Bemærk! Markering af din egen datotabel som en datotabel og oprettelse af relationer ved hjælp af datokolonner understøttes. Understøttet Ikke understøttet
Længden af strengkolonneværdier er begrænset til 32.764 Unicode-tegn. Ja Ja
Ikke-numeriske flydende talværdier, f.eks . NaN (ikke et tal), understøttes ikke. Ja Ja
Publicer på internettet fra Power BI ved hjælp af en tjenesteprincipal understøttes kun, når du bruger en fast identitet for den semantiske Direct Lake-model. Ja Ja
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. Ja Ja
På Fabric-portalen viser fanen Direct Lake i opdateringshistorikken Direct Lake-relaterede opdateringsfejl. Vellykkede opdateringshandlinger (indramning) vises normalt ikke, medmindre opdateringsstatussen ændres, f.eks. fra ingen tidligere kørsel eller opdateringsfejl for at opdatere lykkedes eller opdatere succes med advarsel. Ja Ja
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. Ja Ja
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. Ja Ja
Integrering af rapporter kræver et V2-integreringstoken. Ja Ikke understøttet
Tjenesteprincipalprofiler til godkendelse. Ikke understøttet Ikke understøttet
Semantiske Power BI Direct Lake-modeller kan oprettes og forespørges af tjenesteprincipaler og seerrollemedlemskab med tjenesteprincipaler understøttes, men standard semantiske Direct Lake-modeller på lakehouse/warehouse understøtter ikke dette scenarie. Ja Ja
Genveje i et lakehouse kan bruges som datakilder til semantiske modeltabeller. Understøttes ikke under offentlig prøveversion Understøttet
Opret Direct Lake-modeller i personlige arbejdsområder (Mit arbejdsområde). Ikke understøttet Ikke understøttet
Regler for udrulningspipeline for at genoprette datakilden. Ikke understøttet Understøttet

Relateret indhold