Direct Lake

Direct Lake-läget är en semantisk modellfunktion för analys av mycket stora datavolymer i Power BI. Direct Lake baseras på inläsning av parquet-formaterade filer direkt från en datasjö utan att behöva köra frågor mot en lakehouse- eller lagerslutpunkt och utan att behöva importera eller duplicera data till en Power BI-modell. Direct Lake är en snabb väg för att läsa in data från sjön direkt till Power BI-motorn, redo för analys. Följande diagram visar hur klassiska import- och DirectQuery-lägen jämförs med Direct Lake-läget.

I DirectQuery-läge frågar Power BI-motorn data vid källan, vilket kan vara långsamt men undviker att behöva kopiera data som med importläge. Alla ändringar i datakällan återspeglas omedelbart i frågeresultatet.

Å andra sidan, med importläge, kan prestandan vara bättre eftersom data cachelagras och optimeras för DAX- och MDX-rapportfrågor utan att behöva översätta och skicka SQL eller andra typer av frågor till datakällan. Power BI-motorn måste dock först kopiera nya data till modellen under uppdateringen. Alla ändringar i källan hämtas endast vid nästa modelluppdatering.

Direct Lake-läget eliminerar importkravet genom att läsa in data direkt från OneLake. Till skillnad från DirectQuery finns det ingen översättning från DAX eller MDX till andra frågespråk eller frågekörning på andra databassystem, vilket ger prestanda som liknar importläge. Eftersom det inte finns någon explicit importprocess går det att hämta eventuella ändringar i datakällan när de inträffar, vilket kombinerar fördelarna med både DirectQuery- och importlägen samtidigt som man undviker deras nackdelar. Direct Lake-läge kan vara det perfekta valet för att analysera mycket stora modeller och modeller med frekventa uppdateringar i datakällan.

Direct Lake har också stöd för säkerhet på radnivå och säkerhet på objektnivå så att användarna bara ser de data som de har behörighet att se.

Förutsättningar

Direct Lake stöds endast på SKU:er för Microsoft Premium (P) och Microsoft Fabric (F).

Viktigt!

För nya kunder stöds Direct Lake endast på SKU:er för Microsoft Fabric (F). Befintliga kunder kan fortsätta att använda Direct Lake med Premium-SKU:er (P), men övergången till en SKU för Infrastrukturkapacitet rekommenderas. Mer information om Power BI Premium-licensiering finns i licensieringsmeddelandet.

Sjöhus

Innan du använder Direct Lake måste du etablera ett lakehouse (eller ett lager) med en eller flera Delta-tabeller på en arbetsyta som finns på en Microsoft Fabric-kapacitet som stöds. Lakehouse krävs eftersom det tillhandahåller lagringsplatsen för dina parquet-formaterade filer i OneLake. Lakehouse tillhandahåller också en åtkomstpunkt för att starta webbmodelleringsfunktionen för att skapa en Direct Lake-modell.

Information om hur du etablerar ett sjöhus, skapar en Delta-tabell i lakehouse och skapar en grundläggande modell för lakehouse finns i Skapa ett sjöhus för Direct Lake.

SQL-slutpunkt

Som en del av etableringen av ett lakehouse skapas och uppdateras en SQL-slutpunkt för SQL-frågor och en standardmodell för rapportering med tabeller som läggs till i lakehouse. Även om Direct Lake-läget inte frågar SQL-slutpunkten när data läses in direkt från OneLake, krävs det när en Direct Lake-modell sömlöst måste återgå till DirectQuery-läge, till exempel när datakällan använder specifika funktioner som avancerad säkerhet eller vyer som inte kan läsas via Direct Lake. Direct Lake-läget frågar också SQL-slutpunkten efter schema- och säkerhetsrelaterad information.

Informationslager

Som ett alternativ till ett lakehouse med SQL-slutpunkt kan du även etablera ett lager och lägga till tabeller med hjälp av SQL-instruktioner eller datapipelines. Proceduren för att etablera ett fristående informationslager är nästan identisk med proceduren för ett sjöhus.

Stöd för modellskrivning med XMLA-slutpunkt

