Sdílet prostřednictvím


Přehled Direct Lake

Direct Lake je možnost režimu úložiště pro tabulky v sémantickém modelu Power BI, který je uložený v pracovním prostoru Microsoft Fabric. Je optimalizovaná pro velké objemy dat, která je možné rychle načíst do paměti z tabulek Delta, které ukládají data do souborů Parquet v OneLake– jediné úložiště pro všechna analytická data. Po načtení do paměti umožňuje sémantický model dotazy s vysokým výkonem. Direct Lake eliminuje pomalé a nákladné importování dat do modelu.

Režim úložiště Direct Lake můžete použít k připojení k tabulkám nebo pohledům jednoho Fabric lakehouse nebo Fabric skladu. Oba tyto Fabric prvky a sémantické modely Direct Lake vyžadují kapacitní licenci Fabric.

diagram znázorňuje sémantický model Direct Lake a způsob připojení k tabulkám Delta v OneLake, jak je popsáno v předchozích odstavcích.

Sémantický model Direct Lake se některým způsobem podobá sémantickému modelu Import. Důvodem je to, že modul VertiPaq načítá data modelu do paměti pro rychlý výkon dotazů (s výjimkou případu náhradníDirectQuery, což je vysvětleno dále v tomto článku).

Sémantický model Direct Lake se ale liší od sémantického modelu importu důležitým způsobem. Důvodem je to, že operace aktualizace pro sémantický model Direct Lake se koncepčně liší od operace aktualizace pro sémantický model importu. V případě sémantického modelu Direct Lake obnovení zahrnuje operaci rámování (popsanou dále v tomto článku), která může trvat několik sekund. Jedná se o nízkonákladovou operaci, kdy sémantický model analyzuje metadata nejnovější verze tabulek Delta a aktualizuje se, aby odkazoval na nejnovější soubory v OneLake. Naproti tomu u sémantického modelu importu vytvoří aktualizace kopii dat, což může trvat poměrně dlouho a spotřebovávat významné zdroje dat a prostředky kapacity (paměť a procesor).

Poznámka

Přírůstkové aktualizace pro sémantický model importu mohou pomoct zkrátit dobu aktualizace a snížit využití prostředků kapacity.

Kdy byste měli použít režim úložiště Direct Lake?

Primárním případem použití pro režim úložiště Direct Lake je obvykle projekty analýzy řízené IT, které používají architektury zaměřené na jezero. V tomto scénáři máte (nebo očekáváte, že se nahromáždí) velké objemy dat ve OneLake. Rychlé načítání těchto dat do paměti, časté a rychlé operace aktualizace, efektivní využití prostředků kapacity a rychlý výkon dotazů jsou pro tento případ použití důležité.

Poznámka

Sémantické modely importu a DirectQuery jsou v prostředcích Fabric stále relevantní a pro některé scénáře jsou správnou volbou sémantického modelu. Režim úložiště importu například často funguje dobře pro samoobslužného analytika, který potřebuje svobodu a flexibilitu, aby rychle fungoval a bez závislosti na IT přidávat nové datové prvky.

Integrace OneLake automaticky zapisuje data pro tabulky v režimu importu do tabulek Delta v OneLake, aniž by to vyžadovalo jakékoli úsilí o migraci. Pomocí této možnosti můžete využít mnoho výhod systému Fabric, které jsou dostupné uživatelům importovaného sémantického modelu, jako je integrace s lakehouses prostřednictvím zástupců, dotazů SQL, poznámkových bloků a dalších nástrojů. Tuto možnost doporučujeme zvážit jako rychlý způsob, jak využít výhody Fabric, aniž byste museli nutně nebo okamžitě znovu navrhnout stávající datový sklad nebo analytický systém.

