Del via

Administrer semantiske Direct Lake-modeller

  • Artikel

I denne artikel beskrives designemner, der er relevante for administration af semantiske Direct Lake-modeller.

Opgaver efter publicering

Når du først har publiceret en semantisk Direct Lake-model, der er klar til rapportering, skal du straks udføre nogle opgaver efter publiceringen. Disse opgaver kan også justeres når som helst i den semantiske models livscyklus.

Du kan også konfigurere dataregistrering, så forfattere af rapporter kan læse metadata, hvilket hjælper dem med at finde data i OneLake-datahub og anmode om adgang til dem. Du kan også anbefale (certificeret eller fremhævet) den semantiske model for at kommunikere, at den repræsenterer kvalitetsdata, der er egnet til brug.

Konfigurer cloudforbindelsen

En semantisk Direct Lake-model bruger en cloudforbindelse til at oprette forbindelse til SQL Analytics-slutpunktet. Det giver adgang til kildedata, som enten er Parquet-filerne i OneLake (Direct Lake-lagringstilstand, som omfatter indlæsning af kolonnedata i hukommelsen) eller SQL-analyseslutpunktet (når forespørgsler falder tilbage til DirectQuery-tilstand).

Standardforbindelse i skyen

Når du opretter en semantisk Direct Lake-model, bruges standardforbindelsen i skyen. Den bruger enkeltlogon (SSO), hvilket betyder, at den identitet, der forespørger den semantiske model (ofte en rapportbruger), bruges til at forespørge sql-analyseslutpunktdataene.

Cloudforbindelse, der kan deles

Du kan eventuelt oprette en SCC(sharable Cloud Connection), så forbindelser til datakilden kan oprettes med en fast identitet. Det kan hjælpe virksomhedskunder med at beskytte deres organisationsdatalagre. It-afdelingen kan administrere legitimationsoplysninger, oprette SCC'er og dele dem med de tilsigtede oprettere til central adgangsstyring.

Hvis du vil konfigurere en fast identitet, skal du se Angiv en fast identitet for en semantisk Direct Lake-model.

Godkendelse

Den faste identitet kan godkendes enten ved hjælp af OAuth 2.0 eller tjenesteprincipal.

Seddel

Kun Microsoft Entra-godkendelse understøttes. Derfor understøttes godkendelse af Grundlæggende ikke for semantiske Direct Lake-modeller.

OAuth 2.0

Når du bruger OAuth 2.0, kan du godkende med en Microsoft Entra-brugerkonto. Brugerkontoen skal have tilladelse til at forespørge SQL Analytics-slutpunktstabeller og -visninger samt skemametadata.

Det anbefales ikke at bruge en bestemt brugerkonto. Det skyldes, at semantiske modelforespørgsler mislykkes, hvis adgangskoden ændres, eller brugerkontoen slettes (f.eks. når en medarbejder forlader organisationen).

Tjenesteprincipal

Godkendelse med en tjenesteprincipal er den anbefalede praksis, fordi den ikke er afhængig af en bestemt brugerkonto. Sikkerhedsprincipalen skal have tilladelse til at forespørge SQL Analytics-slutpunktstabeller og -visninger og skemametadata.

Af hensyn til kontinuiteten kan legitimationsoplysningerne for tjenesteprincipalen administreres ved hjælp af rotation af hemmelighed/certifikat.

Seddel

Indstillingerne for Fabric-lejeren skal tillade tjenesteprincipaler, og tjenesteprincipalen skal tilhøre en erklæret sikkerhedsgruppe.

Enkeltlogon

Når du opretter en cloudforbindelse, der kan deles, er afkrydsningsfeltet Single Sign-On som standard ikke markeret. Det er den korrekte konfiguration, når du bruger en fast identitet.

Du kan aktivere SSO, når den identitet, der forespørger den semantiske model, også skal forespørge SQL-analyseslutpunktet. I denne konfiguration bruger den semantiske Direct Lake-model den faste identitet til at opdatere modellen og brugeridentiteten til at forespørge om data.

