Del via

Utvikle semantiske modeller i Direct Lake

  • Artikkel

Denne artikkelen beskriver utformingsemner som er relevante for utvikling av semantiske modeller i Direct Lake.

Opprett modellen

Du bruker Stoff-portalen til å opprette en semantisk direct lake-modell i et arbeidsområde. Det er en enkel prosess som innebærer å velge hvilke tabeller fra ett enkelt lakehouse eller lager som skal legges til i den semantiske modellen.

Deretter kan du bruke nettmodelleringsopplevelsen til å videreutvikle den semantiske modellen. Med denne opplevelsen kan du opprette relasjoner mellom tabeller, opprette mål og beregningsgrupper, merke datotabeller og angi egenskaper for modell og objekter (for eksempel kolonneformater). Du kan også konfigurere sikkerhet på radnivå (RLS) ved å definere roller og regler, og ved å legge til medlemmer (Microsoft Entra-brukerkontoer eller sikkerhetsgrupper) i disse rollene.

Du kan også fortsette utviklingen av modellen ved hjelp av et XMLA-kompatibelt verktøy, for eksempel SQL Server Management Studio (SSMS) (versjon 19.1 eller nyere) eller verktøy for åpen kildekode, fellesskap. Hvis du vil ha mer informasjon, kan du se Skrivestøtte for modell med XMLA-endepunktet senere i denne artikkelen.

Tips

Du kan lære hvordan du oppretter et lakehouse, et Delta-bord og en grunnleggende semantisk direct lake-modell ved å fullføre denne opplæringen.

Modelltabeller

Modelltabeller er basert på enten en tabell eller en visning av SQL Analytics-endepunktet. Unngå imidlertid å bruke visninger når det er mulig. Det er fordi spørringer til en modelltabell basert på en visning alltid vil falle tilbake til DirectQuery-modus, noe som kan føre til langsommere spørringsytelse.

Tabeller bør inneholde kolonner for filtrering, gruppering, sortering og oppsummering, i tillegg til kolonner som støtter modellrelasjoner. Selv om unødvendige kolonner ikke påvirker semantisk modellspørringsytelse (fordi de ikke lastes inn i minnet), resulterer de i en større lagringsstørrelse i OneLake og krever mer databehandlingsressurser for å laste inn og vedlikeholde.

Advarsel!

Bruk av kolonner som bruker dynamisk datamaskering (DDM) i semantiske modeller i Direct Lake, støttes ikke.

Hvis du vil lære hvordan du velger hvilke tabeller som skal inkluderes i semantisk Direct Lake-modell, kan du se Rediger tabeller for semantiske modeller i Direct Lake.

Hvis du vil ha mer informasjon om kolonner som skal inkluderes i semantiske modelltabeller, kan du se Forstå lagring for semantiske modeller i Direct Lake.

Fremtving datatilgangsregler

Når du har krav om å levere delsett med modelldata til forskjellige brukere, kan du håndheve datatilgangsregler. Du håndhever regler ved å konfigurere sikkerhet på objektnivå (OLS) og/eller sikkerhet på radnivå (RLS) i SQL Analytics-endepunktet eller i semantisk modell.

Merk

Emnet for å håndheve datatilgangsregler er forskjellig, men likevel relatert til å angi tillatelser for innholdsforbrukere , opprettere og brukere som skal administrere semantisk modell (og relaterte stoffelementer). Hvis du vil ha mer informasjon om hvordan du angir tillatelser, kan du se Behandle semantiske modeller i Direct Lake.

Sikkerhet på objektnivå (OLS)

OLS innebærer å begrense tilgangen til å oppdage og spørre etter objekter eller kolonner. Du kan for eksempel bruke OLS til å begrense brukerne som har tilgang til Salary kolonnen fra Employee tabellen.

For et SQL-analyseendepunkt kan du konfigurere OLS til å kontrollere tilgangen til endepunktobjektene, for eksempel tabeller eller visninger, og sikkerhet på kolonnenivå (CLS) for å kontrollere tilgangen til tabellkolonner for endepunkt.

For en semantisk modell kan du konfigurere OLS til å kontrollere tilgangen til modelltabeller eller kolonner. Du må bruke åpen kildekode, fellesskapsverktøy som Tabellredigering for å konfigurere OLS.

Sikkerhet på radnivå (RLS)