Direct Lake-modeller stöder skrivåtgärder via XMLA-slutpunkten med hjälp av verktyg som SQL Server Management Studio (19.1 och senare) och de senaste versionerna av externa BI-verktyg som Tabular Editor och DAX Studio. Modellskrivningsåtgärder via 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.

• Automatiseringsuppgifter som att uppdatera och tillämpa ändringar i Direct Lake-modeller med hjälp av PowerShell- och REST-API:er.

Observera att Direct Lake-tabeller som skapats med XMLA-program till en början är i ett obearbetat tillstånd tills programmet utfärdar ett uppdateringskommando. Obearbetade tabeller återgår till DirectQuery-läge. När du skapar en ny semantisk modell måste du uppdatera din semantiska modell för att bearbeta dina tabeller.

Aktivera XMLA-läsning

Innan du utför skrivåtgärder på Direct Lake-modeller via XMLA-slutpunkten måste XMLA-läs- och skrivåtgärder aktiveras för kapaciteten.

För utvärderingskapaciteter för infrastrukturresurser har utvärderingsanvändaren de administratörsbehörigheter som krävs för att aktivera XMLA-läs- och skrivbehörighet.

1. I administratörsportalen väljer du Kapacitetsinställningar.

2. Klicka på fliken Utvärdering .

3. Välj kapacitet med utvärderingsversion och ditt användarnamn i kapacitetsnamnet.

4. Expandera Power BI-arbetsbelastningar och välj lässkrivning i inställningen XMLA-slutpunkt.

   

Tänk på att INSTÄLLNINGEN XMLA-slutpunkt gäller för alla arbetsytor och modeller som tilldelats kapaciteten.

Direct Lake-modellmetadata

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

• Egenskapen compatibilityLevel för databasobjektet är 1604 eller högre.

• Egenskapen Mode 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-slutpunkten för ett lakehouse eller lager. Direct Lake använder SQL-slutpunkten för att identifiera schema- och säkerhetsinformation men läser in data direkt från Delta-tabellerna (om inte Direct Lake måste återgå till DirectQuery-läge av någon anledning).

Här är ett exempel på en XMLA-fråga i SSMS:

Mer information om verktygsstöd via XMLA-slutpunkten finns i Semantisk modellanslutning med XMLA-slutpunkten.

Reserv

Power BI-semantiska modeller i Direct Lake-läge läser Delta-tabeller direkt från OneLake. Men om en DAX-fråga på en Direct Lake-modell överskrider gränserna för SKU:n eller använder funktioner som inte stöder Direct Lake-läge, till exempel SQL-vyer i ett lager, kan frågan återgå till DirectQuery-läge. I DirectQuery-läge använder frågor SQL för att hämta resultatet från SQL-slutpunkten för lakehouse eller informationslagret, vilket kan påverka frågeprestanda. Du kan inaktivera återställning till DirectQuery-läge om du bara vill bearbeta DAX-frågor i rent Direct Lake-läge. Inaktivera återställning rekommenderas om du inte behöver återställning till DirectQuery. Det kan också vara användbart när du analyserar frågebearbetning för en Direct Lake-modell för att identifiera om och hur ofta återställningar inträffar. Mer information om DirectQuery-läge finns i Semantiska modelllägen i Power BI.

Skyddsräcken definierar resursgränser för Direct Lake-läge där en återställning till DirectQuery-läge krävs för att bearbeta DAX-frågor. Mer information om hur du fastställer antalet parquet-filer och radgrupper för en Delta-tabell finns i egenskapsreferensen för Delta-tabellen.

För Direct Lake-semantiska modeller representerar Max minne den övre minnesresursgränsen för hur mycket data som kan sökas i. I själva verket är det inte ett skyddsräcke eftersom överskridning inte orsakar en reserv till DirectQuery; Det kan dock ha en prestandapåverkan om mängden data är tillräckligt stor för att orsaka växling in och ut ur modelldata från OneLake-data.

I följande tabell visas både resursskyddsmekanismer och Maximalt minne:

Infrastruktur-SKU:er	Parquet-filer per tabell	Radgrupper per tabell	Rader per tabell (miljoner)	Maximal modellstorlek på disk/OneLake1 (GB)	Maximalt minne (GB)
F2	1 000	1,000	300	10	3
F4	1 000	1,000	300	10	3
F8	1 000	1,000	300	10	3
F16	1 000	1,000	300	20	5
F32	1 000	1,000	300	40	10
F64/FT1/P1	5 000	5 000	1 500	Obegränsat	25
F128/P2	5 000	5 000	3 000	Obegränsat	50
F256/P3	5 000	5 000	6 000	Obegränsat	100
F512/P4	10,000	10,000	12,000	Obegränsat	200
F1024/P5	10,000	10,000	24,000	Obegränsat	400
F2048	10,000	10,000	24,000	Obegränsat	400

1 – Om den överskrids kommer Max modellstorlek på disk/Onelake att leda till att alla frågor till modellen återgår till DirectQuery, till skillnad från andra skyddsräcken som utvärderas per fråga.

Beroende på din Infrastruktur-SKU gäller även ytterligare kapacitetsenhet och maximalt minne per frågegräns för Direct Lake-modeller. Mer information finns i Kapaciteter och SKU:er.

Återställningsbeteende

Direct Lake-modeller innehåller egenskapen DirectLakeBehavior , som har tre alternativ:

Automatisk – (standard) Anger att frågor återgår till DirectQuery-läge om data inte kan läsas in effektivt i minnet.

DirectLakeOnly – Anger att alla frågor endast använder Direct Lake-läge. Återställning till DirectQuery-läge är inaktiverat. Om data inte kan läsas in i minnet returneras ett fel. Använd den här inställningen för att avgöra om DAX-frågor inte kan läsa in data i minnet, vilket tvingar ett fel att returneras.

DirectQueryOnly – Anger att alla frågor endast använder DirectQuery-läge. Använd den här inställningen för att testa prestanda för återställning.

Egenskapen DirectLakeBehavior kan konfigureras med hjälp av Tabellobjektmodell (TOM) eller TMSL (Tabular Model Scripting Language).

I följande exempel anges att alla frågor endast använder Direct Lake-läge:

// Disable fallback to DirectQuery mode.
//
database.Model.DirectLakeBehavior = DirectLakeBehavior.DirectLakeOnly = 1;
database.Model.SaveChanges();

Analysera frågebearbetning

För att avgöra om ett visuellt rapportobjekts DAX-frågor till datakällan ger bästa prestanda genom att använda Direct Lake-läget eller återgå till DirectQuery-läge kan du använda Prestandaanalys i Power BI Desktop, SQL Server Profiler eller andra verktyg från tredje part för att analysera frågor. Mer information finns i Analysera frågebearbetning för Direct Lake-modeller.

Uppdatera

Som standard återspeglas dataändringar i OneLake automatiskt i en Direct Lake-modell. Du kan ändra det här beteendet genom att inaktivera Håll dina Direct Lake-data uppdaterade i modellens inställningar.

Du kanske vill inaktivera om du till exempel behöver tillåta slutförande av dataförberedelsejobb innan du exponerar nya data för användare av modellen. När du är inaktiverad kan du anropa uppdateringen manuellt eller med hjälp av uppdaterings-API:erna. Att anropa en uppdatering för en Direct Lake-modell är en lågkostnadsåtgärd där modellen analyserar metadata för den senaste versionen av Delta Lake-tabellen och uppdateras för att referera till de senaste filerna i OneLake.

Observera att Power BI kan pausa automatiska uppdateringar av Direct Lake-tabeller om ett oåterkalleligt fel påträffas under uppdateringen, så se till att semantikmodellen kan uppdateras. Power BI återupptar automatiskt automatiska uppdateringar när en efterföljande användaranropad uppdatering slutförs utan fel.

Säkerhet för dataåtkomst i lager

