Podcast

Dobrý den, jmenuji se Jirka Vychrек a vítám vás u dalšího dílu podcastu Datatolk. Tento díl je opět speciální. Je to totiž druhý díl, který vznikl ve spolupráci se společností Revolt BI. Jedná se o druhý díl na našem kanále, který je kompletně v angličtině. V tomto díle si Giuliano Gianetti, zakladatel a CEO Revolt BI, pozval jako hosta Sergeje Gerškoviče, kterého možná znáte jako autora knihy Data Modeling with Snowflake.

V této epizodě se Gigi se Sergejem baví právě o datech, o modelování dat, o Snowflake, ale i například o SAPu či o přechodu Sergeje z pozice datového architekta na datového konzultanta a uznávaného světového autora. Přeji vám krásný poslech.

Use case je specifický pro určitý druh průmyslu. Přestože to trénujeme roky, každý člověk, kterého jsem potkal, postrádá nějakou konkrétní část znalostí. Odkazovat se pouze na tradiční teorii nestačí. Jak jste zmínil, teorie vám neřekne, jak to udělat, pouze vám sdělí, mezi jakými koncepty si můžete vybrat, ale ne skutečnou volbu, kterou byste měli učinit.

To mě na vaší knize velmi zaujalo, protože byla opravdu napsána konkrétně: co byste měli dělat, když nastane určitá situace.

Největší problém, na který jsem ve technických materiálech narazil, je, že jsou buď příliš akademické – autor vám dává teorii bez praktické implementace – nebo jsou to spíše kuchařky typu „tady je, jak napsat agregaci, tady je, jak napsat okno“. Nicméně chybí tam informace, že oknová funkce je náročná na paměť. Je tu velká propast mezi teorií a technikou.

Uvědomil jsem si, že je potřeba tyto dvě věci spojit. Dokonce je téměř nemožné je od sebe oddělit. Proto je ta kniha napsána tak, že se některé věci opakují, ale jsou postupně stále více technické. Než totiž můžete přejít k detailům typu načítání typu 2 dimenze, musíte pochopit, co je to typ 2, jaké jsou ostatní typy, co je dimenze vůbec.

Je toho hodně, co byste museli zvládnout, pokud byste chtěli věnovat celou kapitolu pouze typu 2 dimenzím, aniž byste pochopili, proč to vlastně děláte.

Když jsem poprvé říkal, že chci napsat knihu o modelování se Snowflake, všichni mi říkali, že jsem blázen. Proč Snowflake? Modelování je nezávislé na technologii, omezujete si čtenářskou obec. Mají pravdu, že tvoření modelu je v základech technologicky nezávislé.

Ale jakmile přejdete přes základy, tak ano, můžu vysvětlit, co je typ 2 dimenze – dimenze s dvěma dodatečnými sloupci: valid from, valid to – a teď si ji vytvořte a implementujte.

A jak na to dotazovat data? Když do toho jdete, opravdu vás to nutí vzít v úvahu technické detaily. Přece, pokud má kniha ve svém názvu slovo Snowflake, tak publikum Databricks nebo Google BigQuery si ji nejspíš nevezme.

Ale poprvé šlo o to, že jsem chtěl využít vlastní odbornosti se Snowflake. Hlavně ale kniha dává určitou formuli, technický cíl: jakmile se dostanete za teorii, musíte to nějak implementovat.

Ať už pracujete s Databricks nebo BigQuery, výsledný koncept nebude příliš odlišný než ten, který popisuji. Jistě, můžete použít různé technické akcelerátory a architektonické principy, ale…

Ve skutečnosti s tím nesouhlasím, protože jsem knihu začal číst právě proto, že mi ji doporučil člověk pracující s BigQuery. Zajímavé bylo také sledovat, jaké funkce technologie používáte.

Já sám nepoužívám všechny funkce Snowflake, a vaše využití úloh (tasks) a dalších věcí, i konkrétní implementace pipeline, pro mě bylo velmi zajímavé, protože to byl trochu jiný přístup k architektuře, než jsem byl zvyklý.

Proto nejsem přesvědčený, že právě toto bylo špatné rozhodnutí.

Kolik se mimochodem knih prodalo?

