Dela via

Utveckla Direct Lake-semantiska modeller

  • Artikel

Den här artikeln beskriver designämnen som är relevanta för att utveckla Direct Lake-semantiska modeller.

Skapa modellen

Du använder Fabric-portalen för att skapa en semantisk modell för Direct Lake i en arbetsyta. Det är en enkel process som innebär att du väljer vilka tabeller från ett enda sjöhus eller lager som ska läggas till i semantikmodellen.

Du kan sedan använda webbmodelleringsupplevelse för att utveckla den semantiska modellen ytterligare. Med den här upplevelsen kan du skapa relationer mellan tabeller, skapa mått och beräkningsgrupper, markera datumtabeller och ange egenskaper för modellen och dess objekt (till exempel kolumnformat). Du kan också konfigurera modell säkerhet på radnivå (RLS) genom att definiera roller och regler och genom att lägga till medlemmar (Microsoft Entra-användarkonton eller säkerhetsgrupper) i dessa roller.

Du kan också fortsätta utvecklingen av din modell med hjälp av ett XMLA-kompatibelt verktyg, till exempel SQL Server Management Studio (SSMS) (version 19.1 eller senare) eller communityverktyg med öppen källkod. Mer information finns i skrivstöd för modell med XMLA-slutpunkten senare i den här artikeln.

Tips

Du kan lära dig hur du skapar ett lakehouse, en Delta-tabell och en grundläggande Direct Lake-semantisk modell genom att slutföra den här handledningen.

Modelltabeller

Modelltabeller baseras antingen på en tabell eller en vy över SQL-analysslutpunkten. Undvik dock att använda vyer när det är möjligt. Det beror på att förfrågningar till en modelltabell som baseras på en vy alltid återgår till DirectQuery-läget, vilket kan resultera i långsammare prestanda för förfrågningar.

Tabeller bör innehålla kolumner för filtrering, gruppering, sortering och sammanfattning, förutom kolumner som stöder modellrelationer. Även om onödiga kolumner inte påverkar semantisk modell frågeprestanda (eftersom de inte läses in i minnet), resulterar de i en större lagringsstorlek i OneLake och kräver fler beräkningsresurser för att läsa in och underhålla.

Varning

Det går inte att använda kolumner som använder DDM- i Direct Lake-semantiska modeller.

Information om hur du väljer vilka tabeller som ska ingå i direct lake-semantikmodellen finns i Redigera tabeller för Direct Lake-semantiska modeller.

Mer information om kolumner som ska ingå i dina semantiska modelltabeller finns i Förstå lagring för Direct Lake-semantiska modeller.

Framtvinga regler för dataåtkomst

När du har krav på att leverera delmängder av modelldata till olika användare kan du tillämpa regler för dataåtkomst. Du framtvingar regler genom att konfigurera säkerhet på objektnivå (OLS) och/eller säkerhet på radnivå (RLS) i SQL-analysslutpunkt eller i den semantiska modellen.

Not

Ämnet för att genomdriva regler för dataåtkomst skiljer sig från, men är ändå relaterat till, att ange behörigheter för innehållskonsumenter, skapare och användare som ska hantera den semantiska modellen (och relaterade Fabric-element). Mer information om hur du anger behörigheter finns i Hantera Direct Lake-semantiska modeller.

Säkerhet på objektnivå (OLS)

OLS innebär att begränsa åtkomsten till att identifiera och fråga efter objekt eller kolumner. Du kan till exempel använda OLS för att begränsa de användare som har åtkomst till kolumnen Salary från tabellen Employee.

För en SQL-analysslutpunkt kan du konfigurera OLS för att styra åtkomsten till slutpunktsobjekten, till exempel tabeller eller vyer, och säkerhet på kolumnnivå (CLS) för att styra åtkomsten till slutpunktstabellkolumner.

För en semantisk modell kan du konfigurera OLS för att styra åtkomsten till modelltabeller eller kolumner. Du måste använda communityverktyg med öppen källkod som Tabellredigeraren för att konfigurera OLS.

Säkerhet på radnivå (RLS)