Direct Lake-modeller som skapats ovanpå lakehouses och lager följer den säkerhetsmodell i lager som lakehouses och lager stöder genom att utföra behörighetskontroller via T-SQL-slutpunkten för att avgöra om identiteten som försöker komma åt data har de behörigheter som krävs för dataåtkomst. Som standard använder Direct Lake-modeller enkel inloggning (SSO), så de effektiva behörigheterna för den interaktiva användaren avgör om användaren tillåts eller nekas åtkomst till data. Om Direct Lake-modellen är konfigurerad för att använda en fast identitet avgör den faktiska behörigheten för den fasta identiteten om användare som interagerar med den semantiska modellen kan komma åt data. T-SQL-slutpunkten returnerar Tillåten eller Nekad till Direct Lake-modellen baserat på kombinationen av OneLake-säkerhet och SQL-behörigheter.

En lageradministratör kan till exempel bevilja användaren SELECT-behörigheter i en tabell så att användaren kan läsa från den tabellen även om användaren inte har några OneLake-säkerhetsbehörigheter. Användaren har auktoriserats på sjöhus-/lagernivå. Omvänt kan en lageradministratör neka en användare läsbehörighet till en tabell. Användaren kommer då inte att kunna läsa från tabellen även om användaren har Läsbehörigheter för OneLake-säkerhet. DENY-instruktionen åsidoler alla beviljade OneLake-säkerhets- eller SQL-behörigheter. Se följande tabell för de gällande behörigheter som en användare kan ha gett valfri kombination av OneLake-säkerhet och SQL-behörigheter.

Säkerhetsbehörigheter för OneLake	SQL-behörigheter	Gällande behörigheter
Tillåt	Ingen	Tillåt
Ingen	Tillåt	Tillåt
Tillåt	Neka	Neka
Ingen	Neka	Neka

Kända problem och begränsningar

• Avsiktligt stöder endast tabeller i den semantiska modellen som härleds från tabeller i ett Lakehouse- eller Warehouse-läge Direct Lake-läge. Även om tabeller i modellen kan härledas från SQL-vyer i Lakehouse eller Warehouse, återgår frågor som använder dessa tabeller till DirectQuery-läge.

• Direct Lake-semantiska modelltabeller kan bara härledas från tabeller och vyer från en enda Lakehouse eller Warehouse.

• Direct Lake-tabeller kan för närvarande inte blandas med andra tabelltyper, till exempel Import, DirectQuery eller Dual, i samma modell. Sammansatta modeller stöds för närvarande inte.

• DateTime-relationer stöds inte i Direct Lake-modeller.

• Beräknade kolumner och beräknade tabeller stöds inte.

• Vissa datatyper kanske inte stöds, till exempel decimaler med hög precision och pengatyper.

• Direct Lake-tabeller stöder inte komplexa deltatabellkolumntyper. Binära och guid-semantiska typer stöds inte heller. Du måste konvertera dessa datatyper till strängar eller andra datatyper som stöds.

• Tabellrelationer kräver att datatyperna för deras nyckelkolumner sammanfaller. Primärnyckelkolumner måste innehålla unika värden. DAX-frågor misslyckas om duplicerade primärnyckelvärden identifieras.

• Längden på strängkolumnvärden är begränsad till 32 764 Unicode-tecken.

• Flyttalsvärdet "NaN" (inte ett tal) stöds inte i Direct Lake-modeller.

• Inbäddade scenarier som förlitar sig på inbäddade entiteter stöds inte ännu.

• Valideringen är begränsad för Direct Lake-modeller. Användarval antas vara korrekta och inga frågor validerar kardinalitets- och korsfilterval för relationer, eller för den valda datumkolumnen i en datumtabell.

• Fliken Direct Lake i uppdateringshistoriken visar endast Direct Lake-relaterade uppdateringsfel. Lyckade uppdateringar utelämnas för närvarande.

Kom igång

Det bästa sättet att komma igång med en Direct Lake-lösning i din organisation är att skapa en Lakehouse, skapa en Delta-tabell i den och sedan skapa en grundläggande semantisk modell för lakehouse på din Microsoft Fabric-arbetsyta. Mer information finns i Skapa ett sjöhus för Direct Lake.

Relaterat innehåll

• Skapa ett sjöhus för Direct Lake
• Analysera frågebearbetning för Direct Lake-semantiska modeller