Režim úložiště Direct Lake je také vhodný pro minimalizaci latence dat, aby bylo možné rychle zpřístupnit data firemním uživatelům. Pokud se vaše tabulky Delta mění přerušovaně (a za předpokladu, že jste již provedli přípravu dat v datovém jezeře), můžete se spolehnout na automatic updates, které se přizpůsobí těmto změnám. V takovém případě dotazy odeslané do sémantického modelu vrátí nejnovější data. Tato funkce funguje dobře ve spolupráci s funkcí automatické aktualizace stránky sestav Power BI.

Mějte na paměti, že Direct Lake závisí na přípravě dat v datovém jezeře. Přípravu dat je možné provádět pomocí různých nástrojů, jako jsou úlohy Sparku pro Fabric Lakehouses, příkazy T-SQL DML pro sklady Fabric, toky dat, kanály a další. Tento přístup pomáhá zajistit, aby byla logika přípravy dat v architektuře co nejnižší, aby se maximalizovala použitelnost. Pokud ale autor sémantického modelu nemá možnost upravovat zdrojovou položku, například pokud samoobslužný analytik nemá oprávnění k zápisu do jezera spravovaného IT, může být vhodnější režim úložiště importu. Je to proto, že podporuje přípravu dat pomocí Power Query, který je definován jako součást sémantického modelu.

Při zvažování režimu úložiště Direct Lake nezapomeňte vzít v úvahu aktuální licenci na kapacitu Fabric a mantinely kapacity Fabric . Zvažte také aspekty a omezení, které jsou popsány dále v tomto článku.

Spropitné

Doporučujeme vytvořit prototyp neboli testování konceptu (POC), abyste zjistili, jestli je sémantický model Direct Lake správným řešením a jak zmírnit rizika.

Jak Direct Lake funguje

Dotazy odeslané do sémantického modelu Direct Lake se obvykle zpracovávají z mezipaměti v paměti sloupců zdrojových z tabulek Delta. Podkladové úložiště pro tabulku Delta je jeden nebo více souborů Parquet v OneLake. Soubory Parquet uspořádají data podle sloupců místo řádků. Sémantické modely načítají celé sloupce z tabulek Delta do paměti, protože je vyžadují dotazy.

Sémantický model Direct Lake může také používat záložní režim DirectQuery, což zahrnuje bezproblémové přepínání do režimu DirectQuery. Náhradní funkce DirectQuery načítá data přímo z koncového bodu analýzy SQL lakehouse nebo skladu. K náhradnímu použití může dojít například v případě, že tabulka Delta obsahuje více řádků dat, než je podporováno vaší kapacitou systému Fabric (popsáno později v tomto článku). V tomto případě operace DirectQuery odešle dotaz do koncového bodu analýzy SQL. Náhradní operace můžou vést ke zpomalení výkonu dotazů.

Následující diagram znázorňuje, jak Direct Lake funguje pomocí scénáře uživatele, který otevře sestavu Power BI.

diagram ukazuje, jak fungují sémantické modely Direct Lake. Koncepty zobrazené na obrázku jsou popsány v následující tabulce.

Diagram znázorňuje následující akce, procesy a funkce uživatelů.

Položka Popis
OneLake je datové jezero, které ukládá analytická data ve formátu Parquet. Tento formát souboru je optimalizovaný pro ukládání dat pro sémantické modely Direct Lake.
Sklad Fabric Lakehouse nebo Fabric existuje v pracovním prostoru, který je v kapacitě Fabric. Lakehouse má koncový bod analýzy SQL, který poskytuje prostředí založené na SQL pro dotazování. Tabulky (nebo zobrazení) poskytují způsob dotazování tabulek Delta v OneLake pomocí Transact-SQL (T-SQL).
V pracovním prostoru Fabric existuje sémantický model Direct Lake. Připojuje se k tabulkám nebo zobrazením v jezeře nebo skladu.
Uživatel otevře sestavu Power BI.
Sestava Power BI odesílá dotazy DAX (Data Analysis Expressions) do sémantického modelu Direct Lake.
Pokud je to možné (a nezbytné), sémantický model načte sloupce do paměti přímo ze souborů Parquet uložených ve OneLake. Dotazy dosahují vysokého výkonu díky zpracování přímo v paměti, což je velmi rychlé.
Sémantický model vrátí výsledky dotazu.
Sestava Power BI vykresluje vizuály.
Za určitých okolností, například když sémantický model překročí mantinely kapacity, dotazy na sémantický model se automaticky vrátí do režimu DirectQuery. V tomto režimu se dotazy posílají do koncového bodu analytiky SQL v datové jezeře nebo skladu.
Dotazy DirectQuery odeslané do koncového bodu analýzy SQL se pak dotazují na tabulky Delta v OneLake. Z tohoto důvodu může být výkon dotazů pomalejší než dotazy v paměti.