RLS innebär att begränsa åtkomsten till delmängder av data i tabeller. Du kan till exempel använda RLS för att se till att säljare bara kan komma åt försäljningsdata för kunder i sin försäljningsregion.

För en SQL-analysslutpunkt kan du konfigurera RLS för att styra åtkomsten till rader i en slutpunktstabell.

Viktig

När en fråga använder en tabell som har RLS i SQL-analysslutpunkten återgår den till DirectQuery-läge. Frågeprocessens prestanda kan bli långsammare.

För en semantisk modell kan du konfigurera RLS för att styra åtkomsten till rader i modelltabeller. RLS kan konfigureras i webbmodelleringsmiljön eller med hjälp av ett verktyg från tredje part.

Så utvärderas frågor

Den anledningen till att utveckla Direct Lake-semantiska modeller är att uppnå frågor med höga prestanda över stora mängder data i OneLake. Därför bör du sträva efter att utforma en lösning som maximerar möjligheterna för minnesintern frågekörning.

Följande steg beskriver hur frågor utvärderas (och om de misslyckas). Fördelarna med Direct Lake-lagringsläget är bara möjliga när det femte steget uppnås.

  1. Om frågan innehåller en tabell eller kolumn som begränsas av semantisk modell OLS returneras ett felresultat (det visuella rapportobjektet kan inte återges).
  2. Om frågan innehåller en kolumn som begränsas av SQL-analysslutpunkten CLS (eller om tabellen nekas) returneras ett felresultat (det visuella rapportobjektet kan inte återges).
    1. Om molnanslutningen använder enkel inloggning (standard) bestäms CLS av rapportkonsumentens åtkomstnivå.
    2. Om molnanslutningen använder en fast identitet bestäms CLS av åtkomstnivån för den fasta identiteten.
  3. Om frågan innehåller en tabell i SQL-analysslutpunkten som framtvingar RLS eller om en vy används, återgår frågan till DirectQuery-läge.
    1. Om molnanslutningen använder enkel inloggning (standard) bestäms RLS av rapportkonsumentens åtkomstnivå.
    2. Om molnanslutningen använder en fast identitet bestäms RLS av åtkomstnivån för den fasta identiteten.
  4. Om frågan överskrider skyddsräckena för kapacitetenåtergår den till DirectQuery-läge.
  5. Annars uppfylls frågan från minnesintern cache. Kolumndata läses in i minnet när och när de behövs.

Behörigheter för källobjekt

Det konto som används för att komma åt data är något av följande.

  • Om molnanslutningen använder SSO (standardinställning) är det rapportmottagaren.
  • Om molnanslutningen använder en fast identitet är det den fasta identiteten.

Kontot måste minst ha Läs och ReadData behörigheter för källobjektet (lakehouse eller lager). Objektbehörigheter kan ärvas från arbetsyteroller eller tilldelas uttryckligen för objektet enligt beskrivningen i den här artikeln.

Förutsatt att detta krav uppfylls ger Fabric nödvändig åtkomst till den semantiska modellen för att läsa Delta-tabellerna och associerade Parquet-filer (för att läsa in kolumndata i minnet) och regler för dataåtkomst kan tillämpas.

Alternativ för dataåtkomstregel

Du kan konfigurera regler för dataåtkomst i:

  • Endast den semantiska modellen.
  • Endast SQL-analysens slutpunkt.
  • I både den semantiska modellen och SQL-analysslutpunkten.

Regler i semantikmodellen

Om du måste tillämpa regler för dataåtkomst bör du göra det i den semantiska modellen när det är möjligt. Det beror på att RLS som framtvingas av semantikmodellen uppnås genom att filtrera minnesintern cache för data för att uppnå frågor med höga prestanda.

Det är också en lämplig metod när rapportkonsumenter inte beviljas behörighet att fråga lakehouse eller lager.

I båda fallen rekommenderar vi starkt att molnanslutningen använder en fast identitet i stället för enkel inloggning. Enkel inloggning skulle innebära att slutanvändarna kan komma åt SQL-analysslutpunkten direkt och därför kringgå säkerhetsregler i semantikmodellen.

