Sdílet prostřednictvím

Pokyny k načítání dat pro stránkované sestavy

  • Článek

Tento článek je určen jako autor sestavy, která navrhuje stránkované sestavy Power BI. Poskytuje doporučení, která vám pomůžou navrhnout efektivní a efektivní načítání dat.

Typy zdrojů dat

Stránkované sestavy nativně podporují relační i analytické zdroje dat. Tyto zdroje jsou dále kategorizovány jako cloudové nebo místní. Místní zdroje dat – ať už hostované místně nebo na virtuálním počítači – vyžadují bránu dat, aby se Power BI mohl připojit. Cloudová služba znamená, že se Power BI může připojit přímo pomocí připojení k internetu.

Pokud můžete zvolit typ zdroje dat (možná v novém projektu), doporučujeme používat cloudové zdroje dat. Stránkované sestavy se můžou připojit s nižší latencí sítě, zejména pokud se zdroje dat nacházejí ve stejné oblasti jako tenant Power BI. K těmto zdrojům se také můžete připojit pomocí jednotného přihlašování (SSO). To znamená, že identita uživatele sestavy může proudit do zdroje dat, což umožňuje vynutit oprávnění na úrovni řádků pro jednotlivé uživatele. Jednotné přihlašování se v současné době podporuje jenom pro místní zdroje dat SQL Server a Oracle (viz Podporované zdroje dat pro stránkované sestavy Power BI).

Poznámka:

I když se v současné době není možné připojit k místním databázím pomocí jednotného přihlašování, stále můžete vynutit oprávnění na úrovni řádků. Provádí se předáním předdefinovaných polí UserID do parametru dotazu datové sady. Zdroj dat bude muset ukládat hodnoty hlavního názvu uživatele (UPN) způsobem, který dokáže správně filtrovat výsledky dotazu.

Představte si například, že každý prodejce je uložený jako řádek v tabulce Prodejce . Tabulka obsahuje sloupce hlavního názvu uživatele (UPN) a také prodejní oblast prodejce. V době dotazu se tabulka filtruje podle hlavního názvu uživatele sestavy a souvisí také s prodejními fakty pomocí vnitřního spojení. Dotaz tak efektivně filtruje řádky faktů prodeje na řádky prodejních faktů uživatele sestavy.

Relační zdroje dat

Obecně platí, že relační zdroje dat jsou vhodné pro sestavy provozního stylu, jako jsou prodejní faktury. Jsou také vhodné pro sestavy, které potřebují načíst velmi velké datové sady (nad 10 000 řádků). Relační zdroje dat mohou také definovat uložené procedury, které lze provádět datovými sadami sestav. Uložené procedury poskytují několik výhod:

  • Parametrizace
  • Zapouzdření programovací logiky, což umožňuje složitější přípravu dat (například dočasné tabulky, kurzory nebo skalární uživatelem definované funkce)
  • Vylepšili jsme udržovatelnost, což umožňuje snadno aktualizovat logiku uložených procedur. V některých případech je možné to provést bez nutnosti upravovat a znovu publikovat stránkované sestavy (poskytování názvů sloupců a datových typů zůstává beze změny).
  • Lepší výkon, protože jejich plány provádění se ukládají do mezipaměti pro opakované použití
  • Opakované použití uložených procedur napříč několika sestavami

V Power BI Tvůrce sestav můžete pomocí návrháře relačních dotazů graficky vytvořit příkaz dotazu, ale jenom pro zdroje dat Microsoftu.

Analytické zdroje dat

Analytické zdroje dat, označované také jako datové modely nebo jenom modely, jsou vhodné pro provozní i analytické sestavy a můžou poskytovat rychlé souhrnné výsledky dotazů i přes velmi velké objemy dat. Míry modelu a klíčové ukazatele výkonu můžou zapouzdřit složitá obchodní pravidla, aby se dosáhlo souhrnu dat. Tyto zdroje dat ale nejsou vhodné pro sestavy, které potřebují načíst velmi velké objemy dat (nad 10 000 řádků).