Následující části popisují koncepty a funkce Direct Lake, včetně načítání sloupců, rámování, automatických aktualizací a náhradního režimu DirectQuery.

Načítání sloupců (překódování)

Sémantické modely Direct Lake načítají data z OneLake pouze tehdy, jakmile jsou sloupce poprvé dotazovány. Proces načítání dat na vyžádání z OneLake je známý jako překódování.

Když sémantický model obdrží dotaz DAX (nebo multidimenzionální výrazy – MDX), nejprve určí, které sloupce jsou potřeba k vytvoření výsledku dotazu. Libovolný sloupec, který dotaz přímo používá, je potřeba a také sloupce vyžadované relacemi a mírami. Obvykle je počet sloupců potřebných k vytvoření výsledku dotazu výrazně menší než počet sloupců definovaných v sémantickém modelu.

Jakmile pochopí, které sloupce jsou potřeba, sémantický model určuje, které sloupce už jsou v paměti. Pokud některé sloupce potřebné pro dotaz nejsou v paměti, načte sémantický model všechna data pro tyto sloupce z OneLake. Načítání dat sloupců je obvykle rychlá operace, ale může záviset na faktorech, jako je kardinalita dat uložených ve sloupcích.

Sloupce načtené do paměti jsou pak rezidentní v paměti. Budoucí dotazy, které zahrnují pouze rezidentní sloupce, nemusí do paměti načítat žádné další sloupce.

Sloupec zůstane rezidentní, pokud není důvod k jeho odstranění (vyřazení) z paměti. Mezi důvody odebrání sloupců patří:

  • Model nebo tabulka se aktualizovaly po aktualizaci tabulky Delta ve zdroji (viz framing v další části).
  • Po nějakou dobu se ve sloupci nepoužíval žádný dotaz.
  • Jiné důvody správy paměti, včetně zatížení paměti v kapacitě z důvodu jiných souběžných operací.

Volba SKU položky Fabric určuje maximální dostupnou paměť pro každý sémantický model Direct Lake v rámci kapacity. Další informace o mantinelech prostředků a maximálních limitech paměti najdete v tématu mantinely a omezení kapacity fabric dále v tomto článku.

Rámování

Framing poskytuje vlastníkům modelů časovou kontrolu nad tím, jaká data se načtou do sémantického modelu. Framing je operace Direct Lake aktivovaná aktualizací sémantického modelu a ve většině případů trvá dokončení jen pár sekund. Je to proto, že jde o nízkonákladovou operaci, kdy sémantický model analyzuje metadata nejnovější verze tabulek Delta Lake a který se aktualizuje tak, aby odkazoval na nejnovější soubory Parquet v OneLake.

Při vytváření rámců mohou být rezidentní segmenty sloupců a slovníky tabulky odstraněny z paměti, pokud se podkladová data změnila a okamžik aktualizace se stane novým referenčním bodem pro všechny budoucí události překódování. Od tohoto okamžiku berou dotazy Direct Lake v úvahu data pouze v tabulkách Delta k času nejnovější operace rámování. Z tohoto důvodu jsou tabulky Direct Lake dotazovány tak, aby vracely data na základě stavu tabulky Delta v okamžiku poslední operace rámování. Tento čas nemusí nutně odpovídat nejnovějšímu stavu tabulek Delta.