Dobrá otázka. Přiznám se, že nemám přesné číslo, ale je to blízko kolem tisíce výtisků, přes tisíc něco, což nevím, jestli je hodně, nebo málo. Je to moje první kniha a je na trhu teprve pár měsíců, tak uvidíme, jak to půjde dál.

Zmínili jste, že jste zvolil Snowflake, ale původně jste pracoval se SAPem, že?

Ano, kariéru jsem začínal v SAPu. Nejprve na straně HR IT, tedy HR technologie. Pracoval jsem buď s middlewarem, prostým SQL nebo front-endovými reportovacími nástroji. SAP je známý tím, že má mnoho modulů, ale právě HR je jeden z nich. ECC a cokoli používáte, všechno končí v datovém skladu, což je SAP BW.

Za mých časů to byla verze BW 3.5, 7.4, 7.5 a tak dále, SAP HANA přišla později. Ve světě SAPu jste omezeni na jejich ekosystém – cokoli ETL, dashboarding, musí být SAP. Takže se vlastně stáváte takovým „všestranným“ specialistou, i když jste z týmu pro datový sklad.

Děláte business objects reporting, VEX reporting nebo načítáte data jejich ETL nástrojem.

Jak jsem se tedy dostal do světa Snowflake? To souvisí i s tím, jak vznikla moje kniha. Když pracujete se SAP, stáváte se obecným specialistou. Jsou samozřejmě i specialisté na jednotlivá řešení, ale většina lidí umí trochu všeho.

Nejdůležitější dovedností v SAPu je troubleshooting – řešení problémů. Není to o návrhu nebo architektuře, ale když něco nefunguje, být schopen najít chybu, vědět, do které transakce zajít, zakliknout detailní volbu, najít chybu v logu a poté ji opravit jinou transakcí a vypnout.

To ale není cesta, jak dodávat hodnotu uživatelům. Je to jen práce s chybami, která vám brání skutečně dodávat, co jste slíbili.

Často jsem přemýšlel, jestli je SAP tak úspěšný proto, že je složitý, nebo je složitý proto, že je tak úspěšný a táhne s sebou armádu konzultantů, kteří z toho žijí.

Naimplementovaný SAP si málokdo dovolí měnit nástrojem jiného výrobce, protože riskujete vysoké pokuty a sankce, což znamená, že jste do systému „zacejchnutí“. A to nejen kvůli zaplacení licence, ale i kvůli právním komplikacím při připojování dalších nástrojů.

Vždycky říkám, že podle způsobu, jak probíhá „discovery session“ s firmou, poznáte, kdo ji řídí. U technologické firmy je to o tom, jak něco hacknout, aby to fungovalo. U prodejem řízené firmy jde o to, co dalšího koupit pro fungování. U právně řízené firmy je to o tom, co všechno nesmíte dělat, abyste nedostali pokutu.

Takto jsem vždy vnímal SAP, i když nedávno se docela otevřeli. Mají novou politiku, která vám umožňuje legálně kopírovat data; myslím, že se to jmenuje „indirect approach“. Díky ní můžete vytvořit prakticky kopie dat a používat je volně bez porušení licence. Možná.

Když jsem řekl, že se nepodívám zpět, myslel jsem to vážně.

Zjistil jsem, že takový přístup k datům škodí byznysové hodnotě. Co se dál stalo?

Pracoval jsem na straně klienta, který působil v hotelovém B2B segmentu a najednou koupil dva konkurenty najednou. Museli jsme konsolidovat a integrovat data ze tří systémů.

Naše BI oddělení tak mělo za úkol vybrat, s čím budeme pracovat – SAP BW HANA, zděděný SQL Server a také Snowflake.

SQL Server bylo jednoduché – das to prostě načíst, ETL a začít modelovat. S Snowflakem jsme měli podobný přístup – SQL v cloudu, modelování připravené.

Začali jsme stavět model na SAP BW, protože jsme měli experty na SAP. Načítali jsme data z ostatních systémů s cílem je před ETL „vyčistit“.

Celý ETL proces v SAPu trval téměř měsíc. Naplánovali jsme úlohy tak, aby běžely nepřetržitě.

Když jsme zjistili chybu v datech, bylo nutné znovu celý proces restartovat.

Přišli jsme na to, že můžeme některé chyby opravit už v Snowflake před ETL – trvalo to minimum času. Pak jsme zkusili vyřešit i další kroky transformace dat v Snowflake – také téměř okamžitě.