V Power BI Tvůrce sestav máte na výběr ze dvou návrhářů dotazů: návrháře dotazů DAX služby Analysis Services a návrháře dotazů MDX služby Analysis Services. Tyto návrháře je možné použít pro zdroje dat sémantických modelů Power BI nebo jakýkoli Služba Analysis Services serveru SQL nebo model služby Azure Analysis Services – tabulkové nebo multidimenzionální.

Doporučujeme použít návrháře dotazů DAX– tím, že plně vyhovuje vašim požadavkům na dotazy. Pokud model nedefinuje potřebné míry, budete muset přepnout do režimu dotazu. V tomto režimu můžete příkaz dotazu přizpůsobit přidáním výrazů (pro dosažení souhrnu).

Návrhář dotazů MDX vyžaduje, aby váš model zahrnoval míry. Návrhář má dvě funkce, které návrhář dotazů DAX nepodporuje. Konkrétně vám to umožní:

  • Definujte počítané členy na úrovni dotazu (v MDX).
  • Nakonfigurujte oblasti dat tak, aby požadovaly agregace serveru v nepodrobných skupinách. Pokud vaše sestava potřebuje prezentovat souhrny částečně nebo nesoučtových měr (jako jsou výpočty časového měřítka nebo jedinečné počty), bude pravděpodobně efektivnější používat agregace serverů, než načíst řádky podrobností nízké úrovně a mít souhrny výpočetních sestav.

Velikost výsledku dotazu

Obecně se doporučuje načíst pouze data požadovaná vaší sestavou. Proto nenačítejte sloupce ani řádky, které sestava nevyžaduje.

Pokud chcete omezit řádky, měli byste vždy použít nejvíce omezující filtry a definovat agregační dotazy. Agregace dotazů seskupuje a sumarizuje zdrojová data za účelem načtení výsledků s vyššími agregačními intervaly. Představte si například, že sestava musí prezentovat souhrn prodeje prodejce. Místo načtení všech řádků prodejních objednávek vytvořte dotaz datové sady, který seskupuje podle prodejce, a sumarizuje prodeje pro každou skupinu.

Pole založená na výrazech

Datovou sadu sestavy je možné rozšířit o pole založená na výrazech. Pokud například vaše datová sada zdrojuje jméno a příjmení zákazníka, můžete chtít pole, které zřetězí tato dvě pole, aby se vytvořilo celé jméno zákazníka. K dosažení tohoto výpočtu máte dvě možnosti. Můžete provádět následující akce:

  • Vytvořte počítané pole, což je pole datové sady založené na výrazu.
  • Vložte výraz přímo do dotazu datové sady (pomocí nativního jazyka zdroje dat), což vede k běžnému poli datové sady.

Pokud je to možné, doporučujeme druhou možnost. Existují dva dobré důvody, proč je lepší vložit výrazy přímo do dotazu datové sady:

  • Je možné, že je zdroj dat optimalizovaný tak, aby vyhodnotil výraz efektivněji než Power BI (je to zejména případ relačních databází).
  • Vylepšili jsme výkon sestavy, protože Před vykreslováním sestav není potřeba power BI materializovat počítaná pole. Počítaná pole můžou výrazně prodloužit dobu vykreslování sestavy, když datové sady načtou velký počet řádků.

Názvy polí

Když vytvoříte datovou sadu, její pole se automaticky pojmenují po sloupcích dotazu. Je možné, že tyto názvy nejsou popisné nebo intuitivní. Je také možné, že názvy sloupců zdrojového dotazu obsahují znaky zakázané v identifikátorech objektů jazyka RDL (Report Definition Language) (jako jsou mezery a symboly). V tomto případě jsou zakázané znaky nahrazeny znakem podtržítka (_).

Doporučujeme nejdřív ověřit, jestli jsou všechny názvy polí popisné, stručné, ale přesto smysluplné. Pokud ne, doporučujeme, abyste je před zahájením rozložení sestavy přejmenovali. Je to proto, že přejmenovaná pole se nemění na výrazy použité v rozložení sestavy. Pokud se rozhodnete přejmenovat pole po zahájení rozložení sestavy, budete muset najít a aktualizovat všechny poškozené výrazy.

Filtr vs. parametr

