Principy a optimalizace aktualizací toků dat

  • Článek

Toky dat Power BI umožňují připojení, transformaci, kombinování a distribuci dat pro podřízenou analýzu. Klíčovým prvkem toků dat je proces aktualizace, který použije kroky transformace vytvořené v tocích dat a aktualizuje data v samotných položkách.

Abyste porozuměli době spuštění, výkonu a tomu, jestli z toku dat získáváte maximum, můžete si po aktualizaci toku dat stáhnout historii aktualizací.

Vysvětlení aktualizací

Pro toky dat platí dva typy aktualizací:

  • Úplné, což provede úplné vyprázdnění a opětovné načtení dat.

  • Přírůstkové (pouze Premium), které zpracovává podmnožinu dat na základě časových pravidel vyjádřených jako filtr, který nakonfigurujete. Filtr sloupce kalendářního data dynamicky rozdělí data do rozsahů v služba Power BI. Po nakonfigurování přírůstkové aktualizace tok dat automaticky změní váš dotaz tak, aby zahrnoval filtrování podle data. Automaticky vygenerovaný dotaz můžete upravit pomocí Rozšířený editor v Power Query a doladit nebo přizpůsobit aktualizaci. Pokud používáte vlastní službu Azure Data Lake Storage, uvidíte časové řezy dat na základě nastavených zásad aktualizace.

    Poznámka:

    Další informace o přírůstkové aktualizaci a jejím fungování najdete v tématu Použití přírůstkové aktualizace s toky dat.

Přírůstková aktualizace umožňuje v Power BI velké toky dat s následujícími výhodami:

  • Aktualizace jsou po první aktualizaci rychlejší, a to z důvodu následujících faktů:

    • Power BI aktualizuje poslední oddíly N určené uživatelem (kde je oddíl den/týden/měsíc atd.) nebo
    • Power BI aktualizuje jenom data, která je potřeba aktualizovat. Například aktualizace pouze posledních pěti dnů 10letého sémantického modelu.
    • Power BI aktualizuje jenom data, která se změnila, pokud zadáte sloupec, který chcete zkontrolovat změny.

  • Aktualizace jsou spolehlivější – už není nutné udržovat dlouhotrvající připojení k nestálým zdrojovým systémům.

  • Spotřeba prostředků se snižuje – méně dat pro aktualizaci snižuje celkovou spotřebu paměti a dalších prostředků.

  • Kdykoli je to možné, Power BI využívá paralelní zpracování na oddílech, což může vést k rychlejším aktualizacím.

V některém z těchto scénářů aktualizace se data neaktualizují, pokud selže aktualizace. Data můžou být zastaralá, dokud se nejnovější aktualizace neskončí, nebo je můžete aktualizovat ručně a pak se můžou dokončit bez chyby. K aktualizaci dochází u oddílu nebo entity, takže pokud přírůstková aktualizace selže nebo u entity dojde k chybě, nedojde k celé transakci aktualizace. Řekl jiný způsob, pokud oddíl (zásady přírůstkové aktualizace) nebo entita selže pro tok dat, celá operace aktualizace selže a žádná data se neaktualizují.

Principy a optimalizace aktualizací

Pokud chcete lépe pochopit, jak funguje operace aktualizace toku dat, projděte si historii aktualizace toku dat tím, že přejdete na některý z vašich toků dat. Vyberte Další možnosti (...) pro tok dat. Pak zvolte Nastavení > Historie aktualizace. Můžete také vybrat tok dat v pracovním prostoru. Pak zvolte Další možnosti (...) > Historie aktualizace.

Screenshot of dataflows refresh history.

Historie aktualizací poskytuje přehled aktualizací, včetně typu – na vyžádání nebo naplánované, doby trvání a stavu spuštění. Pokud chcete zobrazit podrobnosti ve formě souboru CSV, vyberte ikonu pro stažení úplně vpravo od řádku popisu aktualizace. Stažený sdílený svazek clusteru obsahuje atributy popsané v následující tabulce. Aktualizace Premium poskytují další informace na základě dalších možností výpočetních a toků dat oproti tokům dat založeným na platformě Pro, které se nacházejí ve sdílené kapacitě. Některé z následujících metrik jsou například k dispozici pouze v Premium.