RLS innebærer å begrense tilgangen til delsett av data i tabeller. Du kan for eksempel bruke RLS for å sikre at selgere bare kan få tilgang til salgsdata for kunder i salgsområdet.

For et SQL Analytics-endepunkt kan du konfigurere RLS til å kontrollere tilgangen til rader i en endepunkttabell.

Viktig

Når en spørring bruker en tabell som har RLS i SQL Analytics-endepunktet, vil den falle tilbake til DirectQuery-modus. Spørringsytelsen kan være tregere.

For en semantisk modell kan du konfigurere RLS til å kontrollere tilgangen til rader i modelltabeller. RLS kan konfigureres i nettmodelleringsopplevelsen eller ved hjelp av et tredjepartsverktøy.

Slik evalueres spørringer

Grunnen til å utvikle semantiske modeller i Direct Lake er å oppnå spørringer med høy ytelse over store mengder data i OneLake. Derfor bør du strebe etter å utforme en løsning som maksimerer sjansene for spørring i minnet.

Følgende trinn tilnærmer seg hvordan spørringer evalueres (og om de mislykkes). Fordelene med Direct Lake-lagringsmodus er bare mulig når det femte trinnet oppnås.

  1. Hvis spørringen inneholder en tabell eller kolonne som er begrenset av ols for semantisk modell, returneres et feilresultat (visualobjektet i rapporten vil ikke gjengis).
  2. Hvis spørringen inneholder en kolonne som er begrenset av SQL Analytics-endepunktet CLS (eller tabellen nektes), returneres et feilresultat (rapportvisualobjektet vil ikke gjengis).
    1. Hvis skytilkoblingen bruker SSO (standard), bestemmes CLS av tilgangsnivået til rapportforbrukeren.
    2. Hvis skytilkoblingen bruker en fast identitet, bestemmes CLS av tilgangsnivået for den faste identiteten.
  3. Hvis spørringen inneholder en tabell i SQL Analytics-endepunktet som håndhever RLS eller en visning brukes, går spørringen tilbake til DirectQuery-modus.
    1. Hvis skytilkoblingen bruker SSO (standard), bestemmes RLS av tilgangsnivået til rapportforbrukeren.
    2. Hvis skytilkoblingen bruker en fast identitet, bestemmes RLS av tilgangsnivået for den faste identiteten.
  4. Hvis spørringen overskrider rekkverket for kapasiteten, faller den tilbake til DirectQuery-modus.
  5. Ellers er spørringen fornøyd fra minnehurtigbufferen. Kolonnedata lastes inn i minnet når og når det er nødvendig.

Kildeelementtillatelser

Kontoen som brukes til å få tilgang til data, er ett av følgende.

  • Hvis skytilkoblingen bruker SSO (standard), er det rapportforbrukeren.
  • Hvis skytilkoblingen bruker en fast identitet, er den den faste identiteten.

Kontoen må minst ha tillatelsen Lese og LesData på kildeelementet (lakehouse eller warehouse). Elementtillatelser kan arves fra arbeidsområderoller eller tilordnes eksplisitt for elementet som beskrevet i denne artikkelen.

Forutsatt at dette kravet oppfylles, gir Fabric den nødvendige tilgangen til den semantiske modellen for å lese Delta-tabellene og tilknyttede parkettfiler (for å laste inn kolonnedata i minnet) og datatilgangsregler kan brukes.

Alternativer for datatilgangsregel

Du kan konfigurere datatilgangsregler i:

  • Bare den semantiske modellen.
  • Bare endepunktet for SQL-analyse.
  • I både den semantiske modellen og sql analytics-endepunktet.

Regler i semantisk modell

Hvis du må fremtvinge datatilgangsregler, bør du gjøre det i den semantiske modellen når det er levedyktig. Det er fordi RLS fremtvunget av den semantiske modellen oppnås ved å filtrere minnehurtigbufferen for data for å oppnå spørringer med høy ytelse.

Det er også en passende tilnærming når rapportforbrukere ikke får tillatelse til å spørre lakehouse eller lager.

I begge tilfeller anbefales det på det sterkeste at skytilkoblingen bruker en fast identitet i stedet for SSO. SSO vil antyde at sluttbrukere kan få tilgang til SQL Analytics-endepunktet direkte og kan derfor omgå sikkerhetsregler i den semantiske modellen.

Viktig

