Obs!
Tilgang til denne siden krever autorisasjon. Du kan prøve å logge på eller endre kataloger.
Tilgang til denne siden krever autorisasjon. Du kan prøve å endre kataloger.
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 er lagret i OneLake – det eneste lageret for alle analysedata. Når den er lastet inn i minnet, aktiverer den semantiske modellen interaktiv analyse med høy ytelse.
Direct Lake er ideell for semantiske modeller som kobler til store Fabric lakehouses, varehus og andre kilder med Delta-tabeller, spesielt når replikering av hele datavolumet til en importmodell er utfordrende eller umulig. Direct Lake-spørringer behandles, som importmodus, av VertiPaq-spørringsmotoren, mens DirectQuery samler spørringer til den underliggende datakilden. Dette betyr at Direct Lake-spørringer, for eksempel importmodus, vanligvis overgår DirectQuery.
En Direct Lake skiller seg imidlertid fra en importmodus på en viktig måte: En oppdateringsoperasjon for en semantisk direct lake-modell er imidlertid helt forskjellig fra en oppdateringsoperasjon for en semantisk importmodell. Importmodus replikerer dataene og oppretter en hel hurtigbufret kopi av dataene for den semantiske modellen, mens en Direct Lake-oppdatering bare kopierer metadata (kjent som innramming, beskrevet senere i denne artikkelen), noe som kan ta noen sekunder å fullføre. Direct Lake-oppdateringen er en rimelig operasjon som analyserer metadataene til den nyeste versjonen av Delta-tabellene og oppdateres for å referere til de nyeste filene i OneLake. For en importoppdatering produserer derimot en kopi av dataene, noe som kan ta lang tid og bruke betydelige datakilde- og kapasitetsressurser (minne og CPU). Direct Lake flytter dataforberedelser til OneLake og bruker dermed hele bredden av Fabric-teknologier for dataforberedelser, inkludert Spark-jobber, T-SQL DML-setninger, dataflyter, datasamlebånd og mer.
Direct Lake-lagringsmodus gir følgende viktige fordeler:
- I likhet med importmodus behandles Direct Lake-spørringer av VertiPaq-motoren, og gir dermed spørringsytelse som kan sammenlignes med importmodus uten administrasjonskostnadene for dataoppdateringssykluser for å laste inn hele datavolumet.
- Bruker eksisterende Fabric-investeringer ved sømløst å integrere med store innsjøer, varehus og andre Fabric-kilder med Delta-tabeller. Direct Lake er for eksempel et ideelt valg for gullanalyselaget i medaljongsjøens arkitektur.
- Maksimerer avkastning på investering (AVKASTNING) fordi analyserte datavolumer kan overskride kapasitetens maksimale minnegrenser, siden bare dataene som kreves for å svare på en spørring, lastes inn i minnet.
- Minimerer dataventefrekvenser ved raskt og automatisk synkronisering av en semantisk modell med kildene, noe som gjør nye data tilgjengelige for forretningsbrukere uten oppdateringsplaner.
Når bør du bruke Direct Lake-lagringsmodus?
Det primære brukstilfellet for Direct Lake-lagringsmodus er vanligvis for IT-drevne analyseprosjekter som bruker innsjøsentriske arkitekturer. I slike scenarier 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.
Notat
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 noen overføringsinnsats, noe som lar deg realisere mange av fordelene med Fabric som er gjort tilgjengelig for import av semantiske modellbrukere, for eksempel integrering med lakehouses gjennom snarveier, SQL-spørringer, notatblokker og mer. Vi anbefaler dette alternativet som en rask måte å høste fordelene av Fabric uten nødvendigvis eller umiddelbart å redesigne eksisterende datalager og / eller analysesystem.
Direct Lake avhenger 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, datasamlebånd og andre, noe som bidrar til å sikre at dataforberedelseslogikk utføres oppstrøms i arkitekturen for å maksimere gjenbrukbarheten. Hvis den semantiske modellforfatteren ikke har mulighet til å endre kildeelementet, for eksempel hvis en selvbetjent analytiker ikke har skrivetillatelser på et lakehouse som administreres av IT, kan det være et godt valg å utvide modellen med importlagringsmodustabeller, siden importmodus støtter klargjøring av data ved hjelp av Power Query, som er definert som en del av semantisk modell.
Pass på å vurdere gjeldende fabric kapasitet lisens og Fabric kapasitet rekkverk 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.
Nøkkelkonsepter og terminologi
Denne artikkelen forutsetter kjennskap til følgende konsepter:
- Brukere samhandler med visualobjekter i Power BI-rapporter, som genererer DAX-spørringer til den semantiske modellen.
-
Lagringsmodus: Den semantiske modellen behandler DAX-spørringene forskjellig avhengig av lagringsmodusen som brukes. Eksempel:
- Lagringsmoduser for Import og Direct Lake bruker VertiPaq-motoren til å behandle DAX-spørringer og returnere resultater til Power BI-rapporten og -brukeren.
- DirectQuery oversetter derimot DAX-spørringer til spørringssyntaksen for datakilden (vanligvis en form for SQL) og gir dem til den underliggende databasen. Kildedatabasespørringsprosessorer er ofte ikke rettet mot BI-stil, aggregerte spørringer og resulterer derfor i langsommere ytelse og redusert brukerinteraktivitet sammenlignet med import- og Direct Lake-moduser.
Lagringsmodus er en egenskap for en tabell i den semantiske modellen. Når en semantisk modell inneholder tabeller med ulike lagringsmoduser, kalles den en sammensatt modell. Hvis du vil ha mer informasjon om lagringsmoduser, kan du se Semantiske modellmoduser i Power BI-tjenesten.
Direct Lake-modus kan bruke to forskjellige tilgangsmetoder:
- Direct Lake på OneLake er ikke avhengig av SQL-endepunkter og kan bruke data fra en hvilken som helst Fabric-datakilde med Delta-tabeller. Direct Lake på OneLake faller ikke tilbake til DirectQuery-modus.
Notat
Direct Lake på OneLake er for tiden i offentlig forhåndsvisning.
- Direct Lake på SQL-endepunkter bruker SQL-endepunktet til et fabric lakehouse eller lager for Delta-tabelloppdagelse og tillatelseskontroller. Direct Lake på SQL-endepunkter kan falle tilbake til DirectQuery-modus når de ikke kan laste inn dataene direkte fra en Delta-tabell, for eksempel når datakilden er en SQL-visning eller når Lageret bruker SQL-basert sikkerhet på radnivå (RLS). Direct Lake på SQL-endepunkter er generelt tilgjengelig og støttes fullt ut i produksjon.
Sammenligning av lagringsmoduser
Tabellen nedenfor sammenligner Lagringsmodus for Direct Lake med lagringsmodus for Import og DirectQuery.
| Evne | Direct Lake på OneLake | Direct Lake på SQL-endepunkter | Importere | DirectQuery |
|---|---|---|---|---|
| Lisensiering | Bare abonnement på stoffkapasitet (SKU-er) | 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 | Tabeller for alle Fabric-datakilder støttet av Delta-tabeller | Bare lakehouse- eller lagertabeller (eller utsikt) | Alle koblinger | Alle koblinger som støtter DirectQuery-modus |
| Koble til endepunktvisninger for SQL-analyse | Nei | Ja – men vil automatisk falle tilbake til DirectQuery-modus | Ja | Ja |
| Sammensatte modeller | Nr . 1 | 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 | Ja | Ikke aktuelt | Ja |
| Beregnede tabeller | Ja – men beregninger kan ikke referere til kolonner med tabeller i Direct Lake-modus. | 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 | Ja – men beregninger kan ikke referere til kolonner med tabeller i Direct Lake-modus. | Nei | Ja | Ja |
| Hybridtabeller | Nei | Nei | Ja | Ja |
| Modelltabellpartisjoner | Nei – men partisjonering kan gjøres på Delta-tabellnivå | Nei – men partisjonering kan gjøres på Delta-tabellnivå | Ja – enten automatisk opprettet av trinnvis oppdatering, eller manuelt opprettet ved hjelp av XMLA-endepunktet | Nei |
| Brukerdefinerte aggregasjoner | Nei | Nei | Ja – Importer aggregasjonstabeller i DirectQuery-tabeller støttes | Ja |
| Sikkerhet på objektnivå på SQL-analysenivå eller sikkerhet på kolonnenivå | Nei | Ja – men kan gi 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) | Nei | 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 – men det anbefales på det sterkeste å bruke en fast identitetsskytilkobling | Ja | Ja |
| Sikkerhet på objektnivå for semantisk modell (OLS) | Ja | Ja | Ja | Ja |
| Store datavolumer uten oppdateringskrav | Ja | Ja | Nei | Ja |
| Redusere ventetid for data | Ja – når automatiske oppdateringer er aktivert, eller programmatisk reframing | Ja – når automatiske oppdateringer er aktivert, eller programmatisk reframing | Nei | Ja |
| Power BI Embedded | Ja 2 | Ja 2 | Ja | Ja |
1 Når du bruker Direct Lake på SQL-endepunkter, kan du 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.
2 Krever et innebyggingstoken for V2. Hvis du bruker en tjenestekontohaver, må du bruke en fast identitetsskytilkobling .
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.
Direct Lake på OneLake er ikke kombinert med SQL-endepunktet, og tilbyr tettere integrasjon med OneLake-funksjoner som OneLake-sikkerhet og mer effektive DAX-spørringsplaner fordi det for eksempel ikke er nødvendig å se etter SQL-basert sikkerhet. DirectQuery-tilbakefall støttes ikke av Direct Lake på OneLake.
Med Direct Lake på SQL-endepunkter kan en DAX-spørring bruke DirectQuery-tilbakefall, som innebærer sømløs bytte til DirectQuery-modus. DirectQuery-tilbakefall henter data direkte fra SQL Analytics-endepunktet til lakehouse eller lageret. For eksempel oppstår tilbakefall når SQL-basert sikkerhet oppdages i SQL-endepunktet. I dette tilfellet sender en DirectQuery-operasjon en spørring til endepunktet for SQL-analyse. Tilbakefallsoperasjoner kan føre til langsommere spørringsytelse.
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. Alle kolonner som brukes direkte av spørringen, er nødvendig, og også kolonner som kreves av relasjoner og mål. Vanligvis er antall kolonner som kreves for å produsere et spørringsresultat, betydelig mindre enn antall kolonner som er definert i den semantiske modellen.
Når den forstår 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 rask operasjon, men det kan avhenge av faktorer som kardinaliteten til data som er lagret i kolonnene.
Kolonner som lastes inn i minnet, 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 ble oppdatert etter en deltatabelloppdatering ved kilden (se Innramming i neste del).
- Ingen spørring brukte 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 utløst 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 skjer, kan det hende at segmenter og ordlister for bosatt tabell utestenger fra minnet hvis de underliggende dataene er endret 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.
Den semantiske modellen analyserer Delta-loggen for hver Delta-tabell under innramming for å slippe bare de berørte kolonnesegmentene og laste inn nylig tilføyde data under transkoding. En viktig optimalisering er at ordlister vanligvis ikke vil bli fjernet når trinnvis innramming trer i kraft, og nye verdier legges til i de eksisterende ordlistene. Denne trinnvise innrammingstilnærmingen bidrar til å redusere belastningen og ytelsen til fordelsspørringen. I det ideelle tilfellet, når en Delta-tabell ikke mottok noen oppdateringer, er det ikke nødvendig å laste inn på nytt for kolonner som allerede er bosatt i minnet, og spørringer viser langt mindre ytelsespåvirkning etter innramming fordi trinnvis innramming i hovedsak gjør det mulig for den semantiske modellen å oppdatere betydelige deler av de eksisterende minnedataene på plass.
Diagrammet nedenfor viser hvordan Direct Lake-innramming fungerer.
Diagrammet viser følgende prosesser og funksjoner.
| Vare | Beskrivelse |
|---|---|
|
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.
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
Når du bruker Direct Lake på SQL-endepunkter, kan en spørring som sendes til en semantisk direct lake-modell, falle tilbake til DirectQuery-modus i så fall at tabellen ikke lenger fungerer i Direct Lake-modus. Den henter data direkte fra SQL Analytics-endepunktet i lakehouse eller warehouse. Slike spørringer returnerer alltid de nyeste dataene fordi de ikke er begrenset til tidspunktet for den siste innrammingsoperasjonen.
Når DirectQuery-tilbakefall oppstår, bruker en spørring ikke lenger Direct Lake-modus. En spørring kan ikke dra nytte av Direct Lake-modus 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 heller ikke dra nytte av Direct Lake-modus når en Delta-tabell 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 . Denne innstillingen gjelder bare for Direct Lake på SQL-endepunkter. Direct Lake på OneLake støtter ikke DirectQuery-tilbakefall. Hvis du vil ha mer informasjon, kan du se Angi virkemåten for Direct Lake.
Datasikkerhet og tilgangstillatelser
Som standard bruker Direct Lake enkel pålogging (SSO), noe som betyr at identiteten som spør den semantiske modellen (ofte en rapportbruker) må ha tillatelse til å få tilgang til dataene. Alternativt kan du binde en Direct Lake-modell til en delbar skytilkobling (SCC) for å gi en fast identitet og deaktivere SSO. I dette tilfellet krever bare den faste identiteten lesetilgang til dataene i kilden.
Tillatelser for stoffelement
Direct Lake semantiske modeller holder seg til en lagdelt sikkerhetsmodell. De utfører tillatelseskontroller for å finne ut om identiteten som forsøker å få tilgang til dataene, har de nødvendige datatilgangstillatelsene i kildedataelementet og den semantiske modellen. Tillatelser kan tilordnes direkte eller anskaffes implisitt ved hjelp av arbeidsområderoller i Microsoft Fabric.
Det er viktig å vite at Direct Lake på OneLake og Direct Lake på SQL-endepunkter utfører tillatelseskontroller annerledes.
- Direct Lake på OneLake krever Lese- og ReadAll-tillatelser på lakehouse/warehouse for å få tilgang til Delta-tabeller.
- Direct Lake på SQL-endepunkter krever lese- og ReadData-tillatelser på lakehouse/warehouse for å få tilgang til data fra SQL Analytics-endepunktet.
Notat
Direct Lake på OneLake krever at brukere har tillatelse til å lese Delta-tabeller i OneLake og ikke nødvendigvis SQL-endepunktet. Dette håndhever en sentralisert sikkerhetsutforming der OneLake er den eneste tilgangskontrollkilden.
Direct Lake på SQL-endepunkter krever derimot at brukere har lesetilgang til SQL-endepunktet og ikke nødvendigvis til Delta-tabeller i OneLake. Det er fordi Fabric gir de nødvendige tillatelsene til den semantiske modellen for å lese Delta-tabellene og tilknyttede Parquet-filer (for å laste inn kolonnedata i minnet). Den semantiske modellen har også de nødvendige tillatelsene til regelmessig å lese SQL Analytics-endepunktet for å utføre tillatelseskontroller for å finne ut hvilke data spørringsbrukeren (eller fast identitet) har tilgang til.
Semantiske modelltillatelser
I tillegg til fabric-elementtillatelser må du også gi tillatelser til brukere slik at de kan bruke eller administrere semantisk direct lake-modell. Kort sagt, rapportforbrukere trenger lesetillatelse , og rapportopprettere trenger ekstra kompileringstillatelse . Semantiske modelltillatelser kan tilordnes direkte eller anskaffes implisitt ved hjelp av arbeidsområderoller. Hvis du vil administrere semantiske modellinnstillinger (for oppdatering og andre konfigurasjoner), må du være semantisk modelleier.
Tillatelseskrav
Vurder følgende scenarioer og tillatelseskrav.
| Scenario | Nødvendige tillatelser | Kommentarer |
|---|---|---|
| Brukere kan vise rapporter | Gi lesetillatelse for rapportene og lesetillatelsen for semantisk modell. Hvis den semantiske modellen bruker Direct Lake på SQL-endepunkter og skytilkoblingen bruker SSO, kan du gi minst Lese - og ReadData-tillatelser for lakehouse eller lageret. Hvis den semantiske modellen bruker Direct Lake på OneLake og skytilkoblingen bruker SSO, kan du gi minst Lese - og ReadAll-tillatelse for Delta-tabellene i OneLake. |
Rapporter trenger ikke å tilhøre samme arbeidsområde som den semantiske modellen. Hvis du vil ha mer informasjon, kan du se Strategi for skrivebeskyttede forbrukere. |
| Brukere kan opprette rapporter | Gi kompileringstillatelse for semantisk modell. Hvis den semantiske modellen bruker Direct Lake på SQL-endepunkter og skytilkoblingen bruker SSO, kan du gi minst Lese - og ReadData-tillatelser for lakehouse eller lageret. Hvis den semantiske modellen bruker Direct Lake på OneLake og skytilkoblingen bruker SSO, kan du gi minst Lese - og ReadAll-tillatelse for Delta-tabellene i OneLake. |
Hvis du vil ha mer informasjon, kan du se Strategi for innholdsopprettere. |
| Brukere kan vise rapporter, men blir nektet å spørre lakehouse-, SQL Analytics-endepunktet eller Delta-tabellene i OneLake | Gi lesetillatelse for rapportene og lesetillatelsen for semantisk modell. Ikke gi brukerne tillatelse til lakehouse-, lager- eller Delta-tabellene. |
Bare egnet når Direct Lake-modellen bruker en fast identitet gjennom en skytilkobling med SSO deaktivert. |
| Administrere semantisk modell, inkludert oppdateringsinnstillinger | Krever semantisk modelleierskap. | Hvis du vil ha mer informasjon, kan du se Semantic-modelleierskap. |
Viktig
Du bør alltid teste tillatelsene grundig før du slipper semantisk modell og rapporter i produksjon.
Hvis du vil ha mer informasjon, kan du se semantiske modelltillatelser.
Krav til 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). 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, fører den maksimale modellstørrelsen på disk/OneLake 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.
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.
Notat
Funksjonene og funksjonene til Semantiske modeller i Direct Lake utvikler seg raskt. Pass på å sjekke tilbake med jevne mellomrom for å se gjennom den nyeste listen over hensyn og begrensninger.
| Vurdering/begrensning | Direct Lake på OneLake | Direct Lake på SQL (analyseendepunkt) |
|---|---|---|
| Når SQL Analytics-endepunktet håndhever sikkerhet på radnivå, behandles DAX-spørringer på en annen måte avhengig av hvilken type Direct Lake-modus som brukes. Når Direct Lake på OneLake brukes, vil spørringer lykkes, og SQL-basert RLS brukes ikke. Direct Lake på OneLake krever at brukeren har tilgang til filene i OneLake, som ikke observerer SQL-baserte RLS. |
Spørringer vil lykkes. | Ja, med mindre tilbakefall er deaktivert i så fall vil spørringer mislykkes. |
| Hvis en tabell i den semantiske modellen er basert på en (ikke-materialisert) SQL-visning, behandles DAX-spørringer forskjellig avhengig av hvilken type Direct Lake-modus som brukes. Direct Lake på SQL-endepunkter vil falle tilbake til DirectQuery i dette tilfellet. Det støttes ikke for å opprette en Direct Lake på OneLake-tabell basert på en ikke-materialisert SQL-visning. Du kan i stedet bruke en materialisert visning i lakehouse fordi Delta-tabeller opprettes. Du kan også bruke en annen lagringsmodus, for eksempel Importer eller DirectLake for tabeller basert på ikke-materialiserte SQL-visninger. |
Ikke aktuelt | Ja, med mindre tilbakefall er deaktivert i så fall vil spørringer mislykkes. |
| Sammensatt modellering støttes ikke for øyeblikket, noe som betyr at semantiske tabeller i Direct Lake ikke kan blandes med tabeller i andre lagringsmoduser, for eksempel Import, DirectQuery eller Dual (bortsett fra spesielle tilfeller, inkludert beregningsgrupper, hva-skjer-hvis-parametere og feltparametere). | Støttes ikke | Støttes ikke |
| 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. | Støttes ikke | Støttes ikke |
| 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. | Støttes ikke | Støttes ikke |
| Tabellrelasjoner krever at datatypene for relaterte kolonner samsvarer. | Ja | Ja |
| Kolonner på én side av relasjoner må inneholde unike verdier. Spørringer mislykkes hvis dupliserte verdier oppdages i en kolonne på én side. | Ja | Ja |
| Automatisk informasjon om dato/klokkeslett i Power BI Desktop for å opprette relasjoner ved hjelp av bare datodelen av en datetime-kolonne. Obs! Merking av din egen datotabell som en datotabell og oppretting av relasjoner ved hjelp av datokolonner støttes. | Støttes | Støttes ikke |
| Lengden på strengkolonneverdier er begrenset til 32 764 Unicode-tegn. | Ja | Ja |
| Ikke-numeriske flyttallsverdier, for eksempel NaN (ikke et tall), støttes ikke. | Ja | Ja |
| Publiser på nett fra Power BI ved hjelp av en tjenestekontohaver støttes bare når du bruker en fast identitet for semantisk Direct Lake-modell. | Ja | Ja |
| 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. | Ja | Ja |
| I Fabric-portalen viser Direct Lake-fanen i oppdateringsloggen direkte lake-relaterte oppdateringsfeil. Vellykkede oppdateringsoperasjoner (innramming) er vanligvis ikke oppført med mindre oppdateringsstatusen endres, for eksempel fra ingen tidligere kjøring eller oppdateringsfeil for å oppdatere vellykket eller oppdatere vellykket med advarsel. | Ja | Ja |
| 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. | Ja | Ja |
| 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. | Ja | Ja |
| Innebygging av rapporter krever et V2-innebyggingstoken. | Ja | Støttes ikke |
| Tjenestekontohaverprofiler for godkjenning. | Støttes ikke | Støttes ikke |
| Semantiske modeller for Power BI Direct Lake kan opprettes og spørres av tjenestekontohavere og seerrollemedlemskap med tjenestekontohavere støttes, men standard semantiske modeller for Direct Lake på lakehouse/warehouse støtter ikke dette scenarioet. | Ja | Ja |
| Snarveier i et lakehouse kan brukes som datakilder for semantiske modelltabeller. | Støttes ikke under offentlig forhåndsvisning | Støttes |
| Opprett Direct Lake-modeller i personlige arbeidsområder (Mitt arbeidsområde). | Støttes ikke | Støttes ikke |
| Distribusjonssamlebåndregler for å binde inn datakilden på nytt. | Støttes ikke | Støttes |