Når du bruger en fast identitet, er det almindelig praksis at deaktivere SSO, så den faste identitet bruges til både opdateringer og forespørgsler, men der er ikke noget teknisk krav om at gøre det.

Her er anbefalede fremgangsmåder, der er relateret til cloudforbindelser:

  • Når alle brugere har adgang til dataene (og har tilladelse til at gøre det), er det ikke nødvendigt at oprette en delt cloudforbindelse. I stedet kan standardindstillingerne for cloudforbindelsen bruges. I dette tilfælde vil identiteten for den bruger, der forespørger modellen, blive brugt, hvis forespørgslerne vender tilbage til DirectQuery-tilstand.
  • Opret en delt cloudforbindelse, når du vil bruge en fast identitet til at forespørge om kildedata. Det kan skyldes, at de brugere, der forespørger den semantiske model, ikke har tilladelse til at læse lakehouse eller warehouse. Denne fremgangsmåde er især relevant, når den semantiske model gennemtvinger sikkerhed på rækkeniveau.
  • Hvis du bruger en fast identitet, skal du bruge indstillingen tjenesteprincipal, fordi den er mere sikker og pålidelig. Det skyldes, at den ikke er afhængig af en enkelt brugerkonto eller deres tilladelser, og det kræver ikke vedligeholdelse (og afbrydelse), hvis de ændrer deres adgangskode eller forlader organisationen.
  • Hvis forskellige brugere skal begrænses til kun at få adgang til undersæt af data, hvis de er levedygtige, skal du kun gennemtvinge sikkerhed på rækkeniveau på det semantiske modellag. På den måde kan brugerne drage fordel af forespørgsler i hukommelsen med høj ydeevne.
  • Hvis det er muligt, skal du undgå OLS og CLS, da det resulterer i fejl i rapportvisualiseringer. Fejl kan skabe forvirring eller bekymring for brugerne. I forbindelse med kolonner, der kan opsummeres, kan du overveje at oprette målinger, der returnerer BLANK i visse betingelser i stedet for CLS (hvis det er muligt).

Administrer medlemskab af sikkerhedsrolle

Hvis din semantiske Direct Lake-model gennemtvinger sikkerhed på rækkeniveau, skal du muligvis administrere de medlemmer, der er tildelt til sikkerhedsrollerne. Du kan få flere oplysninger under Administrer sikkerhed på din model.

Angiv tilladelser til fabric-elementer

Semantiske Direct Lake-modeller overholder en lagdelt sikkerhedsmodel. De udfører tilladelseskontrol via SQL Analytics-slutpunktet for at afgøre, om den identitet, der forsøger at få adgang til dataene, har de nødvendige tilladelser til dataadgang.

Du skal give tilladelser til brugere, så de kan bruge eller administrere den semantiske Direct Lake-model. Forbrugere af rapporter skal kort sagt have tilladelsen Læs, og rapportoprettere skal tilladelsen Opret. Semantiske modeltilladelser kan tildeles direkte eller erhverves implicit via arbejdsområderoller. Hvis du vil administrere indstillingerne for semantiske modeller (til opdatering og andre konfigurationer), skal du være den semantiske modelejer.

Afhængigt af den cloudforbindelse, der er konfigureret, og om brugerne har brug for at forespørge sql analytics-slutpunktet for lakehouse eller warehouse, skal du muligvis tildele andre tilladelser (beskrevet i tabellen i dette afsnit).

Seddel

Brugerne behøver især aldrig at have tilladelse til at læse data 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.

Overvej følgende scenarier og tilladelseskrav.