A najednou: měsíc práce v SAPu šlo provést za 2,5 hodiny v Snowflake.

Proč? SAP BW je trochu „černá skříňka“. Když pracujete přímo s HANA databází, může být situace trochu jiná, ale ztrácíte služební vrstvu SAP.

V BW nevidíte hvězdicové schéma, ale pracujete s abstraktními koncepty jako info objekty, ODS. Systém za vás řídí surrogate keys, texty a další.

To vše však přináší režii.

Pokud tedy jen chcete načíst primární data bez vytváření surrogate keys nebo integrit, nemáte jinou možnost než jet „tradičním způsobem“.

Musíte si sami rozhodnout, kde budete provádět čištění dat a referenční integritu. Není dobré dělat vše všude.

Pocházím z firmy Kabula, která začala používat Snowflake v roce 2015 krátce po veřejném uvedení produktu.

Vzpomínám si, že jsem se s nimi pustil do práce, protože nás unavovalo škálování databází Redshift a myšlení nad obrovskými MySQL servery, kde byly všechny data vícero klientů v jedné databázi – noční můra, pomalý systém.

Všechny problémy zmizely a už se tam nikdy nevracím.

Přesto podle mě byznys stále podceňuje náklady technických omezení a ztracené příležitosti, když nevyužívá takové technologie.

Protože ve firemních termínech, jak jste zmínil, měsíční ETL běží zdarma. Ve skutečnosti ne, protože byznys nemá svá data k dispozici, tým platí za činnost, která nemá přímou hodnotu – údržba a refaktoring infrastrukturní vrstvy jsou neviditelné a těžko měřitelné.

Proto často působí dilema jako jednoduchá volba mezi několika dolary za hodinu nebo jedinou investicí do capex a podobně.

Tak jsem se tedy dostal do světa Snowflake. Ale co skutečně změnilo mou kariéru, bylo když jsme rok používali Snowflake a já získal lepší přehled o tom, co to je.

Ve stejnou dobu, okolo roku 2017–2018, Snowflake začínal opravdu růst. Migrace od SAPu byla pomalá a stovky firem stále zůstávaly u SAP.

Po téměř patnácti letech v SAP jsem konečně cítil, že mám co říct.

Věděl jsem, že lidé o SAPu budou chtít slyšet názor někoho, kdo zná každodenní problémy – proč něco nefunguje, jaké chyby se objevují, do jaké transakce jít, aby se to vyřešilo.

Věděl jsem, že vylepšování ticketů a řešení problémů se stává byrokratickým procesem, kdy vás nejprve ignorují, pak obviňují z nepoužívání posledních patchů, a až když se vše ukáže jako chyba systému, možná se na to někdo podívá.

Rozhodl jsem se napsat článek, který nebude SAP kritizovat, ale popíše situaci objektivně – jak jsme přecházeli z SAP na Snowflake, proč jsme tak rozhodli a co to přineslo.

Článek publikovaný pod názvem „Migrace ze SAP na Snowflake – jak a proč“ se stal mým nejčtenějším článkem, protože lidem ukázal, že existuje alternativa. Ať už se pro ni rozhodnou, nebo ne, je dobré znát výhody i nevýhody obou přístupů.

Věděl jsem, že tento článek nebude přijat s otevřenou náručí a bude kriticky zkoumán, proto jsem se snažil být co nejvíce objektivní a opřít vše o fakta.

To mě uvedlo do povědomí jako autora a začátečníka ve světě profesionálního psaní.

První naplno autorský článek, ale zároveň i ukázka mého přístupu a práce.

Následně mě oslovila společnost SQLDBM, která hledala technického spisovatele. Najít spisovatele, který chce skutečně psát a zároveň má technické zázemí, není jednoduché.

Našli jsme se ve správnou dobu na našem profesním i osobním životním směru.

Chtěl jsem pak možná mírně změnit svou kariéru a…

Něco, ne nutně evangelizace, ale právě proto jsem vymyslel svou roli produktového leadra pro úspěch produktu, protože to není produktový evangelista, není to produktový manažer, ale je to přesto role obracející se k zákazníkovi, která má mnohem více interakcí s produktovým týmem. Je to něco, co komunikuje a evangelizuje datové modelování obecně, ale také pomáhá vyvíjet nástroj, který činí datové modelování agilním a efektivním. Co se mi zdá zajímavé, je například to, co říkal Bill Inman, že jeho kariéra začala vlastně tím, že navzdory něčemu, co se v té firmě dělalo, napsal knihu nebo článek, který ho učinil veřejně známým. Takže se v podstatě vymanil z rámce situace, ve které byl.

