Hantera semantiska Direct Lake-modeller
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.
- Konfigurera molnanslutningen
- Hantera medlemskap i säkerhetsroller
- Ange behörigheter för tygobjekt
- Konfigurera schemalagd uppdatering
Du kan valfritt också ställa in dataupptäckteknik så att rapportskapare kan läsa metadata, vilket hjälper dem att hitta data i OneLake-datahubben och begära åtkomst till dem. Du kan också stödja (certifierad eller promoverad) den semantiska modellen och 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, som 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 hjälp av OAuth 2.0 eller Service Principal.
Obs
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 tjänsthuvudautentiseringens autentiseringsuppgifter hanteras med rotation av hemligheter och certifikat.
Not
Inställningarna för Fabric-klienten måste tillåta tjänstprincipaler, och tjänstprincipalen måste tillhöra en deklarerad säkerhetsgrupp.
Enkel inloggning
När du skapar en delbar molnanslutning är kryssrutan Single Sign-On avmarkerad som standard. Det är rätt konfiguration när du använder en fast identitet.
Du kan aktivera SSO när du vill att identiteten som ställer frågor till den semantiska modellen även ska förfråga 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 fastställd identitet är det vanligt att avaktivera SSO så att den fastställda identiteten används för både uppdatering och frågor, men det finns inga tekniska krav på detta.
Rekommenderade metoder för molnanslutningar
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 warehouse. 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 att endast få tillgång till delmängder av data, tillämpa om möjligt RLS endast på det semantiska modellskiktet. På så sätt kan användarna dra nytta av högpresterande minnesbaserade frågeställningar.
- Undvik om möjligt OLS och CLS eftersom det leder till fel i rapportbilder. 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äkerhetsroller
Om din Direct Lake-semantiska modell framtvingar säkerhet på radnivå (RLS)kan du behöva hantera de medlemmar som har tilldelats säkerhetsrollerna. Mer information finns i Hantera säkerhet på din modell.
Ange behörigheter för Fabric-objekt
Direct Lake-semantiska modeller följer en flerskiktad säkerhetsmodell. 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 sagt behöver rapportkonsumenter läsbehörighet, och rapportskapare behöver byggläggningstillstånd. 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 semantisk modellägare.
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).
Obs
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 | Nödvändiga behörigheter | Kommentarer |
|---|---|---|
| Användare kan visa rapporter | • Ge Läs behörighet för rapporterna och Läs behörighet för semantikmodellen. • Om den 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 Bygg behörighet för semantikmodellen. • Om molnanslutningen använder enkel inloggning beviljar du minst Läs behö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 dataåtkomstbehörigheter som tillämpas av semantikmodellen. |
| Hantera den semantiska modellen, inklusive uppdateringsinställningar | • Kräver semantisk modellägarskap. | Mer information finns i semantisk modellägarskap. |
Viktig
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 semantisk modell av Direct Lake resulterar i en operation av typen inramning. En uppdateringsåtgärd kan utlösas:
- Genom att göra en uppdatering på begäran i Fabric-portalen, eller genom att köra kommandot Uppdatera i Tabular Model Scripting Language (TMSL) från ett skript i SQL Server Management Studio (SSMS), eller genom att använda ett verktyg från tredje part som ansluter via XMLA-slutpunkten.
- Automatiskt genom att konfigurera ett uppdateringsschema i Fabric-portalen.
- När ändringar identifieras automatiskt i de underliggande Delta-tabellerna finns mer information i Automatiska uppdateringar (beskrivs härnäst).
- Programmatiskt genom att utlösa en uppdatering med hjälp av Power BI REST API eller TOM. Du kan utlösa en programmatisk uppdatering som ett sista steg i en ETL-process (extrahering, transformering och inläsning).
Automatiska uppdateringar
Det finns en semantisk modellnivåinställning med namnet Håll dina Direct Lake-data uppdaterade som gör automatiska uppdateringar av Direct Lake-tabeller. Den är aktiverad som standard. 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 inom inställningarna för den semantiska modellen.
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).
Not
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 eftersom 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.
Viktig
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 kapaciteter och arbetsbelastningar, vilket gör att de begränsas eller blir nedprioriterade.
Ange egenskap för Direct Lake-beteende
Du kan kontrollera återställningen av direct lake-semantikmodellerna genom att ange dess DirectLakeBehavior egenskap. Den kan ställas in på:
- Automatiska: (standard) Förfrågningar återgå till DirectQuery-läge om nödvändiga data 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 reservlösning, när du till exempel kan observera prestandan för frågor i anslutna rapporter.
Du kan ange egenskapen i webbmodelleringsmiljöneller med hjälp av TOM (Tabular Object Model) eller TMSL (Tabular Model Scripting Language).
Tips
Överväg att inaktivera DirectQuery-alternativväxling när du endast vill bearbeta frågor i Direct Lake-lagringsläget. 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 Performance Analyzer, SQL Server Profiler, Azure Log Analytics eller ett communityverktyg med öppen källkod, till exempel DAX Studio.
Prestandaanalys
Du kan använda Performance Analyzer 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 DirectQuery-mått betyder 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 Performance Analyzer.
SQL Server Profiler
Du kan använda SQL Server Profiler för att hämta information om frågeprestanda genom att spåra frågehändelser. Det 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 hjälp av SQL Server Profiler.
Viktig
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 (tjänst för logganalys)
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.