Dela via

Hantera semantiska Direct Lake-modeller

  • Artikel

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

Uppgifter efter publicering

När du har publicerat en Direct Lake-semantisk modell som är redo för rapportering bör du omedelbart slutföra vissa uppgifter efter publiceringen. Dessa uppgifter kan också justeras när som helst under semantikmodellens livscykel.

Du kan också konfigurera dataidentifiering så att rapportskapare kan läsa metadata, vilket hjälper dem att identifiera data i OneLake-datahubben och begära åtkomst till dem. Du kan också godkänna (certifierad eller upphöjd) semantisk modell för att kommunicera att den representerar kvalitetsdata som passar för användning.

Konfigurera molnanslutningen

En Direct Lake-semantisk modell använder en molnanslutning för att ansluta till SQL-analysslutpunkten. Det ger åtkomst till källdata, vilket antingen är Parquet-filerna i OneLake (Direct Lake-lagringsläge, vilket innebär att kolumndata läses in i minnet) eller SQL-analysslutpunkten (när frågor återgår till DirectQuery-läge).

Standardanslutning till molnet

När du skapar en Direct Lake-semantisk modell används standardmolnanslutningen. Den utnyttjar enkel inloggning (SSO), vilket innebär att den identitet som frågar den semantiska modellen (ofta en rapportanvändare) används för att köra frågor mot SQL-analysslutpunktsdata.

Delbar molnanslutning

Du kan också skapa en delbar molnanslutning (SCC) så att anslutningar till datakällan kan göras med en fast identitet. Det kan hjälpa företagskunder att skydda sina organisationsdatalager. IT-avdelningen kan hantera autentiseringsuppgifter, skapa SCC:er och dela dem med de avsedda skaparna för centraliserad åtkomsthantering.

Information om hur du konfigurerar en fast identitet finns i Ange en fast identitet för en Direct Lake-semantisk modell.

Autentisering

Den fasta identiteten kan autentiseras med OAuth 2.0 eller tjänstens huvudnamn.

Kommentar

Endast Microsoft Entra-autentisering stöds. Därför stöds inte grundläggande autentisering för Direct Lake-semantiska modeller.

OAuth 2.0

När du använder OAuth 2.0 kan du autentisera med ett Microsoft Entra-användarkonto. Användarkontot måste ha behörighet att köra frågor mot SQL Analytics-slutpunktstabeller och vyer samt schemametadata.

Att använda ett specifikt användarkonto är inte en rekommenderad metod. Det beror på att semantiska modellfrågor misslyckas om lösenordet ändras eller användarkontot tas bort (till exempel när en anställd lämnar organisationen).

Tjänstens huvudnamn

Autentisering med tjänstens huvudnamn är den rekommenderade metoden eftersom den inte är beroende av ett specifikt användarkonto. Säkerhetsobjektet måste ha behörighet att köra frågor mot SQL Analytics-slutpunktstabeller och vyer samt schemametadata.

För kontinuitet kan autentiseringsuppgifterna för tjänstens huvudnamn hanteras med rotering av hemlighet/certifikat.

Kommentar

Inställningarna för infrastrukturklientorganisationen måste tillåta tjänstens huvudnamn och tjänstens huvudnamn måste tillhöra en deklarerad säkerhetsgrupp.

Enkel inloggning

När du skapar en delbar molnanslutning avmarkeras kryssrutan Enkel inloggning som standard. Det är rätt konfiguration när du använder en fast identitet.

Du kan aktivera enkel inloggning när du vill att identiteten som frågar den semantiska modellen även ska köra frågor mot SQL-analysslutpunkten. I den här konfigurationen använder Direct Lake-semantikmodellen den fasta identiteten för att uppdatera modellen och användaridentiteten för att fråga efter data.

När du använder en fast identitet är det vanligt att inaktivera enkel inloggning så att den fasta identiteten används för både uppdateringar och frågor, men det finns inga tekniska krav på detta.

Här följer rekommenderade metoder för molnanslutningar:

  • När alla användare har åtkomst till data (och har behörighet att göra det) behöver du inte skapa en delad molnanslutning. I stället kan standardinställningarna för molnanslutning användas. I det här fallet används identiteten för den användare som frågar modellen om frågorna återgår till DirectQuery-läge.
  • Skapa en delad molnanslutning när du vill använda en fast identitet för att fråga källdata. Det kan bero på att de användare som frågar efter semantikmodellen inte har behörighet att läsa lakehouse eller informationslagret. Den här metoden är särskilt relevant när den semantiska modellen tillämpar RLS.
  • Om du använder en fast identitet använder du alternativet Tjänstens huvudnamn eftersom det är säkrare och mer tillförlitligt. Det beror på att det inte förlitar sig på ett enskilt användarkonto eller deras behörigheter, och det kräver inte underhåll (och avbrott) om de ändrar sitt lösenord eller lämnar organisationen.
  • Om olika användare måste begränsas till åtkomst endast delmängder av data, om det är möjligt, framtvinga RLS endast på semantikmodellskiktet. På så sätt kan användarna dra nytta av frågor med hög prestanda i minnet.
  • Undvik om möjligt OLS och CLS eftersom det resulterar i fel i visuella rapportobjekt. Fel kan skapa förvirring eller problem för användare. 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).