Scenario Påkrævede tilladelser Kommentarer
Brugerne kan få vist rapporter • Giv tilladelsen Læs for rapporterne, og tilladelsen Læs for den semantiske model.
• Hvis den cloudforbindelse bruger SSO, skal du give mindst Tilladelsen Læs til lakehouse eller warehouse.		 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 cloudforbindelsen bruger SSO, skal du give mindst Tilladelsen Læs til lakehouse eller warehouse.		 Du kan finde flere oplysninger under strategi for indholdsoprettere.
Brugerne kan forespørge den semantiske model, men de afvises ved at forespørge lakehouse- eller SQL Analytics-slutpunktet • Giv ikke tilladelse til lakehouse eller warehouse. Kun egnet, når cloudforbindelsen bruger en fast identitet.
Brugerne kan forespørge den semantiske model og SQL Analytics-slutpunktet, men de nægtes at forespørge lakehouse • Tildel tilladelsen Læs og ReadData tilladelser til lakehouse eller warehouse. Vigtigt: Forespørgsler, der sendes til SQL Analytics-slutpunktet, tilsidesætter tilladelser til dataadgang, der gennemtvinges af den semantiske model.
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.

Opdater semantiske Direct Lake-modeller

En opdatering af en semantisk Direct Lake-model resulterer i en handling. En opdateringshandling kan udløses:

  • Manuelt ved at udføre en opdatering efter behov på Fabric-portalen eller ved at udføre TMSL-kommandoen (Tabular Model Scripting Language) kommandoen Opdater fra et script i SSMS (SQL Server Management Studio)eller ved hjælp af et tredjepartsværktøj, der opretter forbindelse via XMLA-slutpunktet.
  • Automatisk ved at konfigurere en tidsplan for opdatering på Fabric-portalen.
  • Når der registreres ændringer i de underliggende Delta-tabeller, kan du automatisk se Automatiske opdateringer (beskrevet næste).
  • Programmatisk ved at udløse en opdatering ved hjælp af REST API'en til Power BI eller TOM. Du kan udløse en programmatisk opdatering som et sidste trin i en etl-proces (Extract, Transform og Load).

Automatiske opdateringer

Der er en semantisk indstilling på modelniveau med navnet hold dine Direct Lake-data opdateret, der foretager automatiske opdateringer af Direct Lake-tabeller. Den er aktiveret som standard. Det sikrer, at dataændringer i OneLake automatisk afspejles i den semantiske Direct Lake-model. Indstillingen er tilgængelig på Fabric-portalen i afsnittet Opdater i indstillingerne for semantiske modeller.

Når indstillingen er aktiveret, udfører den semantiske model en indramning, når der registreres dataændringer i underliggende Delta-tabeller. Indramningshandlingen er altid kun specifik for de tabeller, hvor der registreres datamodifikationer.

Vi anbefaler, at du lader indstillingen være slået til, især når du har en lille eller mellemstor semantisk model. Det er især nyttigt, når du har krav til rapportering med lav ventetid, og Delta-tabeller ændres regelmæssigt.

I nogle situationer kan det være en god idé at deaktivere automatiske opdateringer. Det kan f.eks. være, at du skal tillade fuldførelse af job til dataforberedelse eller ETL-processen, før du eksponerer nye data for forbrugere af den semantiske model. Når indstillingen er deaktiveret, kan du udløse en opdatering ved hjælp af en programmatisk metode (beskrevet tidligere).

Seddel

Power BI afbryder automatiske opdateringer, når der opstår en fejl, der ikke kan genoprettes, opstår under opdateringen. Der kan opstå en fejl, der ikke kan genoprettes, f.eks. når en opdatering mislykkes efter flere forsøg. Så sørg for, at din semantiske model kan opdateres korrekt. Power BI genoptager automatisk automatiske opdateringer, når en efterfølgende opdatering efter behov fuldføres uden fejl.

Varm cachen

En opdateringshandling for en semantisk Direct Lake-model kan fjerne alle residente kolonner fra hukommelsen. Det betyder, at de første forespørgsler efter en opdatering af en Semantisk Direct Lake-model kan opleve en vis forsinkelse, da kolonner indlæses i hukommelsen. Forsinkelser kan kun ses, når du har ekstremt store datamængder.

Hvis du vil undgå sådanne forsinkelser, kan du overveje at opvarme cachen ved at sende en forespørgsel til den semantiske model. En nem måde at sende en forespørgsel på er ved at bruge semantisk link. Denne handling skal udføres, umiddelbart efter at opdateringshandlingen er fuldført.

Vigtig

