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.

Je váš DAX kód v Power BI už příliš složitý na údržbu?

Platforma pro automatizaci datových skladů, které důvěřují datové týmy napříč obory

Petr Beles Petr Beles Co-Founder · Publikováno v Řešení problémů s BI nástroji LinkedIn

Zní vám to povědomě?

  • Jedna kalkulovaná míra (measure) přerostla sto řádků a rozumí jí jen jeden člověk.
  • Vizuály se načítají patnáct až čtyřicet pět sekund, a vždy kvůli stejným třem mírám.
  • Úprava jedné míry nenápadně rozbije čtyři vizuály na jiné stránce.
  • Píšete DAX, abyste zjistili, jaká hodnota byla loni v březnu, ne jaká je teď.

Příliš dlouhý DAX kód je jen zřídka problémem samotného DAX. Je to struktura, která chyběla výše v řetězci a skládá se znovu v době dotazu, při každém kliknutí.

Co ty dlouhé measures ve skutečnosti dělají

  • Rekonstruují historii. CALCULATE s filtry na datum zastupuje pomalu se měnící dimenzi, kterou datový sklad nikdy neuchovával.
  • Přemosťují relace many-to-many (mnoho k mnoha). Iterátory řeší vztah, pro který chybí propojovací tabulka (bridge table).
  • Nahrazují klíče. LOOKUPVALUE a spojované textové sloupce, protože chybí surrogátní klíč, přes který by šlo tabulky propojit.
  • Opravují granularitu. SUMX přes filtrovanou tabulku, protože tabulka faktů obsahuje dvě granularity najednou.

Všechny čtyři běží pro každý vizuál, každý filtr a každého uživatele. Odtud těch patnáct až čtyřicet pět sekund.

Proč to dopadá na vás

  • Nikdo si to nevybral. Každá míra byla ten týden nejkratší cestou k fungujícímu vizuálu.
  • Mimo soubor .pbix není logika vidět, takže ji nelze zrevidovat ani znovu použít.
  • Kalkulovanou míru přepsat můžete. Dimenzi, kterou potřebuje, přidat nemůžete.

Práce se dělá na špatném místě

  • Správa historie, klíčů, propojovacích tabulek a granularity patří do datového skladu. V DAX kódu se musí počítat znovu při každém kliknutí.
  • 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 klíče, historii a granularitu přímo v datovém skladu, na SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks nebo BigQuery.

  • Surrogátní klíče jsou explicitní, takže vztahy jsou skutečné a LOOKUPVALUE zmizí.
  • Point-in-Time (PIT) tabulky odpoví na otázku “jak to vypadalo v březnu” joinem, ne složitým výpočtem.
  • Propojovací tabulky (bridge tables) vyřeší relace many-to-many dřív, než data uvidí Power BI.
  • Jedna granularita na tabulku faktů, takže SUM provádí skutečný součet bez nečekaných překvapení.
  • Measures se zkrátí na SUM, AVERAGE, COUNT. Dost krátké na to, aby je kolega zrevidoval.

O co požádat

“Tato kalkulovaná míra rekonstruuje historii v době dotazu, protože dimenze není historizovaná. Můžeme v datovém skladu vytvořit Point-in-Time tabulku a surrogátní klíče, aby z ní byl obyčejný SUM?”

Tím pojmenujete, co chybí, místo abyste jen žádali rychlejší report.

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.

Rezervovat bezplatné demo

Tři kroky k číslům, která sedí

  1. Vytáhněte stávající logiku

    Posbírejte výpočty, joiny a filtry, které dnes vězí ve vašich reportech.

  2. Centralizujte ji na jednom místě

    Logika se jednou přesune do modelu datového skladu, takže každý report čte stejnou definici.

  3. Čí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

BI nové generace — jediný zdroj pravdy na Snowflake. Až 200 KPI na oddělení poskytovaných v Power BI.
Číst případovou studii
Porta customer success story

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

Matt Collett

Sales Director

Co hledáte?

Odesláním souhlasíte s našimi Zásadami ochrany osobních údajů.

Další problémy, které tato série řeší

  • Roztříštěné datasety

    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.

  • Výkon DirectQuery

    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.

  • Selhávající refresh

    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.