Del via

Udvikl semantiske Direct Lake-modeller

  • Artikel

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

Opret modellen

Du kan bruge Fabric-portalen til at oprette en semantisk Direct Lake-model i et arbejdsområde. Det er en enkel proces, der involverer valg af, hvilke tabeller fra et enkelt lakehouse eller lager der skal føjes til den semantiske model.

Du kan derefter bruge webmodelleringsoplevelsen til yderligere at udvikle den semantiske model. Denne oplevelse giver dig mulighed for at oprette relationer mellem tabeller, oprette målinger og beregningsgrupper, markere datotabeller og angive egenskaber for modellen og dens objekter (f.eks. kolonneformater). Du kan også konfigurere sikkerhed på rækkeniveau for modeller ved at definere roller og regler og ved at føje medlemmer (Microsoft Entra-brugerkonti eller sikkerhedsgrupper) til disse roller.

Du kan også fortsætte udviklingen af din model ved hjælp af et XMLA-kompatibelt værktøj, f.eks. SQL Server Management Studio (SSMS) (version 19.1 eller nyere) eller communityværktøjer med åben kildekode. Du kan finde flere oplysninger under Understøttelse af modelskrivning med XMLA-slutpunktet senere i denne artikel.

Tip

Du kan få mere at vide om, hvordan du opretter et lakehouse, en Delta-tabel og en grundlæggende semantisk Direct Lake-model ved at fuldføre dette selvstudium.

Modeltabeller

Modeltabeller er baseret på enten en tabel eller en visning af SQL Analytics-slutpunktet. Undgå dog at bruge visninger, når det er muligt. Det skyldes, at forespørgsler til en modeltabel, der er baseret på en visning, altid vender tilbage til DirectQuery-tilstand, hvilket kan resultere i langsommere forespørgselsydeevne.

Tabeller skal indeholde kolonner til filtrering, gruppering, sortering og opsummering ud over kolonner, der understøtter modelrelationer. Selvom unødvendige kolonner ikke påvirker forespørgselsydeevnen for semantiske modeller (fordi de ikke indlæses i hukommelsen), resulterer de i en større lagerstørrelse i OneLake og kræver flere beregningsressourcer at indlæse og vedligeholde.

Advarsel!

Brug af kolonner, der anvender DDM (Dynamic Data Masking) i semantiske Direct Lake-modeller, understøttes ikke.

Hvis du vil vide mere om, hvordan du vælger, hvilke tabeller der skal medtages i din semantiske Direct Lake-model, skal du se Rediger tabeller for Semantiske Direct Lake-modeller.

Du kan få flere oplysninger om kolonner, der skal medtages i dine semantiske modeltabeller, under Forstå lager til semantiske Direct Lake-modeller.

Gennemtving regler for dataadgang

Når du har krav om at levere undersæt af modeldata til forskellige brugere, kan du gennemtvinge regler for dataadgang. Du gennemtvinger regler ved at konfigurere sikkerhed på objektniveau (OLS) og/eller sikkerhed på rækkeniveau (RLS) i SQL Analytics-slutpunktet eller i den semantiske model.

Bemærk

Emnet om håndhævelse af regler for dataadgang er anderledes, men relateret til angivelse af tilladelser for indholdsforbrugere, oprettere og brugere, der skal administrere den semantiske model (og relaterede Fabric-elementer). Du kan få flere oplysninger om angivelse af tilladelser under Administrer semantiske Direct Lake-modeller.

Sikkerhed på objektniveau (OLS)

OLS omfatter begrænsning af adgangen til at finde og forespørge objekter eller kolonner. Du kan f.eks. bruge OLS til at begrænse de brugere, der kan få adgang til kolonnen Salary fra tabellen Employee .

I forbindelse med et SQL Analytics-slutpunkt kan du konfigurere OLS til at styre adgangen til slutpunktsobjekter, f.eks. tabeller eller visninger, og sikkerhed på kolonneniveau (CLS) for at styre adgangen til slutpunktstabelkolonner.

For en semantisk model kan du konfigurere OLS til at styre adgangen til modeltabeller eller -kolonner. Du skal bruge værktøjer med åben kildekode, f.eks. Tabular Editor, til at konfigurere OLS.

Sikkerhed på rækkeniveau

