Direct Lake
Direct Lake-tilstand er en semantisk modelfunktion til analyse af meget store datamængder i Power BI. Direct Lake er baseret på indlæsning af parquetformaterede filer direkte fra en data lake uden at skulle forespørge et lakehouse- eller lagerslutpunkt og uden at skulle importere eller duplikere data til en Power BI-model. Direct Lake er en hurtig vej til at indlæse dataene fra søen direkte i Power BI-programmet, der er klar til analyse. I følgende diagram kan du se, hvordan klassiske import- og DirectQuery-tilstande sammenlignes med Direct Lake-tilstand.
I DirectQuery-tilstand forespørger Power BI-programmet dataene ved kilden, hvilket kan være langsomt, men undgår at skulle kopiere dataene, f.eks. med importtilstand. Eventuelle ændringer i datakilden afspejles straks i forespørgselsresultaterne.
På den anden side kan ydeevnen med importtilstand være bedre, fordi dataene cachelagres og optimeres til DAX- og MDX-rapportforespørgsler uden at skulle oversætte og overføre SQL eller andre typer forespørgsler til datakilden. Power BI-programmet skal dog først kopiere nye data til modellen under opdateringen. Eventuelle ændringer i kilden hentes kun med den næste modelopdatering.
Direct Lake-tilstand fjerner importkravet ved at indlæse dataene direkte fra OneLake. I modsætning til DirectQuery er der ingen oversættelse fra DAX eller MDX til andre forespørgselssprog eller udførelse af forespørgsler på andre databasesystemer, hvilket giver en ydeevne, der svarer til importtilstanden. Da der ikke er nogen eksplicit importproces, er det muligt at hente ændringer i datakilden, efterhånden som de opstår, ved at kombinere fordelene ved både DirectQuery- og importtilstande og samtidig undgå deres ulemper. Direct Lake-tilstand kan være det ideelle valg til analyse af meget store modeller og modeller med hyppige opdateringer i datakilden.
Direct Lake understøtter også sikkerhed på rækkeniveau og sikkerhed på objektniveau , så brugerne kun kan se de data, de har tilladelse til at se.
Forudsætninger
Direct Lake understøttes kun på Microsoft Premium-SKU'er (P) og Microsoft Fabric -SKU'er .
Vigtigt
For nye kunder understøttes Direct Lake kun på Microsoft Fabric-SKU'er. Eksisterende kunder kan fortsætte med at bruge Direct Lake med Premium-SKU'er (P), men det anbefales at skifte til en Fabric-kapacitets-SKU. Se meddelelsen om licenser for at få flere oplysninger om Power BI Premium-licenser.
Lakehouse
Før du bruger Direct Lake, skal du klargøre et lakehouse (eller et lager) med en eller flere Delta-tabeller i et arbejdsområde, der hostes på en understøttet Microsoft Fabric-kapacitet. Lakehouse er påkrævet, fordi det angiver lagringsplaceringen for dine parketformaterede filer i OneLake. Lakehouse giver også et adgangspunkt til at starte webmodelleringsfunktionen for at oprette en Direct Lake-model.
Du kan få mere at vide om, hvordan du klargør et lakehouse, opretter en Delta-tabel i lakehouse og opretter en grundlæggende model til lakehouse'et under Opret et lakehouse til Direct Lake.
SQL-slutpunkt
Som en del af klargøringen af et lakehouse oprettes og opdateres et SQL-slutpunkt for SQL-forespørgsler og en standardmodel til rapportering med alle tabeller, der føjes til lakehouse. Selvom Direct Lake-tilstand ikke forespørger SQL-slutpunktet, når data indlæses direkte fra OneLake, er det påkrævet, når en Direct Lake-model uden problemer skal gå tilbage til DirectQuery-tilstand, f.eks. når datakilden bruger bestemte funktioner som avanceret sikkerhed eller visninger, der ikke kan læses via Direct Lake. Direct Lake-tilstand forespørger også SQL-slutpunktet om skema- og sikkerhedsrelaterede oplysninger.
Data Warehouse
Som et alternativ til et lakehouse med SQL-slutpunkt kan du også klargøre et lager og tilføje tabeller ved hjælp af SQL-sætninger eller datapipelines. Proceduren for klargøring af et separat data warehouse er næsten identisk med proceduren for et lakehouse.
Understøttelse af modelskrivning med XMLA-slutpunkt
Direct Lake-modeller understøtter skrivehandlinger via XMLA-slutpunktet ved hjælp af værktøjer som SQL Server Management Studio (19.1 og nyere) og de nyeste versioner af eksterne BI-værktøjer, f.eks. Tabular Editor og DAX Studio. Skrivehandlinger for modellen via understøttelse af XMLA-slutpunktet:
Tilpasning, fletning, scripting, fejlfinding og test af Direct Lake-modelmetadata.
Kilde- og versionsstyring, kontinuerlig integration og kontinuerlig udrulning (CI/CD) med Azure DevOps og GitHub.
Automatiseringsopgaver som opdatering og anvendelse af ændringer på Direct Lake-modeller ved hjælp af PowerShell og REST API'er.
Bemærk, at Direct Lake-tabeller, der er oprettet ved hjælp af XMLA-programmer, indledningsvist vil være i ubehandlet tilstand, indtil programmet udsteder en opdateringskommando. Ikke-behandlede tabeller går tilbage til DirectQuery-tilstand. Når du opretter en ny semantisk model, skal du sørge for at opdatere din semantiske model for at behandle tabellerne.
Aktivér læse- og skriveadgang til XMLA
Før du udfører skrivehandlinger på Direct Lake-modeller via XMLA-slutpunktet, skal læse- og skriveadgang til XMLA være aktiveret for kapaciteten.
I forbindelse med fabric-prøveversionskapaciteter har prøvebrugeren de administratorrettigheder, der er nødvendige for at aktivere læse- og skriveadgang til XMLA.
Vælg Kapacitetsindstillinger på Administration-portalen.
Klik på fanen Prøveversion .
Vælg kapaciteten med Prøveversion og dit brugernavn i kapacitetsnavnet.
Udvid Power BI-arbejdsbelastninger, og vælg derefter Læs skrivning i indstillingen XMLA-slutpunkt.
Vær opmærksom på, at indstillingen FOR XMLA-slutpunktet gælder for alle arbejdsområder og modeller, der er tildelt kapaciteten.
Direct Lake-modelmetadata
Når du opretter forbindelse til en separat Direct Lake-model via XMLA-slutpunktet, ligner metadataene enhver anden model. Direct Lake-modeller viser dog følgende forskelle:
Egenskaben
compatibilityLevelfor databaseobjektet er 1604 eller højere.Egenskaben
Modefor Direct Lake-partitioner er angivet tildirectLake.Direct Lake-partitioner bruger delte udtryk til at definere datakilder. Udtrykket peger på SQL-slutpunktet for en lakehouse eller et lager. Direct Lake bruger SQL-slutpunktet til at finde skema- og sikkerhedsoplysninger, men indlæser dataene direkte fra Delta-tabellerne (medmindre Direct Lake af en eller anden grund skal gå tilbage til DirectQuery-tilstand).
Her er et eksempel på en XMLA-forespørgsel i SSMS:
Hvis du vil vide mere om værktøjssupport via XMLA-slutpunktet, skal du se Semantisk modelforbindelse med XMLA-slutpunktet.
Reserve
Semantiske Power BI-modeller i Direct Lake-tilstand læser Delta-tabeller direkte fra OneLake. Men hvis en DAX-forespørgsel i en Direct Lake-model overskrider grænserne for SKU'en eller bruger funktioner, der ikke understøtter Direct Lake-tilstand, f.eks. SQL-visninger i et lager, kan forespørgslen gå tilbage til DirectQuery-tilstand. I DirectQuery-tilstand bruger forespørgsler SQL til at hente resultaterne fra SQL-slutpunktet for lakehouse eller warehouse, hvilket kan påvirke forespørgselsydeevnen. Du kan deaktivere fallback til DirectQuery-tilstand, hvis du kun vil behandle DAX-forespørgsler i ren Direct Lake-tilstand. Deaktivering af fallback anbefales, hvis du ikke har brug for fallback til DirectQuery. Det kan også være nyttigt, når du analyserer forespørgselsbehandling for en Direct Lake-model for at identificere, om og hvor ofte der opstår fallbacks. Hvis du vil vide mere om DirectQuery-tilstand, skal du se Semantiske modeltilstande i Power BI.
Guardrails definerer ressourcegrænser for Direct Lake-tilstand, ud over hvilken en fallback til DirectQuery-tilstand er nødvendig for at behandle DAX-forespørgsler. Du kan finde flere oplysninger om, hvordan du bestemmer antallet af parquetfiler og rækkegrupper for en Delta-tabel, i referencen til egenskaber for Delta-tabellen.
For semantiske Direct Lake-modeller repræsenterer Maksimal hukommelse den øvre grænse for hukommelsesressourcer for, hvor mange data der kan sideinddeles i. Det er i realiteten ikke et gelænder, fordi overskridelse af det ikke medfører et tilbagefald til DirectQuery. Det kan dog have en indvirkning på ydeevnen, hvis mængden af data er stor nok til at forårsage sideinddeling i og ud af modeldataene fra OneLake-dataene.
I følgende tabel vises både ressourcebeskyttelseslister og maks. hukommelse:
| Stof-SKU'er | Parquetfiler pr. tabel | Rækkegrupper pr. tabel | Rækker pr. tabel (millioner) | Maksimal modelstørrelse på disk/OneLake1 (GB) | Maks. hukommelse (GB) |
|---|---|---|---|---|---|
| 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 – Hvis den maksimale modelstørrelse overskrides på disken/Onelake, vil alle forespørgsler til modellen falde tilbage til DirectQuery i modsætning til andre gelændere, der evalueres pr. forespørgsel.
Afhængigt af din Fabric SKU gælder yderligere kapacitetsenhed og maksimal hukommelse pr. forespørgselsgrænser også for Direct Lake-modeller. Du kan få mere at vide under Kapaciteter og SKU'er.
Fallback-funktionsmåde
Direct Lake-modeller omfatter egenskaben DirectLakeBehavior , som har tre muligheder:
Automatisk – (standard) Angiver, at forespørgsler går tilbage til DirectQuery-tilstand , hvis data ikke kan indlæses effektivt i hukommelsen.
DirectLakeOnly – Angiver, at alle forespørgsler kun bruger Tilstanden Direct Lake. Fallback til DirectQuery-tilstand er deaktiveret. Hvis data ikke kan indlæses i hukommelsen, returneres der en fejl. Brug denne indstilling til at bestemme, om DAX-forespørgsler ikke kan indlæse data i hukommelsen, hvilket tvinger en fejl til at blive returneret.
DirectQueryOnly – Angiver, at alle forespørgsler kun bruger DirectQuery-tilstand. Brug denne indstilling til at teste ydeevnen for fallback.
Egenskaben DirectLakeBehavior kan konfigureres ved hjælp af TOM (Tabular Object Model) eller TMSL (Tabular Model Scripting Language).
I følgende eksempel angives det, at alle forespørgsler kun bruger Direct Lake-tilstand:
// Disable fallback to DirectQuery mode.
//
database.Model.DirectLakeBehavior = DirectLakeBehavior.DirectLakeOnly = 1;
database.Model.SaveChanges();
Analysér behandling af forespørgsler
Hvis du vil finde ud af, om en rapportvisualiserings DAX-forespørgsler til datakilden giver den bedste ydeevne ved hjælp af Direct Lake-tilstand eller går tilbage til DirectQuery-tilstand, kan du bruge Effektivitetsanalyse i Power BI Desktop, SQL Server Profiler eller andre tredjepartsværktøjer til at analysere forespørgsler. Du kan få mere at vide under Analysér forespørgselsbehandling for Direct Lake-modeller.
Opdater
Dataændringer i OneLake afspejles som standard automatisk i en Direct Lake-model. Du kan ændre denne funktionsmåde ved at deaktivere Hold dine Direct Lake-data opdateret i modellens indstillinger.
Det kan være en god idé at deaktivere, hvis du f.eks. skal tillade fuldførelse af job til dataforberedelse, før du eksponerer nye data for forbrugere af modellen. Når indstillingen er deaktiveret, kan du aktivere opdateringen manuelt eller ved hjælp af API'erne til opdatering. Aktivering af en opdatering af en Direct Lake-model er en handling med lave omkostninger, hvor modellen analyserer metadataene for den nyeste version af Tabellen Delta Lake og opdateres, så den refererer til de nyeste filer i OneLake.
Bemærk, at Power BI kan afbryde automatiske opdateringer af Direct Lake-tabeller midlertidigt, hvis der opstår en uoprettelig fejl under opdateringen, så sørg for, at din semantiske model kan opdateres korrekt. Power BI genoptager automatisk automatiske opdateringer, når en efterfølgende brugeraktiveret opdatering fuldføres uden fejl.
Sikkerhed for lagdelt dataadgang
Direct Lake-modeller, der er oprettet oven på lakehouses og lagre, overholder den lagdelte sikkerhedsmodel, som lakehouses og warehouses understøtter, ved at udføre tilladelseskontrol via T-SQL-slutpunktet for at afgøre, om den identitet, der forsøger at få adgang til dataene, har de nødvendige tilladelser til dataadgang. Direct Lake-modeller bruger som standard enkeltlogon (SSO), så de gældende tilladelser for den interaktive bruger bestemmer, om brugeren har tilladelse til eller nægtet adgang til dataene. Hvis Direct Lake-modellen er konfigureret til at bruge en fast identitet, bestemmer den gældende tilladelse for den faste identitet, om brugere, der interagerer med den semantiske model, kan få adgang til dataene. T-SQL-slutpunktet returnerer Tilladt eller Nægtet til Direct Lake-modellen baseret på kombinationen af OneLake-sikkerhed og SQL-tilladelser.
En lageradministrator kan f.eks. tildele en bruger SELECT-tilladelser til en tabel, så brugeren kan læse fra tabellen, selvom brugeren ikke har nogen OneLake-sikkerhedstilladelser. Brugeren blev godkendt på lakehouse-/lagerniveau. Omvendt kan en lageradministrator også NÆGTE en bruger læseadgang til en tabel. Brugeren kan derefter ikke læse fra den pågældende tabel, selvom brugeren har læserettigheder til OneLake-sikkerhed. DENY-sætningen tilsidesætter alle tildelte OneLake-sikkerheds- eller SQL-tilladelser. I følgende tabel kan du se de gældende tilladelser, som en bruger kan have givet en hvilken som helst kombination af OneLake-sikkerhed og SQL-tilladelser.
| OneLake-sikkerhedstilladelser | SQL-tilladelser | Gældende tilladelser |
|---|---|---|
| Tillad | Ingen | Tillad |
| Ingen | Tillad | Tillad |
| Tillad | Afvis | Afvis |
| Ingen | Afvis | Afvis |
Kendte problemer og begrænsninger
Det er kun tabeller i den semantiske model, der er afledt af tabeller i en Lakehouse- eller Warehouse-tilstand, der understøtter Direct Lake-tilstand. Selvom tabeller i modellen kan udledes fra SQL-visninger i Lakehouse eller Warehouse, vil forespørgsler, der bruger disse tabeller, falde tilbage til DirectQuery-tilstand.
Semantiske Direct Lake-modeltabeller kan kun afledes fra tabeller og visninger fra et enkelt Lakehouse eller Warehouse.
Direct Lake-tabeller kan i øjeblikket ikke blandes med andre tabeltyper, f.eks. Import, DirectQuery eller Dual, i den samme model. Sammensatte modeller understøttes ikke i øjeblikket.
DateTime-relationer understøttes ikke i Direct Lake-modeller.
Beregnede kolonner og beregnede tabeller understøttes ikke.
Nogle datatyper understøttes muligvis ikke, f.eks. decimaler med høj præcision og pengetyper.
Direct Lake-tabeller 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 deres nøglekolonner falder sammen. Kolonner med primær nøgle skal indeholde entydige værdier. DAX-forespørgsler mislykkes, hvis der registreres dublerede primære nøgleværdier.
Længden af strengkolonneværdier er begrænset til 32.764 Unicode-tegn.
Den flydende talværdi 'NaN' (Ikke et tal) understøttes ikke i Direct Lake-modeller.
Integrerede scenarier, der er afhængige af integrerede enheder, understøttes endnu ikke.
Validering er begrænset for Direct Lake-modeller. Brugervalg antages at være korrekte, og ingen forespørgsler validerer kardinalitet og tværgående filtervalg for relationer eller for den valgte datokolonne i en datotabel.
Fanen Direct Lake i opdateringshistorikken viser kun Direct Lake-relaterede opdateringsfejl. Vellykkede opdateringer udelades i øjeblikket.
Kom i gang
Den bedste måde at komme i gang med en Direct Lake-løsning i din organisation på er ved at oprette et Lakehouse, oprette en Delta-tabel i den og derefter oprette en grundlæggende semantisk model til lakehouse'et i dit Microsoft Fabric-arbejdsområde. Du kan få mere at vide under Opret et lakehouse til Direct Lake.
Relateret indhold
Feedback
Kommer snart: I hele 2024 udfaser vi GitHub-problemer som feedbackmekanisme for indhold og erstatter det med et nyt feedbacksystem. Du kan få flere oplysninger under: https://aka.ms/ContentUserFeedback.
Indsend og få vist feedback om