Zmínil jste to i u sebe. Já jsem do své firmy nějakým způsobem vstoupil napsáním článku, který měl několik tisíc přečtení před několika lety. Myslím, že je to opravdu zásadní téma, protože je těžké začít dělat něco jiného, když jste v pozici, kde vám platí a dávají vám příkazy nebo úkoly, a vy si myslíte, že byste měli něco dělat jinak, že víte, jak by to mělo být, ale nemáte hlas, který by byl vyslyšen. A myslím, že toto je poměrně běžné zejména ve službách a v týmech business intelligence (BI).

Vy jste pak musel firmu i opustit, tedy byl jste do jisté míry nucen odejít a začít zcela novou kariéru jinde. Myslím, že jste pravil velmi zajímavou věc, že psaní odstartovalo kariéry mnoha z nás. Mnoho lidí vnímá psaní jen jako sdílení informací, jako kázání na široké publikum. Ale ve skutečnosti, co vlastně děláte, je, že svá sdělení dáváte do arény veřejné debaty. Je spousta špatných knih a špatných článků. To, že něco napíšete, automaticky nezaručuje, že lidé to vezmou a budou sdílet a chválit. Vaše myšlenky musí samy o sobě obstát.

A protože jsou veřejně dostupné – článek je na internetu, nemůžete ho jednoduše stáhnout – lidé si ho přečtou, vidí ho, tweetují o něm. Psát knihu je ještě odvážnější čin, protože vlastně říkáte: „Toto jsou moje myšlenky, klidně je můžete zaútočit, já je budu bránit proti kritice a přijmu, kde jsou slabiny, a budu je rozvíjet.“ Co se týče dalšího směřování, nenapsal jsem ten článek jako sebevraždu kariéry v současné společnosti, protože, jak jsem již říkal, v tom článku jsem nedělal žádné úsudky, nešel jsem proti svému vedení ani proti politice firmy. Dokonce jsem to předem konzultoval a řekli mi: „Vyndej naše jméno a napiš, co chceš.“ Takže to nijak neohrozilo mou pozici.

Co to skutečně udělalo, bylo svěřilo mi hlas. Když vám někdo dává jednoduché úkoly, nemáte kam si stěžovat. Jakmile vstoupíte do prostoru debaty a diskuse, rostete jako člověk, jako profesionál, jako myslitel. To byla výzva, když jsem se rozhodoval odejít z čistě technické role datového architekta, kterou jsem měl v době psaní toho článku. Bylo zde mnoho rizik, protože jsem se trochu odklonil od čistě praktického přístupu a šel do neznáma mimo svou komfortní zónu.

Takže napsáním článku jste se stal osobou s názorem, a to změnilo vaši kariéru, že? Řekl bych, že jsem se stal osobou s hlasem. Vlastně vyjadřuji velmi málo názorů, pokud jste si všimli. V knize a obecných článcích se velmi málo zapojuji do debat na LinkedIn typu „dělej to tak“ nebo „dělej to jinak“; Inman versus Kimball versus Data Vault, CIO, CDO, CTO, kdo co dělá. Je tam spousta šumu. Když si člověk poslechne ty názory, většinou je to strawman, tedy karikatura protistrany, kterou používají, aby ji zesměšnili a podpořili svůj argument. Ale promyslete si to – kdyby to bylo pravda, všichni by to dělali správně podle vás, že? Samozřejmě, že ne.

Každý z nás má svůj oblíbený přístup k budování datového stacku. Samozřejmě mám svůj názor na to, zda je lepší používat Snowflake nebo SAP, ale co mě nejvíce zajímá, je porozumění základům vycházejícím z prvních principů, vysvětlování a pochopení nástrojů, toolkitů a metodologií. Jasně, není jen jedna správná cesta. Nechávám situaci rozhodnout o přístupu.