Sikkerhed på rækkeniveau omfatter begrænsning af adgangen til undersæt af data i tabeller. Du kan f.eks. bruge sikkerhed på rækkeniveau til at sikre, at sælgere kun kan få adgang til salgsdata for kunder i deres salgsområde.

For et SQL Analytics-slutpunkt kan du konfigurere sikkerhed på rækkeniveau til at styre adgangen til rækker i en slutpunktstabel.

Vigtigt

Når en forespørgsel bruger en tabel, der har sikkerhed på rækkeniveau i SQL-analyseslutpunktet, vender den tilbage til DirectQuery-tilstand. Forespørgselsydeevnen kan være langsommere.

For en semantisk model kan du konfigurere sikkerhed på rækkeniveau til at styre adgangen til rækker i modeltabeller. Sikkerhed på rækkeniveau kan konfigureres i webmodelleringsoplevelsen eller ved hjælp af et tredjepartsværktøj.

Sådan evalueres forespørgsler

Grunden til at udvikle semantiske Direct Lake-modeller er at opnå forespørgsler med høj ydeevne over store datamængder i OneLake. Derfor bør du bestræbe dig på at designe en løsning, der maksimerer chancerne for forespørgsler i hukommelsen.

Følgende trin angiver, hvordan forespørgsler evalueres (og om de mislykkes). Fordelene ved Direct Lake-lagringstilstanden er kun mulige, når det femte trin er nået.

  1. Hvis forespørgslen indeholder en tabel eller kolonne, der er begrænset af semantisk ols-model, returneres der et fejlresultat (rapportvisualiseringen gengives ikke).
  2. Hvis forespørgslen indeholder en kolonne, der er begrænset af SQL Analytics-slutpunktet CLS (eller tabellen er nægtet), returneres der et fejlresultat (rapportvisualiseringen kan ikke gengives).
    1. Hvis cloudforbindelsen bruger SSO (standard), bestemmes CLS af rapportforbrugerens adgangsniveau.
    2. Hvis cloudforbindelsen bruger en fast identitet, bestemmes CLS af adgangsniveauet for den faste identitet.
  3. Hvis forespørgslen indeholder en tabel i SQL Analytics-slutpunktet, der gennemtvinger sikkerhed på rækkeniveau, eller der bruges en visning, går forespørgslen tilbage til DirectQuery-tilstand.
    1. Hvis cloudforbindelsen bruger SSO (standard), bestemmes sikkerhed på rækkeniveau af adgangsniveauet for rapportforbruger.
    2. Hvis cloudforbindelsen bruger en fast identitet, bestemmes sikkerhed på rækkeniveau af adgangsniveauet for den faste identitet.
  4. Hvis forespørgslen overskrider gelænderne for kapaciteten, går den tilbage til DirectQuery-tilstand.
  5. Ellers opfyldes forespørgslen fra cachen i hukommelsen. Kolonnedata indlæses i hukommelsen , når og når det er påkrævet.

Tilladelser til kildeelement

Den konto, der bruges til at få adgang til data, er en af følgende.

  • Hvis cloudforbindelsen bruger SSO (standard), er det rapportens forbruger.
  • Hvis cloudforbindelsen bruger en fast identitet, er det den faste identitet.

Kontoen skal som minimum have tilladelsen Læs og ReadData for kildeelementet (lakehouse eller warehouse). Elementtilladelser kan nedarves fra arbejdsområderoller eller tildeles eksplicit for elementet som beskrevet i denne artikel.

Hvis dette krav er opfyldt, giver Fabric den nødvendige adgang til den semantiske model for at læse Delta-tabellerne og de tilknyttede Parquet-filer (for at indlæse kolonnedata i hukommelsen), og der kan anvendes regler for dataadgang.

Indstillinger for dataadgangsregel

Du kan konfigurere regler for dataadgang i:

  • Kun den semantiske model.
  • Kun SQL-analyseslutpunktet.
  • I både den semantiske model og SQL Analytics-slutpunktet.

Regler i den semantiske model

Hvis du skal gennemtvinge regler for dataadgang, skal du gøre det i den semantiske model, når det er muligt. Det skyldes, at RLS, der gennemtvinges af den semantiske model, opnås ved at filtrere cachen i hukommelsen for data for at opnå forespørgsler med høj ydeevne.

Det er også en passende tilgang, når rapportforbrugere ikke får tilladelse til at forespørge lakehouse eller warehouse.