Semantiske tillatelser for modellelementer kan angis eksplisitt via Power BI-apper, eller anskaffes implisitt via arbeidsområderoller.

Semantiske datatilgangsregler for semantisk modell håndheves ikke for brukere som har skrivetillatelse på den semantiske modellen. Datatilgangsregler gjelder derimot for brukere som er tilordnet rollen som visningsområde. Brukere som er tilordnet rollen administrator, medlem eller bidragsyterarbeidsområde, har imidlertid implisitt skrivetillatelse på den semantiske modellen, og derfor håndheves ikke datatilgangsregler. Hvis du vil ha mer informasjon, kan du se Roller i arbeidsområder.

Regler i endepunktet for SQL-analyse

Det er hensiktsmessig å fremtvinge datatilgangsregler i SQL Analytics-endepunktet når den semantiske skytilkoblingen for modell bruker enkel pålogging (SSO). Det er fordi identiteten til brukeren er delegert til å spørre sql analytics-endepunktet, slik at spørringer returnerer bare dataene brukeren har tilgang til. Det er også hensiktsmessig å fremtvinge datatilgangsregler på dette nivået når brukere vil spørre sql analytics-endepunktet direkte etter andre arbeidsbelastninger (for eksempel for å opprette en Paginert Power BI-rapport eller eksportere data).

Spesielt vil imidlertid en semantisk modellspørring falle tilbake til DirectQuery-modus når den inneholder en tabell som håndhever RLS i SQL Analytics-endepunktet. Derfor kan den semantiske modellen aldri bufre data i minnet for å oppnå spørringer med høy ytelse.

Regler på begge lag

Datatilgangsregler kan håndheves på begge lag. Denne tilnærmingen innebærer imidlertid ekstra kompleksitet og administrasjonskostnader. I dette tilfellet anbefales det på det sterkeste at skytilkoblingen bruker en fast identitet i stedet for SSO.

Sammenligning av regelalternativer for datatilgang

Tabellen nedenfor sammenligner konfigurasjonsalternativer for datatilgang.

Bruke datatilgangsregler på Kommentar
Bare semantisk modell Bruk dette alternativet når brukere ikke får elementtillatelser til å spørre lakehouse eller lager. Konfigurer skytilkoblingen til å bruke en fast identitet. Høy spørringsytelse kan oppnås fra minnehurtigbufferen.
Bare SQL Analytics-endepunkt Bruk dette alternativet når brukere trenger tilgang til data fra lageret eller den semantiske modellen, og med konsekvente datatilgangsregler. Kontroller at SSO er aktivert for skytilkoblingen. Spørringsytelsen kan være treg.
Lakehouse eller lager og semantisk modell Dette alternativet innebærer ekstra administrasjonskostnader. Konfigurer skytilkoblingen til å bruke en fast identitet.

Her er anbefalte fremgangsmåter knyttet til å håndheve datatilgangsregler:

  • Hvis ulike brukere må begrenses til delsett av data, må du fremtvinge RLS bare på semantisk modelllag når de er levedyktige. På den måten vil brukerne dra nytte av spørringer med høy ytelse i minnet. I dette tilfellet anbefales det på det sterkeste at skytilkoblingen bruker en fast identitet i stedet for SSO.
  • Hvis det er mulig, bør du unngå å håndheve OLS og CLS på begge lag fordi det resulterer i feil i visualobjekter i rapporten. Feil kan føre til forvirring eller bekymring for brukere. Vurder å opprette mål som returnerer BLANK under bestemte betingelser i stedet for CLS (hvis mulig) for summerbare kolonner.

Skrivestøtte for modell med XMLA-endepunktet

Semantiske modeller i Direct Lake støtter skriveoperasjoner med XMLA-endepunktet ved hjelp av verktøy som SSMS (19.1 eller nyere) og verktøy for åpen kildekode, fellesskap.

Tips

Hvis du vil ha mer informasjon om hvordan du bruker tredjepartsverktøy til å utvikle, administrere eller optimalisere semantiske modeller, kan du se det avanserte bruksscenariet for datamodellbehandling .

Før du kan utføre skriveoperasjoner, må alternativet XMLA-leseskriving være aktivert for kapasiteten. Hvis du vil ha mer informasjon, kan du se Aktivere skrivetilgang for XMLA.

