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á.
Zní vám to povědomě?
- Hledáte na Tableau Serveru metriku a vrátí se vám čtyři publikované datové zdroje.
- Dvě oddělení uvádějí za stejný měsíc různá čísla a obě se odvolávají na Tableau.
- Nikdo neví, který .tdsx lze bezpečně smazat, takže se nesmaže žádný.
- Stejný extract je uložený několikrát a úložiště dál roste.
Každý publikovaný datový zdroj byl ve svůj den rozumným rozhodnutím. Potíž je, že každý z nich zároveň obsahuje vlastní soukromou odpověď na to, co metrika znamená.
Jak roztříštěnost vzniká
- Duplikace je rychlá cesta. Zkopírovat datový zdroj a upravit ho je hotové zítra, změna sdíleného zdroje vyžaduje dohodu.
- Logika putuje s kopií. Filtry, výjimky a vypočítaná pole jsou zapečené přímo
v
.tdsx. - Rozdíly nejsou vidět. Dva zdroje s názvem “Sales” vypadají v katalogu úplně stejně.
- Nic nejde vyřadit, protože nikdo nedokáže doložit, které workbooky závisí na kterém zdroji.
Certifikace pomáhá, ale až poté, co někdo rozhodne, jaké to číslo je. Toto rozhodnutí není funkcí Tableau.
Proč to dopadá na vás
- Máte odsouhlasit čísla, která vznikla rozhodnutími v jiných odděleních.
- Odsouhlasování je neviditelná práce, které si někdo všimne, až když se neudělá.
- Svůj zdroj certifikovat můžete. Přimět čtyři týmy k jedné definici nemůžete.
Práce se dělá na špatném místě
- Definovat metriku je práce pro datový sklad. Když se dělá zvlášť v každém
.tdsx, vznikne několik odpovědí. - 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 drží byznys pravidla v datovém skladu a generuje dimenzionální pohledy, ke kterým se připojuje každý workbook.
- Metrika se počítá jednou, a každý workbook čte stejné číslo.
- Pravidlo je vidět a má verze, místo aby bylo zamčené v publikovaném extractu.
- Lineage ukazuje odvození, takže neshodu vyřeší otevření grafu.
- Nové otázky znovu využijí model, a právě to zastaví dalších sto kopií.
- Úložiště se přestane násobit, protože jeden mart obslouží mnoho workbooků.
O co požádat
“Máme čtyři publikované zdroje, které počítají tržby odlišně, a logika je uvnitř souborů .tdsx. Může pravidlo žít v datovém skladu, aby se každý workbook připojoval k jednomu řízenému dimenzionálnímu pohledu?”
Tím se diskuse posune od toho, který datový zdroj je správný, k tomu, kam definice patří.
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.
Tři kroky k číslům, která sedí
-
Vytáhněte stávající logiku
Posbírejte výpočty, joiny a filtry, které dnes žijí ve vašich reportech.
-
Centralizujte ji na jednom místě
Logika se jednou přesune do modelu datového skladu, takže každý report čte stejnou definici.
-
Čí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.
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
Sales Director
Skvělé, vyberte si vyhovující termín:
Další problémy, které tato série řeší
-
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á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.