Položka Popis Pro Premium
Požadováno dne Časová aktualizace byla naplánovaná nebo aktualizace byla nyní v místním čase kliknuta. ✔ ✔
Název toku dat Název toku dat ✔ ✔
Stav aktualizace toku dat Možné stavy jsou dokončené, neúspěšné nebo přeskočené (pro entitu). Případy použití, jako jsou propojené entity, jsou důvody, proč se může přeskočit. ✔ ✔
Název entity Název tabulky. ✔ ✔
Název oddílu Tato položka závisí na tom, jestli je tok dat premium nebo ne, a pokud se Pro zobrazuje jako NA, protože nepodporuje přírůstkové aktualizace. Premium zobrazuje hodnotu FullRefreshPolicyPartition nebo IncrementalRefreshPolicyPartition-[DateRange]. ✔
Stav aktualizace Stav aktualizace jednotlivé entity nebo oddílu, který poskytuje stav pro daný časový řez dat, která se aktualizují. ✔ ✔
Počáteční čas V premium je tato položka čas, kdy byl tok dat zařazen do fronty pro zpracování entity nebo oddílu. Tato doba se může lišit, pokud toky dat mají závislosti a potřebují počkat na zahájení zpracování sady výsledků upstreamového toku dat. ✔ ✔
Koncový čas Koncový čas je čas dokončení entity toku dat nebo oddílu, pokud je to možné. ✔ ✔
Doba trvání Celkový uplynulý čas aktualizace toku dat vyjádřený v HH:MM:SS. ✔ ✔
Zpracované řádky U dané entity nebo oddílu je počet naskenovaných nebo zapsaných řádků modulem toků dat. Tato položka nemusí vždy obsahovat data na základě provedené operace. Data se můžou vynechat, když se výpočetní modul nepoužívá nebo když používáte bránu, protože se tam zpracovávají data. ✔
Zpracované bajty U dané entity nebo oddílu jsou data zapsaná modulem toků dat vyjádřená v bajtech.

Při použití brány u tohoto konkrétního toku dat nejsou tyto informace k dispozici.		 ✔
Maximální potvrzení (KB) Maximální potvrzení je paměť potvrzení ve špičce užitečná pro diagnostiku selhání nedostatku paměti, pokud není dotaz M optimalizovaný.

Pokud používáte bránu pro tento konkrétní tok dat, tyto informace nejsou k dispozici.		 ✔
Processor Time U dané entity nebo oddílu je čas vyjádřený v HH:MM:SS, který modul toků dat strávil prováděním transformací.

Pokud používáte bránu pro tento konkrétní tok dat, tyto informace nejsou k dispozici.		 ✔
Doba čekání U dané entity nebo oddílu je čas strávený entitou ve stavu čekání na základě úlohy v kapacitě Premium. ✔
Výpočetní modul U dané entity nebo oddílu podrobně popisuje, jak operace aktualizace používá výpočetní modul. Hodnoty jsou:
- NA
-Složen
-Mezipaměti
- Cached + Folded

Tyto prvky jsou podrobněji popsány dále v tomto článku.		 ✔
Chyba V případě potřeby je podrobná chybová zpráva popsaná pro každou entitu nebo oddíl. ✔ ✔

Pokyny k aktualizaci toku dat

Statistika aktualizace poskytuje cenné informace, které můžete použít k optimalizaci a urychlení výkonu toků dat. V následujících částech popisujeme některé scénáře, co je potřeba hlídat a jak optimalizovat na základě poskytnutých informací.

Orchestrace

Použití toků dat ve stejném pracovním prostoru umožňuje přímou orchestraci. Jako příklad můžete mít toky dat A, B a C v jednom pracovním prostoru a řetězení jako A > B > C. Pokud zdroj (A) aktualizujete, aktualizují se také podřízené entity. Pokud ale aktualizujete jazyk C, musíte aktualizovat ostatní nezávisle. Pokud přidáte do toku dat B nový zdroj dat (který není součástí A), nebudou se tato data aktualizovat jako součást orchestrace.

Můžete chtít zřetězení položek, které nevyhovují výkonu spravované orchestrace Power BI. V těchto scénářích můžete použít rozhraní API a/nebo použít Power Automate. Informace o programové aktualizaci najdete v dokumentaci k rozhraní API a skriptu PowerShellu. K dispozici je konektor Power Automate, který umožňuje tento postup bez psaní kódu. Můžete si prohlédnout podrobné ukázky s konkrétními návody pro sekvenční aktualizace.

Sledování