Viktig

Behörigheter för semantiska modellobjekt kan anges explicit via Power BI-appar, eller hämtas implicit via arbetsyteroller.

Semantiska regler för dataåtkomst för semantikmodeller tillämpas inte för användare som har Skriv behörighet för semantikmodellen. Å andra sidan gäller regler för dataåtkomst för användare som har tilldelats rollen Viewer arbetsyteroll. Användare som tilldelats rollen Admin, Membereller Deltagare arbetsyteroll har dock implicit skrivbehörighet för semantikmodellen och därför tillämpas inte dataåtkomstregler. Mer information finns i Roller i arbetsytor.

Regler i SQL-analysslutpunkten

Det är lämpligt att tillämpa dataåtkomstregler i SQL-analysändpunkten när den semantiska modellen molnanslutning använder enkel inloggning (SSO). Det beror på att användarens identitet delegeras för att köra frågor mot SQL Analytics-slutpunkten, vilket säkerställer att frågor endast returnerar de data som användaren har åtkomst till. Det är också lämpligt att tillämpa regler för dataåtkomst på den här nivån när användarna frågar SQL-analysslutpunkten direkt efter andra arbetsbelastningar (till exempel för att skapa en sidnumrerad Power BI-rapport eller exportera data).

Framför allt kommer dock en semantisk modellfråga att återgå till DirectQuery-läge när den innehåller alla tabeller som tillämpar RLS i SQL-analysslutpunkten. Därför kanske semantikmodellen aldrig cachelagrar data i minnet för att uppnå frågor med höga prestanda.

Regler i båda lagren

Dataåtkomstregler kan tillämpas i båda lagren. Den här metoden innebär dock extra komplexitet och hanteringskostnader. I det här fallet rekommenderar vi starkt att molnanslutningen använder en fast identitet i stället för enkel inloggning.

Jämförelse av alternativ för dataåtkomstregler

I följande tabell jämförs konfigurationsalternativ för dataåtkomst.

Tillämpa regler för dataåtkomst på Kommentar
Endast semantisk modell Använd det här alternativet när användare inte beviljas objektbehörigheter för att göra frågor i lakehouse eller informationslagret. Konfigurera molnanslutningen så att den använder en fast identitet. Hög frågeprestanda kan uppnås med cache i arbetsminnet.
Endast SQL-analysslutpunkt Använd det här alternativet när användare behöver komma åt data från antingen lagret eller semantikmodellen och med konsekventa regler för dataåtkomst. Kontrollera att SSO är aktiverat för molnanslutningen. Sökfrågans prestanda kan vara långsam.
Lakehouse eller lager och i den semantiska modellen Det här alternativet innebär extra hanteringskostnader. Konfigurera molnanslutningen så att den använder en fast identitet.

Här följer rekommenderade metoder för att framtvinga regler för dataåtkomst:

  • Om olika användare måste begränsas till delmängder av data, ska du när det är möjligt endast tillämpa RLS på det semantiska modellskiktet. På så sätt kan användarna dra nytta av högpresterande frågor som sker direkt i minnet. I det här fallet rekommenderar vi starkt att molnanslutningen använder en fast identitet i stället för enkel inloggning.
  • Undvik om möjligt att tillämpa OLS och CLS i någon av lagren eftersom det resulterar i fel i rapportvisualiseringar. Fel kan leda till förvirring eller problem för användarna. För sammanfattningsbara kolumner bör du överväga att skapa mått som returnerar BLANK under vissa villkor i stället för CLS (om möjligt).

Stöd för modellskrivning med XMLA-slutpunkten

Direct Lake-semantiska modeller stöder skrivåtgärder med XMLA-slutpunkten med hjälp av verktyg som SSMS (19.1 eller senare) och communityverktyg med öppen källkod.

Tips

Mer information om hur du använder verktyg från tredje part för att utveckla, hantera eller optimera semantiska modeller finns i avancerade datamodellhantering användningsscenario.