Je pravděpodobné, že návrhy stránkovaných sestav budou mít parametry sestavy. Parametry sestavy se běžně používají k zobrazení výzvy uživatele sestavy k filtrování sestavy. Jako autor stránkované sestavy máte dva způsoby, jak dosáhnout filtrování sestav. Parametr sestavy můžete mapovat na:

  • Filtr datové sady, v takovém případě se hodnoty parametrů sestavy používají k filtrování dat, která datová sada už načítala.
  • Parametr datové sady, v takovém případě se hodnoty parametrů sestavy vloží do nativního dotazu odeslaného do zdroje dat.

Poznámka:

Všechny datové sady sestav se za každou relaci ukládají do mezipaměti po dobu až 10 minut za jejich poslední použití. Datovou sadu můžete znovu použít při odesílání nových hodnot parametrů (filtrování), vykreslování sestavy v jiném formátu nebo interakci s návrhem sestavy nějakým způsobem, jako je přepínání viditelnosti nebo řazení.

Představte si příklad sestavy prodeje, která má jeden parametr sestavy pro filtrování sestavy podle jednoho roku. Datová sada načítá prodeje za všechny roky. Dělá to proto, že parametr sestavy se mapuje na filtry datové sady. Sestava zobrazuje data pro požadovaný rok, což je podmnožina dat datové sady. Když uživatel sestavy změní parametr sestavy na jiný rok a pak sestavu zobrazí, Power BI nemusí načítat žádná zdrojová data. Místo toho použije jiný filtr na datovou sadu, která už je uložená v mezipaměti. Jakmile je datová sada uložená do mezipaměti, může být filtrování velmi rychlé.

Teď zvažte jiný návrh sestavy. Tentokrát návrh sestavy mapuje parametr sestavy prodejního roku na parametr datové sady. Power BI tak vloží hodnotu roku do nativního dotazu a datová sada načte data jenom pro daný rok. Pokaždé, když uživatel sestavy změní hodnotu parametru sestavy roku a pak zobrazí sestavu, datová sada načte nový výsledek dotazu pouze pro daný rok.

Oba přístupy k návrhu můžou filtrovat data sestavy a oba návrhy můžou dobře fungovat pro návrhy sestav. Optimalizovaný návrh ale bude záviset na očekávaném objemu dat, nestálosti dat a očekávaném chování uživatelů sestavy.

Filtrování datových sad doporučujeme, pokud očekáváte, že se vícekrát znovu použije jiná podmnožina řádků datové sady (což šetří dobu vykreslování, protože nová data nemusí být načtena). V tomto scénáři zjistíte, že náklady na načtení větší datové sady se dají odměňovat oproti počtu opětovného použití datové sady. Proto je užitečné vygenerovat dotazy, které jsou časově náročné. Dávejte ale pozor – ukládání velkých datových sad do mezipaměti na základě jednotlivých uživatelů může negativně ovlivnit výkon a propustnost kapacity.

Parametrizace datové sady doporučujeme, pokud očekáváte, že se pravděpodobně vyžádá jiná podmnožina řádků datové sady, nebo pokud bude počet řádků datové sady, které se mají filtrovat, pravděpodobně velmi velké (a neefektivní pro ukládání do mezipaměti). Tento přístup k návrhu funguje dobře i v případě, že je vaše úložiště dat nestálé. V tomto případě každá změna hodnoty parametru sestavy způsobí načtení aktuálních dat.

Jiné než nativní zdroje dat

Pokud potřebujete vyvíjet stránkované sestavy založené na zdrojích dat, které stránkované sestavy nativně nepodporují, měli byste nejprve v Power BI Desktopu vyvíjet datový model. Tímto způsobem se můžete připojit ke stovkám zdrojů dat, které Power BI podporuje. Po publikování do služba Power BI můžete vyvinout stránkovanou sestavu, která se připojí k sémantickému modelu Power BI.

Integrace dat

