Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Direct Lake er en Power BI semantisk model tabellagringsmodus, der findes i Microsoft Fabric. Den er optimeret til store datamængder, der hurtigt kan indlæses i hukommelsen fra Delta-tabeller , der er tilgængelige i OneLake – den eneste butik for alle analysedata. Når den semantiske model er indlæst i hukommelsen, muliggør den højtydende interaktiv analyse.
Direct Lake er ideelt til semantiske modeller, der forbinder til store Fabric-lakehuse, lagre og andre Fabric-datakilder med Delta-tabeller. Direct Lake er især nyttigt, når det er upraktisk eller umuligt at replikere hele datavolumen i en importtabel. Direct Lake- og Import-forespørgsler behandles af VertiPaq-forespørgselsmotoren, mens DirectQuery fødererer forespørgsler til den underliggende datakilde. Direct Lake- og Import-forespørgsler overgår normalt DirectQuery-forespørgsler, når de indlæser og interagerer med visualiseringer i rapporter.
Dog adskiller Direct Lake sig fra Import-tilstand på en vigtig måde: en opdateringsoperation for en Direct Lake-semantisk model adskiller sig konceptuelt fra en opdateringsoperation for en Import-semantisk model. 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. Direct Lake-opdateringen er en lavprisoperation, der analyserer metadata fra den nyeste version af Delta-tabellerne og opdaterer referencer til de nyeste filer i OneLake. Til sammenligning producerer en importopdatering en kopi af dataene, hvilket kan tage betydelig tid og forbruge betydelige datakilde- og kapacitetsressourcer (hukommelse og CPU). Direct Lake flytter dataforberedelsen til OneLake og udnytter dermed hele bredden af Fabric-teknologier til dataforberedelse, herunder Spark-jobs, T-SQL DML-sætninger, dataflows, pipelines og mere.
Direct Lake-lagringstilstand giver følgende vigtige fordele:
- Ligesom i Import-tilstand behandles Direct Lake-forespørgsler af VertiPaq-motoren og leverer derfor forespørgselsydelse, der kan sammenlignes med Import-tilstand, uden administrationsomkostningerne ved dataopdateringscyklusser for at indlæse hele datavolumen.
- Bruger eksisterende Fabric-investeringer ved sømløst at integrere med store søhuse, lagre og andre Fabric-kilder med Delta-borde. Direct Lake er f.eks. et ideelt valg til guldanalyselaget i medaljonens lakehouse-arkitektur.
- Maksimerer investeringsafkastet (ROI), fordi analyserede datavolumer kan overskride kapacitetens maksimale hukommelsesgrænser, da kun de data, der er nødvendige for at besvare en forespørgsel, 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.
Drikkepenge
Direct Lake-ydelsen afhænger af velafstemte Delta-tabeller. For omfattende vejledning i optimering af tabeller til Direct Lake-forbrug, inklusive V-Order og anbefalinger til rækkegrupper, se Cross-workload table maintenance and optimization.
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
Import- og DirectQuery-tabeller i semantiske modeller er stadig relevante i Fabric, og de er det rigtige valg af semantisk model i 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.
En semantisk model med importtabeller og Direct Lake-tabeller tilbyder den skala og fleksibilitet, der er nødvendig for mange BI-scenarier.
Desuden skriver OneLake-integration automatisk data til tabeller i Import-lagringstilstand til Delta-tabeller i OneLake uden at involvere nogen migrationsindsats, hvilket giver dig mulighed for at udnytte mange af fordelene ved Fabric, der stilles til rådighed for brugere af Import semantic model, såsom integration med lakehouses via genveje, SQL-forespørgsler, notesbøger og mere. Vi anbefaler denne mulighed som en hurtig måde at høste fordelene ved Fabric uden nødvendigvis eller straks at skulle redesigne dit eksisterende datalager 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, såsom Spark-jobs til Fabric lakehouses, T-SQL DML statements til Fabric warehouses, dataflows, pipelines og andre, hvilket hjælper med at sikre, at dataforberedelseslogik udføres opstrøms i arkitekturen for at maksimere genanvendelighed. Men hvis den semantiske modelforfatter ikke har mulighed for at ændre kildeelementet, for eksempel hvis en selvbetjeningsanalytiker ikke har skrivetilladelser på et lakehouse, der administreres af IT, kan det være en god idé at udvide modellen med Import storage mode-tabeller, fordi Import mode understøtter dataforberedelse ved brug af Power Query, som er defineret som en del af den semantiske model.
Sørg for at overveje din nuværende Fabric kapacitetslicens og Fabric kapacitetsrækværket 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:
Brugere indlæser og interagerer med visualiseringer i Power BI-rapporter, der genererer DAX-forespørgsler til den semantiske model.
Lagringstilstand: Den semantiske model behandler DAX-forespørgslerne forskelligt, afhængigt af den anvendte tabellagringstilstand. Eksempel:
- Import- og Direct Lake-lagringstilstande bruger VertiPaq-motoren til at behandle DAX-forespørgsler og returnere resultater til Power BI-rapporten og brugeren.
- DirectQuery oversætter DAX-forespørgsler til forespørgselssyntaksen for datakilden, f.eks. en SQL-forespørgsel, og kører dem på den underliggende kildedatabase. Disse kildedatabaser er typisk ikke optimeret til tung forespørgselsbelastning, der kommer fra rapporter og aggregerede forespørgsler, der er nødvendige for visualiseringerne, og kan resultere i langsommere ydeevne sammenlignet med Import- og Direct Lake-tilstande.
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. For mere information om lagringstilstande, se Semantiske modeltilstande i Power BI-tjeneste.
Direct Lake-bordlagringstilstand har to muligheder:
Direct Lake på OneLake kan bruge data fra en eller flere Fabric datakilder med Delta-tabeller. Direct Lake på OneLake falder ikke tilbage til DirectQuery-tilstand via datakildens SQL-analyseslutpunkt. Semantiske modeller med Direct Lake på OneLake-tabeller kan også have Import-tabeller tilføjet fra andre datakilder.
Direct Lake på SQL kan bruge data fra en enkelt Fabric datakilde med Delta-tabeller. SQL analytics-endpointet bruges til opdagelse og tilladelsestjek af Delta-tabeller og SQL-visninger. Direct Lake på SQL-endpoints falder tilbage til DirectQuery-tabellagringstilstand, når den ikke kan indlæse data direkte fra en Delta-tabel, for eksempel når datakilden er en SQL-visning eller når lageret bruger SQL-baseret granulær adgangskontrol. Den semantiske model-egenskab, Direct Lake-adfærd, styrer fallback-adfærden.
Sammenligning af lagringstilstande
I følgende tabel sammenlignes Lagringstilstanden Direct Lake med lagringstilstanden Import og DirectQuery.
| Kapacitet | Direkte sø på OneLake | Direct Lake på SQL-slutpunkter | Importér | DirectQuery |
|---|---|---|---|---|
| Licenser | Fabric kapacitetsabonnement (SKU'er) kun | Fabric kapacitetsabonnement (SKU'er) kun | Enhver Fabric- eller Power BI-licens (inklusive Microsoft Fabric Free-licenser) | Enhver Fabric- eller Power BI-licens (inklusive Microsoft Fabric Free-licenser) |
| Datakilde | Tabeller over enhver Fabric-datakilde understøttet 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 | Ja – kan kombineres med Import Storage mode-tabeller i Power BI webmodellering og DirectQuery-tabeller med XMLA-værktøjer. | Nr . 1 | Ja – kan kombineres med tabeller i DirectQuery-, Dual- og Direct Lake-lagringstilstand | Ja – kan kombineres med import-, Dual- og Direct Lake-lagringstilstandstabeller |
| 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 | Nej | 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 Direct Lake semantisk model og derefter udvide den med nye tabeller (ved at bruge import, DirectQuery eller Dual storage mode) 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 .
For detaljer om, hvordan Direct Lake fungerer, herunder kolonneindlæsning (transkodning), indramning, automatiske opdateringer og DirectQuery-fallback, se Hvordan Direct Lake fungerer.
For detaljer om tilladelser, autentificering, OLS/RLS og dataadgangsregelmuligheder, se Integrér Direct Lake sikkerhed.
Fabric kapacitetskrav
Direct Lake semantiske modeller kræver en Fabric kapacitetslicens. Derudover er der kapacitetsgarantier og begrænsninger, der gælder for dit Fabric-kapacitetsabonnement (SKU), som vist i tabellen nedenfor.
Vigtig
Den første kolonne i den følgende tabel inkluderer også Power BI Premium-kapacitetsabonnementer (P SKUs). Microsoft konsoliderer købsmulighederne og pensionerer Power BI Premium pr. kapacitet-SKU'erne. Nye og eksisterende kunder bør overveje at købe Fabric-kapacitetsabonnementer (F SKU'er) i stedet.
For mere information, se Vigtig opdatering på vej til Power BI Premium-licensering og Power BI Premium.
| Fabric 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. Af denne grund er det ikke et sikkerhedsrækværk; dog kan det påvirke ydeevnen, hvis mængden af data er stor nok til at forårsage overdreven paging ind og ud af modeldataene fra OneLake-dataene.
Hvis sikringsgrænserne overskrides, afhænger adfærden af tabellagringstilstanden:
- Direct Lake på OneLake: Ligesom i Import-tilstand fejler opdateringen, og modellen kan ikke forespørges, før Delta-tabellerne er optimeret til at ligge inden for sikkerhedsgrænserne.
- Direct Lake på SQL:Falder tilbage til DirectQuery-tilstand , hvis fallback er aktiveret. Opfriskning lykkes med en advarsel, og forespørgsler returnerer stadig resultater, men med langsommere ydeevne.
Maksimal modelstørrelse på disk/OneLake-rækværket evalueres på modelniveau og påvirker alle forespørgsler. 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 semantisk model for at undgå unødvendigt at skalere 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
Direkte Lake-semantiske modeller har 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 | Direkte sø på 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 følger SQL-baseret RLS. |
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 falder tilbage til 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. Alternativt kan du bruge en anden lagringstilstand som Import eller Direct Lake til tabeller baseret på ikke-materialiserede SQL-visninger. |
Ikke relevant | Ja, medmindre fallback er deaktiveret, og i så fald mislykkes forespørgsler. |
| Sammensat modellering, hvilket betyder, at semantiske Direct Lake-modeltabeller 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). | Understøttet | Ikke understøttet |
| Beregnede kolonner og beregnede tabeller, der refererer til kolonner eller tabeller i Direct Lake-lagringstilstand. Beregningsgrupper, hvad nu hvis-parametre og feltparametre, der implicit opretter beregnede tabeller, og beregnede tabeller, der ikke refererer til Direct Lake-kolonner eller -tabeller, understøttes i alle scenarier. | 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 |
| Auto dato/tidsintelligens i Power BI Desktop til at oprette relationer ved kun at bruge datodelen af en dato-tid-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 |
| Publish to web from Power BI ved brug af en service principal understøttes kun, når man bruger en fixed identitet for Direct Lake semantic 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 |
| I 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 maksimalt tilgængelige hukommelse ifølge Direct Lake-semantisk 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. For at finde ud af, hvilken region du befinder dig i, se find din Fabric hjemregion. | Ja | Ja En løsning er at oprette et søhus i den anden regions arbejdsområde og genveje til tabellerne, før man opretter den semantiske model. |
| Integrering af rapporter kræver et V2-integreringstoken. | Ja | Ja |
| Tjenesteprincipalprofiler til godkendelse. | Ikke understøttet | Ikke understøttet |
| Power BI Direct Lake semantiske modeller kan oprettes og forespørges af Service Principals, og medlemskab af Viewer-roller med service principals understøttes, men de standard Direct Lake-semantiske modeller på lakehouse/warehouse understøtter ikke dette scenarie. | Ja | Ja |
| Genveje i et lakehouse kan bruges som datakilder til semantiske modeltabeller. | Understøttet | 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 direkte – kan oprette et parameterudtryk til brug i forbindelsesstreng. | Understøttet |
| Tilføjelse af flere tabeller fra den samme datakildetabel. | Understøttes ikke i Power BI Desktop eller webmodellering. Det er muligt at tilføje flere tabeller fra den samme datakildetabel ved hjælp af XMLA-baserede eksterne værktøjer. Brug af Rediger tabeller i Power BI værktøjer og refresh resulterer i en fejl med flere tabeller fra samme datakildetabel i den semantiske model. | Understøttes ikke i Power BI Desktop eller webmodellering. Det er muligt at tilføje flere tabeller fra den samme datakildetabel ved hjælp af XMLA-baserede eksterne værktøjer. Brug af Rediger tabeller i Power BI værktøjer og refresh resulterer i en fejl med flere tabeller fra samme datakildetabel i den semantiske model. |
| Direct Lake-tabeller oprettet ved brug af XMLA-applikationer er i starten i en ubehandlet tilstand, indtil applikationen sender en opdateringskommando. Sørg for at opdatere modellen til at behandle dens tabeller, når du opretter en ny semantisk model. | Forespørgsler, der involverer ubehandlede tabeller, returnerer en fejl. | Forespørgsler med ubehandlede tabeller falder tilbage til DirectQuery-tilstand, medmindre fallback deaktiveres, i hvilket tilfælde forespørgsler fejler. |
XMLA-kompatible værktøjer skal understøtte compatibilityLevel 1604 eller højere for at arbejde med Direct Lake-semantiske modeller og eksponere Direct Lake-specifikke metadata. |
Ja | Ja |
Analyse i Excel pivottabeller (og andre MDX-klienter) har de samme begrænsninger som DirectQuery med Direct Lake-tabeller i den semantiske model. MDX-sætninger med sessionsomfang, f.eks. navngivne sæt, beregnede medlemmer, standardmedlemmer osv., understøttes ikke. MDX-sætninger med forespørgselsomfang, f.eks. "WITH"-delsætningen, understøttes. Brugerdefinerede hierarkier i Direct Lake-tabel understøttes ikke. Brugerdefinerede hierarkier i importtabeller understøttes selv med Direct Lake-tabeller i den semantiske model.
Power BI Desktop kan live redigere en semantisk model med Direct Lake-tabeller og import-tabeller. Beregningsgrupper, hvad-nu-hvis-parametre og feltparametre, der implicit opretter beregnede tabeller, og beregnede tabeller, der ikke refererer til Direct Lake-kolonner eller -tabeller, kan også medtages.
Power BI-webmodellering kan åbne enhver semantisk model, inklusive Direct Lake-tabeller med andre lagringsmode-tabeller.
DAX-forespørgselsvisning ved live-redigering eller live-forbindelse samt ved skrivning af DAX-forespørgsler på nettet understøttes for Direct Lake på SQL, Direct Lake på OneLake og ægte sammensatte (Direct Lake på OneLake + import fra enhver datakilde) semantiske modeller.
TMDL-visning understøttes ved live-redigering i Power BI Desktop.
Oprettelse af rapporter med en direkte forbindelse understøttes for alle semantiske modeller, når rapportforfatteren som minimum har buildadgang.
Direct Lake på SQL-forbindelsesudtrykket i den semantiske model skal referere til SQL-analyse-endpointet med GUID, ikke med et venligt navn, for at bruge Edit-tabeller og refresh-operationer i Power BI Desktop og Power BI webmodellering. Forbindelsesudtrykket kan opdateres i TMDL-visning eller XMLA-baserede eksterne værktøjer. GUID'et er tilgængeligt i URL-adressen, når du får vist SQL-analyseslutpunktet i browseren.