Všimněte si, že sémantický model analyzuje protokol Delta každé tabulky Delta, aby při překódování odstranil pouze ovlivněné segmenty sloupců a znovu načetl nově přidaná data. Důležitou optimalizací je, že slovníky se obvykle při postupném vytváření rámců nezahodí a do existujících slovníků se přidají nové hodnoty. Tento přístup přírůstkového rámování pomáhá snížit nároky na opětovné načtení a zlepšuje výkon dotazů. V ideálním případě, když tabulka Delta nepřijala žádné aktualizace, není nutné znovu načíst sloupce, které už jsou v paměti, a dotazy ukazují mnohem menší dopad na výkon po rámování, protože přírůstkové rámování v podstatě umožňuje sémantickému modelu aktualizovat podstatné části stávajících dat v paměti.

Následující diagram znázorňuje, jak fungují operace rámování Direct Lake.

Diagram znázorňuje, jak fungují rámcové operace Direct Lake.

Diagram znázorňuje následující procesy a funkce.

Položka Popis
V pracovním prostoru Fabric existuje sémantický model.
Operace rámování probíhají pravidelně a nastaví směrný plán pro všechny budoucí překódování událostí. Operace vytváření rámců se můžou provádět automaticky, ručně, podle plánu nebo programově.
OneLake ukládá metadata a soubory Parquet, které jsou reprezentované jako tabulky Delta.
Poslední rámovací operace zahrnuje soubory Parquet související s tabulkami Delta, a konkrétně soubory Parquet, které byly přidány před poslední rámovací operací.
Pozdější rámovací operace zahrnuje soubory Parquet přidané po poslední operaci rámování.
Rezidentní sloupce v sémantickém modelu Direct Lake mohou být vyřazeny z paměti a časový bod aktualizace se stane novým základem pro všechny budoucí události transkódování.
Následné úpravy dat reprezentované novými soubory Parquet nejsou viditelné, dokud nedojde k další operaci rámování.

Není vždy žádoucí mít data představující nejnovější stav jakékoli tabulky Delta při provedení operace překódování. Zvažte, že framing vám může pomoct poskytovat konzistentní výsledky dotazů v prostředích, kde jsou data v tabulkách Delta přechodná. Data můžou být přechodná z několika důvodů, například při dlouhotrvajících procesech extrakce, transformace a načítání (ETL).

Aktualizaci sémantického modelu Direct Lake je možné provést ručně, automaticky nebo programově. Další informace najdete v tématu Aktualizace sémantických modelů Direct Lake.

Další informace o verzování a rámování tabulek Delta najdete v tématu Vysvětlení úložiště pro sémantické modely Direct Lake.

Automatické aktualizace

K dispozici je nastavení sémantické úrovně modelu pro automatickou aktualizaci tabulek Direct Lake. Ve výchozím nastavení je povolená. Zajišťuje, aby se změny dat v OneLake automaticky projevily v sémantickém modelu Direct Lake. Automatické aktualizace byste měli zakázat, když chcete řídit změny dat rámováním, což bylo vysvětleno v předchozí části. Další informace najdete v tématu Správa sémantických modelů Direct Lake.

Spropitné

V sestavách Power BI můžete nastavit automatické obnovení stránky. Jedná se o funkci, která automaticky aktualizuje konkrétní stránku sestavy, pokud se sestava připojuje k sémantickému modelu Direct Lake (nebo jiným typům sémantického modelu).

Záložní režim DirectQuery

Dotaz odeslaný do sémantického modelu Direct Lake se může vrátit do režimu DirectQuery. V tomto případě načte data přímo z koncového bodu analýzy SQL lakehouse nebo datového skladu. Tyto dotazy vždy vrací nejnovější data, protože nejsou omezeny na bod v čase poslední operace rámování.