Jaké jsou tedy první otázky, které kladete, abyste určil, jaký přístup použít? Protože pokud chápu správně, radíte firmám, jak stavět datové modely pro jejich datová sklady. Jak to děláte? Nedělám tak moc poradenství, spíš odpovídám na otázky a vyvracím nesprávná přesvědčení, která mohou mít. Nedělám konzultace jako takové. Hlavní sílu své energie věnuji porozumění bolestivých bodů zákazníků v datovém modelování a budování nástroje, který jim usnadní práci s jakoukoli metodologií či přístupem, kterého se nakonec drží.

Když ale tyto rozhovory vedu, vždy začínám ne technicky, ale otázkami: „S čím máte potíže? Kde je problém? Je to kvalita dat? Jsou požadavky? Jste příliš pomalí? Existuje ztráta důvěry mezi datovými týmy? Je to příčinné izolování (siloing)?“

Ve vzorku, se kterým pracuji, jsou to lidé, kteří buď přecházejí z legacy nástrojů pro datové modelování, které byly všechny desktopové a velmi obtížně sdílené a aktualizovatelné, nebo firmy, které formální praxi datového modelování vůbec nemají. Jak se říká, i když neděláte datové modelování, stále máte datový model, jen je špatný.

Pokud si vzpomenete na mou knihu, začíná přístupem zaměřeným na byznys. Zavádí datové modelování jako zjednodušení a pak rovnou vysvětluje, že datový model je abstrakcí byznysových procesů, jimiž firma operuje. Není to ani datově orientovaná abstrakce, ale realitou orientovaná. Mluví o tom, jakou část reality data zachycují a zda ji zachycují správně.

A abychom to věděli, nejsou to technické otázky, které lze kvalitativně analyzovat. Jediný způsob, jak to zjistit, je dát model před odborníky, doménové experty, byznysové experty a zeptat se jich: „Co jsem tu vytvořil, pokud to zjednoduším na koncepty, dává to smysl ve vašem každodenním pracovním životě, když jste v terénu, děláte smlouvy, prodáváte, podepisujete zákazníky?“ Líbí se jim to takhle? Má generovaná data ty správné vlastnosti? Které z nich jsou nejdůležitější? Zachycujeme všechno důležité, co potřebujete pro svou práci?

To spustí skvělou debatu: „Teď, když chápeme koncepty, můžeme pokračovat dál.“

Co mě na tom baví je, že říkáte: „Pokud chcete vědět, jaký typ datového modelu stavět, musíte se zeptat byznysu.“ A přitom jste napsal knihu, která pomáhá technikům najít odpovědi na tyto otázky. Protože se zdá, že je opravdu těžké pro nás technické lidi najít správné otázky, nebo správný jazyk, jak se s byznysem domluvit.

Do jisté míry ano. Je známo a trochu i humorné, že lidé od dat nejsou výborní komunikátoři obecně. Pokud tahle kniha slouží jako „povolení“ na domlouvání schůzek s byznysovými týmy, jsem s tím rád. Už úplně na začátku knihy se snažím zdůraznit, že když lidé myslí datový model, mnozí technici jdou hned na ERD diagram, nejčastěji fyzický model. Ale to je jen špička ledovce. Fyzický datový model reprezentuje, co je v databázi.

Opravdový model jako celek zahrnuje celou řadu konvencí, ať už vizuálních nebo verbálních, které shrnují spoustu informací do něčeho velmi jednoduchého. Když řeknu „primární klíč“, jsou to opravdu dvě slova, která i netechnickému člověku sdělí hodně – že jde o unikátní identifikátor řádku, neboli co dělá data unikátními. Když jste technik, hned máte otázky, jak to validovat, na co se připojit, ale my jsme jen jedním slovem už hodně řekli.

Pokud se podíváte na celý soubor vizuálních a technických významů, zjistíte, že jich není mnoho a nejsou složité. Není třeba školit datový tým ani byznysový tým vysoko technicky, pokud udržujete věci jednoduché, všichni vás pochopí, když přinesete diagram se dvěma boxy a čarou – to je dvě entity spojené vztahem. Nemusíte přejít do složitých technických detailů z databáze. Na takové úrovni je komunikace mezi technickými a netechnickými lidmi velmi jednoduchá.

Myslím, že to je most. Na jedné straně připomeňte lidem, aby nepřicházeli s odborným žargonem a neočekávali, že jimi někdo bude ohromen, protože tím spíš ztratí pozornost.