Pomocí vylepšených statistik aktualizace popsaných výše v tomto článku můžete získat podrobné informace o aktualizaci toku dat. Pokud byste ale chtěli zobrazit toky dat s přehledem aktualizací pro celého tenanta nebo pracovního prostoru, například k vytvoření řídicího panelu monitorování, můžete použít rozhraní API nebo šablony PowerAutomate. Podobně pro případy použití, jako je odesílání jednoduchých nebo složitých oznámení, můžete použít konektor PowerAutomate nebo vytvořit vlastní aplikaci pomocí rozhraní API.

Chyby časového limitu

Optimalizace doby potřebnou k provádění scénářů extrakce, transformace a načítání (ETL) je ideální. V Power BI platí následující případy:

  • Některé konektory mají explicitní nastavení časového limitu, které můžete nakonfigurovat. Další informace najdete v tématu Připojení orům v Power Query.
  • Toky dat Power BI, které používají Power BI Pro, můžou mít také časové limity pro dlouhotrvající dotazy v rámci entity nebo toků dat samotné. Toto omezení v pracovních prostorech Power BI Premium neexistuje.

Pokyny k vypršení časového limitu

Prahové hodnoty časového limitu pro toky dat Power BI Pro jsou:

  • Dvě hodiny na úrovni jednotlivých entit.
  • Tři hodiny na celé úrovni toku dat

Pokud máte například tok dat se třemi tabulkami, nemůže trvat déle než dvě hodiny a v případě, že doba trvání překročí tři hodiny, vyprší časový limit celého toku dat.

Pokud dochází k vypršení časových limitů, zvažte optimalizaci dotazů toku dat a zvažte použití posouvání dotazů ve zdrojových systémech.

Samostatně zvažte upgrade na Premium na uživatele, který se na tyto časové limity nevztahují a nabízí vyšší výkon kvůli mnoha funkcím Power BI Premium na uživatele.

Dlouhé doby trvání

Aktualizace složitých nebo velkých toků dat může trvat déle, protože můžou být špatně optimalizované toky dat. Následující části obsahují pokyny ke zmírnění dlouhých dob aktualizace.

Pokyny pro dlouhé doby trvání aktualizace

Prvním krokem ke zlepšení dlouhých dob aktualizace toků dat je vytvoření toků dat podle osvědčených postupů. Mezi vhodné vzory patří:

Dále vám může pomoct vyhodnotit, jestli můžete použít přírůstkovou aktualizaci.

Použití přírůstkové aktualizace může zvýšit výkon. Při odesílání dotazů pro operace aktualizace je důležité, aby se filtry oddílů odesílaly do zdrojového systému. Pokud chcete odesílat filtrování, znamená to, že zdroj dat by měl podporovat posouvání dotazů, nebo můžete obchodní logiku vyjádřit pomocí funkce nebo jiných prostředků, které můžou Power Query pomoct eliminovat a filtrovat soubory nebo složky. Většina zdrojů dat, které podporují dotazy SQL, podporuje posouvání dotazů a některé datové kanály OData můžou také podporovat filtrování.

Zdroje dat, jako jsou ploché soubory, objekty blob a rozhraní API, ale obvykle nepodporují filtrování. V případech, kdy back-end zdroje dat nepodporuje filtr, nejde ho odeslat dolů. V takových případech modul mash-up kompenzuje a aplikuje filtr místně, což může vyžadovat načtení úplného sémantického modelu ze zdroje dat. Tato operace může způsobit, že přírůstková aktualizace bude pomalá a v případě použití může dojít k výpadku prostředků v služba Power BI nebo v místní bráně dat.

Vzhledem k různým úrovním podpory posouvání dotazů pro každý zdroj dat byste měli provést ověření, abyste zajistili, že je logika filtru zahrnutá do zdrojových dotazů. Aby se to usnadnilo, Power BI se pokusí toto ověření provést za vás s indikátory posouvání kroků pro Power Query Online. Mnohé z těchto optimalizací jsou prostředí v době návrhu, ale po aktualizaci máte příležitost analyzovat a optimalizovat výkon aktualizace.