Modellskrivingsoperasjoner med STØTTE for XMLA-endepunkt:

  • Tilpassing, sammenslåing, skripting, feilsøking og testing av metadata for Direct Lake-modellen.
  • Kilde- og versjonskontroll, kontinuerlig integrasjon og kontinuerlig distribusjon (CI/CD) med Azure DevOps og GitHub. Hvis du vil ha mer informasjon, kan du se Behandling av innholdslivssyklus.
  • Automatiseringsoppgaver som semantisk modelloppdatering og bruk av endringer i semantiske modeller i Direct Lake ved hjelp av PowerShell og REST-API-ene.

Når du endrer en semantisk modell ved hjelp av XMLA, må du oppdatere ChangedProperties og PBI_RemovedChildren samling for det endrede objektet for å inkludere eventuelle endrede eller fjernede egenskaper. Hvis du ikke utfører denne oppdateringen, kan Power BI-modelleringsverktøy overskrive eventuelle endringer neste gang skjemaet synkroniseres.

De støttede modellene for å endre en semantisk modell ved hjelp av XMLA er følgende:

  • Gi nytt navn til tabell/kolonne (ChangeProperty = navn)
  • Fjern tabell (legg til tabell i PBI_RemovedChildren merknad i spørringsuttrykket)

Viktig

Direct Lake-tabeller som opprettes ved hjelp av XMLA-programmer, vil i utgangspunktet være i en ubehandlet tilstand til programmet sender en oppdateringskommando. Spørringer som involverer ubehandlede tabeller, vil alltid falle tilbake til DirectQuery-modus. Når du oppretter en ny semantisk modell, må du derfor oppdatere modellen for å behandle tabellene.

Hvis du vil ha mer informasjon, kan du se Semantisk modelltilkobling med XMLA-endepunktet.

Metadata for Direct Lake-modell

Når du kobler til en semantisk Direct Lake-modell med XMLA-endepunktet, ser metadataene ut som en hvilken som helst annen modell. Direct Lake-modeller viser imidlertid følgende forskjeller:

  • Egenskapen compatibilityLevel for databaseobjektet er 1604 (eller høyere).
  • Modusegenskapen for Direct Lake-partisjoner er satt til directLake.
  • Direct Lake-partisjoner bruker delte uttrykk til å definere datakilder. Uttrykket peker til SQL Analytics-endepunktet for lakehouse eller warehouse. Direct Lake bruker SQL Analytics-endepunktet til å oppdage skjema- og sikkerhetsinformasjon, men det laster inn dataene direkte fra OneLake (med mindre det faller tilbake til DirectQuery-modus av en eller annen grunn).

Oppgaver etter publisering

Når du har publisert en semantisk Direct Lake-modell, bør du fullføre noen konfigurasjonsoppgaver. Hvis du vil ha mer informasjon, kan du se Behandle semantiske modeller i Direct Lake.

Funksjoner som ikke støttes

Følgende modellfunksjoner støttes ikke av semantiske modeller i Direct Lake:

  • Beregnede tabeller som refererer til tabeller eller kolonner i Direct Lake-lagringsmodus
  • Beregnede kolonner som refererer til tabeller eller kolonner i Direct Lake-lagringsmodus
  • Hybridtabeller
  • Brukerdefinerte aggregasjoner
  • Sammensatte modeller, der du ikke kan kombinere direct lake-lagringsmodustabeller med DirectQuery- eller Dual Storage-modustabeller i samme modell. Du kan imidlertid bruke Power BI Desktop til å opprette en live-tilkobling til en semantisk direct lake-modell og deretter utvide den med nye mål, og derfra kan du klikke alternativet for å gjøre endringer i denne modellen for å legge til nye tabeller (ved hjelp av Import, DirectQuery eller Dobbel lagringsmodus). Denne handlingen oppretter en DirectQuery-tilkobling til den semantiske modellen i Direct Lake-modus, slik at tabellene vises som DirectQuery-lagringsmodus, men denne lagringsmodusen angir ikke tilbakefall til DirectQuery. Bare forbindelsen mellom denne nye modellen og Direct Lake-modellen er DirectQuery, og spørringer bruker fortsatt Direct Lake til å hente data fra OneLake. Hvis du vil ha mer informasjon, kan du se Bygge en sammensatt modell på en semantisk modell.
  • Kolonner basert på SQL Analytics-endepunktkolonner som bruker dynamisk datamaskering.

Relatert innhold