Je váš Tableau dashboard pomalý při každé změně filtru?

Dvacet sekund "Executing Query" při každém kliknutí na filtr. Tableau nevykresluje pomalu. Čeká na databázi, která dostala otázku, na kterou nedokáže rychle odpovědět.

Je váš Tableau dashboard pomalý při každé změně filtru?

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

  • Po změně jednoho filtru svítí na obrazovce "Executing Query" dvacet sekund i déle.
  • Performance recording ukazuje, že skoro všechen čas padne na provádění dotazu a na vykreslování téměř nic.
  • S jedním čtvrtletím dat je dashboard v pořádku, se třemi roky je nepoužitelný.
  • Začali jste skrývat filtry, aby lidé nespouštěli tu pomalou cestu.

Tableau dashboard není ze své podstaty pomalý. Technologie VizQL převádí každou interakci na SQL a doba odezvy závisí výhradně na struktuře a modelování podkladových dat.

Co se po VizQL chce

  • Oproti star schema (hvězdicovému schématu): jedna tabulka faktů, pár joinů na dimenze přes skutečné surrogátní klíče. Výsledek se vrátí v milisekundách.
  • Oproti relační 3NF nebo surovým tabulkám: náročné joiny přes tucet tabulek, přepočítávané znovu pro každou značku, každý filtr a každého uživatele.
  • Není podle čeho indexovat. Provozní tabulky jsou indexované pro transakce, ne pro sloupce, podle kterých analytici seskupují.
  • Sčítá se to. Každý list na dashboardu posílá vlastní dotaz.

Proč to dopadá na vás

  • Datový zdroj, který jste dostali, je ten, který existoval, ne ten postavený pro analýzu.
  • Vlastní dotazy (Custom SQL) a data blendy byly jediným způsobem, jak to zprovoznit, ale každý odeslaný dotaz ještě více zpomalují.
  • Workbook vyladit můžete. Zdroj přemodelovat nemůžete.

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

  • Transformovat a spojovat surové tabulky pro analytické účely patří do datového skladu. VizQL to jinak musí opakovat při každé změně filtru.
  • 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ý workbook.
  • 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 fakta a dimenze nativně ve Snowflake, Databricks, BigQuery, Synapse, SQL Server, Oracle, Exasol nebo PostgreSQL, stavěné pro analytický přístup.

  • Jedna tabulka faktů a konformní dimenze: VizQL generuje kompaktní a rychlé SQL dotazy přímo z principu.
  • Skutečné surrogátní klíče, takže joiny jdou přes jeden sloupec místo párování textu přes více polí.
  • Jedna granularita na tabulku, což odstraní duplicitní řádky, které nafukují scany.
  • Živá připojení zůstanou použitelná, takže extract je volba, ne úniková cesta.
  • Filtry reagují dost rychle na to, abyste je mohli vrátit zpět na dashboard.

O co požádat

“VizQL při každém kliknutí na filtr provádí joiny nad normalizovanými tabulkami, takže doba odezvy roste s objemem dat. Můžeme pro tento dashboard připravit star schema, ke kterému se připojí místo provozních tabulek?”

Tím pojmenujete mechanismus a ukážete na vrstvu, kde se dá opravit.

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.

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é datové zdroje

    Máte na Tableau Serveru příliš mnoho verzí stejného čísla?

    Každý publikovaný soubor .tdsx byl v den svého vzniku rozumný. Dohromady jsou to stovky soukromých definic stejné metriky a žádný způsob, jak poznat, která je správná.

  • LOD výrazy

    Jsou vaše LOD výrazy v Tableau tak složité, že se jich bojíte dotknout?

    FIXED, INCLUDE a EXCLUDE jsou přesné nástroje pro skutečné otázky nad více granularitami. Většina těch ve vašem workbooku tam je, protože datový sklad nikdy nevyřešil granularitu ani neuchoval historii.

  • Selhávající refresh extractů

    Selhává vám refresh extractů v Tableau, nebo nestíhá doběhnout?

    Tableau Backgrounder skončí timeoutem, soubor .hyper stále roste a dashboard ukazuje včerejšek. Extract je velký, protože nese surové řádky, které se výše v řetězci nikdy neagregovaly.