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.

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

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

  • Workbook má tucet výrazů FIXED a odstranění kteréhokoli z nich rozbije některý pohled.
  • Výpočty se výrazně zpomalí, jakmile se přidá blend s druhým datovým zdrojem.
  • LOD používáte k rekonstrukci toho, jaká hodnota byla k určitému datu.
  • Na záložku s výpočty si kromě původního autora nikdo netroufne sáhnout.

Výrazy Level of Detail jsou správnou odpovědí na skutečnou otázku nad více granularitami. Zároveň se do nich ale schovává oprava, když data přijdou ve špatné granularitě, a právě tento druhý druh dělá workbook křehkým.

Co LOD výrazy zastupují

  • Stav k určitému okamžiku. FIXED s logikou nad datem rekonstruuje historii, kterou zdroj přepsal.
  • Chybějící dimenzi. FIXED nad spojovaným klíčem, protože skutečný klíč pro join neexistuje.
  • Dvě granularity v jedné tabulce. EXCLUDE ruší duplicitu, kterou by pořádná tabulka faktů nikdy nevytvořila.
  • Vztah bez bridge tabulky. INCLUDE dělá práci bridge tabulky.

Každý z nich se vyhodnocuje v době dotazu, pro každý pohled, a blending přes více zdrojů náklady násobí.

Proč to dopadá na vás

  • Každý z nich byl ten týden nejrychlejší cestou ke správnému číslu.
  • Mimo workbook nejsou vidět, takže je nelze zrevidovat ani znovu použít.
  • Výpočet přestavět můžete. Dimenzi, kterou nahrazuje, přidat nemůžete.

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

  • Historie, klíče a granularita jsou práce pro datový sklad. V LOD výrazech se skládají znovu pro každý pohled.
  • 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 řeší granularitu, klíče a historii v datovém skladu, na Snowflake, Databricks, BigQuery, Synapse, SQL Server, Oracle, Exasol nebo PostgreSQL.

  • Point in time tabulky odpoví na otázku “stav k březnu” joinem, ne výrazem.
  • Bridge tabulky vyřeší many to many dřív, než se Tableau připojí.
  • Explicitní surrogate klíče, takže vztahy nahradí párování spojovaných textových řetězců.
  • Jedna granularita na tabulku faktů, což rovnou odstraní většinu práce s EXCLUDE.
  • Zůstanou jen skutečné LOD otázky, a ty jsou dost krátké na to, aby je kolega přečetl.

O co požádat

“Tyto LOD výrazy rekonstruují stav k určitému okamžiku a řeší granularitu v době dotazu. Může nám datový sklad dát PIT tabulku a tabulku faktů s jednou granularitou, aby se z výpočtů staly obyčejné agregace?”

Tím odlišíte LOD, které opravdu potřebujete, od LOD, které 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ší

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

    Každý publikovaný .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á.

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

    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.

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