Již jsem se vyjádřil k úloze, kterou hraje jádro v tradičních řešeních datových skladů. I když tato koncepce není nejmladší, stále může nabídnout významné výhody. Dnes bych se chtěl více věnovat možnostem, které jsou k dispozici, pokud k jádru přistupujete spíše jako ke stavu mysli než jako k databázové vrstvě.

Začněme samotným účelem jádra – umožňuje transformaci dat z datových modelů zdrojových systémů do univerzálnějších struktur. Rovněž umožňuje integraci z různých datových zdrojů do stejného datového modelu, představuje jediný zdroj pravdy a efektivně předává data následným řešením. Samozřejmě, že lze do této vrstvy přidat mnoho dalších funkcí, například kontroly kvality dat, ale věřím, že si vystačíme s výše uvedenými hlavními funkcemi.

Jsem přesvědčen, že přinejmenším hlavní důvody, které stály za vznikem konceptu jádra, jsou stále platné – pokud existuje více zdrojových systémů, je třeba je integrovat a kombinovat. Uživatelé musí mít jistotu, že data zobrazená v různých sestavách pocházejí ze stejného konzistentního zdroje dat. Je však vytvoření základní vrstvy jedinou odpovědí na tuto potřebu?

Databáze jádra jistě není jediným řešením tohoto problému, i když k výše popsaným hlavním účelům slouží velmi dobře. Některé přístupy kombinují demokratizaci dat s odpovědností za danou doménu nebo oblast dat (např. data mesh). Jiné teorie navrhují spíše technický přístup, který se zaměřuje na efektivitu transformace (např. data vault) a většinu transformace související s podnikáním přesouvá do vyšších úrovní řešení datového skladu blíže k uživatelům (nebo níže, podle toho, zda vidíte sklenici poloprázdnou nebo poloplnou). V rámci sady nástrojů pro vytváření datových řešení je k dispozici více přístupů (např. Databricks, Snowflake), kde se základní vrstva přesouvá více do vrstvy metadat a jako specializovaná databáze existuje v menší míře.

Všechna zmíněná řešení mají svá pro a proti – data mesh představuje ideální řešení pro dobře fungující agilní organizaci, kde vlastníci produktů vytvářejí datové sady, přičemž na interním trhu dat převládá ta nejlepší. Na druhou stranu vyžaduje vyspělé uživatele a specifické organizační uspořádání, kde je jasně definována odpovědnost a strategie je nejen dobře pochopena, ale také správně propojena s ostatními podnikovými procesy. Technický přístup, jako je data vault, umožňuje zvýšit automatizaci, která je řízena metadaty (alespoň na úrovni raw data vault).

Stále je však třeba někde provést transformaci na úrovni business pravidel (informační mart a business data vault). Může to být jednodušší, protože základní transformace na nižších úrovních je automatizovaná a řízená metadaty. Nebo to také jednodušší být nemusí. Některé nástroje nabízejí funkce pro označování a tagování částí kódu, které z hlediska architektury patří do jádrové vrstvy. Nicméně i když v takovém případě nepotřebujete velké jádro, potřebujete funkční řešení správy metadat a efektivní procesy pro zajištění spolehlivosti těchto označení.

Jinými slovy – pokud musíte pro přeměnu surových dat na požadovaný výsledek vynaložit úsilí o velikosti 100, je naivní věřit, že jakýkoli přístup, metodika nebo nástroj sníží toto potřebné úsilí na 10. Domnívám se, že by bylo možné snížit toto úsilí o 20 %, pokud by případ užití ideálně odpovídal zvolenému přístupu (nebo nástroji či metodice). Takže i když je vaše základní vrstva čistě virtuální, stále vyžaduje určité úsilí, aby byla skutečná a funkční. Někteří zákazníci však dávají přednost „hmatatelnější podobě“ jádrové vrstvy, spíše než jako stavu mysli – a tak v mnoha řešeních základní vrstva jako transformační fáze / databázová vrstva stále existuje a používá se i ve zcela nových datových řešeních.

Nicméně jsem viděl několik datových řešení, která použila koncept „jádrová vrstva jako stav mysli“ namísto databázové úrovně, a zatím to funguje dobře. Mluvím však především o menších společnostech s omezeným počtem zdrojových systémů, s malým týmem a s velmi štíhlými procesy. Obávám se, že od určité velikosti řešení/týmů/firem se tento přístup stane neudržitelným, resp. že se dramaticky zvýší nároky na správu metadat v souvislosti s takovýmto datovým řešením. Dalším případem, kdy je takový přístup efektivní, je prototypování nebo budování řešení omezené velikosti/komplexnosti, kde je základní vrstva v daném okamžiku pouhým režijním nákladem.

I přes snahu o maximální úroveň automatizace transformace bude vždy existovat datová transformace související s business procesy, která je velmi specifická. A je jedno, jaké datové řešení máte. Tato transformace musí být provedena (nebo alespoň navržena) s minimální automatizací. Transformace dat na této úrovni s je také fází s největší přidanou hodnotou – v této fázi se data kombinují s obchodním know-how, aby uživatelům poskytla relevantní výsledky.

Ačkoli se zdá, že automatizovat transformace na úrovni podniku je příliš obtížné, neznamená to, že bychom měli rezignovat na myšlenku zvýšení automatizace, zejména s ohledem na dostupné technologie. Tento druh automatizace může (a měl by) být použit ve fázi analýzy, hlavně pak pro transformaci, která může být řízena metadaty. Mám na mysli činnosti, jako je klasifikace dat, profilování dat atd.

Jaký je závěr? Může virtuální jádro efektivně poskytovat stejnou úroveň služeb jako fyzická vrstva? Domnívám se, že ano, ale pouze za určitých podmínek. Kromě agilních podniků, které začínají od nuly, mohou z tohoto virtuálního přístupu těžit i společnosti se silnou datovou kulturou. Zkušený tým a kvalifikovaní uživatelé budou mít s větší pravděpodobností z takového řešení užitek, místo toho, aby je jeho složitost táhla ke dnu. Proto podle mého názoru budou i nadále existovat řešení s robustními základními databázemi, protože některým firmám bude trvat ještě dlouho, než si vytvoří kulturu správy dat a získají datovou gramotnost na takové úrovni, která umožní efektivní využití virtuálního jádra. Příště se blíže podíváme na to, jaký vliv má kultura správy dat na návrh datového řešení.

Autor: Tomáš Rezek