Nakonec zvažte optimalizaci prostředí. Prostředí Power BI můžete optimalizovat vertikálním navýšením kapacity, správnou velikostí bran dat a snížením latence sítě pomocí následujících optimalizací:

  • Pokud používáte kapacity dostupné v Power BI Premium nebo Premium na uživatele, můžete zvýšit výkon zvýšením instance Premium nebo přiřazením obsahu k jiné kapacitě.

  • Brána se vyžaduje vždy, když Power BI potřebuje přístup k datům, která nejsou k dispozici přímo přes internet. Místní bránu dat můžete nainstalovat na místní server nebo na virtuální počítač.

    • Pokud chcete porozumět úlohám brány a doporučením pro změnu velikosti, přečtěte si téma Určení velikosti místní brány dat.
    • Také vyhodnoťte, že se data nejprve přenesou do přípravného toku dat a budou na něj odkazovat pomocí propojených a počítaných entit.

  • Latence sítě může ovlivnit výkon aktualizace 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. Pokud chcete zjistit, kde se váš tenant nachází, přečtěte si téma Vyhledání výchozí oblasti pro vaši organizaci. 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ší požadavky, například do podkladového zdroje dat nebo do brány dat, které podléhají také latenci sítě.

    • Nástroje, jako je Azure Speed Test , poskytují informace o latenci sítě mezi klientem a oblastí Azure. Obecně platí, že pokud chcete minimalizovat dopad latence sítě, snažte se udržovat zdroje dat, brány a cluster Power BI co nejblíže. Umístění ve stejné oblasti je vhodnější. Pokud je latence sítě problém, zkuste vyhledat brány a zdroje dat blíže ke clusteru Power BI tak, že je umístíte do virtuálních počítačů hostovaných v cloudu.

Vysoký čas procesoru

Pokud se zobrazí vysoký čas procesoru, pravděpodobně máte nákladné transformace, které se nepřeloží. Vysoká doba procesoru je způsobená počtem použitých kroků nebo typem transformací, které vytváříte. Každá z těchto možností může mít za následek vyšší dobu aktualizace.

Pokyny pro vysoký čas procesoru

Pro optimalizaci vysokého času procesoru existují dvě možnosti.

Nejprve použijte posouvání dotazů v samotném zdroji dat, což by mělo snížit zatížení výpočetního modulu toku dat přímo. Posouvání dotazů ve zdroji dat umožňuje zdrojovému systému většinu práce. Tok dat pak může předávat dotazy v nativním jazyce zdroje, místo aby po počátečním dotazu musel provádět všechny výpočty v paměti.

Ne všechny zdroje dat můžou provádět posouvání dotazů, a i když je možné, že je možné, že existují toky dat, které provádějí určité transformace, které se nedají přeložit do zdroje. V takových případech je vylepšený výpočetní modul funkcí, kterou Power BI zavádí, aby potenciálně zlepšil výkon až o 25krát, konkrétně pro transformace.

Použití výpočetního modulu k maximalizaci výkonu

I když má Power Query přehled o posouvání dotazů v době návrhu, sloupec výpočetního modulu poskytuje podrobnosti o tom, jestli se používá samotný interní modul. Výpočetní modul je užitečný, když máte složitý tok dat a provádíte transformace v paměti. Tato situace spočívá v tom, že vylepšená statistika aktualizace může být užitečná, protože sloupec výpočetního modulu poskytuje podrobnosti o tom, zda byl samotný modul použit.

Následující části obsahují pokyny k používání výpočetního modulu a jeho statistiky.

Upozorňující

Během návrhu může indikátor skládání v editoru ukázat, že dotaz se při využívání dat z jiného toku dat nepřeloží. Zkontrolujte zdrojový tok dat, pokud je povolené rozšířené výpočetní prostředí a ujistěte se, že je povolené posouvání na zdrojovém toku dat.

Pokyny ke stavu výpočetního modulu

Zapnutí vylepšeného výpočetního modulu a pochopení různých stavů je užitečné. Vylepšený výpočetní modul interně používá k čtení a ukládání dat databázi SQL. Nejlepší je, aby se vaše transformace spouštěly v tomto dotazovacím stroji. Následující odstavce poskytují různé situace a pokyny k tomu, co dělat pro každou z nich.

NA – Tento stav znamená, že se výpočetní modul nepoužíval, protože:

  • Používáte toky dat Power BI Pro.
  • Výpočetní modul jste explicitně vypnuli.
  • Používáte posouvání dotazů ve zdroji dat.
  • Provádíte složité transformace, které nemůžou využívat modul SQL, který se používá k urychlení dotazů.

Pokud máte dlouhé doby trvání a stále se zobrazuje stav NA, ujistěte se, že je zapnutý a nechtěně vypnutý. Jedním zdoporučenýchm vzorem je počáteční načtení dat do služba Power BI pomocí pracovních toků dat. Tento model může snížit zatížení zdrojových systémů a společně s výpočetním modulem zvýšit rychlost transformací a zvýšit výkon.