Dotaz se vždy vrací zpět, když sémantický model dotazuje zobrazení nebo tabulku v koncovém bodu analýzy SQL, který vynucuje zabezpečení na úrovni řádků (RLS).

Také může dotaz selhat, když sémantický model překročí hranice kapacity.

Důležitý

Pokud je to možné, měli byste vždy navrhnout řešení (nebo velikost kapacity), aby se zabránilo náhradnímu použití DirectQuery. Důvodem je, že může vést k pomalejšímu výkonu dotazů.

Náhradní funkci vašich sémantických modelů Direct Lake můžete řídit nastavením jejich vlastnosti DirectLakeBehavior. Další informace naleznete v tématu Nastavení vlastnosti chování Direct Lake.

Mantinely a omezení kapacity prostředků infrastruktury

Sémantické modely Direct Lake vyžadují licenci na kapacitu Fabric. Existují také omezení a limity kapacity, které platí pro vaše předplatné kapacity Fabric (SKU), jak ukazuje následující tabulka.

Důležitý

První sloupec v následující tabulce obsahuje také předplatná kapacity Power BI Premium (SKU P). Mějte na paměti, že Microsoft slučuje možnosti nákupu a vyřazuje licencování Power BI Premium na základě kapacitního využití. Místo toho by měli noví a stávající zákazníci zvážit nákup předplatných kapacity Fabric (SKU F).

Další informace najdete v tématu Důležitá aktualizace přichází k licencování Power BI Premium a Power BI Premium.

Skladová položka Fabric Soubory Parquet pro každou tabulku Skupiny řádků na každou tabulku Řádky v tabulce (miliony) Maximální velikost modelu na disku/ OneLake (GB) Maximální velikost paměti (GB) 1
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 Neomezený 25
F128/P2 5,000 5,000 3,000 Neomezený 50
F256/P3 5,000 5,000 6,000 Neomezený 100
F512/P4 10 000 10 000 12,000 Neomezený 200
F1024/P5 10 000 10 000 24,000 Neomezený 400
F2048 10 000 10 000 24,000 Neomezený 400

1 Pro sémantické modely Direct Lake Maximální paměť představuje horní limit prostředků paměti pro množství dat, které lze stránkovat do paměti. Z tohoto důvodu to nejsou ochranné mantinely, protože jejich překročení nezpůsobí návrat do režimu DirectQuery; může však mít dopad na výkon, pokud je množství dat dostatečně velké na to, aby způsobilo nadměrné stránkování dat modelů z databáze OneLake a do ní.

Pokud dojde k překročení, Maximální velikost modelu na disku nebo OneLake způsobí, že se všechny dotazy na sémantický model vrátí do režimu DirectQuery. Všechny ostatní mantinely zobrazené v tabulce se vyhodnocují pro každý dotaz. Proto je důležité optimalizovat tabulky Delta a sémantický model Direct Lake, aby se předešlo zbytečnému škálování na vyšší Fabric SKU (což vede ke zvýšení nákladů).

Kromě toho jednotky kapacity a maximální paměti na dotazy, platí pro sémantické modely Direct Lake. Další informace naleznete v tématu kapacity a skladové položky.

Důležité informace a omezení

Sémantické modely Direct Lake představují některé aspekty a omezení.

Poznámka