Opvarmning af cachen giver måske kun mening, når forsinkelser er uacceptable. Vær forsigtig med ikke at unødigt indlæse data i hukommelsen, der kan lægge pres på andre kapacitetsarbejdsbelastninger, hvilket får dem til at begrænse eller blive deprioriteret.

Angiv egenskaben Direct Lake-funktionsmåde

Du kan styre fallback af dine semantiske Direct Lake-modeller ved at angive egenskaben DirectLakeBehavior. Den kan indstilles til:

  • Automatiske: (standard) forespørgsler gå tilbage til DirectQuery-tilstand, hvis de påkrævede data ikke kan indlæses effektivt i hukommelsen.
  • DirectLakeOnly: Alle forespørgsler bruger kun Direct Lake-lagringstilstand. Tilbagefald til DirectQuery-tilstand er deaktiveret. Hvis data ikke kan indlæses i hukommelsen, returneres der en fejl.
  • DirectQueryOnly: Alle forespørgsler bruger kun DirectQuery-tilstand. Brug denne indstilling til at teste fallbackydeevnen, hvor du f.eks. kan se forespørgslens ydeevne i forbundne rapporter.

Du kan angive egenskaben i webmodelleringsoplevelseeller ved hjælp af TOM (Tabular Object Model) eller TMSL (Tabular Model Scripting Language).

Drikkepenge

Overvej at deaktivere DirectQuery-fallback, når du kun vil behandle forespørgsler i Direct Lake-lagringstilstand. Vi anbefaler, at du deaktiverer fallback, når du ikke vil gå tilbage til DirectQuery. Det kan også være nyttigt, når du vil analysere forespørgselsbehandling for en Direct Lake-semantisk model for at identificere, om og hvor ofte fallback opstår.

Overvåg semantiske Direct Lake-modeller

Du kan overvåge en semantisk Direct Lake-model for at bestemme ydeevnen af DAX-forespørgsler for rapportvisualisering eller for at bestemme, hvornår den går tilbage til DirectQuery-tilstand.

Du kan bruge Effektivitetsanalyse, SQL Server Profiler, Azure Log Analytics eller et communityværktøj med åben kildekode, f.eks. DAX Studio.

Effektivitetsanalyse

Du kan bruge Effektivitetsanalyse i Power BI Desktop til at registrere den behandlingstid, der kræves for at opdatere rapportelementer, der startes som følge af enhver brugerinteraktion, der medfører kørsel af en forespørgsel. Hvis overvågningsresultaterne viser en Direct-forespørgsel metrikværdi, betyder det, at DAX-forespørgslerne blev behandlet i DirectQuery-tilstand. Da denne metrikværdi ikke findes, blev DAX-forespørgslerne behandlet i Direct Lake-tilstand.

Du kan få flere oplysninger under Analysér ved hjælp af Effektivitetsanalyse.

SQL Server Profiler

Du kan bruge SQL Server Profiler- til at hente oplysninger om forespørgslens ydeevne ved at spore forespørgselshændelser. Den installeres sammen med SSMS (SQL Server Management Studio). Før du starter, skal du sørge for, at du har den nyeste version af SSMS installeret.

Du kan få flere oplysninger under Analysér ved hjælp af SQL Server Profiler.

Vigtig

Direct Lake-lagringstilstand giver generelt hurtig forespørgselsydeevne, medmindre det er nødvendigt med en fallback til DirectQuery-tilstand. Da fallback til DirectQuery-tilstand kan påvirke forespørgselsydeevnen, er det vigtigt at analysere behandling af forespørgsler for en semantisk Direct Lake-model for at identificere, om, hvor ofte og hvorfor der opstår fallbacks.

Azure Log Analytics

Du kan bruge Azure Log Analytics- til at indsamle, analysere og reagere på telemetridata, der er knyttet til en semantisk Direct Lake-model. Det er en tjeneste i Azure Monitor, som Power BI bruger til at gemme aktivitetslogge.

Du kan få flere oplysninger i Brug af Azure Log Analytics i Power BI.

Relateret indhold