Hantera medlemskap i säkerhetsrollen

Om direct lake-semantikmodellen tillämpar säkerhet på radnivå (RLS) kan du behöva hantera de medlemmar som är tilldelade till säkerhetsrollerna. Mer information finns i Hantera säkerhet för din modell.

Ange behörigheter för infrastrukturobjekt

Direct Lake-semantiska modeller följer en säkerhetsmodell i lager. De utför behörighetskontroller via SQL-analysslutpunkten för att avgöra om identiteten som försöker komma åt data har nödvändiga dataåtkomstbehörigheter.

Du måste bevilja behörigheter till användare så att de kan använda eller hantera Direct Lake-semantikmodellen. Kort och kort behöver rapportkonsumenter läsbehörighet och rapportskapare behöver skapa-behörighet . Semantiska modellbehörigheter kan tilldelas direkt eller hämtas implicit via arbetsyteroller. Om du vill hantera semantiska modellinställningar (för uppdatering och andra konfigurationer) måste du vara ägare till semantikmodellen.

Beroende på molnanslutningsuppsättningen och om användarna behöver fråga lakehouse- eller lagerslutpunkten för SQL-analys kan du behöva bevilja andra behörigheter (beskrivs i tabellen i det här avsnittet).

Kommentar

I synnerhet behöver användarna aldrig behörighet att läsa data i OneLake. Det beror på att Fabric ger den semantiska modellen nödvändiga behörigheter för att läsa Delta-tabellerna och associerade Parquet-filer (för att läsa in kolumndata i minnet). Den semantiska modellen har också de behörigheter som krävs för att regelbundet läsa SQL-analysslutpunkten för att utföra behörighetskontroller för att avgöra vilka data som frågeanvändaren (eller den fasta identiteten) kan komma åt.

Tänk på följande scenarier och behörighetskrav.

Scenario Behörigheter som krävs Kommentarer
Användare kan visa rapporter • Bevilja läsbehörighet för rapporter och läsbehörighet för semantikmodellen.
• Om molnanslutningen använder enkel inloggning beviljar du minst läsbehörighet för sjöhuset eller lagret.		 Rapporter behöver inte tillhöra samma arbetsyta som den semantiska modellen. Mer information finns i Strategi för skrivskyddade konsumenter.
Användare kan skapa rapporter • Bevilja build-behörighet för semantikmodellen.
• Om molnanslutningen använder enkel inloggning beviljar du minst läsbehörighet för sjöhuset eller lagret.		 Mer information finns i Strategi för innehållsskapare.
Användare kan köra frågor mot den semantiska modellen men nekas att köra frågor mot lakehouse- eller SQL-analysslutpunkten • Bevilja inte tillstånd för sjöboden eller lagret. Endast lämpligt när molnanslutningen använder en fast identitet.
Användare kan köra frågor mot den semantiska modellen och SQL-analysslutpunkten, men nekas att köra frågor mot lakehouse • Bevilja Läs - och ReadData-behörigheter för sjöhuset eller lagret. Viktigt: Frågor som skickas till SQL-analysslutpunkten kringgår behörigheter för dataåtkomst som tillämpas av den semantiska modellen.
Hantera den semantiska modellen, inklusive uppdateringsinställningar • Kräver semantisk modellägarskap. Mer information finns i Semantisk modellägarskap.

Viktigt!

Du bör alltid noggrant testa behörigheter innan du släpper din semantiska modell och rapporter i produktion.

Mer information finns i Semantiska modellbehörigheter.

Uppdatera Direct Lake-semantiska modeller

En uppdatering av en Direct Lake-semantisk modell resulterar i en inramningsåtgärd . En uppdateringsåtgärd kan utlösas:

Automatiska uppdateringar

Det finns en semantisk modellnivåinställning med namnet Keep your Direct Lake data up to date (Håll dina Direct Lake-data uppdaterade ) som gör automatiska uppdateringar av Direct Lake-tabeller. Som standard är den aktiverad. Det säkerställer att dataändringar i OneLake automatiskt återspeglas i Direct Lake-semantikmodellen. Inställningen är tillgänglig i fabric-portalen i avsnittet Uppdatera i de semantiska modellinställningarna.

När inställningen är aktiverad utför den semantiska modellen en inramningsåtgärd när dataändringar i underliggande Delta-tabeller identifieras. Inramningsåtgärden är alltid specifik för endast de tabeller där datamodifieringar identifieras.

Vi rekommenderar att du lämnar inställningen på, särskilt när du har en liten eller medelstor semantisk modell. Det är särskilt användbart när du har rapporteringskrav med låg latens och Delta-tabeller ändras regelbundet.