Pokud potřebujete zkombinovat data z více zdrojů dat, máte dvě možnosti:

  • Kombinování datových sad sestav: Pokud jsou zdroje dat nativně podporovány stránkovanými sestavami, můžete zvážit vytvoření počítaných polí, která používají funkce Lookup nebo LookupSet Tvůrce sestav.
  • Vývoj modelu Power BI Desktopu: Je pravděpodobně efektivnější, ale v Power BI Desktopu vyvíjíte datový model. Power Query můžete použít ke kombinování dotazů na základě libovolného podporovaného zdroje dat. Po publikování do služba Power BI můžete vyvinout stránkovanou sestavu, která se připojí k sémantickému modelu Power BI.

Latence sítě

Latence sítě může ovlivnit výkon sestavy zvýšením času potřebného k dosažení služba Power BI požadavků a doručením odpovědí. Tenanti v Power BI se přiřazují ke konkrétní oblasti.

Tip

Pokud chcete zjistit, kde se nachází váš tenant, přečtěte si téma Kde se nachází můj tenant Power BI?

Když uživatelé z tenanta přistupují k služba Power BI, jejich žádosti se vždy směrují do této oblasti. Jakmile se požadavky dostanou do služba Power BI, může služba posílat další žádosti , například do podkladového zdroje dat nebo brány dat, které podléhají také latenci sítě. Obecně platí, že pokud chcete minimalizovat dopad latence sítě, snažte se zachovat zdroje dat, brány a kapacitu Power BI co nejblíže. Pokud možno, nacházejí se ve stejné oblasti. Pokud je latence sítě problém, zkuste vyhledat brány a zdroje dat blíže ke své kapacitě Power BI tak, že je umístíte do virtuálních počítačů hostovaných v cloudu.

Komplexní datové typy SQL Serveru

Vzhledem k tomu, že SQL Server je místní zdroj dat, musí se Power BI připojit přes bránu. Brána ale nepodporuje načítání dat pro složité datové typy. Komplexní datové typy zahrnují předdefinované typy, jako jsou geometrické a geografické datové typy prostorových dat a hierarchii. Mohou také zahrnovat uživatelem definované typy implementované prostřednictvím třídy sestavení v modulu CLR (Common Language Runtime Microsoft.NET Framework).

Vykreslení prostorových dat a analýz ve vizualizaci mapy vyžaduje prostorová data SQL Serveru. Proto není možné pracovat s vizualizací mapy, pokud je SQL Server vaším zdrojem dat. Aby bylo jasné, bude fungovat, pokud je zdrojem dat Azure SQL Database, protože Se Power BI nepřipojí přes bránu.

Obrázky můžete použít k přidání loga nebo obrázků do rozložení sestavy. Pokud obrázky souvisejí s řádky načtenými datovou sadou sestavy, máte dvě možnosti:

  • Je možné, že data obrázků se dají načíst také z vašeho zdroje dat (pokud už jsou uložená v tabulce).
  • Když jsou obrázky uložené na webovém serveru, můžete k vytvoření cesty URL obrázku použít dynamický výraz.

Další informace a návrhy najdete v tématu Pokyny k obrázkům pro stránkované sestavy.

Redundantní načítání dat

Je možné, že vaše sestava načte redundantní data. K tomu může dojít při odstranění polí dotazu na datovou sadu nebo pokud sestava obsahuje nepoužívané datové sady. Vyhýbejte se těmto situacím, protože představují zbytečné zatížení zdrojů dat, sítě a prostředků kapacity Power BI.

Odstraněná pole dotazu

Na stránce Pole okna Vlastnosti datové sady je možné odstranit pole dotazu datové sady (pole dotazu se mapují na sloupce načtené dotazem datové sady). Tvůrce sestav ale neodebere z dotazu datové sady odpovídající sloupce.

Pokud potřebujete odstranit pole dotazu z datové sady, doporučujeme odebrat odpovídající sloupce z dotazu datové sady. Tvůrce sestav automaticky odebere všechna redundantní pole dotazu. Pokud dojde k odstranění polí dotazu, nezapomeňte také upravit příkaz dotazu datové sady tak, aby se sloupce odebraly.

Nepoužité datové sady

Při spuštění sestavy se vyhodnocují všechny datové sady, i když nejsou svázané s objekty sestavy. Proto před publikováním sestavy nezapomeňte odebrat všechny testovací nebo vývojové datové sady.

Související obsah

Další informace týkající se tohoto článku najdete v následujících zdrojích informací: