Sdílet prostřednictvím

Správa sémantických modelů Direct Lake

  • Článek

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 vytváření sestav, měli byste okamžitě dokončit některé úkoly po publikování. Tyto úlohy lze také kdykoli upravit během životního cyklu sémantického modelu.

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 žádat o přístup k nim. Sémantický model můžete také doporučit (certifikovaný nebo propagovaný) a sdělit, ž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), se používá k dotazování dat koncových bodů analýzy SQL.

Sharable cloud connection

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 zamýšlenými tvůrci pro centralizovanou správu přístupu.

Pokud chcete nastavit pevnou identitu, přečtěte si téma Určení pevné identity pro sémantický model Direct Lake.

Ověřování

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í se proto nepodporuje 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).

Instanční objekt

Ověřování pomocí instančního objektu 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 instanční objekty a instanční objekt musí patřit do deklarované skupiny zabezpečení.

Jednotné přihlášení

Když vytvoříte připojení ke cloudu se zabezpečením, není ve výchozím nastavení zaškrtnuto políčko Jednotné přihlašování . 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.

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 identita uživatele, který dotazuje model, použije, 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 zabezpečení na úrovni řádků.
  • Pokud používáte pevnou identitu, použijte možnost instančního objektu, 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 pouze na přístup k podmnožině dat, pokud je to možné, vynucujte zabezpečení na úrovni sémantického modelu pouze na úrovni sémantického modelu. Uživatelé tak budou těžit 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álech sestavy. 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 přiřazené k rolím zabezpečení. Další informace najdete v tématu Správa zabezpečení modelu.

Nastavení oprávnění k položce infrastruktury

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 sestavení. Sémantická oprávnění modelu je možné přiřadit přímo nebo implicitně získat 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. Důvodem je to, ž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žadována oprávnění Komentáře
Uživatelé můžou zobrazit sestavy • Udělte oprávnění ke čtení pro sestavy a oprávnění ke čtení 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 jen pro čtení.
Uživatelé můžou vytvářet sestavy • Udělte oprávnění k sestavení 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.		 Další informace naleznete v tématu Strategie pro tvůrce obsahu.
Uživatelé mohou dotazovat sémantický model, ale dotazování na koncový bod lakehouse nebo SQL Analytics jsou odepřeni. • 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 ČteníData 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 Sémantické vlastnictví 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 najdete 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 rámování . Operaci aktualizace je možné aktivovat:

Automatické aktualizace

K dispozici je sémantické nastavení na úrovni modelu s názvem Udržovat data Direct Lake v aktualizovaném stavu , které automaticky aktualizuje tabulky Direct Lake. Ve výchozím nastavení je zapnuté. 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 zvlášť užitečné, když máte pravidelně upravené požadavky na generování sestav s nízkou latencí a tabulky Delta.

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, pokud během aktualizace dojde k neopravitelné 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í při načítání sloupců 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 tlačit na jiné úlohy kapacity, což by způsobilo jejich omezování nebo zastaralost.

Nastavení vlastnosti chování Direct Lake

Náhradní sémantické modely Direct Lake můžete řídit nastavením jeho DirectLakeBehavior vlastnosti. 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 Object Language).

Tip

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. Pokud se nechcete vracet zpět do DirectQuery, doporučujeme zakázat náhradní použití. 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 a určit výkon dotazů DAX vizuálu sestavy nebo určit, kdy se vrátí do režimu 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átor 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 přímých dotazů , 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í Analyzátor výkonu.

SQL Server Profiler

Sql Server Profiler můžete použít k načtení podrobností o výkonu dotazů trasováním událostí dotazů. Instaluje se pomocí aplikace 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 Analyzovat 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

Azure Log Analytics můžete použít ke shromažďování, analýze a provádění telemetrických dat přidružených k sémantickému modelu Direct Lake. Jedná se o službu ve službě Azure Monitor, 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.

Související obsah