Metadata management: Proč je katalog dat nutností, ne luxusem | Mňamka #551

Listopad 25, 2025

Metadata management: Proč je katalog dat nutností, ne luxusem

“Metadata jsou data o datech.“ - tohle, když od nás slyšeli profesoři na VŠE (Vysoké škole ekonomické), rovnou nás poslali ze zkoušky domů s tím, že se za nedlouho opět uvidíme. 😀Ona je to sice pravda, ale nejde ani tak úplně o jednu pevně stanovenou “definici” jako spíš o tu samotnou podstatu. Díky metadatům organizace chápe svá data, své systémy i pracovní postupy, protože metadata popisují, vysvětlují a usnadňují vyhledání, použití a správu jakéhokoliv datového zdroje.

Proč to řešit? Bez metadat je analytika jen rychlá zkratka k chaosu: 

  • různé definice ad-hoc metrik, které se jmenují stejně, 

  • spory mezi týmy, protože když řekne Sales pojem “aktivní uživatel”, je to něco jiného, než když to řekne Marketing,

  • a místo jasné data lineage nastává při otázce “Co znamená tohle číslo a odkud je?” detektivka napříč celou datovou pipelinou zakončenou x zdrojovými systémy a Google Sheety.

Když se číslo změní, neví se, zda jde o bug v transformaci, nové pravidlo, nebo špatný filtr. A právě tady nastupují metadata a katalog: s dobře vedenými metadaty máte jednotný jazyk, data lineage i governance, takže se můžete spolehnout, že „Revenue“ dnes znamená totéž, co zítra.

Jaké by mohly být první kroky, když firmě dojde, že metadata jí usnadní práci?

1) Zavést „jediný zdroj pravdy“ pro definice

Nejdříve je třeba si ujasnit, kde budou metriky oficiálně žít. Možností je několik, ale dali by se rozdělit do dvou skupin:

  • Přímo ve využívaném nástroji (GoodData, Fabric, …) – metriky jsou definované v sémantické vrstvě a použitelné napříč dashboardy i API (o tom jak, si povíme více někdy jindy 😉)

  • Mimo nástroj (katalog/glosář) – v externím katalogu/glosáři (jako je například platforma Dawiso) a nebo v různých verzovacích aplikací (Git) v kombinaci s dokumentačními portály (Confluence), kde Git drží technický obsah a Confluence slouží jako čitelná „výloha“ pro business.

Aby vůbec bylo možné něco takového vytvořit, musí platit jednoduché pravidlo: 1 metrika = 1 definice. Každý dashboard, SQL skript i notebook vede na stejný odkaz a neexistují žádné „téměř stejné“ klony bokem. Když se definice změní, starou verzi je třeba jasně označit třeba jako “deprecated” ideálně s datem konce platnosti a odkazem na náhradu – ať je zřejmé, co se právě používá a co už dožívá. 
Než se ale daná změna implementuje, je dobré si nastavit alespoň jednoduché RACI (Responsible, Accountable, Consulted, Informed) / DACI (Driver, Approver, Contributor,Informed) –> kdo změnu schvaluje, kdo ji realizuje, koho informovat a kde se zapisují dopady (stručné release notes stačí). A s tím tak trochu souvisí další bod.

2) Ujasnit role a zodpovědnosti

Dalším bodem by bylo definování rolí a odpovědností. Typicky se specifikují následující role:

  • Data Owner (typicky z businessu) je „majitel významu“: určuje, co metrika říká, kdy se má používat, jaké změny dávají smysl a hlídá konzistenci napříč doménou (Sales, Marketing, a další) 

  • Data Steward (často analytik) je „správce obsahu“: zavádí změny do pipeline, drží technickou kvalitu a zajišťuje, že je lineage čitelná od zdroje po vizualizaci. Zároveň  v případě změn udržuje popisy v katalogu. 

Proces implementace nech lehký, ale předvídatelný:
požadavek → review → schválení → implementace → krátké release notes.
Ideálně tohle celé obohatit tím, že u každé metriky mít uvedené obě role, ať je jasné, kdo rozhoduje o významu a kdo provádí změnu v systému.

3) Vybrat klíčová KPI a vytvořit jim katalogový záznam

Nikdo neříká, že ze dne na den bude mít jakákoliv firma vyšperkovaný katalog s definicemi vytesanými do kamene. Proto je dobré na začátek vybrat třeba 5-10 KPI, které padají na každé poradě (Revenue, MRR, Active Users, NPS…) a těmhle KPI udělat katalogový záznam.

Taková katalogový záznam by v základu mohl obsahovat:

  • Business definici (jednou větou),

  • Technickou definici (tabulky/sloupce/vzorec),

  • Doménu (Sales, Marketing, Logistika, ..)

  • Data Ownera a Data Stewarda,

  • Granularitu & časové okno,

  • Filtry/výjimky

  • Lineage (zdroj → transformace → sémantika → vizuál)

A cokoliv dalšího, co by firmě pomohlo se orientovat v obsahu.

4) Nastavit si „minimum governance“

V neposlední řadě - Pro začátek je dobré si definovat jasná pravidla, která všem pomohou se orientovat v té hromadě dat, tabulek a metrik, které ve firmě jsou. Mně osobně se v praxi osvědčilo zavést například jasné prefixy tabulek jako: src_ pro zdroje, stg_ pro stage, out_ pro výstupy a vw_ pro pohledy – takže už z názvu uživatel pozná roli tabulky. 

Ve vizualizačním nástroji místo tří různých „Account Name“ raději doplním dataset do názvu: Account Name (Accounts), aby bylo na první dobrou jasné, odkud sloupec pochází a nemusím pokaždé agresivně proklikávat všechny tabulky. 

Pokud není oddělené testovací a produkční prostředí, pomůže označení přímo v názvu daného objektu: dev, test, _prod. A nebo, u číselných polí držím jednotky v názvu sloupce – amount_czk, price_eur, margin_pct, duration_sec – díky čemuž se nikdo nemusí dohadovat, co je to vlastně za hodnotu. 

Hotovo, žádná velká byrokracie, ale pořádek, který ušetří spoustu času i nedorozumění.

Anička