A na straně byznysu jste nyní schopni komunikovat požadavky tak, že je technik pochopí a dokáže vám je zopakovat, což dříve moc nefungovalo. Technici vás během toho většinou považovali za „blázny“, což není úplně pravda, ale trochu s despektem nebo prostě jako za netechnické.

Nakonec co děláte, když se snažíte popsat datový model? Byl jsem překvapen, jak detailně jste v knize popsal různé datové modely, tedy různé diagramy používané k jejich znázornění. V mé praxi byznys lidem nic neříkají pojmy fyzický model, konceptuální model a podobně. Přitom je to pro nás zásadní, abychom jim vysvětlili, že nemohou očekávat určité analýzy, pokud data nejsou k dispozici. Například pokud neexistuje vazba mezi produkty a fakturami, těžko prodáte, jak se produkty prodávají.

Byznys to musí pochopit, což může být těžké. Často je to jako manželská debata na začátku projektu, kdy se sejdou technici a byznysáci na jednom místě a prostě nejsou schopni se shodnout, protože mají odlišné zkušenosti s tím, co vidí. A často je ten moment prozření – aha, o co opravdu jde – to hlavní na celém projektu.

Ano, myslím, že lidé obecně velmi dobře komunikují a chápou vizuálně. Existuje limit, kolik slov přijmete, dokud neřeknete: „Počkejte, nakreslete mi obrázek, abych to pochopil.“ Naštěstí modelování má vizuální stránku – hovoříme o konceptuální vrstvě a logických modelech před fyzickým modelem. A pokud se modeluje správně, tedy zdola nahoru, začínáte od velmi jednoduchých prvků než jdeme k pokročilým věcem. Než začnete mluvit o indexech a klastrech, musíte vědět, co věc představuje, jaké má atributy. Technicky nemusíte být odborník, abyste to sdíleli s doménovým expertem a ověřili to před samotným vývojem.

Pokud jdete opačně, což je často realita – mnoho lidí má buď špatný model nebo žádný, a něco má postaveno nejvýš na fyzické databázi – trvá zhruba 30 sekund, než to zpětně zpracujete a vytvoříte relační diagram. Můžete jít z DDL kódu na obrázek rychle. Ale říká to něco víc? Potvrzuje, že to je správná verze reality?

Ve filozofii je pojem „je“ versus „měl by být“. Toto je „je“. Je to technická reprodukce toho, co už máte v databázi. Je to jako když máte přítele, který si právě pořídil pas, koupil letenku do Velké Británie, šel do nějakého baru, kde probíhala oslava vína, a pak vám řekne: „Lidé v UK pijí jen víno, neviděl jsem pivo ani ležák.“ Není úplně vedle, ale je daleko od pravdy – to je jeho realita, to, co viděl, ale ne odraz celé země.

Vysvětluji to na meteorologických datech, protože data jsou konvencí mezi těmi, co je čtou, a těmi, co je zaznamenávají. Používáme termín „záznam“, protože je to záznam dat. Když nemáte správnou metodiku pro meteorologická data – pokud měříte průměrnou teplotu jednou v noci, jednou přes den, výsledky budou zkreslené. Nebo když měříte jednou v letadle a jednou na hoře – to nelze srovnávat. Záznam musí být konzistentní. A aby byla konzistence zajištěna, musí v organizaci existovat akceptovaný proces, který to zajišťuje.

Toto často chybí a ztrácí se v technických diskuzích, protože to nelze jednoduše popsat. Vaše kniha a obecně všechny pokusy o zobecnění jsou složité, protože každý byznys je jiný a není možné napsat knihu o konkrétním byznysu.

Přesně tak. Dokonce i příklady v knize jsou – jak jste řekl – jen nějaké úkoly, datové proudy, a spousta z nich je tam jen proto, aby neodváděly pozornost od hlavního poselství. I když je příkladem například faktová tabulka, ukážu i jiné způsoby jejího načtení, na které jste možná nikdy nepomysleli. To však není střed knihy, spíše jen ukázka možných variant.

A ještě jedna věc, o které jste možná přemýšleli. Co se týče návratu k základním pojmům konceptuálních a logických modelů, není to zbytečná práce. Není to jen další požadavek, na který nemáme čas. Pokud jsou provedeny správně, ušetří vám čas. Je však velmi obtížné objektivně říci, co je rychlejší – jestli jednoduše začít stavět, nebo nejprve přemýšlet a pak stavět. Samozřejmě první varianta bude na papíře pravděpodobně mnohem výkonnější. Možná je na vině agilní přístup, nevím.