I vissa situationer kanske du vill inaktivera automatiska uppdateringar. Du kan till exempel behöva tillåta slutförande av dataförberedelsejobb eller ETL-processen innan du exponerar nya data för konsumenter av semantikmodellen. När du är inaktiverad kan du utlösa en uppdatering med hjälp av en programmatisk metod (beskrivs tidigare).

Kommentar

Power BI pausar automatiska uppdateringar när ett fel som inte kan återställas påträffas under uppdateringen. Ett fel som inte kan återställas kan inträffa, till exempel när en uppdatering misslyckas efter flera försök. Se därför till att din semantiska modell kan uppdateras. Power BI återupptar automatiskt automatiska uppdateringar när en efterföljande uppdatering på begäran slutförs utan fel.

Värm cacheminnet

En uppdateringsåtgärd för Direct Lake-semantikmodellen kan avlägsna alla residenta kolumner från minnet. Det innebär att de första frågorna efter en uppdatering av en Direct Lake-semantisk modell kan uppleva viss fördröjning när kolumner läses in i minnet. Fördröjningar kan bara märkas när du har extremt stora mängder data.

För att undvika sådana fördröjningar bör du överväga att värma cachen genom att programmatiskt skicka en fråga till den semantiska modellen. Ett praktiskt sätt att skicka en fråga är att använda semantisk länk. Den här åtgärden bör utföras omedelbart efter att uppdateringsåtgärden har slutförts.

Viktigt!

Att värma cachen kanske bara är meningsfullt när fördröjningar är oacceptabla. Var noga med att inte i onödan läsa in data i minnet som kan sätta press på andra kapacitetsarbetsbelastningar, vilket gör att de begränsas eller blir deprioriterade.

Ange egenskap för Direct Lake-beteende

Du kan styra återställningen av direct lake-semantikmodellerna genom att ange dess DirectLakeBehavior egenskap. Den kan ställas in på:

  • Automatisk: (standard) Frågor återgår till DirectQuery-läge om de data som krävs inte kan läsas in effektivt i minnet.
  • DirectLakeOnly: Alla frågor använder endast Direct Lake-lagringsläge. Återgå till DirectQuery-läget är inaktiverat. Om data inte kan läsas in i minnet returneras ett fel.
  • DirectQueryOnly: Alla frågor använder endast DirectQuery-läge. Använd den här inställningen för att testa prestanda för återställning, där du till exempel kan se frågeprestanda i anslutna rapporter.

Du kan ange egenskapen i webbmodelleringsmiljön, eller med hjälp av Tabellobjektmodell (TOM) eller TMSL (Tabular Model Scripting Language).

Dricks

Överväg att inaktivera DirectQuery-återställning när du endast vill bearbeta frågor i Direct Lake-lagringsläge. Vi rekommenderar att du inaktiverar återställning när du inte vill återgå till DirectQuery. Det kan också vara användbart när du vill analysera frågebearbetning för en Direct Lake-semantisk modell för att identifiera om och hur ofta återställning sker.

Övervaka semantiska Direct Lake-modeller

Du kan övervaka en Direct Lake-semantisk modell för att fastställa prestanda för visuella DAX-frågor för rapporter eller för att avgöra när den återgår till DirectQuery-läge.

Du kan använda Prestandaanalys, SQL Server Profiler, Azure Log Analytics eller ett communityverktyg med öppen källkod, till exempel DAX Studio.

Prestandaanalys

Du kan använda Prestandaanalys i Power BI Desktop för att registrera den bearbetningstid som krävs för att uppdatera rapportelement som initierats till följd av användarinteraktion som resulterar i att en fråga körs. Om övervakningsresultaten visar ett direct query-mått innebär det att DAX-frågorna bearbetades i DirectQuery-läge. I avsaknad av det måttet bearbetades DAX-frågorna i Direct Lake-läge.

Mer information finns i Analysera med hjälp av Prestandaanalys.

SQL Server-profilerare

Du kan använda SQL Server Profiler för att hämta information om frågeprestanda genom att spåra frågehändelser. Den installeras med SQL Server Management Studio (SSMS). Kontrollera att du har den senaste versionen av SSMS installerad innan du börjar.

Mer information finns i Analysera med SQL Server Profiler.

Viktigt!

I allmänhet ger Direct Lake-lagringsläget snabba frågeprestanda om inte en återställning till DirectQuery-läge krävs. Eftersom återställning till DirectQuery-läge kan påverka frågeprestanda är det viktigt att analysera frågebearbetning för en Direct Lake-semantisk modell för att identifiera om, hur ofta och varför återställningar inträffar.

Azure Log Analytics

Du kan använda Azure Log Analytics för att samla in, analysera och agera på telemetridata som är associerade med en Direct Lake-semantisk modell. Det är en tjänst i Azure Monitor som Power BI använder för att spara aktivitetsloggar.

Mer information finns i Använda Azure Log Analytics i Power BI.

Relaterat innehåll