Selhávají vám reloady v Qliku s tím, jak data rostou?

In-memory engine je rychlý, protože všechno leží v RAM. Reloady selhávají a aplikace se zpomalují, když tuto RAM zaplní detail na úrovni řádků a transformace, které předtím neudělal žádný datový sklad.

Selhávají vám reloady v Qliku s tím, jak data rostou?

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

  • Noční reload selže s chybou nedostatku paměti, nebo prostě přetáhne své okno.
  • Aplikace narostla na několik gigabajtů a její otevření trvá znatelně dlouho.
  • Výběry, které byly loni okamžité, teď nechávají uživatele čekat.
  • Načítáte každý transakční řádek, protože neexistuje agregovaná tabulka, kterou byste mohli načíst místo něj.

Asociativní engine je rychlý, protože celý datový model žije v paměti. Právě proto aplikaci plné surového detailu nakonec dojde místo.

Proč aplikace pořád roste

  • Načítá se detail na úrovni řádků, desítky milionů řádků, protože výše v řetězci neexistuje žádný agregát.
  • Transformace běží při reloadu. Joiny, lookupy a čištění spotřebují paměť dřív, než se uloží jediný řádek.
  • Plné reloady jsou každý měsíc pomalejší. Inkrementální logika s QVD je možná, ale píše se ručně a je křehká.
  • Reloady a uživatelé sdílejí stejnou RAM. Náročný reload soupeří s lidmi, kteří aplikace používají.

Víc paměti získá čas. Křivku nezmění.

Proč to dopadá na vás

  • Detail se načetl, protože to byla jediná dostupná tabulka, ne proto, že by ho někdo potřeboval.
  • Kapacitu serveru ani limity velikosti aplikací ve vašem tenantu Qlik Cloud změnit nemůžete.
  • Pole vypustit a skript optimalizovat můžete. Agregáty výše v řetězci vytvořit nemůžete.

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

  • Joinování, agregace a inkrementální načítání jsou práce pro datový sklad. V Qliku se opakují při každém reloadu každé aplikace.
  • 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 information marty nativně v databázi, kterou firma už má, například Snowflake, Databricks, Synapse, Fabric nebo Exasol.

  • Agregované marty v granularitě, kterou aplikace potřebuje, takže do paměti se dostane mnohem méně řádků.
  • Inkrementální načítání probíhá výše v řetězci, generované, ne ručně psané ve skriptu.
  • Reload kopíruje, nepočítá. Stane se z něj obyčejný LOAD z hotových tabulek.
  • Velikost aplikace odpovídá otázce, ne velikosti zdrojového systému.
  • Detail zůstává v datovém skladu, dostupný, když se k němu někdo opravdu potřebuje proklikat.

O co požádat

Ne “reload pořád selhává”, ale:

“Naše aplikace načítá každý transakční řádek a joiny dělá během reloadu, proto jí dochází paměť. Můžeme v datovém skladu dostat agregovaný mart, načítaný inkrementálně, který bude aplikace jen číst?”

Pokud zazní, že pořádné postavení martů by zabralo čtvrtletí, právě k odstranění této námitky Datavault Builder vznikl.

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.

  • 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.