V debatě rychlost versus formalita je na straně rychlosti první varianta. Rád používám analogie a ta, která mi v této souvislosti přijde na mysl, je příprava na pěší výlet, kdy říkáte: „Nemám čas si obout boty, prostě půjdu.“ A jakmile vyrazíte, nemůžete jít příliš rychle, protože začnou puchýře, a nikdy se nezastavíte a nepřemýšlíte nad tím, že jste si možná měli obout boty. Místo toho přemýšlíte, jak puchýře ošetřit – jestli existuje náplast, obvaz. Modelování je spíše plán, který roste s procesem architektury. Stává se mapou a dokumentem pro orientaci v tom, co jste vytvořili – ale pouze pokud se provede správně.

Když se vrátím k tématu rozdílu mezi tím, jak věci jsou, a jak by měly být. Pokud zpětně analyzujete fyzický diagram, je velmi obtížné tvrdit, že to, co máte, by nemělo být tak, jak je. Protože když o tom mluvíte na papíře, říkáte: „Tohle je tabulka zákazníků, tohle jsou prodeje.“ Ale neodráží se tím nuance, jaké atributy by měly být nebo nebyly reprezentovány, neukazuje se nuance kardinálnosti a vztahů mnoho ku mnoha či jedno ku mnoha. Tyto věci v konceptuálním a logickém modelu jsou zachyceny, ale ve fyzickém modelu často chybí. Pokud pracujete odspodu nahoru, již jste s byznysem komunikovali a potvrdili tyto záležitosti. Pokud jdete shora dolů, nejste hotovi, dokud opravdu nepokryjete všechny tyto aspekty a nezajistíte, že to, co bylo postaveno, odpovídá tomu, jak by mělo být postaveno.

Právě zde vzniká většina problémů – jakmile je něco špatně, je to velmi obtížné napravit. I kdyby šlo o jediný rozměr z deseti, který není správný, postupně se to ve výsledku negativně promítne i do dalších dimenzí. Jakmile začnete dotazovat data a tvořit sestavy, budete vytvářet různé záplaty, abyste opravili to, co mělo být správné, protože budete dostávat data, která neodpovídají očekávaným hodnotám a kardinálnostem. Budete se snažit někam vtlačit něco nevyhovujícího, jako kdybyste tlačili čtvercový kolík do kulaté díry.

V tomto okamžiku jste jako žába ve vroucí vodě – museli jste to udělat jednou, tak jste to udělali, a musíte to dělat znovu. To je vaše realita, až si říkáte, že to děláte takhle už vždycky. Myslím, že jde o klasickou chybu začátečníků – snažit se opravovat data pro byznys místo opravy samotného procesu. Opět je to proto, že je obvykle snadnější pro technického člověka vytvořit dodatečný dotaz a opravit špatná data, než jít za byznysem a říci jim, že by měli změnit proces v primárním systému. Ale nakonec to vede přesně do problémů, o kterých mluvíte.

Přemýšlel jsem, co s technologií? Zmínil jste, jak by měly být tyto modely vytvářeny. Vidím, že se objevuje spousta „černých skříněk“, protože snažíme se být efektivní – chceme automatizovat data, automatizovat modelování, reporting a tak dále. Někdy mám pocit, že při tomto přístupu hodně chápání mizí, protože kdybyste přistoupili dnes k Snowflake, možná ani nevíte, co je index, možná ani nevíte, co je partition, protože to nepotřebujete. Myslíte si, že to bude mít na dlouhou dobu vliv na naši praxi?

Ano, určitě to bude mít vliv. Přiznám se, že to asi plyne z mého pozadí, ale existují objekty, se kterými pracujete, které jsou paralelou stávajících metodik modelování – jako surrogate keys (náhradní klíče) nebo star schema. Ale nikdy vás to neučí, jen vám řeknou, že tady je objekt, takhle se chová a funguje. Jste tedy vyučováni druhotné implementaci základního principu.

