Delen via

Semantische Direct Lake-modellen ontwikkelen

  • Artikel

In dit artikel worden ontwerponderwerpen beschreven die relevant zijn voor het ontwikkelen van semantische Direct Lake-modellen.

Het model maken

U gebruikt de Fabric-portal om een semantisch Direct Lake-model in een werkruimte te maken. Het is een eenvoudig proces waarbij u selecteert welke tabellen uit één lakehouse of magazijn moeten worden toegevoegd aan het semantische model.

Vervolgens kunt u de webmodelleringservaring gebruiken om het semantische model verder te ontwikkelen. Met deze ervaring kunt u relaties tussen tabellen maken, metingen en berekeningsgroepen maken, datumtabellen markeren en eigenschappen instellen voor het model en de bijbehorende objecten (zoals kolomindelingen). U kunt het model ook instellen beveiliging op rijniveau (RLS) door rollen en regels te definiëren en door leden (Microsoft Entra-gebruikersaccounts of beveiligingsgroepen) toe te voegen aan deze rollen.

U kunt ook de ontwikkeling van uw model voortzetten met behulp van een XMLA-compatibel hulpprogramma, zoals SQL Server Management Studio (SSMS) (versie 19.1 of hoger) of opensource-communityhulpprogramma's. Zie Ondersteuning voor het schrijven van modellen met het XMLA-eindpunt verderop in dit artikel voor meer informatie.

Tip

U kunt leren hoe u een lakehouse, een Delta-tabel en een eenvoudig semantisch Direct Lake-model maakt door deze zelfstudie te voltooien.

Modeltabellen

Modeltabellen zijn gebaseerd op een tabel of een weergave van het SQL Analytics-eindpunt. Vermijd het gebruik van weergaven echter waar mogelijk. Dat komt doordat query's naar een modeltabel op basis van een weergave altijd terugvallen op de DirectQuery-modus, wat kan leiden tot tragere queryprestaties.

Tabellen moeten kolommen bevatten voor filteren, groeperen, sorteren en samenvatten, naast kolommen die modelrelaties ondersteunen. Hoewel onnodige kolommen geen invloed hebben op de prestaties van semantische modellenquery's (omdat ze niet in het geheugen worden geladen), resulteren ze in een grotere opslaggrootte in OneLake en vereisen ze meer rekenresources om te laden en te onderhouden.

Waarschuwing

Het gebruik van kolommen die dynamische gegevensmaskering (DDM) toepassen in semantische Direct Lake-modellen, wordt niet ondersteund.

Zie Tabellen bewerken voor semantische Direct Lake-modellenvoor meer informatie over het selecteren van de tabellen die u wilt opnemen in uw Direct Lake-semantische model.

Zie Inzicht in opslag voor Direct Lake-semantische modellenvoor meer informatie over welke kolommen in uw semantische modellen opgenomen moeten worden.

Regels voor gegevenstoegang afdwingen

Wanneer u vereisten hebt voor het leveren van subsets van modelgegevens aan verschillende gebruikers, kunt u regels voor gegevenstoegang afdwingen. U dwingt regels af door BEVEILIGING op objectniveau (OLS) en/of beveiliging op rijniveau (RLS) in te stellen in het SQL Analytics-eindpunt of in het semantische model.

Notitie

Het onderwerp van het afdwingen van regels voor gegevenstoegang verschilt, maar is gerelateerd aan het instellen van machtigingen voor inhoudsgebruikers, makers en gebruikers die het semantische model (en gerelateerde Fabric-items) beheren. Zie Direct Lake-semantische modellen beherenvoor meer informatie over het instellen van machtigingen.

Beveiliging op objectniveau (OLS)

OLS omvat het beperken van de toegang tot het detecteren en opvragen van objecten of kolommen. U kunt bijvoorbeeld OLS gebruiken om de gebruikers te beperken die toegang hebben tot de Salary kolom uit de Employee tabel.

Voor een SQL-analyse-eindpunt kunt u OLS instellen om de toegang tot de eindpuntobjecten tebeheren, zoals tabellen of weergaven, en cls (beveiliging op kolomniveau) om de toegang tot kolommen van eindpunttabellen te beheren.

Voor een semantisch model kunt u OLS instellen om de toegang tot modeltabellen of -kolommente beheren. U moet opensource-communityhulpprogramma's zoals Tabular Editor gebruiken om OLS in te stellen.

Beveiliging op rijniveau (RLS)

RLS omvat het beperken van de toegang tot subsets van gegevens in tabellen. U kunt bijvoorbeeld RLS gebruiken om ervoor te zorgen dat verkopers alleen toegang hebben tot verkoopgegevens voor klanten in hun verkoopregio.

