Selhává vám refresh v Power BI každou noc?
Naplánovaný refresh skončí timeoutem, Power Query dojde paměť a vy se to dozvíte, až když někdo otevře dashboard. Příčinou téměř nikdy není Power BI. Je to práce, kterou po Power BI chcete.
Platforma pro automatizaci datových skladů, které důvěřují datové týmy napříč obory
Zní vám to povědomě?
- Noční refresh selže a vy se to dozvíte od toho, kdo v 08:00 otevřel report.
- Power Query hlásí "nedostatek paměti" nebo gateway skončí timeoutem, ale nikdy, když to testujete.
- Refresh, který v lednu trval čtyři minuty, trvá v říjnu padesát. V reportu se přitom nic nezměnilo.
- Před důležitými schůzkami spouštíte refresh ručně, protože plánu nevěříte.
Refresh neselhává kvůli nedostatku paměti. Selhává, protože dělá práci, která se nikdy neměla odehrávat v době refreshe.
Co selhává: Query Folding
- Dokud Query Folding ve vašem M kódu funguje, Power Query napíše jeden SQL příkaz a práci odvede databáze. Power BI pak jen převezme výsledek.
- Jakmile se Query Folding přeruší, stane se enginem samotné Power Query. Stáhne surové tabulky přes síť do paměti a práci odvede samo.
- Přeruší se potichu a bez varování: stačí merge (sloučení), vlastní sloupec, fuzzy match nebo indexový sloupec.
- Testováním projde, protože na vašem notebooku běží proti malé tabulce. Pak tabulka naroste.
Proč to dopadá na vás
- Tyto kroky existují, protože jste museli dodat report. Potřebná dimenze neexistovala, nebo přidání sloupce znamenalo čekat měsíce.
- Logika sedí uvnitř souboru
.pbix, neviditelná pro všechny výše v řetězci. - Report změnit můžete. Datový sklad změnit nemůžete.
Práce se dělá na špatném místě
- Merge, vlastní sloupce a fuzzy match jsou integrační operace, které patří do datového skladu. V Power Query běží znovu při každém refreshi.
- Patří na jedno centrální místo: do datového skladu nebo data hubu, který se postaví jednou a čte z něj každý report.
- Pokud to zní draze, odhad nejspíš počítá s tím, že se datové pipeline budou stavět ručně. Specializovaná automatizační platforma je generuje z modelu, a to mění náklady i čas, který to zabere.
Co se změní, když model přijde hotový
Datavault Builder generuje vault a star schema tak, aby běžely nativně v databázi, kterou už máte: SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks nebo BigQuery.
- Z vašeho M kódu se stane
SELECT * FROM dim_customer, na který se Query Folding uplatní přímo z definice. - Žádný merge, žádné parsování, žádný fuzzy match. Tato práce z reportu zmizela.
- Refresh doběhne za několik sekund, a doběhne předvídatelně.
- Pomalu se měnící dimenze se řeší výše v řetězci jako vault satelity, místo aby se jen aproximovaly.
- Logika získá lineage, takže otázka “odkud se tohle číslo vzalo” má viditelnou odpověď.
O co požádat
Ne “refresh pořád selhává”, ale:
“Naše kroky v Power Query nepodporují Query Folding, takže refresh každou noc stahuje surové tabulky do paměti. Můžeme je dostat jako konformní dimenze a tabulku faktů v datovém skladu, aby je report už jen četl?”
Pokud zazní, že pořádné namodelování by zabralo čtvrtletí práce inženýrů, přesně tuto námitku Datavault Builder odstraňuje.
Podívejte se, jak to funguje na vašich vlastních datech
Rezervujte si bezplatné demo a přineste report, se kterým máte největší potíže.
Tři kroky k číslům, která sedí
-
Vytáhněte stávající logiku
Posbírejte výpočty, joiny a filtry, které dnes vězí ve vašich reportech.
-
Centralizujte ji na jednom místě
Logika se jednou přesune do modelu datového skladu, takže každý report čte stejnou definici.
-
Čísla, která sedí
Každý report ukazuje stejné číslo a “odkud se tohle číslo vzalo” má viditelnou odpověď.
Jak Datavault Builder předá vašemu reportu hotový model
-
Model přijde hotový
Datavault Builder generuje vault a star schema tak, aby běžely nativně v databázi, kterou už máte: SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks nebo BigQuery.
-
Práce opustí report
Žádný merge, žádné parsování, žádný fuzzy match. Tato práce z reportu zmizela.
-
Zdroje přicházejí integrované
Zákazníci z ERP, CRM a e-shopu se spárují do jedné sady konformních dimenzí. Join proběhne jednou v datovém skladu, ne znovu v každém reportu.
-
Historie, na kterou se lze dotázat
Každá změna se uchová tak, jak přijde, takže můžete reportovat stav tehdy i stav nyní, i tam, kde zdrojový systém přepisuje vlastní záznamy.
-
Každé číslo má lineage
Logika získá lineage, takže otázka “odkud se tohle číslo vzalo” má viditelnou odpověď.
-
Změny řešené v datovém skladu
Pomalu se měnící dimenze se řeší přímo v datovém skladu jako vault satelity, místo aby se jen aproximovaly.
Příběh zákazníka: Porta
Oceněno společností BARC v The Data Fabric Survey 26
Seznamte se s naším expertem
Dvacet minut s naším obchodním ředitelem a upřímná odpověď, zda se to hodí do vaší situace.
Matt Collett
Sales Director
Skvělé, vyberte si vyhovující termín:
Další problémy, které tato série řeší
-
Ukazují vaše Power BI reporty pro stejný ukazatel různá čísla?
Finance, Obchod i Provoz si každý postavili vlastní sémantický model a každý z nich je vnitřně konzistentní. Definice nebyly špatně na jednom místě. Nebyly dohodnuté nikde.
-
Je váš Power BI report v DirectQuery pomalý při každém kliknutí?
DirectQuery a Direct Lake slibují živá data. Dostanete třicetisekundový vizuál a účet za výpočetní výkon, který nikdo nechce vysvětlovat. Problém není v režimu. Je ve schématu pod ním.
-
Je váš DAX kód v Power BI už příliš složitý na údržbu?
Dvě stě řádků CALCULATE a FILTER není známka pokročilého DAX. Obvykle je to známka toho, že vám datový sklad nikdy nedal klíče, historii ani granularitu, kterou jste potřebovali.