Správa sémantických modelů Direct Lake
Tento článek popisuje témata návrhu relevantní pro správu sémantických modelů Direct Lake.
Úkoly po publikování
Jakmile poprvé publikujete sémantický model Direct Lake připravený k sestavování zpráv, měli byste okamžitě dokončit některé úkoly po publikaci. Tyto úlohy lze také kdykoli upravit během životního cyklu sémantického modelu.
- Nastavení cloudového připojení
- Správa členství v rolích zabezpečení
- Nastavení oprávnění k položce Fabric
- Nastavení naplánované aktualizace
Volitelně můžete také nastavit zjišťování dat, aby tvůrci sestav mohli číst metadata, což jim pomáhá zjišťovat data v centru dat OneLake a požádat o přístup k nim. Můžete také schválit (certifikovaný nebo propagovaný) sémantický model, aby vyjádřil, že představuje kvalitní data vhodná pro použití.
Nastavení cloudového připojení
Sémantický model Direct Lake používá cloudové připojení k připojení ke koncovému bodu analýzy SQL. Umožňuje přístup ke zdrojovým datům, což jsou soubory Parquet v režimu úložiště OneLake (režim úložiště Direct Lake, který zahrnuje načítání dat sloupců do paměti) nebo koncový bod analýzy SQL (když dotazy přejdou zpět do režimu DirectQuery).
Výchozí cloudové připojení
Když vytvoříte sémantický model Direct Lake, použije se výchozí cloudové připojení. Využívá jednotné přihlašování (SSO), což znamená, že identita, která dotazuje sémantický model (často uživatel sestavy), je používána k dotazování na data z koncového bodu SQL analytiky.
Sdílitelná cloudová připojení
Volitelně můžete vytvořit spravitelné cloudové připojení (SCC), aby bylo možné vytvořit připojení ke zdroji dat s pevnou identitou. Může pomoct podnikovým zákazníkům chránit úložiště dat organizace. IT oddělení může spravovat přihlašovací údaje, vytvářet SCCs a sdílet je s určenými tvůrci pro centralizovanou správu přístupů.
Pokud chcete nastavit pevnou identitu, přečtěte si téma Určení pevné identity pro sémantický model Direct Lake.
Autentizace
Pevná identita se může ověřit pomocí OAuth 2.0 nebo instančního objektu.
Poznámka
Podporuje se pouze ověřování Microsoft Entra. Základní ověřování tedy není podporováno pro sémantické modely Direct Lake.
OAuth 2.0
Pokud používáte OAuth 2.0, můžete se ověřit pomocí uživatelského účtu Microsoft Entra. Uživatelský účet musí mít oprávnění k dotazování tabulek a zobrazení koncových bodů analýzy SQL a metadat schématu.
Použití konkrétního uživatelského účtu není doporučeným postupem. Důvodem je to, že dotazy na sémantický model selžou, pokud dojde ke změně hesla nebo odstranění uživatelského účtu (například když zaměstnanec opustí organizaci).
Hlavní služba
Ověřování pomocí služebního principálu je doporučeným postupem, protože není závislé na konkrétním uživatelském účtu. Objekt zabezpečení musí mít oprávnění k dotazování tabulek a zobrazení koncových bodů analýzy SQL a metadat schématu.
V případě kontinuity je možné přihlašovací údaje instančního objektu spravovat pomocí obměny tajných kódů nebo certifikátů.
Poznámka
Nastavení tenanta Fabric musí umožňovat služební identity a služební identita musí patřit do deklarované skupiny zabezpečení.
Jednotné přihlašování
Při vytváření sdíleného připojení ke cloudu není zatržítko Jednotné přihlášení ve výchozím nastavení zaškrtnuté. Toto je správné nastavení při použití pevné identity.
Jednotné přihlašování můžete povolit, pokud chcete, aby identita, která dotazuje sémantický model, dotazuje také koncový bod analýzy SQL. V této konfiguraci použije sémantický model Direct Lake pevnou identitu k aktualizaci modelu a identity uživatele k dotazování dat.
Když používáte pevnou identitu, je běžné zakázat jednotné přihlašování, aby se pevná identita používala pro aktualizace i dotazy, ale neexistuje žádný technický požadavek.
Doporučené postupy pro cloudová připojení
Tady jsou doporučené postupy související s cloudovými připojeními:
- Když mají všichni uživatelé přístup k datům (a mají k tomu oprávnění), není potřeba vytvářet sdílené cloudové připojení. Místo toho je možné použít výchozí nastavení cloudového připojení. V tomto případě se použije identita uživatele, který model dotazuje, pokud by se dotazy měly vrátit do režimu DirectQuery.
- Pokud chcete použít pevnou identitu k dotazování zdrojových dat, vytvořte sdílené cloudové připojení. Důvodem může být to, že uživatelé, kteří se dotazují na sémantický model, nemají udělená oprávnění ke čtení jezera nebo skladu. Tento přístup je zvlášť relevantní, pokud sémantický model vynucuje RLS (zabezpečení na úrovni řádků).
- Pokud používáte pevnou identitu, použijte možnost aplikační objekt, protože je bezpečnější a spolehlivější. Je to proto, že se nespoléhá na jeden uživatelský účet nebo jejich oprávnění a nebude vyžadovat údržbu (a přerušení) v případě, že změní heslo nebo opustí organizaci.
- Pokud musí být různí uživatelé omezeni na přístup pouze k podmnožinám dat, vynucujte RLS, pokud je to možné, pouze na úrovni sémantického modelu. Tak budou uživatelé profitovat z vysoce výkonných dotazů v paměti.
- Pokud je to možné, vyhněte se OLS a CLS, protože výsledkem jsou chyby ve vizuálních prvcích zprávy. Chyby můžou uživatelům způsobit nejasnosti nebo obavy. U sumarizovatelných sloupců zvažte vytvoření měr, které v určitých podmínkách vrátí prázdnou hodnotu místo CLS (pokud je to možné).
Správa členství v rolích zabezpečení
Pokud sémantický model Direct Lake vynucuje zabezpečení na úrovni řádků (RLS), možná budete muset spravovat členy, které jsou přiřazeny k rolím zabezpečení. Další informace najdete v tématu Správa zabezpečení v modelu.
Nastavit oprávnění položek Fabric
Sémantické modely Direct Lake se řídí vrstveným modelem zabezpečení. Provádějí kontroly oprávnění prostřednictvím koncového bodu sql Analytics, aby zjistili, jestli má identita, která se pokouší o přístup k datům, potřebná oprávnění pro přístup k datům.
Uživatelům musíte udělit oprávnění, aby mohli používat nebo spravovat sémantický model Direct Lake. Uživatelé sestav potřebují oprávnění ke čtení a tvůrci sestav potřebují oprávnění k vytváření. Sémantická oprávnění modelu je možné přiřadit přímo nebo získat implicitně prostřednictvím rolí pracovního prostoru. Pokud chcete spravovat nastavení sémantického modelu (pro aktualizaci a další konfigurace), musíte být vlastníkem sémantického modelu .
V závislosti na nastavení cloudového připojení a na to, jestli se uživatelé potřebují dotazovat na koncový bod služby Lakehouse nebo SQL Analytics skladu, možná budete muset udělit další oprávnění (popsaná v tabulce v této části).
Poznámka
Zejména uživatelé nikdy nevyžadují oprávnění ke čtení dat ve OneLake. Je to proto, že Fabric uděluje potřebná oprávnění k sémantickému modelu ke čtení tabulek Delta a přidružených souborů Parquet (k načtení dat sloupců do paměti). Sémantický model má také potřebná oprávnění k pravidelnému čtení koncového bodu analýzy SQL, aby mohl provádět kontroly oprávnění, abyste zjistili, k jakým datům má uživatel dotazující se (nebo pevná identita) přístup.
Zvažte následující scénáře a požadavky na oprávnění.
| Scénář | Požadovaná oprávnění | Komentáře |
|---|---|---|
| Uživatelé můžou zobrazit sestavy | • Udělte oprávnění ke čtení pro sestavy a oprávnění Číst pro sémantický model. • Pokud cloudové připojení používá jednotné přihlašování, udělte alespoň oprávnění ke čtení pro lakehouse nebo sklad. |
Sestavy nemusí patřit do stejného pracovního prostoru jako sémantický model. Další informace naleznete v tématu Strategie pro uživatele s přístupem pouze ke čtení. |
| Uživatelé můžou vytvářet sestavy | • Udělte oprávnění pro sestavení v rámci sémantického modelu. • Pokud cloudové připojení používá jednotné přihlašování, udělte alespoň oprávnění ke čtení pro lakehouse nebo datový sklad. |
Další informace naleznete v tématu Strategie pro tvůrce obsahu. |
| Uživatelé mohou dotazovat sémantický model, ale je jim odepřeno dotazovat lakehouse nebo endpoint SQL Analytics. | • Neudělujte žádné oprávnění k jezeru ani skladu. | Vhodné pouze v případech, kdy cloudové připojení používá pevnou identitu. |
| Uživatelé můžou dotazovat sémantický model a koncový bod analýzy SQL, ale dotazování na lakehouse se zamítá. | • Udělte oprávnění ke čtení a ReadData pro jezero nebo sklad. | Důležité: Dotazy odeslané do koncového bodu analýzy SQL budou obcházet přístupová oprávnění k datům vynucená sémantickým modelem. |
| Správa sémantického modelu, včetně nastavení aktualizace | • Vyžaduje sémantické vlastnictví modelu. | Další informace najdete v tématu Vlastnictví sémantického modelu. |
Důležitý
Před vydáním sémantického modelu a sestav do produkčního prostředí byste vždy měli důkladně testovat oprávnění.
Další informace naleznete v tématu sémantická oprávnění modelu.
Aktualizace sémantických modelů Direct Lake
Aktualizace sémantického modelu Direct Lake vede k operaci "framing". Operaci aktualizace je možné aktivovat:
- Ručním provedením aktualizace na vyžádání na portálu Fabric nebo spuštěním příkazu TMSL (Tabular Model Scripting Language) Aktualizovat ze skriptu v SQL Server Management Studio (SSMS) nebo pomocí nástroje třetí strany, který se připojuje přes koncový bod XMLA.
- Automaticky nastavením plánu aktualizace na portálu Fabric.
- K automatickým změnám dochází, když jsou v podkladových tabulkách Delta zjištěny změny - podrobnosti najdete v části automatické aktualizace (popsáno dále).
- Automatizovaně, spuštěním aktualizace pomocí rozhraní Power BI REST API nebo TOM. Programovou aktualizaci můžete aktivovat jako poslední krok procesu extrakce, transformace a načítání (ETL).
Automatické aktualizace
K dispozici je sémantické nastavení na úrovni modelu s názvem Udržování dat Direct Lake v aktualizovaném stavu, které automaticky aktualizuje tabulky 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. Nastavení je k dispozici na portálu Fabric v části Aktualizovat nastavení sémantického modelu.
Když je nastavení povolené, sémantický model provádí operaci rámování při zjištění úprav dat v podkladových tabulkách Delta. Operace rámování je vždy specifická pouze pro tabulky, ve kterých jsou zjištěny úpravy dat.
Doporučujeme ponechat nastavení zapnuté, zejména pokud máte malý nebo střední sémantický model. Je to zvlášť užitečné, když jsou vaše požadavky na generování sestav s nízkou latencí a tabulky Delta jsou pravidelně upravovány.
V některých situacích můžete chtít zakázat automatické aktualizace. Před zveřejněním nových dat pro uživatele sémantického modelu může být například potřeba povolit dokončení úloh přípravy dat nebo procesu ETL. Pokud je tato možnost zakázaná, můžete aktualizaci aktivovat pomocí programové metody (popsané výše).
Poznámka
Power BI pozastaví automatické aktualizace, když během aktualizace dojde k neobnovitelné chybě. K neobnovitelné chybě může dojít například v případě, že aktualizace selže po několika pokusech. Proto se ujistěte, že je možné úspěšně aktualizovat sémantický model. Power BI automaticky obnoví automatické aktualizace, když se následná aktualizace na vyžádání dokončí bez chyb.
Zahřejte mezipaměť.
Operace aktualizace sémantického modelu Direct Lake může vyřadit všechny rezidentní sloupce z paměti. To znamená, že první dotazy po aktualizaci sémantického modelu Direct Lake můžou zaznamenat určité zpoždění, protože sloupce se načtou do paměti. Zpoždění můžou být patrná jenom v případech, kdy máte extrémně velké objemy dat.
Abyste se takovým zpožděním vyhnuli, zvažte oteplení mezipaměti programovým odesláním dotazu do sémantického modelu. Pohodlný způsob, jak odeslat dotaz, je použít sémantický odkaz. Tato operace by se měla provést okamžitě po dokončení operace aktualizace.
Důležitý
Oteplení mezipaměti může dávat smysl pouze v případech, kdy zpoždění jsou nepřijatelná. Dbejte na to, abyste zbytečně nenačítali data do paměti, která by mohla zatížit jiné pracovní zátěže, což by mohlo způsobit jejich omezování nebo upozadění.
Nastavení vlastnosti chování Direct Lake
Náhradní mechanismus vašich sémantických modelů Direct Lake můžete řídit nastavením vlastnosti DirectLakeBehavior. Dá se nastavit na:
- automatické: (výchozí) dotazy se vrátí do režimu DirectQuery, pokud se požadovaná data nedají efektivně načíst do paměti.
- DirectLakeOnly: Všechny dotazy používají pouze režim úložiště Direct Lake. Návrat do režimu DirectQuery je zakázaný. Pokud data nelze načíst do paměti, vrátí se chyba.
- DirectQueryOnly: Všechny dotazy používají pouze režim DirectQuery. Toto nastavení použijte k otestování záložního výkonu, kdy můžete například sledovat výkon dotazů v připojených sestavách.
Vlastnost můžete nastavit v prostředí webového modelování nebo pomocí tabulkového objektového modelu (TOM) nebo jazyka TMSL (Tabular Model Scripting Language) .
Spropitné
Pokud chcete zpracovávat dotazy pouze v režimu úložiště Direct Lake, zvažte zakázání náhradního režimu DirectQuery. Doporučujeme zakázat záložní režim, pokud se nechcete vrátit k DirectQuery. Může být také užitečné, když chcete analyzovat zpracování dotazů pro sémantický model Direct Lake, abyste zjistili, jestli a jak často dochází k náhradnímu řešení.
Monitorování sémantických modelů Direct Lake
Sémantický model Direct Lake můžete monitorovat, abyste určili výkon dotazů DAX vizuálních prvků sestavy, nebo abyste zjistili, kdy přepne na režim DirectQuery.
Můžete použít Analyzátor výkonu, SQL Server Profiler, Azure Log Analytics nebo opensourcový komunitní nástroj, jako je DAX Studio.
Analyzátor výkonu
Pomocí Analyzátoru výkonu v Power BI Desktopu můžete zaznamenat dobu zpracování potřebnou k aktualizaci prvků sestavy zahájených v důsledku jakékoli interakce uživatele, která má za následek spuštění dotazu. Pokud výsledky monitorování zobrazují metriku Direct dotazu, znamená to, že dotazy DAX byly zpracovány v režimu DirectQuery. Bez této metriky se dotazy DAX zpracovávaly v režimu Direct Lake.
Další informace naleznete v tématu Analýza pomocí nástroje k analýze výkonu.
SQL Server Profiler
K načtení podrobností o výkonu dotazů trasováním událostí dotazů můžete použít SQL Server Profiler. Instaluje se s SQL Server Management Studio (SSMS). Než začnete, ujistěte se, že máte nainstalovanou nejnovější verzi aplikace SSMS.
Další informace naleznete v tématu Analyzování pomocí SQL Server Profiler.
Důležitý
Obecně platí, že režim úložiště Direct Lake poskytuje rychlý výkon dotazů, pokud není nutný náhradní režim DirectQuery. Vzhledem k tomu, že záložní režim DirectQuery může mít vliv na výkon dotazů, je důležité analyzovat zpracování dotazů pro sémantický model Direct Lake, abyste zjistili, jestli, jak často a proč dochází k náhradním operacím.
Azure Log Analytics
Ke shromažďování, analýze a zpracování telemetrických dat přidružených k sémantickému modelu Direct Lake můžete použít azure Log Analytics. Jedná se o službu v rámci azure Monitoru, kterou Power BI používá k ukládání protokolů aktivit.
Další informace najdete v tématu Použití Azure Log Analytics v Power BI.