Vývoj sémantických modelů Direct Lake
Tento článek popisuje témata návrhu relevantní pro vývoj sémantických modelů Direct Lake.
Vytvoření modelu
Pomocí portálu Fabric vytvoříte v pracovním prostoru sémantický model Direct Lake. Jedná se o jednoduchý proces, který zahrnuje výběr tabulek z jednoho jezera nebo skladu, které se mají přidat do sémantického modelu.
Pak můžete použít prostředí webového modelování k dalšímu vývoji sémantického modelu. Toto prostředí umožňuje vytvářet relace mezi tabulkami, vytvářet míry a skupiny výpočtů, označit tabulky kalendářních dat a nastavit vlastnosti pro model a jeho objekty (například formáty sloupců). Model můžete také nastavit zabezpečení na úrovni řádků (RLS) definováním rolí a pravidel a přidáním členů (uživatelských účtů Microsoft Entra nebo skupin zabezpečení) do těchto rolí.
Alternativně můžete pokračovat ve vývoji modelu pomocí nástroje kompatibilního s XMLA, jako je SQL Server Management Studio (SSMS) (verze 19.1 nebo novější) nebo opensourcové komunitní nástroje. Další informace najdete v tématu Podpora zápisu modelu s koncovým bodem XMLA dále v tomto článku.
Spropitné
Prostřednictvím tohoto návodu se dozvíte, jak vytvořit lakehouse, tabulku Delta a základní sémantický model Direct Lake.
Tabulky modelů
Tabulky modelu jsou založené na tabulce nebo zobrazení koncového bodu analýzy SQL. Pokud je to ale možné, vyhněte se používání zobrazení. Důvodem je to, že dotazy na tabulku modelu založené na zobrazení budou vždy přecházet do režimu DirectQuery, což může způsobit pomalejší výkon dotazů.
Tabulky by měly obsahovat sloupce pro filtrování, seskupování, řazení a sumarizaci, kromě sloupců, které podporují relace modelu. I když nepotřebné sloupce nemají vliv na výkon dotazů na sémantický model (protože se nenačtou do paměti), mají za následek větší velikost úložiště ve OneLake a vyžadují k načtení a údržbě více výpočetních prostředků.
Varování
Použití sloupců, které dynamické maskování dat (DDM) v sémantických modelech Direct Lake, se nepodporuje.
Informace o výběru tabulek, které mají být součástí sémantického modelu Direct Lake, najdete v tématu Úprava tabulek pro sémantické modely Direct Lake.
Další informace o sloupcích, které chcete zahrnout do sémantických tabulek modelu, najdete v tématu Vysvětlení úložiště pro sémantické modely Direct Lake.
Vynucení pravidel přístupu k datům
Pokud máte požadavky na doručování podmnožina dat modelu různým uživatelům, můžete vynutit pravidla přístupu k datům. Pravidla vynucujete nastavením zabezpečení na úrovni objektů (OLS) nebo zabezpečení na úrovni řádků (RLS) v koncovém bodu analýzy SQL nebo v sémantickém modelu.
Poznámka
Téma vynucování pravidel přístupu k datům je odlišné, ale související s nastavením oprávnění pro spotřebitele obsahu, tvůrce a uživatele, kteří budou spravovat sémantický model (a související položky prostředků infrastruktury). Další informace o nastavení oprávnění naleznete v tématu Správa sémantických modelů Direct Lake.
Zabezpečení na úrovni objektů (OLS)
OLS zahrnuje omezení přístupu ke zjišťování a dotazování objektů nebo sloupců. OlS můžete například použít k omezení uživatelů, kteří mají přístup ke sloupci Salary
z tabulky Employee
.
U koncového bodu analýzy SQL můžete nastavit OLS tak, aby řízení přístupu k objektům koncových bodů, jako jsou tabulky nebo zobrazení, a zabezpečení na úrovni sloupců (CLS) pro řízení přístupu ke sloupcům tabulky koncových bodů.
Pro sémantický model můžete nastavit OLS k ovládání přístupu k tabulkám nebo sloupcům modelu. K nastavení OLS musíte použít opensourcové komunitní nástroje, jako je tabulkový editor.
Zabezpečení na úrovni řádků (RLS)
RLS (Zabezpečení na úrovni řádků) zahrnuje omezení přístupu k podmnožinám dat v tabulkách. Pomocí RLS můžete například zajistit, aby prodejci měli přístup pouze k prodejním datům pro zákazníky v jejich prodejní oblasti.
Pro koncový bod analýzy SQL můžete nastavit zabezpečení na úrovni řádků tak, aby řídit přístup k řádkům v tabulce koncových bodů.
Důležitý
Když dotaz použije jakoukoli tabulku, která má zabezpečení na úrovni řádků v koncovém bodu analýzy SQL, přepne se zpět do režimu DirectQuery. Výkon dotazů může být pomalejší.
Pro sémantický model můžete nastavit zabezpečení na úrovni řádků pro řízení přístupu k řádkům v tabulkách modelu . Nastavení RLS je možné provést v prostředí webového modelování nebo pomocí nástroje třetí strany.
Jak se vyhodnocují dotazy
důvod vývoje sémantických modelů Direct Lake je dosáhnout vysoce výkonných dotazů nad velkými objemy dat v OneLake. Proto byste se měli snažit navrhnout řešení, které maximalizuje šance na dotazování přímo z paměti.
Následující kroky odhadují, jak se dotazy vyhodnocují (a jestli selžou). Výhody režimu úložiště Direct Lake jsou možné pouze v případech, kdy se dosáhne pátého kroku.
- Pokud dotaz obsahuje jakoukoli tabulku nebo sloupec omezený sémantickým modelem OLS, vrátí se výsledek chyby (vizuál sestavy se nevykreslí).
- Pokud dotaz obsahuje libovolný sloupec omezený koncovým bodem SQL Analytics CLS (nebo je tabulka zamítnutá), vrátí se výsledek chyby (vizuál sestavy se nevykreslí).
- Pokud cloudové připojení používá jednotné přihlašování (výchozí), CLS je určeno úrovní přístupu uživatele sestavy.
- Pokud cloudové připojení používá pevnou identitu, modul CLS je určen úrovní přístupu pevné identity.
- Pokud dotaz obsahuje jakoukoli tabulku v koncovém bodu analýzy SQL, která vynucuje zabezpečení na úrovni řádků, nebo pokud je použito zobrazení, dotaz se vrátí do režimu DirectQuery.
- Pokud cloudové připojení používá jednotné přihlašování (výchozí), RLS určuje úroveň přístupu uživatele sestavy.
- Pokud cloudové připojení používá pevnou identitu, RLS je určeno úrovní přístupu této pevné identity.
- Pokud dotaz překročí mantinelykapacity, vrátí se do režimu DirectQuery.
- V opačném případě je dotaz splněn z mezipaměti v paměti. Data sloupců se načte do paměti podle potřeby.
Oprávnění ke zdrojové položce
Účet použitý pro přístup k datům je jedním z následujících.
- Pokud cloudové připojení používá SSO (jednotné přihlašování, výchozí), je to uživatel sestavy.
- Pokud cloudové připojení používá pevnou identitu, jedná se o pevnou identitu.
Účet musí mít alespoň oprávnění Čtení a ReadData pro zdrojovou položku (lakehouse nebo warehouse). Oprávnění k položce mohou být zděděna z rolí pracovního prostoru nebo explicitně přiřazena položce, jak je popsáno v tomto článku.
Za předpokladu, že je tento požadavek splněný, Fabric udělí nezbytný přístup k sémantickému modelu pro čtení tabulek Delta a souvisejících souborů Parquet (pro načtení dat sloupců do paměti), a teprve poté lze použít pravidla přístupu k datům.
Možnosti pravidla přístupu k datům
Pravidla přístupu k datům můžete nastavit v:
- Pouze sémantický model.
- Pouze koncový bod analýzy SQL.
- V sémantickém modelu i v koncovém bodu analýzy SQL.
Pravidla v sémantickém modelu
Pokud musíte vynutit pravidla přístupu k datům, měli byste to udělat v sémantickém modelu, kdykoli je to možné. To proto, že RLS (zabezpečení na úrovni řádků) vynucené sémantickým modelem se dosahuje filtrováním mezipaměti dat v paměti, aby byly dotazy výkonově efektivní.
Je to také vhodný přístup, pokud uživatelům sestav není uděleno oprávnění dotazovat se na jezero nebo sklad.
V obou případech důrazně doporučujeme, aby cloudové připojení místo jednotného přihlašování používalo pevnou identitu. Jednotné přihlašování by znamenalo, že koncoví uživatelé mají přímý přístup ke koncovému bodu sql Analytics, a proto můžou obejít pravidla zabezpečení v sémantickém modelu.
Důležitý
Sémantická oprávnění položek modelu se dají explicitně nastavit prostřednictvím aplikací Power BInebo implicitně prostřednictvím rolí pracovního prostoru.
Pravidla přístupu k datům sémantického modelu nejsou zejména vynucována pro uživatele, kteří mají oprávnění k zápisu na sémantický model. Pravidla přístupu k datům se naopak vztahují na uživatele, kteří jsou přiřazeni k roli pracovního prostoru Prohlížeč. Uživatelé přiřazení k rolím Administrátor, Člennebo Přispěvatel pracovního prostoru mají implicitně oprávnění k zápisu v sémantickém modelu, a proto nejsou vynucována pravidla pro přístup k datům. Další informace najdete v tématu Role v pracovních prostorech.
Pravidla v koncovém bodu analýzy SQL
Je vhodné vynutit pravidla přístupu k datům v koncovém bodu analýzy SQL, když sémantický model používá jednotné přihlašovánía cloudové připojení. Je to proto, že identita uživatele je delegována k dotazování na koncový bod analýzy SQL a zajišťuje, aby dotazy vracely pouze data, ke kterým má uživatel povolený přístup. Je také vhodné vynutit pravidla přístupu k datům na této úrovni, když se uživatelé dotazují přímo na koncový bod analýzy SQL pro jiné úlohy (například pro vytvoření stránkované sestavy Power BI nebo export dat).
Nicméně se dotaz sémantického modelu vrátí do režimu DirectQuery, pokud obsahuje jakoukoli tabulku, která využívá RLS v analytickém koncovém bodu SQL. V důsledku toho by sémantický model nikdy nemusel ukládat data do mezipaměti, aby bylo možné dosáhnout vysoce výkonných dotazů.
Pravidla v obou vrstvách
Pravidla přístupu k datům je možné vynutit v obou vrstvách. Tento přístup ale zahrnuje větší složitost a režii správy. V tomto případě důrazně doporučujeme, aby cloudové připojení místo jednotného přihlašování používalo pevnou identitu.
Porovnání možností pravidel přístupu k datům
Následující tabulka porovnává možnosti nastavení datového přístupu.
Použít pravidla přístupu k datům | Komentář |
---|---|
Pouze sémantický model | Tuto možnost použijte, pokud uživatelé nemají udělená oprávnění k zadání dotazu na lakehouse nebo sklad. Nastavte cloudové připojení tak, aby používalo pevnou identitu. Vysoký výkon dotazů lze dosáhnout z mezipaměti v paměti. |
Pouze koncový bod analýzy SQL | Tuto možnost použijte, když uživatelé potřebují přistupovat k datům z datového skladu nebo sémantického modelu a s konzistentními pravidly přístupu k datům. Ujistěte se, že je pro cloudové připojení povolené jednotné přihlašování. Výkon dotazů může být pomalý. |
Sémantický model lakehouse nebo skladu a | Tato možnost zahrnuje další správní režii. Nastavte cloudové připojení tak, aby používalo pevnou identitu. |
Doporučené postupy pro vynucování pravidel přístupu k datům
Tady jsou doporučené postupy související s vynucováním pravidel přístupu k datům:
- Pokud musí být různí uživatelé omezeni na podmnožinu dat, když je to proveditelné, vynucujte RLS pouze na úrovni sémantického modelu. Uživatelé tak budou mít prospěch z vysoce výkonných dotazů zpracovávaných v paměti. V tomto případě důrazně doporučujeme, aby cloudové připojení místo jednotného přihlašování používalo pevnou identitu.
- Pokud je to možné, vyhněte se vynucování OLS a CLS v obou vrstvách, protože výsledkem jsou chyby ve vizuálech sestavy. Chyby můžou vést k nejasnostem nebo obavám uživatelů. V případě sumarizovatelných sloupců zvažte vytvoření měr, které v určitých podmínkách vrátí BLANK místo CLS (pokud je to možné).
Podpora zápisu modelu pomocí koncového bodu XMLA
Sémantické modely Direct Lake podporují operace zápisu s koncovým bodem XMLA pomocí nástrojů, jako jsou SSMS (19.1 nebo novější) a opensourcových komunitních nástrojů.
Spropitné
Další informace o používání nástrojů třetích stran k vývoji, správě nebo optimalizaci sémantických modelů najdete v pokročilé správě datových modelů scénář použití.
Než budete moct provádět operace zápisu, musí být pro kapacitu povolená možnost čtení a zápisu XMLA. Další informace najdete v tématu Povolení čtení a zápisu XMLA.
Operace zápisu modelu s podporou koncového bodu XMLA:
- Přizpůsobení, sloučení, skriptování, ladění a testování metadat modelu Direct Lake
- Správa zdrojového kódu a verzí, kontinuální integrace a průběžné nasazování (CI/CD) s Využitím Azure DevOps a GitHubu Další informace naleznete v tématu Správa životního cyklu obsahu.
- Úlohy automatizace, jako je sémantická aktualizace modelu, a použití změn v sémantických modelech Direct Lake pomocí PowerShellu a rozhraní REST API.
Při změně sémantického modelu pomocí XMLA je nutné aktualizovat ChangedProperties a PBI_RemovedChildren kolekci změněného objektu tak, aby zahrnoval všechny změněné nebo odebrané vlastnosti. Pokud tuto aktualizaci neprovedete, nástroje modelování Power BI můžou při příští synchronizaci schématu se službou Lakehouse přepsat všechny změny.
Další informace o značkách rodokmenu objektů sémantického modelu najdete v článku značky rodokmenu pro sémantické modely Power BI .
Důležitý
Tabulky Direct Lake vytvořené pomocí aplikací XMLA budou zpočátku v nezpracovaném stavu, dokud aplikace neodešle příkaz pro aktualizaci. Dotazy, které zahrnují nezpracované tabulky, se vždy vrátí do režimu DirectQuery. Proto při vytváření nového sémantického modelu nezapomeňte model aktualizovat, aby zpracovával jeho tabulky.
Další informace najdete v tématu Připojení sémantického modelu s koncovým bodem XMLA.
Metadata modelu Direct Lake
Když se připojíte k sémantickému modelu Direct Lake pomocí koncového bodu XMLA, metadata vypadají jako u jakéhokoli jiného modelu. Modely Direct Lake ale ukazují následující rozdíly:
- Vlastnost
compatibilityLevel
databázového objektu je 1604 (nebo vyšší). - Vlastnost režimu oddílů Direct Lake je nastavena na
directLake
. - Oddíly Direct Lake používají sdílené výrazy k definování zdrojů dat. Výraz odkazuje na analytický SQL koncový bod lakehousu nebo datového skladu. Direct Lake používá koncový bod analýzy SQL ke zjišťování schématu a informací o zabezpečení, ale načítá data přímo z OneLake (pokud se z jakéhokoli důvodu nevrátí do režimu DirectQuery).
Úkoly po publikování
Po publikování sémantického modelu Direct Lake byste měli dokončit některé úlohy nastavení. Další informace najdete v tématu Správa sémantických modelů Direct Lake.
Nepodporované funkce
Sémantické modely Direct Lake nepodporují následující funkce modelu:
- Počítané tabulky odkazující na tabulky nebo sloupce v režimu úložiště Direct Lake
- Počítané sloupce odkazující na tabulky nebo sloupce v režimu úložiště Direct Lake
- Hybridní tabulky
- Uživatelem definované agregace
- Složené modely v tom, že 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 modelu. Power BI Desktop ale můžete použít k vytvoření živého připojení k sémantickému modelu Direct Lake a jeho rozšíření o nové míry a odtud můžete kliknout na možnost provést změny v tomto modelu přidat nové tabulky (pomocí režimu importu, DirectQuery nebo duálního úložiště). Tato akce vytvoří připojení DirectQuery k sémantickému modelu v režimu Direct Lake, takže tabulky se zobrazují jako režim úložiště DirectQuery, ale tento režim úložiště neukazuje náhradní režim directQuery. Pouze připojení mezi tímto novým modelem a modelem Direct Lake je DirectQuery a dotazy stále využívají Direct Lake k získání dat z OneLake. Další informace najdete v tématu Sestavení složeného modelu na sémantickém modelu.
- Sloupce založené na sloupcích koncových bodů analýzy SQL, které používají dynamické maskování dat