Možnosti a funkce sémantických modelů Direct Lake se vyvíjejí. Nezapomeňte pravidelně kontrolovat nejnovější seznam aspektů a omezení.

  • Když se tabulka sémantických modelů Direct Lake připojí k tabulce v koncovém bodu analýzy SQL, který vynucuje zabezpečení na úrovni řádků (RLS), dotazy zahrnující danou tabulku modelu se vždy vrátí do režimu DirectQuery. Výkon dotazů může být pomalejší.
  • Když se tabulka sémantických modelů Direct Lake připojí k zobrazení v koncovém bodu analýzy SQL, dotazy zahrnující danou tabulku modelu se vždy vrátí do režimu DirectQuery. Výkon dotazů může být pomalejší.
  • Složené modelování se nepodporuje. To znamená, že tabulky sémantických modelů Direct Lake nelze kombinovat s tabulkami v jiných režimech úložiště, jako je Import, DirectQuery nebo Duální (s výjimkou zvláštních případů, včetně skupin výpočtů , parametry citlivostní analýzya parametry pole).
  • Počítané sloupce a počítané tabulky, které odkazují na sloupce nebo tabulky v režimu úložiště Direct Lake, se nepodporují. Skupiny výpočtů, parametry 'co kdyby'a parametry pole, které implicitně vytvářejí počítané tabulky, stejně jako počítané tabulky neodkazující na sloupce nebo tabulky Direct Lake, jsou podporovány.
  • Tabulky režimu úložiště Direct Lake nepodporují složité typy sloupců tabulky Delta. Binární a sémantické typy GUID nejsou podporovány. Tyto datové typy je nutné převést na řetězce nebo jiné podporované datové typy.
  • Relace mezi tabulkami vyžadují, aby se datové typy souvisejících sloupců shodovaly.
  • Jednostranné sloupce relací musí obsahovat jedinečné hodnoty. Dotazy selžou, pokud se v jednom sloupci zjistí duplicitní hodnoty.
  • Automatické zpracování dat a času v Power BI Desktop není podporováno. Je podporováno označení vlastní tabulky kalendářních dat jako tabulky kalendářních dat.
  • Délka hodnot řetězcového sloupce je omezená na 32 764 znaků Unicode.
  • Hodnota s plovoucí desetinnou čárkou NaN (ne číslo) není podporovaná.
  • Publikování na web z Power BI pomocí servisního principálu je podporováno pouze při použití pevné identity pro sémantický model Direct Lake.
  • V prostředí webového modelování je ověřování omezené pro sémantické modely Direct Lake. Předpokládá se, že výběry uživatelů jsou správné a neprobíhá žádné dotazování k ověření kardinality nebo výběrů křížových filtrů pro relace nebo pro vybraný sloupec v označené tabulce s datem.
  • Karta Direct Lake na portálu Fabric v historii aktualizací obsahuje pouze chyby aktualizace související s Direct Lake. Operace úspěšné aktualizace (rámování) nejsou uvedené.
  • Skladová položka Fabric určuje maximální dostupnou paměť pro sémantický model Direct Lake pro kapacitu. Při překročení limitu můžou být dotazy na sémantický model pomalejší kvůli nadměrnému načítání a uvolňování dat modelu.
  • Vytvoření sémantického modelu Direct Lake v pracovním prostoru, který je v jiné oblasti pracovního prostoru zdroje dat, se nepodporuje. Pokud je například Lakehouse ve středozápadní části USA, můžete vytvořit pouze sémantické modely z tohoto Lakehouse ve stejné oblasti. Alternativním řešením je vytvořit Lakehouse v pracovním prostoru jiné oblasti a vytvořit zástupce k tabulkám před vytvořením sémantického modelu. Pokud chcete zjistit, v jaké oblasti se nacházíte, podívejte se, vyhledejte domovskou oblast Fabric.
  • Vlastní sémantický model Direct Lake můžete vytvořit a zobrazit pomocí identity instančního objektu, ale výchozí sémantický model Direct Lake nepodporuje instanční objekty. Ujistěte se, že je pro rozhraní REST API služby Fabric ve vašem tenantovi povoleno ověřování aplikačního objektu, a udělte aplikačnímu objektu oprávnění Přispěvatel nebo vyšší k pracovnímu prostoru vašeho sémantického modelu Direct Lake.
  • Vkládání sestav vyžaduje token pro vloženíV2 .
  • Direct Lake nepodporuje profily služebního principálu pro ověřování.
  • Podporované jsou přizpůsobené sémantické modely Direct Lake vytvořené instančním objektem a prohlížečem s instančním objektem, ale výchozí sémantické modely Direct Lake se nepodporují.