Uložená v mezipaměti – Pokud se zobrazí stav uložený v mezipaměti, data toku dat byla uložena ve výpočetním modulu a je k dispozici pro odkazování jako součást jiného dotazu. Tato situace je ideální, pokud ji používáte jako propojenou entitu, protože výpočetní modul ukládá tato data do mezipaměti pro použití v podřízené části. Data uložená v mezipaměti nemusí být ve stejném toku dat několikrát aktualizována. Tato situace je také potenciálně ideální, pokud ji chcete použít pro DirectQuery.

Při ukládání do mezipaměti se výkon při počátečním příjmu dat později ve stejném toku dat nebo v jiném toku dat ve stejném pracovním prostoru vyplácí.

Pokud máte pro entitu velkou dobu trvání, zvažte vypnutí výpočetního modulu. Pokud chcete entitu uložit do mezipaměti, Power BI ji zapíše do úložiště a do SQL. Pokud se jedná o entitu s jedním použitím, výhody výkonu pro uživatele nemusí být za trest dvojitého příjmu dat.

Přeložené – přeložené znamená, že tok dat mohl ke čtení dat používat výpočetní prostředky SQL. Počítaná entita použila tabulku z SQL ke čtení dat a použitý JAZYK SQL souvisí s konstrukty jejich dotazu.

Přeložený stav se zobrazí, pokud při používání místních nebo cloudových zdrojů dat nejprve načetli data do přípravného toku dat a odkazovali na tok dat v tomto toku dat. Tento stav platí jenom pro entity, které odkazují na jinou entitu. To znamená, že vaše dotazy byly spuštěny nad modulem SQL a mají potenciál zlepšit se výpočetními prostředky SQL. Pokud chcete zajistit, aby modul SQL zpracovává vaše transformace, použijte transformace, které podporují skládání SQL, jako je sloučení (spojení), seskupení podle (agregace) a akce připojení (sjednocení) v Editor Power Query.

Cached + Folded – Když uvidíte , že je uložená v mezipaměti + přeložená, je pravděpodobné, že aktualizace dat je optimalizovaná, protože máte entitu, která odkazuje na jinou entitu a odkazuje na jinou entitu upstream. Tato operace také běží nad SQL a má také potenciál pro zlepšení výpočetních prostředků SQL. Abyste měli jistotu, že dosáhnete nejlepšího možného výkonu, použijte transformace, které podporují skládání SQL, jako je sloučení (spojení), seskupení podle (agregace) a akce připojení (sjednocení) v Editor Power Query.

Pokyny pro optimalizaci výkonu výpočetního modulu

Následující kroky umožňují úlohám aktivovat výpočetní modul a tím vždy zvýšit výkon.

Počítané a propojené entity ve stejném pracovním prostoru:

Při příjmu dat se zaměřte na co nejrychlejší načtení dat do úložiště, použijte filtry pouze v případě, že zmenší celkovou sémantickou velikost modelu. Nechte logiku transformace oddělenou od tohoto kroku. Dále rozdělte transformaci a obchodní logiku do samostatného toku dat ve stejném pracovním prostoru. Použijte propojené nebo počítané entity. Tím umožníte, aby modul aktivoval a urychloval výpočty. Pro jednoduchou analogii je to jako příprava jídla v kuchyni: příprava jídla je obvykle samostatný a odlišný krok od shromažďování surovin a předpoklad pro umístění jídla do trouby. Podobně je potřeba logiku připravit samostatně, abyste mohli využít výhod výpočetního modulu.

Ujistěte se, že provádíte operace, které se skládají, jako jsou sloučení, spojení, převod a další.

Také můžete vytvářet toky dat v publikovaných pokynech a omezeních.

Když je výpočetní modul zapnutý, ale výkon je pomalý:

Při zkoumání scénářů, ve kterých je výpočetní modul zapnutý, proveďte následující kroky, ale dochází k nízkému výkonu:

  • Omezte počítané a propojené entity, které existují v celém pracovním prostoru.
  • Pokud je vaše počáteční aktualizace se zapnutým výpočetním modulem, data se zapisují do jezera a do mezipaměti. Výsledkem tohoto dvojitého zápisu jsou aktualizace pomalejší.
  • Pokud máte tok dat propojování s více toky dat, nezapomeňte naplánovat aktualizace zdrojových toků dat tak, aby se neaktualily ve stejnou dobu.

Úvahy a omezení

Licence Power BI Pro má limit aktualizace toků dat 8 aktualizací za den.

Související obsah