Innan du kan utföra skrivåtgärder måste XMLA-skrivalternativet vara aktiverat för kapaciteten. Mer information finns i Aktivera XMLA-läs-skriv.

Modellskrivningsåtgärder med XMLA-slutpunktsstöd:

  • Anpassa, slå samman, skripta, felsöka och testa Direct Lake-modellmetadata.
  • Käll- och versionskontroll, kontinuerlig integrering och kontinuerlig distribution (CI/CD) med Azure DevOps och GitHub. Mer information finns i Livscykelhantering för innehåll.
  • Automatiseringsuppgifter som uppdatering av semantisk modell och tillämpning av ändringar i Direct Lake-semantiska modeller med hjälp av PowerShell och REST-API:er.

När du ändrar en semantisk modell med XMLA måste du uppdatera ChangedProperties- och PBI_RemovedChildren samling för det ändrade objektet så att de innehåller ändrade eller borttagna egenskaper. Om du inte utför uppdateringen kan Power BI-modelleringsverktyg skriva över eventuella ändringar nästa gång schemat synkroniseras med Lakehouse.

Läs mer om semantiska modellobjekts ursprungstaggar i artikeln härstamningstaggar för Power BI-semantiska modeller.

Viktig

Direct Lake-tabeller som skapas med hjälp av XMLA-program kommer inledningsvis att vara i ett obearbetat tillstånd tills programmet skickar ett uppdateringskommando. Frågor som involverar obearbetade tabeller återgår alltid till DirectQuery-läge. När du skapar en ny semantisk modell bör du därför uppdatera modellen för att bearbeta dess tabeller.

Mer information finns i semantisk modellanslutning med XMLA-slutpunkten.

Direct Lake-modellmetadata

När du ansluter till en Direct Lake-semantisk modell med XMLA-slutpunkten ser metadata ut som för andra modeller. Direct Lake-modeller visar dock följande skillnader:

  • Egenskapen compatibilityLevel för databasobjektet är 1604 (eller högre).
  • Lägesegenskapen för Direct Lake-partitioner är inställd på directLake.
  • Direct Lake-partitioner använder delade uttryck för att definiera datakällor. Uttrycket pekar på SQL-analysslutpunkten för lakehouse eller lagret. Direct Lake använder SQL-analysslutpunkten för att identifiera schema- och säkerhetsinformation, men läser in data direkt från OneLake (såvida den inte återgår till DirectQuery läge av någon anledning).

Uppgifter efter publicering

När du har publicerat en Direct Lake-semantisk modell bör du utföra vissa konfigurationsuppgifter. Mer information finns i Hantera Direct Lake-semantikmodeller.

Funktioner som inte stöds

Följande modellfunktioner stöds inte av Direct Lake-semantiska modeller:

  • Beräknade tabeller som refererar till tabeller eller kolumner i Direct Lake-lagringsläge
  • Beräknade kolumner som refererar till tabeller eller kolumner i Direct Lake-lagringsläge
  • Hybridtabeller
  • Användardefinierade sammansättningar
  • Sammansatta modeller, eftersom du inte kan kombinera Direct Lake-lagringslägestabeller med DirectQuery- eller dubbla lagringslägestabeller i samma modell. Du kan dock använda Power BI Desktop för att skapa en live-anslutning till en Direct Lake-semantisk modell och sedan utöka den med nya mått, och därifrån kan du klicka på alternativet för att göra ändringar i den här modellen för att lägga till nya tabeller (med import, DirectQuery eller dubbelt lagringsläge). Den här åtgärden skapar en DirectQuery-anslutning till den semantiska modellen i Direct Lake-läge, så tabellerna visas som DirectQuery-lagringsläge, men det här lagringsläget anger inte återställning till DirectQuery. Endast anslutningen mellan den nya modellen och Direct Lake-modellen är DirectQuery och frågor använder fortfarande Direct Lake för att hämta data från OneLake. Mer information finns i Skapa en sammansatt modell på en semantisk modell.
  • Kolumner baserade på SQL-analysslutpunktskolumner som använder dynamisk datamaskering.

Relaterat innehåll