Porovnání s jinými režimy úložiště

Následující tabulka porovnává režim úložiště Direct Lake s režimy úložiště Import a DirectQuery.

Schopnost Direct Lake Dovoz DirectQuery
Licencování Pouze předplatné kapacity (SKU) Libovolná licence Fabric nebo Power BI (včetně licencí Microsoft Fabric Free) Libovolná licence Fabric nebo Power BI (včetně licencí Microsoft Fabric Free)
Zdroj dat Pouze tabulky jezera nebo skladu (nebo zobrazení) Jakýkoli konektor Jakýkoli konektor, který podporuje režim DirectQuery
Připojit se k zobrazením koncových bodů analýzy SQL Ano – ale automaticky se vrátí do režimu DirectQuery. Ano Ano
Složené modely Bez 1 Ano – lze kombinovat s tabulkami v režimu úložiště DirectQuery nebo Duální. Ano – může kombinovat s tabulkami režimu úložiště Import nebo Duální
Jednotné přihlašování (SSO) Ano Není relevantní Ano
Počítané tabulky Ne – s výjimkou skupin výpočtů, parametry citlivostní analýzya parametry pole, které implicitně vytvářejí počítané tabulky Ano Ne – počítané tabulky používají režim úložiště Import, i když odkazují na jiné tabulky v režimu DirectQuery.
Počítané sloupce Ne Ano Ano
Hybridní tabulky Ne Ano Ano
Oddíly tabulky modelu Ne – rozdělení lze provádět na úrovni tabulky Delta. Ano – buď automaticky vytvořené přírůstkovou aktualizací, nebo ručně vytvořené pomocí koncového bodu XMLA Ne
Uživatelem definované agregace Ne Ano Ano
Zabezpečení na úrovni objektů koncového bodu SQL Analytics nebo zabezpečení na úrovni sloupců Ano – dotazy se ale vrátí do režimu DirectQuery a můžou způsobit chyby při odepření oprávnění. Ano – ale musí duplikovat oprávnění pro objektové zabezpečení sémantického modelu. Ano – dotazy ale můžou způsobit chyby při odepření oprávnění
Zabezpečení na úrovni řádků koncového bodu SQL Analytics (RLS) Ano – dotazy se ale vrátí do režimu DirectQuery. Ano – ale musí duplikovat oprávnění pomocí sémantického modelu zabezpečení na úrovni řádků (RLS) Ano
Model sémantického zabezpečení na úrovni řádků (RLS) Ano – důrazně se ale doporučuje použít trvalou identitu cloudové připojení. Ano Ano
Sémantické zabezpečení na úrovni objektu modelu (OLS) Ano Ano Ano
Velké objemy dat bez požadavku na aktualizaci Ano Méně vhodná – pro dotazování a aktualizaci se může vyžadovat větší velikost kapacity. Ano
Snížení latence dat Ano – pokud automatické aktualizace povoleny nebo programové reframing; přípravy dat však musí být nejprve dokončeny v upstreamu. Ne Ano
Power BI Embedded Ano 2 Ano Ano

1 Nemůžete kombinovat tabulky režimu úložiště Direct Lake s tabulkami režimu úložiště DirectQuery nebo Duální ve stejném sémantickém modelu. Pomocí Power BI Desktopu ale můžete vytvořit složený model v sémantickém modelu Direct Lake a pak ho rozšířit o nové tabulky (pomocí režimu importu, DirectQuery nebo duálního úložiště) nebo výpočtů. Další informace najdete v tématu Sestavení složeného modelu na sémantickém modelu.

2 vyžaduje token pro vložení V2. Pokud používáte service principal, musíte použít pevnou identitu cloudové připojení.