Voor een SQL-analyse-eindpunt kunt u RLS instellen om de toegang tot rijen in een eindpunttabel te beheren.

Belangrijk

Wanneer een query gebruikmaakt van een tabel met RLS in het SQL Analytics-eindpunt, wordt deze teruggezet naar de DirectQuery-modus. De prestaties van query's kunnen trager zijn.

Voor een semantisch model kunt u RLS instellen om de toegang tot rijen in modeltabellen te regelen . RLS kan worden ingesteld in de webmodelleringservaring of met behulp van een hulpprogramma van derden.

Hoe de queries worden geëvalueerd

De reden om semantische Direct Lake-modellen te ontwikkelen is het bereiken van query's met hoge prestaties ten opzichte van grote hoeveelheden gegevens in OneLake. Daarom moet u ernaar streven om een oplossing te ontwerpen waarmee de kans op query's in het geheugen wordt gemaximaliseerd.

In de volgende stappen wordt geschat hoe query's worden geëvalueerd (en of ze mislukken). De voordelen van de Direct Lake-opslagmodus zijn alleen mogelijk wanneer de vijfde stap wordt bereikt.

  1. Als de query een tabel of kolom bevat die wordt beperkt door semantisch model OLS, wordt een foutresultaat geretourneerd (rapportvisual kan niet worden weergegeven).
  2. Als de query een kolom bevat die wordt beperkt door SQL Analytics-eindpunt CLS (of de tabel wordt geweigerd), wordt een foutresultaat geretourneerd (rapportvisual kan niet worden weergegeven).
    1. Als voor de cloudverbinding SSO (standaard) wordt gebruikt, wordt CLS bepaald door het toegangsniveau van de rapportgebruiker.
    2. Als de cloudverbinding een vaste identiteit gebruikt, wordt CLS bepaald door het toegangsniveau van de vaste identiteit.
  3. Als de query een tabel bevat in het SQL Analytics-eindpunt dat RLS afdwingt of een weergave wordt gebruikt, valt de query terug in de DirectQuery-modus.
    1. Als de cloudverbinding gebruikmaakt van eenmalige aanmelding (standaard), wordt RLS bepaald door het toegangsniveau van de rapportgebruiker.
    2. Als de cloudverbinding een vaste identiteit gebruikt, wordt RLS bepaald door het toegangsniveau van de vaste identiteit.
  4. Als de query de kaders van de capaciteitoverschrijdt, valt deze terug naar de DirectQuery-modus.
  5. Anders wordt aan de query voldaan vanuit de cache in het geheugen. Kolomgegevens worden in het geheugen geladen zodra en wanneer deze nodig zijn.

Machtigingen voor bronitem

Het account dat wordt gebruikt voor toegang tot gegevens, is een van de volgende opties.

  • Als voor de cloudverbinding SSO (Single Sign-On, standaard) wordt gebruikt, is dit de rapportgebruiker.
  • Als de cloudverbinding een vaste identiteit gebruikt, is dit de vaste identiteit.

Het account moet ten minste Lees- en ReadData--machtigingen hebben voor het bronitem (lakehouse of warehouse). Itemmachtigingen kunnen worden overgenomen van werkruimterollen of expliciet aan het item worden toegewezen, zoals beschreven in dit artikel.

Ervan uitgaande dat aan deze vereiste wordt voldaan, verleent Fabric de benodigde toegang tot het semantische model om de Delta-tabellen en bijbehorende Parquet-bestanden te lezen (om kolomgegevens in het geheugen te laden) en regels voor gegevenstoegang kunnen worden toegepast.

Opties voor regels voor gegevenstoegang

U kunt regels voor gegevenstoegang instellen in:

  • Alleen het semantische model.
  • Alleen het SQL-analyse-eindpunt.
  • In zowel het semantische model als het SQL-analyse-eindpunt.

Regels in het semantische model

Als u regels voor gegevenstoegang moet afdwingen, moet u dit doen in het semantische model wanneer dit haalbaar is. Dat komt doordat RLS die door het semantische model wordt afgedwongen, wordt bereikt door de cache in het geheugen van gegevens te filteren om query's met hoge prestaties te bereiken.

Het is ook een geschikte benadering wanneer rapportgebruikers geen toestemming krijgen om een query uit te voeren op het lakehouse of magazijn.

In beide gevallen wordt sterk aanbevolen dat de cloudverbinding een vaste identiteit gebruikt in plaats van SSO (Single Sign-On). SSO (single sign-on) impliceert dat eindgebruikers rechtstreeks toegang zouden kunnen hebben tot het SQL Analytics-eindpunt en daardoor mogelijk beveiligingsregels in het semantische model kunnen omzeilen.

Belangrijk

Semantische machtigingen voor modelitems kunnen expliciet worden ingesteld via Power BI-appsof impliciet verkregen via werkruimterollen.

Met name semantische regels voor gegevenstoegang van semantische modellen worden niet afgedwongen voor gebruikers met machtiging schrijven voor het semantische model. Omgekeerd zijn regels voor gegevenstoegang van toepassing op gebruikers die zijn toegewezen aan de rol Viewer werkruimte. Gebruikers die zijn toegewezen aan de Admin, Member, of Inzender werkruimte rol, hebben impliciet schrijfrechten voor het semantische model, waardoor regels voor gegevenstoegang niet worden afgedwongen. Zie Rollen in werkruimtenvoor meer informatie.

Regels in het SQL Analytics-eindpunt

Het is geschikt om regels voor gegevenstoegang af te dwingen in het SQL Analytics-eindpunt wanneer het semantische model cloudverbinding gebruikmaakt van eenmalige aanmelding (SSO). Dat komt doordat de identiteit van de gebruiker wordt gedelegeerd om een query uit te voeren op het SQL Analytics-eindpunt, zodat query's alleen de gegevens retourneren waartoe de gebruiker toegang heeft. Het is ook geschikt om regels voor gegevenstoegang op dit niveau af te dwingen wanneer gebruikers rechtstreeks een query uitvoeren op het SQL-analyse-eindpunt voor andere workloads (bijvoorbeeld om een gepagineerd Power BI-rapport te maken of gegevens te exporteren).

Echter wordt een semantische modelquery teruggezet naar de DirectQuery-modus wanneer het een tabel bevat die RLS (beveiliging op rijniveau) afdwingt in het SQL-analyse-eindpunt. Daarom kan het semantische model nooit gegevens in het geheugen opslaan om query's met hoge prestaties te bereiken.

Regels op beide lagen

Regels voor gegevenstoegang kunnen op beide lagen worden afgedwongen. Deze aanpak omvat echter extra complexiteit en beheeroverhead. In dit geval wordt het sterk aanbevolen dat de cloudverbinding een vaste identiteit gebruikt in plaats van SSO.

Vergelijking van opties voor regels voor gegevenstoegang

In de volgende tabel worden opties voor het instellen van gegevenstoegang vergeleken.

Regels voor gegevenstoegang toepassen op Commentaar
Alleen semantisch model Gebruik deze optie wanneer gebruikers geen itemmachtigingen krijgen om een query uit te voeren op het lakehouse of magazijn. Stel de cloudverbinding in om een vaste identiteit te gebruiken. Hoge queryprestaties kunnen worden bereikt vanuit de cache in het geheugen.
Alleen SQL Analytics-eindpunt Gebruik deze optie wanneer gebruikers toegang moeten hebben tot gegevens uit het magazijn of het semantische model, en met consistente regels voor gegevenstoegang. Zorg ervoor dat Single Sign-On (SSO) is ingeschakeld voor de cloudverbinding. De prestaties van query's kunnen traag zijn.
Lakehouse ofwel magazijn en model semantisch Deze optie omvat extra beheeroverhead. Stel de cloudverbinding in om een vaste identiteit te gebruiken.

Hier volgen aanbevolen procedures met betrekking tot het afdwingen van regels voor gegevenstoegang:

  • Als verschillende gebruikers beperkt moeten worden tot subsets van gegevens, moet u, wanneer mogelijk, RLS alleen afdwingen op de semantische modellaag. Op die manier profiteren gebruikers van krachtige query's in het geheugen. In dit geval wordt ten sterkste aanbevolen dat de cloudverbinding een vaste identiteit gebruikt in plaats van SSO.
  • Vermijd indien mogelijk het afdwingen van OLS en CLS op beide lagen, omdat dit fouten in rapportvisuals oplevert. Fouten kunnen leiden tot verwarring of bezorgdheid voor gebruikers. Voor samenvatbare kolommen kunt u overwegen maatregelen te creëren die BLANK retourneren onder bepaalde voorwaarden in plaats van CLS (indien mogelijk).

Ondersteuning voor modelschrijfbewerkingen met het XMLA-eindpunt

Direct Lake-semantische modellen ondersteunen schrijfbewerkingen met het XMLA-eindpunt met behulp van hulpprogramma's zoals SSMS (19.1 of hoger) en opensource-communityhulpprogramma's.

Tip

Zie het geavanceerde gegevensmodelbeheer gebruiksscenario voor meer informatie over het gebruik van hulpprogramma's van derden voor het ontwikkelen, beheren of optimaliseren van semantische modellen.