I begge tilfælde anbefales det på det kraftigste, at cloudforbindelsen bruger en fast identitet i stedet for SSO. SSO indebærer, at slutbrugerne kan få direkte adgang til SQL-analyseslutpunktet og derfor kan tilsidesætte sikkerhedsregler i den semantiske model.

Vigtigt

Tilladelser for semantiske modelelement kan angives eksplicit via Power BI-apps eller erhverves implicit via arbejdsområderoller.

Regler for dataadgang til semantiske modeller gennemtvinges ikke for brugere, der har skrivetilladelse til den semantiske model. Omvendt gælder regler for dataadgang for brugere, der er tildelt rollen Fremviser i arbejdsområdet. Brugere, der er tildelt arbejdsområderollen Administrator, Medlem eller Bidragyder , har dog implicit skrivetilladelse til den semantiske model, og derfor gennemtvinges regler for dataadgang ikke. Du kan få flere oplysninger under Roller i arbejdsområder.

Regler i SQL Analytics-slutpunktet

Det er hensigtsmæssigt at gennemtvinge regler for dataadgang i SQL Analytics-slutpunktet, når den semantiske modelskyforbindelsebruger enkeltlogon (SSO). Det skyldes, at brugerens identitet delegeres for at forespørge SQL Analytics-slutpunktet, så det sikres, at forespørgsler kun returnerer de data, som brugeren har adgang til. Det er også hensigtsmæssigt at gennemtvinge regler for dataadgang på dette niveau, når brugerne forespørger SQL-analyseslutpunktet direkte om andre arbejdsbelastninger (f.eks. for at oprette en sideinddelt rapport i Power BI eller eksportere data).

En semantisk modelforespørgsel vender dog tilbage til DirectQuery-tilstand, når den indeholder en tabel, der gennemtvinger sikkerhed på rækkeniveau i SQL-analyseslutpunktet. Derfor cachelagrer den semantiske model muligvis aldrig data i hukommelsen for at opnå forespørgsler med høj ydeevne.

Regler på begge lag

Regler for dataadgang kan gennemtvinges i begge lag. Denne tilgang omfatter dog ekstra kompleksitet og administrationsomkostninger. I dette tilfælde anbefales det på det kraftigste, at cloudforbindelsen bruger en fast identitet i stedet for SSO.

Sammenligning af indstillinger for dataadgangsregel

I følgende tabel sammenlignes indstillinger for konfiguration af dataadgang.

Anvend regler for dataadgang på Kommentar
Kun semantisk model Brug denne indstilling, når brugerne ikke får tildelt elementtilladelser til at forespørge lakehouse eller warehouse. Konfigurer cloudforbindelsen for at bruge en fast identitet. Høj forespørgselsydeevne kan opnås fra cachen i hukommelsen.
Kun SQL-analyseslutpunkt Brug denne indstilling, når brugerne har brug for at få adgang til data fra enten lageret eller den semantiske model og med ensartede regler for dataadgang. Sørg for, at SSO er aktiveret for cloudforbindelsen. Forespørgselsydeevnen kan være langsom.
Lakehouse eller warehouse og semantisk model Denne indstilling omfatter ekstra administrationsomkostninger. Konfigurer cloudforbindelsen for at bruge en fast identitet.

Her er anbefalede fremgangsmåder i forbindelse med håndhævelse af regler for dataadgang:

  • Hvis forskellige brugere skal begrænses til undersæt af data, skal RLS kun gennemtvinges på det semantiske modellag, når de er levedygtige. På den måde kan brugerne drage fordel af forespørgsler i hukommelsen med høj ydeevne. I dette tilfælde anbefales det på det kraftigste, at cloudforbindelsen bruger en fast identitet i stedet for SSO.
  • Hvis det er muligt, skal du undgå at gennemtvinge OLS og CLS på begge lag, fordi det resulterer i fejl i rapportvisualiseringer. Fejl kan føre til 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).

Understøttelse af modelskrivning med XMLA-slutpunktet

Semantiske Direct Lake-modeller understøtter skrivehandlinger med XMLA-slutpunktet ved hjælp af værktøjer som f.eks. SSMS (19.1 eller nyere) og communityværktøjer med åben kildekode.

Tip