Strávil jsem polovinu své kariéry tím, že jsem o modelování dat vůbec nepřemýšlel, nebo jsem o něm přemýšlel pouze z určitého odstupu – jak se objekt chová v konkrétním systému za určitých podmínek – nikoli o samotných základech. Nebylo by prospěšné přemýšlet o tom jinak. Například, jak jste uvedl, ve Snowflake nejsou indexy, takže vám tato znalost denně moc nepomůže, pokud pracujete jen se Snowflake.

V neintuitivním smyslu ale ano, protože chápete, že vše má své výhody a nevýhody. Indexy například urychlují dotazy při hledání „jehly v kupce sena“, ale zpomalují načítání dat, protože je nutné index aktualizovat při každé operaci. Proto jsou základní principy důležité – vysvětlují vám nástroje, se kterými pracujete, a i ty, které ne, ovlivní výkon a omezení technologie, kterou používáte. Ale hlavně vám ukáží, co nevíte.

Pokud například celý den jen čtete technickou dokumentaci BW (Business Warehouse), stáváte se v ní chytřejšími, ale stále se neučíte základy. Zaměřujete se spíše na nové funkce nebo aktualizace, což vám sice pomůže v každodenní práci, ale neporozumíte tomu, jak by něco mohlo vypadat obecněji. Technologické prostředí se rychle mění a můžete zjistit, že „jedete na mrtvém koni“, jako mnoho lidí, kteří pracovali s některou databází z devadesátých nebo počátku 2000. let.

Možná je to dobrá příležitost, jak to shrnout, protože vaše kniha je opravdu hodně o základech, ale posluchači tohoto podcastu pravděpodobně neznají její obsah. Co byste tedy poradil člověku, který začíná v této oblasti, aby si před spuštěním implementace něco nastudoval?

Samozřejmě bude můj názor trochu subjektivní a nejen proto, že jsem autor knihy, ale jak jsem řekl, byla to kniha, kterou jsem si sám přál mít. Psali jsme ji tak, aby byla co nejsrozumitelnějším a nejúspornějším shrnutím základů pro někoho, kdo začíná s daty obecně nebo na platformě Snowflake – s jasným zaměřením na to, jak efektivně navrhovat nejčastější situace, ale také jak jít o krok dál a přizpůsobit je konkrétním případům pochopením prvotních principů.

Abych to však nezaměřil jen na sebe: nedávejte si iluze, že se naučíte věci nasáváním z okolí nebo praxe. Ať už začínáte na jakékoli databázi, neznamená to, že chápete přesně, proč jsou věci postavené tak, jak jsou. Možná jste byli vystaveni něčemu méně optimálnímu, a to pak formovalo vaše názory.

Vraťte se proto ke zdrojům, ať už jde o platformu, databázi či databáze, se kterými denně pracujete. Určitě se vraťte k základům datového oboru. Čtěte Hinmana, Kimbella a další – ty, kteří tyto koncepty vytvořili, o kterých se dnes diskutuje. Pochopte kontext, ve kterém je navrhli, ještě než se pustíte do debaty, na které straně se postavit.

Porozumějte základům řemesla i technologií, protože to ovlivní, jaké volby můžete udělat a jaké ne. Rozdíl je pak markantní – poznáte člověka, který se jen nechal unášet praxí, oproti tomu, kdo si kdykoliv ve své kariéře sáhl na zásadní texty a seznámil se s tím, co vše je možné využít. Protože propast v tom, co můžete zákaznik fyzicky a výkonově využít, je obrovská oproti všeobecnému seznamu nástrojů, které máte k dispozici.

Pro mě je zajímavé, jak lidé tráví osm hodin denně prací a učí se od lidí, kteří se učili od dalších lidí a tak dále, místo aby sáhli přímo k původním knihám od vynálezců – těm nejlepším zdrojům, které nám dokáží vysvětlit podstatu.

Sergei, bylo nám opravdu potěšením vás mít u nás v podcastu. Děkuji, že jste přijel, a doufám, že se brzy uvidíme.

Děkuji, bylo to naprosté potěšení a děkuji za pozvání. Bylo to skvělé.

A to je vše. Děkujeme, že jste doposlouchali až sem. Díky také našim partnerům – BigHubu, Intexu, Sasce, Bystreetu, Colors of Data, Revolt BI, Good Data, Kebule, eMarku, Karl Data Company a Datamindu.

Pokud vás zajímá víc, navštivte naše stránky datatalk.cz a přihlaste se k odběru našeho newsletteru.