Voordat u schrijfbewerkingen kunt uitvoeren, moet de optie lezen/schrijven van XMLA zijn ingeschakeld voor de capaciteit. Zie XMLA-lees-/schrijfbewerkingen inschakelenvoor meer informatie.

Schrijfbewerkingen modelleren met ondersteuning voor XMLA-eindpunten:

  • Aanpassen, samenvoegen, scripten, foutopsporing en het testen van metagegevens van Het Direct Lake-model.
  • Bron- en versiebeheer, continue integratie en continue implementatie (CI/CD) met Azure DevOps en GitHub. Zie Levenscyclusbeheer voor inhoudvoor meer informatie.
  • Automatiseringstaken zoals semantische modelvernieuwing en het toepassen van wijzigingen in Direct Lake-semantische modellen met behulp van PowerShell en de REST API's.

Wanneer u een semantisch model wijzigt met XMLA, moet u de ChangedProperties- en PBI_RemovedChildren verzameling voor het gewijzigde object bijwerken om gewijzigde of verwijderde eigenschappen op te nemen. Als u deze update niet uitvoert, kunnen power BI-modelleringshulpprogramma's wijzigingen overschrijven wanneer het schema de volgende keer wordt gesynchroniseerd met Lakehouse.

Meer informatie over semantische modelobjectherkomsttags vindt u in het herkomsttags voor semantische Power BI-modellen artikel.

Belangrijk

Direct Lake-tabellen die zijn gemaakt met behulp van XMLA-toepassingen, hebben in eerste instantie een niet-verwerkte status totdat de toepassing een vernieuwingsopdracht verzendt. Query's die betrekking hebben op niet-verwerkte tabellen, vallen altijd terug naar de DirectQuery-modus. Wanneer u dus een nieuw semantisch model maakt, moet u het model vernieuwen om de tabellen te verwerken.

Zie Semantische modelconnectiviteit met het XMLA-eindpuntvoor meer informatie.

Metagegevens van Direct Lake-model

Wanneer u verbinding maakt met een Direct Lake-semantisch model met het XMLA-eindpunt, zien de metagegevens eruit als die van een ander model. Direct Lake-modellen tonen echter de volgende verschillen:

  • De eigenschap compatibilityLevel van het databaseobject is 1604 (of hoger).
  • De moduseigenschap van Direct Lake-partities is ingesteld op directLake.
  • Direct Lake-partities maken gebruik van gedeelde expressies om gegevensbronnen te definiëren. De expressie verwijst naar het SQL-analyse-eindpunt van het lakehouse of warehouse. Direct Lake maakt gebruik van het SQL Analytics-eindpunt om schema- en beveiligingsgegevens te detecteren, maar laadt de gegevens rechtstreeks vanuit OneLake (tenzij het om welke reden dan ook terugvalt naar de DirectQuery--modus).

Taken na publicatie

Nadat u een semantisch Direct Lake-model hebt gepubliceerd, moet u enkele installatietaken uitvoeren. Zie Semantische direct lake-modellen beherenvoor meer informatie.

Niet-ondersteunde functies

De volgende modelfuncties worden niet ondersteund door semantische Direct Lake-modellen:

  • Berekende tabellen die verwijzen naar tabellen of kolommen in de Direct Lake-opslagmodus
  • Berekende kolommen die verwijzen naar tabellen of kolommen in de Direct Lake-opslagmodus
  • Hybride tabellen
  • Door de gebruiker gedefinieerde aggregaties
  • Samengestelde modellen, omdat u tabellen in de Direct Lake-opslagmodus niet kunt combineren met DirectQuery- of Dual-opslagmodustabellen in hetzelfde model. U kunt Power BI Desktop echter gebruiken om een liveverbinding met een semantisch Direct Lake-model te maken en het vervolgens uit te breiden met nieuwe metingen. Van daaruit kunt u klikken op de optie om wijzigingen aan te brengen in dit model nieuwe tabellen toe te voegen (met behulp van de import-, DirectQuery- of Dual-opslagmodus). Met deze actie maakt u een DirectQuery-verbinding met het semantische model in de Direct Lake-modus, zodat de tabellen worden weergegeven als DirectQuery-opslagmodus, maar deze opslagmodus geeft geen terugval naar DirectQuery aan. Alleen de verbinding tussen dit nieuwe model en het Direct Lake-model is DirectQuery en query's maken nog steeds gebruik van Direct Lake om gegevens op te halen uit OneLake. Zie Een samengesteld model bouwen op een semantisch modelvoor meer informatie.
  • Kolommen op basis van SQL Analytics-eindpuntkolommen die dynamische gegevensmaskering toepassen.

Verwante inhoud