Du kan få flere oplysninger om, hvordan du bruger tredjepartsværktøjer til at udvikle, administrere eller optimere semantiske modeller, i brugsscenariet for administration af avancerede datamodeller.

Før du kan udføre skrivehandlinger, skal indstillingen XMLA med læse-/skriveadgang være aktiveret for kapaciteten. Du kan få flere oplysninger under Aktivér læse- og skriveadgang til XMLA.

Modelskrivningshandlinger med 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. Du kan finde flere oplysninger under Administration af indholdslivscyklus.
  • Automatiseringsopgaver, f.eks. opdatering af semantiske modeller, og anvendelse af ændringer på Semantiske Direct Lake-modeller ved hjælp af PowerShell og REST API'er.

Når du ændrer en semantisk model ved hjælp af XMLA, skal du opdatere Samlingen ChangedProperties og PBI_RemovedChildren for det ændrede objekt, så den indeholder eventuelle ændrede eller fjernede egenskaber. Hvis du ikke udfører denne opdatering, overskriver Power BI-modelleringsværktøjer muligvis eventuelle ændringer, næste gang skemaet synkroniseres med Lakehouse.

Få mere at vide om semantiske modelobjektafstamningskoder i artiklen afstamningskoder for semantiske Power BI-modeller artikel.

Vigtigt

Direct Lake-tabeller, der oprettes ved hjælp af XMLA-programmer, vil indledningsvist være i ubehandlet tilstand, indtil programmet sender en opdateringskommando. Forespørgsler, der involverer ikke-behandlede tabeller, vender altid tilbage til DirectQuery-tilstand. Så når du opretter en ny semantisk model, skal du sørge for at opdatere modellen for at behandle dens tabeller.

Du kan finde flere oplysninger under Semantisk modelforbindelse med XMLA-slutpunktet.

Direct Lake-modelmetadata

Når du opretter forbindelse til en semantisk Direct Lake-model med XMLA-slutpunktet, ligner metadataene en hvilken som helst anden model. Direct Lake-modeller viser dog følgende forskelle:

  • Egenskaben compatibilityLevel for databaseobjektet er 1604 (eller højere).
  • Tilstandsegenskaben for Direct Lake-partitioner er angivet til directLake.
  • Direct Lake-partitioner bruger delte udtryk til at definere datakilder. Udtrykket peger på SQL Analytics-slutpunktet for lakehouse eller warehouse. Direct Lake bruger SQL Analytics-slutpunktet til at finde skema- og sikkerhedsoplysninger, men de indlæses direkte fra OneLake (medmindre de af en eller anden grund går tilbage til DirectQuery-tilstand ).

Opgaver efter publicering

Når du har publiceret en semantisk Direct Lake-model, skal du udføre nogle konfigurationsopgaver. Du kan få flere oplysninger under Administrer semantiske Direct Lake-modeller.

Funktioner, der ikke understøttes

Følgende modelfunktioner understøttes ikke af semantiske Direct Lake-modeller:

  • Beregnede tabeller, der refererer til tabeller eller kolonner i Direct Lake-lagringstilstand
  • Beregnede kolonner, der refererer til tabeller eller kolonner i Direct Lake-lagringstilstand
  • Hybride tabeller
  • Brugerdefinerede sammenlægninger
  • Sammensatte modeller, hvor du ikke kan kombinere Direct Lake-lagertilstandstabeller med DirectQuery- eller Dual-lagringstilstandstabeller i den samme model. Du kan dog bruge Power BI Desktop til at oprette en direkte forbindelse til en semantisk Direct Lake-model og derefter udvide den med nye målinger, og herfra kan du klikke på indstillingen for at foretage ændringer af denne model for at tilføje nye tabeller (ved hjælp af import-, DirectQuery- eller Dual-lagringstilstand). Denne handling opretter en DirectQuery-forbindelse til den semantiske model i Direct Lake-tilstand, så tabellerne vises som DirectQuery-lagringstilstand, men denne lagringstilstand angiver ikke fallback til DirectQuery. Det er kun forbindelsen mellem denne nye model og Direct Lake-modellen, der er DirectQuery, og forespørgsler bruger stadig Direct Lake til at hente data fra OneLake. Du kan få flere oplysninger under Opret en sammensat model på en semantisk model.
  • Kolonner, der er baseret på sql analytics-slutpunktskolonner, der anvender dynamisk datamaskering.

Relateret indhold