Jsou vaše výrazy Set Analysis v Qliku příliš dlouhé a pomalé?

Set Analysis je přesný nástroj pro skutečná srovnání. Většina dlouhých výrazů ve vaší aplikaci tam je, protože model nikdy nedodal historii, příznaky ani jednu granularitu, takže je graf skládá znovu při každém výběru.

Jsou vaše výrazy Set Analysis v Qliku příliš dlouhé a pomalé?

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ě?

  • Jeden výraz má několik řádků vnořených set modifikátorů a volání Aggr.
  • Grafy po každém výběru ukazují ikonu probíhajícího výpočtu.
  • Set Analysis používáte ke zjištění, jaká hodnota byla k určitému okamžiku.
  • Na hlavní míru si kromě jejího autora nikdo netroufne sáhnout.

Set Analysis je správný nástroj pro skutečné srovnání, například letošek proti loňsku. Zároveň se do ní ale schovává oprava, když modelu něco chybí, a právě tento druhý druh aplikaci zpomaluje.

Co dlouhé výrazy zastupují

  • Historii. Modifikátory data a Aggr rekonstruují stav, který měl záznam loni v březnu.
  • Příznaky. Podmínky If() uvnitř výrazu při každém výpočtu rozhodují, co se počítá jako aktivní nebo platné.
  • Granularitu. Aggr a Only ruší duplicitu z tabulky, která drží dvě granularity najednou.
  • Chybějící vztahy. Vnořené modifikátory jako {<Year={2024}>} v kombinaci s P() dělají to, co by udělala pořádná dimenze.

Každý z nich se vyhodnocuje pro každý graf, každý výběr a každého uživatele. Odtud ta ikona výpočtu.

Proč to dopadá na vás

  • Každý výraz byl ten týden nejrychlejší cestou ke správnému číslu.
  • Logika žije uvnitř .qvf, takže ji nikdo mimo aplikaci nemůže zrevidovat ani znovu použít.
  • Výraz zjednodušit můžete. Historii, kterou model nikdy neuchoval, přidat nemůžete.

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

  • Historie, příznaky a granularita jsou práce pro datový sklad. V Set Analysis se přepočítávají při každém výběru.
  • 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á aplikace.
  • 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 nativně v databázi, kterou už používáte, včetně SQL Server, Azure SQL, Oracle, Snowflake a Databricks.

  • Historie se uchovává jako satelity a point in time tabulky odpoví na otázku “stav k březnu” joinem.
  • Příznaky jsou sloupce, vypočtené jednou v datovém skladu, ne uvnitř každého výrazu.
  • Jedna granularita na tabulku faktů, což rovnou odstraní většinu práce s Aggr.
  • Konformní dimenze dají set modifikátorům skutečná pole, podle kterých lze vybírat.
  • Zůstanou jen skutečná srovnání, dost krátká na to, aby je kolega přečetl.

O co požádat

Ne “dashboard je pomalý”, ale:

“Naše Set Analysis při každém výběru rekonstruuje stav k určitému okamžiku a stavové příznaky. Může nám datový sklad dát point in time tabulku a příznaky jako sloupce, aby se z výrazů staly obyčejné součty?”

Tím odlišíte Set Analysis, kterou opravdu potřebujete, od Set Analysis, kterou používáte jako záplatu.

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 žijí 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ýše v řetězci

    Pomalu se měnící dimenze se řeší výše v řetězci jako vault satelity, místo aby se jen aproximovaly.

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ší

  • Ukazují vaše Qlik aplikace a Power BI reporty různá čísla?

    Chybu nemá Qlik ani Power BI. Každý má vlastní logiku načítání, vlastní definice a vlastní lineage, takže se stejná metrika počítá dvakrát a nikdo je nedokáže sladit. Pravidla patří do jednoho spravovaného modelu v datovém skladu, ze kterého čtou oba nástroje.

  • Čistíte stejná data znovu v každém načítacím skriptu v Qliku?

    Stejné mapovací loady, opravy textových řetězců a deduplikace se znovu píšou v každé aplikaci a každé vrstvě QVD a jejich kopie se rozcházejí. Čištění se opakuje v každém skriptu, protože ho žádná integrovaná vrstva datového skladu neudělá jednou.

  • Vytvářejí vaše Qlik aplikace pořád syntetické klíče?

    Syntetické klíče a cyklické reference jsou jen Qlik, který přesně asociuje to, co dostal. Vznikají, protože data přicházejí bez konformních dimenzí a skutečných klíčů, takže si je musí vymyslet každá aplikace.