Behandle semantiske modeller i Direct Lake
Denne artikkelen beskriver utformingsemner som er relevante for administrasjon av semantiske modeller i Direct Lake.
Oppgaver etter publisering
Når du først publiserer en semantisk Direct Lake-modell som er klar for rapportering, bør du umiddelbart fullføre noen oppgaver etter publisering. Disse oppgavene kan også justeres når som helst i løpet av livssyklusen til semantisk modell.
- Konfigurere skytilkoblingen
- Behandle medlemskap i sikkerhetsrolle
- Angi tillatelser for Stoffelement
- Konfigurere planlagt oppdatering
Du kan også konfigurere dataoppdagelse slik at rapportopprettere kan lese metadata, slik at de kan oppdage data i OneLake-datahuben og be om tilgang til dem. Du kan også godkjenne (sertifisert eller forfremmet) den semantiske modellen for å kommunisere at den representerer kvalitetsdata som passer for bruk.
Konfigurere skytilkoblingen
En semantisk direct lake-modell bruker en skytilkobling til å koble til SQL Analytics-endepunktet. Den gir tilgang til kildedata, som enten er Parquet-filene i OneLake (Direct Lake-lagringsmodus, som innebærer innlasting av kolonnedata i minnet) eller SQL Analytics-endepunktet (når spørringer faller tilbake til DirectQuery-modus).
Standard skytilkobling
Når du oppretter en semantisk Direct Lake-modell, brukes standard skytilkobling. Den bruker enkel pålogging (SSO), noe som betyr at identiteten som spør den semantiske modellen (ofte en rapportbruker) brukes til å spørre sql analytics-endepunktdataene.
Delbar skytilkobling
Du kan også opprette en delbar skytilkobling (SCC), slik at tilkoblinger til datakilden kan opprettes med en fast identitet. Det kan hjelpe bedriftskunder med å beskytte organisasjonens datalagre. IT-avdelingen kan administrere legitimasjon, opprette SCCer og dele dem med de tiltenkte oppretterne for sentralisert tilgangsbehandling.
Hvis du vil konfigurere en fast identitet, kan du se Angi en fast identitet for en semantisk direct lake-modell.
Autentisering
Den faste identiteten kan godkjennes enten ved hjelp av OAuth 2.0 eller Tjenestekontohaver.
Merk
Bare Microsoft Entra-godkjenning støttes. Derfor støttes ikke enkel godkjenning for semantiske direct lake-modeller.
OAuth 2.0
Når du bruker OAuth 2.0, kan du godkjenne med en Microsoft Entra-brukerkonto. Brukerkontoen må ha tillatelse til å spørre etter sql analytics-endepunkttabeller og -visninger og skjemametadata.
Bruk av en bestemt brukerkonto er ikke en anbefalt fremgangsmåte. Det er fordi semantiske modellspørringer mislykkes hvis passordet endres eller brukerkontoen slettes (for eksempel når en ansatt forlater organisasjonen).
Tjenestekontohaver
Godkjenning med en tjenestekontohaver er anbefalt praksis fordi den ikke er avhengig av en bestemt brukerkonto. Sikkerhetskontohaveren må ha tillatelse til å spørre etter SQL Analytics-endepunkttabeller og -visninger, og skjemametadata.
For kontinuitet kan legitimasjonen for tjenestekontohaver administreres ved hemmelig/sertifikatrotasjon.
Merk
Innstillingene for Fabric-tenanten må tillate tjenestekontohavere, og tjenestekontohaveren må tilhøre en deklarert sikkerhetsgruppe.
Enkel pålogging
Når du oppretter en skytilkobling som kan deles, fjernes ikke avmerkingsboksen for enkel pålogging som standard. Det er riktig oppsett når du bruker en fast identitet.
Du kan aktivere SSO når du vil at identiteten som spør den semantiske modellen, også skal spørre sql analytics-endepunktet. I denne konfigurasjonen vil semantisk Direct Lake-modellen bruke den faste identiteten til å oppdatere modellen og brukeridentiteten til å spørre etter data.
Når du bruker en fast identitet, er det vanlig praksis å deaktivere SSO slik at den faste identiteten brukes til både oppdateringer og spørringer, men det er ingen tekniske krav til å gjøre det.
Anbefalte fremgangsmåter for skytilkoblinger
Her er anbefalte fremgangsmåter relatert til skytilkoblinger:
- Når alle brukere har tilgang til dataene (og har tillatelse til å gjøre det), er det ikke nødvendig å opprette en delt skytilkobling. I stedet kan standardinnstillingene for skytilkobling brukes. I dette tilfellet vil identiteten til brukeren som spør modellen, bli brukt hvis spørringer faller tilbake til DirectQuery-modus.
- Opprett en delt skytilkobling når du vil bruke en fast identitet til å spørre kildedata. Det kan skyldes at brukerne som spør etter den semantiske modellen ikke får tillatelse til å lese lakehouse eller lageret. Denne tilnærmingen er spesielt relevant når den semantiske modellen håndhever RLS.
- Hvis du bruker en fast identitet, bruker du alternativet Tjenestekontohaver fordi det er sikrere og mer pålitelig. Det er fordi det ikke er avhengig av én enkelt brukerkonto eller deres tillatelser, og det krever ikke vedlikehold (og avbrudd) hvis de endrer passordet eller forlater organisasjonen.
- Hvis ulike brukere må begrenses til bare å få tilgang til delsett med data, kan du fremtvinge RLS bare på semantisk modelllag. På den måten vil brukerne dra nytte av spørringer med høy ytelse i minnet.
- Hvis det er mulig, unngå OLS og CLS fordi det resulterer i feil i rapportvisualobjekter. Feil kan skape forvirring eller bekymring for brukere. Vurder å opprette mål som returnerer BLANK under bestemte betingelser i stedet for CLS (hvis mulig) for summerbare kolonner.
Behandle medlemskap i sikkerhetsrolle
Hvis semantisk direct lake-modell håndhever sikkerhet på radnivå (RLS), må du kanskje administrere medlemmene som er tilordnet sikkerhetsrollene. Hvis du vil ha mer informasjon, kan du se Administrere sikkerhet på modellen.
Angi tillatelser for Stoffelement
Direct Lake semantiske modeller holder seg til en lagdelt sikkerhetsmodell. De utfører tillatelseskontroller via SQL Analytics-endepunktet for å finne ut om identiteten som prøver å få tilgang til dataene, har de nødvendige datatilgangstillatelsene.
Du må gi tillatelser til brukere slik at de kan bruke eller administrere semantisk direct lake-modell. Kort sagt, rapportforbrukere trenger lesetillatelse , og rapportopprettere trenger kompileringstillatelse . Semantiske modelltillatelser kan tilordnes direkte eller anskaffes implisitt via arbeidsområderoller. Hvis du vil administrere semantiske modellinnstillinger (for oppdatering og andre konfigurasjoner), må du være semantisk modelleier.
Avhengig av hvilken skytilkobling som er konfigurert, og om brukerne må spørre lakehouse eller lagerets SQL Analytics-endepunkt, må du kanskje gi andre tillatelser (beskrevet i tabellen i denne delen).
Merk
Brukere krever ikke noen gang tillatelse til å lese data 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.
Vurder følgende scenarioer og tillatelseskrav.
Scenario | Tillatelser som kreves | Kommentarer |
---|---|---|
Brukere kan vise rapporter | • Gi lesetillatelse for rapportene og lesetillatelsen for semantisk modell. • Hvis skytilkoblingen bruker SSO, må du gi minst lesetillatelse for lakehouse eller lager. |
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 skytilkoblingen bruker SSO, må du gi minst lesetillatelse for lakehouse eller lager. |
Hvis du vil ha mer informasjon, kan du se Strategi for innholdsopprettere. |
Brukere kan spørre den semantiske modellen, men blir nektet å spørre lakehouse- eller SQL Analytics-endepunktet | • Ikke gi tillatelse til lakehouse eller lager. | Bare egnet når skytilkoblingen bruker en fast identitet. |
Brukere kan spørre den semantiske modellen og SQL Analytics-endepunktet, men blir nektet å spørre lakehouse | • Gi Lese- og ReadData-tillatelser for lakehouse eller lageret. | Viktig! Spørringer som sendes til SQL Analytics-endepunktet, vil omgå datatilgangstillatelser som håndheves av den semantiske modellen. |
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.
Oppdater semantiske modeller for Direct Lake
En oppdatering av en semantisk direct lake-modell resulterer i en innrammingsoperasjon . En oppdateringsoperasjon kan utløses:
- Manuelt, ved å gjøre en behovsbetinget oppdatering i Fabric-portalen, eller ved å utføre kommandoen Tabular Model Scripting Language (TMSL) oppdater fra et skript i SQL Server Management Studio (SSMS), eller ved hjelp av et tredjepartsverktøy som kobles til via XMLA-endepunktet.
- Automatisk ved å konfigurere en oppdateringsplan i Stoff-portalen.
- Automatisk, når det oppdages endringer i de underliggende Delta-tabellene, kan du se Automatiske oppdateringer (beskrevet neste) hvis du vil ha mer informasjon.
- Programmatisk, ved å utløse en oppdatering ved hjelp av REST-API-en for Power BI eller TOM. Du kan utløse en programmatisk oppdatering som et siste trinn i en uttrekkings-, transformerings- og innlastingsprosess (ETL).
Automatiske oppdateringer
Det finnes en semantisk innstilling på modellnivå med navnet Hold Direct Lake-dataene oppdatert som gjør automatiske oppdateringer av Direct Lake-tabeller. Den er aktivert som standard. Den sikrer at dataendringer i OneLake automatisk gjenspeiles i semantisk Direct Lake-modell. Innstillingen er tilgjengelig i Stoff-portalen, i Oppdater-delen av innstillingene for semantisk modell.
Når innstillingen er aktivert, utfører den semantiske modellen en innrammingsoperasjon når dataendringer i underliggende Delta-tabeller oppdages. Innrammingsoperasjonen er alltid spesifikk for bare de tabellene der dataendringer oppdages.
Vi anbefaler at du lar innstillingen stå på, spesielt når du har en liten eller mellomstor semantisk modell. Det er spesielt nyttig når du har krav til rapportering med lav ventetid og Delta-tabeller endres regelmessig.
I enkelte situasjoner vil du kanskje deaktivere automatiske oppdateringer. Du må for eksempel kanskje tillate fullføring av dataforberedelsesjobber eller ETL-prosessen før du eksponerer nye data til forbrukere av den semantiske modellen. Når den er deaktivert, kan du utløse en oppdatering ved hjelp av en programmatisk metode (beskrevet tidligere).
Merk
Power BI deaktiverer automatiske oppdateringer når det oppstår en feil som ikke kan gjenopprettes under oppdateringen. En feil som ikke kan gjenopprettes, kan for eksempel oppstå når en oppdatering mislykkes etter flere forsøk. Så pass på at den semantiske modellen kan oppdateres. Power BI gjenopptar automatiske oppdateringer når en etterfølgende behovsbetinget oppdatering fullføres uten feil.
Varm hurtigbufferen
En semantisk oppdateringsoperasjon for Direct Lake-semantisk modell kan kaste ut alle bosatte kolonner fra minnet. Det betyr at de første spørringene etter en oppdatering av en semantisk direct lake-modell kan oppleve en forsinkelse etter hvert som kolonner lastes inn i minnet. Forsinkelser kan bare være merkbare når du har svært store mengder data.
Hvis du vil unngå slike forsinkelser, bør du vurdere å varme opp hurtigbufferen ved programmatisk å sende en spørring til den semantiske modellen. En praktisk måte å sende en spørring på er å bruke semantisk kobling. Denne operasjonen bør utføres umiddelbart etter at oppdateringsoperasjonen er fullført.
Viktig
Oppvarming av hurtigbufferen gir kanskje bare mening når forsinkelser er uakseptable. Pass på at du ikke unødvendig laster inn data i minnet som kan legge press på andre kapasitetsarbeidsbelastninger, noe som fører til at de begrenses eller blir nedprioritert.
Angi virkemåten for Direct Lake
Du kan kontrollere tilbakefall av semantiske direct lake-modeller ved å angi DirectLakeBehavior
egenskapen. Den kan settes til:
- Automatisk: (standard) Spørringer faller tilbake til DirectQuery-modus hvis de nødvendige dataene ikke kan lastes inn i minnet på en effektiv måte.
- DirectLakeOnly: Alle spørringer bruker bare Direct Lake-lagringsmodus. Tilbakefall til DirectQuery-modus er deaktivert. Hvis data ikke kan lastes inn i minnet, returneres en feil.
- DirectQueryOnly: Bare alle spørringer bruker DirectQuery-modus. Bruk denne innstillingen til å teste tilbakefallsytelse, der du for eksempel kan observere spørringsytelsen i tilkoblede rapporter.
Du kan angi egenskapen i nettmodelleringsopplevelsen, eller ved hjelp av Tabular Object Model (TOM) eller Tabular Model Scripting Language (TMSL).
Tips
Vurder å deaktivere DirectQuery-tilbakefall når du bare vil behandle spørringer i Direct Lake-lagringsmodus. Vi anbefaler at du deaktiverer tilbakefall når du ikke vil gå tilbake til DirectQuery. Det kan også være nyttig når du vil analysere spørringsbehandling for en semantisk direct lake-modell for å identifisere om og hvor ofte tilbakefall oppstår.
Overvåk semantiske modeller for Direct Lake
Du kan overvåke en semantisk direct lake-modell for å bestemme ytelsen til DAX-spørringer for rapportvisualobjekter, eller for å finne ut når den faller tilbake til DirectQuery-modus.
Du kan bruke Ytelsesanalyse, SQL Server Profiler, Azure Log Analytics eller et verktøy for åpen kildekode, for eksempel DAX Studio.
Ytelsesanalyse
Du kan bruke Ytelsesanalyse i Power BI Desktop til å registrere behandlingstiden som kreves for å oppdatere rapportelementer som startes som et resultat av brukersamhandling som resulterer i å kjøre en spørring. Hvis overvåkingsresultatene viser en direkte spørringsmetrikk , betyr det at DAX-spørringene ble behandlet i DirectQuery-modus. I mangel av denne måleverdien ble DAX-spørringene behandlet i Direct Lake-modus.
Hvis du vil ha mer informasjon, kan du se Analyser ved hjelp av Ytelsesanalyse.
Profileringsverktøy for SQL Server
Du kan bruke SQL Server Profiler til å hente detaljer om spørringsytelse ved å spore spørringshendelser. Det er installert med SQL Server Management Studio (SSMS). Før du starter, må du kontrollere at du har den nyeste versjonen av SSMS installert.
Hvis du vil ha mer informasjon, kan du se Analyser ved hjelp av SQL Server Profiler.
Viktig
Generelt gir Lagringsmodus for Direct Lake rask spørringsytelse med mindre en tilbakefall til DirectQuery-modus er nødvendig. Fordi tilbakefall til DirectQuery-modus kan påvirke spørringsytelsen, er det viktig å analysere spørringsbehandling for en semantisk direct lake-modell for å identifisere om, hvor ofte og hvorfor tilbakefall oppstår.
Azure Log Analytics
Du kan bruke Azure Log Analytics til å samle inn, analysere og handle på telemetridata som er knyttet til en semantisk direct lake-modell. Det er en tjeneste i Azure Monitor, som Power BI bruker til å lagre aktivitetslogger.
Hvis du vil ha mer informasjon, kan du se Bruke Azure Log Analytics i Power BI.