Podcast

Dobrý den, moje jméno je Jirka Vicherek a vítám vás u dalšího dílu podcastu Datatalk. Mým dnešním hostem je Honza Přívracký, který v SASce působí jako DVH team leader. Ahoj, Honzo.
Ahoj.

Dneska s Honzou pustíme do infrastruktury datové SASky. Podíváme se, co běží úplně dole. Už jsme v Datatalku měli hosty ze SASky několikrát, dívali jsme se na různé věci – jak to funguje v celku, na data governance, na BI, spolupráci analytiků s Data Science. Dneska se s Honzou podíváme pod kapotu toho všeho, do samotné infrastruktury, do toho, jak vypadají databáze, jak vypadají jejich data warehousy a další věci.

Než se pustíme do vašeho stacku a infrastruktury, co tě přivedlo do SASky? Jaká byla tvoje cesta, Honzo?

Moje cesta začala na škole v Praze, ČVUT, FIT, obor Software Engineering. Následně jsem se už při škole posunul do Staropramenu a pak jsem se přesunul do SASky. Ze školy si asi nejvíc pamatuju Michala Valentu, který měl úplně poprvé předmět na databáze. Já už to pro něj vlastně byl trochu opáčko, protože jsem už tehdy nějak věděl, jak databáze fungují, ale on měl na mě velký vliv – třeba měl i předmět pokročilé databáze a grafové databáze a tak dále. Já jsem zůstal u SQL a relačních databází.

Dokonce jsem se na škole potkal už tehdy s lidmi ze SASky, kteří měli cvičení na Data Warehouse, takže to byla poměrně zajímavá zkušenost. Ani jsem nevěděl, že se tam pak za pár let dostanu. Hlavní zaměření na škole bylo software engineering, tedy programování a další věci, ale já jsem zůstal u databází.

Ještě při škole jsem začal pracovat ve Staropramenu, při magisterském studiu. Věnoval jsem se tam databázím, konkrétně datovému skladu, MS SQL On-Prem. Vyzkoušel jsem si nejen SQL, ale vlastně celý proces – od integrace zdrojových dat až po tvorbu reportů, tedy od každé části trochu, což bylo velmi zajímavé a rozvíjející. Ve Staropramenu jsem pracoval od roku 2019 a strávil tam asi čtyři a půl roku. Pak jsem se začátkem minulého roku, tedy 1. ledna 2024, přesunul do SASky.

Co tě přitáhlo do SASky? Po čtyřech letech měnit zaměstnání… Ty jsi asi spíš loajálnější typ, ale co tě tedy přilákalo?

Kdybych to měl shrnout, tak asi dvě až tři věci. Už jsem tam byl nějakým způsobem – bylo to trochu rutinní, věděl jsem, co a jak. Potřeboval jsem novou výzvu a nové technologie. I když v SASce mi zůstal on-prem MS SQL, tak tam bylo něco navíc. Určitě byla motivací i lepší mzda. A třetí věc je, že mě to tam už tolik nebavilo.

Dobře, takže píše se loňský rok, 2024, nastupuješ do SASky předpokládám do Data Warehouse týmu?

Přesně tak, jako developer. Tým je poměrně obměněný. Se mnou tam nastupuje ještě kolega v listopadu… (text končí).

Jasně, tady je opravený text:

Před pár měsíci jsme tam byli ve třech, máme tam ještě jednoho externího kolegu. Jelikož je tým nový, předáváme si spoustu věcí. Snažíme se do toho zapracovat, aby vše fungovalo, jak má, zajistit provoz a až poté případné rozvoje.

Máme otázky, které nám pomůžou sklad zlepšit. Teď je tým už více ustálený, konkrétně čtyři lidé a k tomu jeden externista. Dost mě překvapilo, že jsi byl asi dobře vybraný, a Saska si vybrala dobře, když jsi nastoupil začátkem roku 2024 a o rok později jsi se stal vedoucím týmu. Jak se to stalo? Byla to tvoje motivace? Jak toto vnímáš?

Myslím, že částečně to byla i shoda okolností, protože tým byl celý obměněný, tak jsme to potřebovali nějak uchopit. Nabízel jsem se jako nejvhodnější kandidát ze současného týmu. Zní to, jako kdybyste si tahali sirky. Ne, to ne. Chvilku jsem o tom přemýšlel, jestli do toho jít, a nakonec jsem si řekl, že to bude dobrá výzva. Stejně i dnešní podcast je velmi dobrá výzva, a mám rád problémy, které překonávám, takže jsem do toho šel.

A teď k dnešku – jak jsi říkal, jste čtyři a jeden externista, tedy tým pěti lidí. Pro Kontext, jak vypadá celý datový tým Sasky, resp. jeho součást? Když uděláme organizační schéma - my jsme pouze součástí oddělení BI, které má přibližně 21 členů. Těch týmů jako my je asi tři až čtyři, kde máme datové analytiky, datové inženýry a nás, datový warehouse tým. Dále máme Data Governance tým, architekta a šéfa.

Tyto týmy jsou nějak propojené. Analytický tým většinou komunikuje hlavně s byznysem, připravuje ad hoc analýzy a zadání pro vývoj skladu, komunikuje s námi a společně testujeme vyvinuté věci. Datoví inženýři se soustředí hlavně na cloud, real-time data a podobné use casy, třeba pro Data Science. A zbýváme my, což jsem už zmínil.

Data Governance tým zastřešuje datovou kvalitu – od jednoduchých kontrol až po složitější rekonciliace, například při srovnávání vstupů ze SAPu a loterijního systému, aby na sebe data seděla. Když sedět nebudou, musíme chyby řešit a upozorňujeme na možné problémy v provozu.

Posluchačům doporučuji díl o Data Governance, který mi úplně změnil pohled na tuto oblast. Bral jsem ji jako to nejhorší a nejnudnější nutné zlo. Dnes se mi ale líbí, jak se narativ posunul k něčemu důležitému, co přináší velkou hodnotu celé organizaci a jejím datům. Není to jen něco, co musíte dělat, protože vám to někdo řekl.

Takže tohle doporučuji – díl o Data Governance.

Pokud chceš, mohu text ještě více zpřehlednit nebo rozdělit do odstavců.

Tady je opravený text s důrazem na správnou gramatiku, interpunkci a stylistiku:

Co máte vlastně na starost? Jak vypadají vaše priority a kde končí vaše zodpovědnost a začíná zodpovědnost jiných? Za co má tvůj tým nést zodpovědnost? My vlastně děláme, dejme tomu, tři věci, když to shrnu. Máme požadavky od SASky – nové projekty, které se musí realizovat. Pak máme rozvojové věci, tedy nějakým způsobem vylepšujeme a rozvíjíme náš sklad. A samozřejmě provoz celého datového skladu a dalších komponent, které zde máme.

Jak vypadají byznysové požadavky na warehouse? Co to vlastně znamená? Jde o poměrně různorodou škálu úkolů. Může to být přidání jednoho sloupce do tabulky a jeho propagace do vyšších vrstev do datového modelu, ale také až úplně nový datový zdroj, například řešení projektu nové vertikály, kdy máme desítky nových tabulek, integrace k nám a vystavení tzv. core vrstvy v datovém skladu, kterou napojíme na stávající data.

Než se dostaneme k té nejzajímavější části – rozvoji nového a co coolového naše platforma umí – co pro vás znamená samotný provoz? Je to nutné zlo, předpokládám, a čím menší část kapacit si vyžaduje, tím lépe jsme odvedli práci v rozvoji. Ale jak vlastně vypadá ta platforma, co provozujete?

My provozujeme konkrétně tři systémy, respektive máme na starost tři systémy: datový sklad, regulatorní databázi a operační databázi ODSK. Tyto systémy nějakým způsobem koexistují – největší část zabírá datový sklad, který je on-prem. To je hlavní komponenta, s denním loadem (D-1). Předtím probíhá integrace ze všech různých zdrojů od dodavatelů do datového skladu, a na něj jsou napojené další komponenty, o které už ale nemusí nutně pečovat můj tým – například reporty, data science use case a podobně.

Datový sklad je velký, kolem 30 TB přibližně. Jelikož je on-prem, musíme řešit rostoucí kapacity i optimalizaci místa. Průměrný denní přírůstek je asi 20 GB. Přibližně polovina vstupů jsou near real-time, asi 40 % vstupy od dodavatelů, které nám chodí v souborech (CSV nebo podobné formáty), a zbytek jsou ruční vstupy.

A odkud vlastně do databáze chodí ruční vstupy? Momentálně většinou z Excelu – business člověk vyplní tabulku určitou strukturou a u nás kontrolujeme, zda se tento Excel změnil nebo nikoli. Když ano, vezmeme ho k nám do skladu a naloadujeme data. Má to ale spoustu problémů, protože špatně se tam hlídá datová kvalita, někdo může zadat chybná data, a často ráno nastávají pády na základě špatných vstupů. Proto i s tímto problémem přemýšlíme, jak to dělat lépe. Obecně ruční vstupy nemáme rádi a neradi je povolujeme, takže mě překvapilo, že je takto podporujete.

Momentálně řešíme nebo připravujeme řešení, kdy chceme ruční vstupy už kontrolovat přímo na úrovni datové kvality. Přesunuli bychom se z Excelu pravděpodobně, nebo spíš určitě, do Atacamy, která zároveň umožňuje kontrolovat sloupečky – například jestli jsou správně vyplněné a neobsahují chyby.

Pokud budete chtít, mohu text ještě více upravit podle konkrétního stylu či rozsahu.

Tady je opravený text:

Vyplněno, unikátnost a podobné věci. A pak rovnou teprve uděláme exporty, až když tohle všechno splníme. Exporty k nám jsou proto, že chceme vylepšit vlastně ten provoz tímhle způsobem.

Mám ještě jeden dotaz. Tím, že to je on-prem a vy jste nejníž, tak sázíte i na železo, anebo je to na IT a na jiném týmu?

My na železo přímo nesaháme, máme na to infrastrukturní tým, s nímž samozřejmě komunikujeme. Můžeme mu dávat nějaké návrhy, co bychom tam chtěli. Dáváme například dopředu výhled na diskové kapacity – jak nám asi bude přibývat dat, kolik budeme potřebovat rozšířit diskové pole, nebo když děláme nějaké optimalizace, aby nebylo potřeba tolik rozšiřovat. Tohle máme vlastně v kompetenci infra tým a my s nimi jen komunikujeme, co bychom potřebovali.

Když jsi říkal ty přírůstky, že desítky gigabajtů denně, kolik z toho zůstane po týdnu? Jak moc vám to bobtná?

Bobtná to hodně. Jedna z věcí, co jsme právě začali řešit, je to, že donedávna jsme uchovávali celou historii – nejen historii jako takovou celou, ale i historii věcí, které se už třeba teď nepoužívají. Je tam poměrně dost takových věcí, tak proto postupně rušíme staré objekty, které se už nepoužívají, archivujeme a zároveň i promazáváme stage, kde držíme ty největší objekty, které mají stovky gigabajtů. Začínáme zavádět časovou retenci. Záleží samozřejmě, o jaká data jde, protože něco musíme uchovávat kvůli regulatorním a dalším požadavkům, takže tam to závisí.

Co můžeme, tak ve stage mažeme, protože to už nepotřebujeme. My to pořád máme zaarchivované ve vstupech, takže aby se nám tam nedržela zbytečná data.

A jinak – je to kopie, nebo se musíš starat o dvě databáze?

Jsou to úplně jiná „zvířátka“. Nejde jen o rozdíl ve frekvenci a typu dat, ale i logika systému je posunutá. Musíš hlídat, když něco změníš v jedné databázi, třeba v DVH, jestli se něco nezměnilo i v „kukátku“. Je to tak ve většině částí spíš na integrační vrstvě. Když máme například vstupní soubory, tak máme rozdělené vstupy třikrát denně a teprve pak se skládají do DVH, které jsou celodenní. To je jeden případ.

Buď nám tam chodí realtime data, tam to není takový problém. Stage je vlastně velmi podobná DVH, jenže je to užší výsek vlastně warehouse. Následně už je tam úplně jiná logika v další vrstvě, kdy se provádějí specifické ETL operace, které potřebujeme pro ministerstvo financí, protože datový model za stage je už úplně jiný.

Super, tak se podívejme ještě high-level na tu třetí komponentu, třetí velký systém, co máte na starost, a to je ODSK.

Přesně tak, ODSK – operační databáze – tu už nemáme on-prem, ale je v cloudu, konkrétně v Microsoft Azure. Momentálně slouží v podstatě k jedinému účelu – zachytit near real-time data ze streamů a na D-1 je nahrát do datového skladu.

Pokud chceš, mohu text ještě více upravit nebo zkrátit.

Jistě, tady je opravený text s úpravami pravopisu, interpunkce a stylistiky pro lepší srozumitelnost:

Problémy nastávají, kdy už nám kapacitně úplně nedostačuje ani výkon, takže je to jedna z věcí, které se budeme určitě věnovat. Když se podíváme na data, která k vám přicházejí – o jaký typ dat jde? Jaké kategorie máte nejčastěji?
Jedno jsou webová analytika, uživatelé, byznysové a finanční ukazatele?
Ano, přesně tak. V obou případech máme webovou analytiku, finanční ukazatele, zároveň třeba i data z kurzových sázek. To jsou vlastně ta největší data, protože nám tam přicházejí ve streamech změny každého kurzu.

Takže největší tabulky jsou klasicky transakce na hráčských účtech a všechny takové ukazatele. Dále pak prodejní data a data o balících. Sazka nabízí i balíkové služby – nejenže se přijde na pobočku a sází, ale dá se tam i odeslat balík, takže máme data i o balících. Je to tedy poměrně různorodé.
Když bych to srovnal s databází ve Staropramenu, tak ta byla víc straightforward, zaměřená na retail, pivo a podobné věci, že?
Ano, přesně tak. Tam šlo hodně o byznys, například o podporu obchodním zástupcům – že tady na té hospodě máš toto pivo, už se tam dlouho neobjednávalo, takže takové věci, které podporují hlavně prodej. A tady je to víc produktově orientované, mám takový pocit?
Ano, je to tak. Je to hodně o customer marketingu, o podpoře marketingových kampaní a podobně.
Když se podíváme ještě na ODS, ta je v tuto chvíli spíše průtokový systém než klasická databáze, která by něco uchovávala. Je to tedy nástroj, jak z jedné strany dostat data na druhou?
Ano, přesně tak. Je to hlavně průtokový systém. Občas je tam nějaká výjimka, kdy máme napojený nějaký jiný real-time report, ale primárně to slouží jako průtokový systém.

Možná o tom budeš mluvit v třetí části našeho rozhovoru, o tom, co děláte, jak to celé rozvíjíte a optimalizujete, ale na této úrovni – proč nejde, nebo uvažovali jste o tom, že místo denního refreshu (D-1) byste data aktualizovali třikrát denně, tím se zbavili „kukátka“ a zrychlili celý proces, a možná by pak ODS nebyla potřeba, protože warehouse by byl mnohem real-timeovější a rychlejší?
Ano, to je něco, co bychom velmi rádi. Proto právě startujeme projekt nové datové platformy, kde chceme všechny ty duplikace eliminovat a třeba i různé rychlostní nápočty integrovat tak, abychom měli všechno pohromadě. Co se týče zrychlení data warehouse na třikrát denně, myslím, že by to bylo poměrně obtížné, protože ne všichni dodavatelé nám jsou schopni data dodávat častěji. Real-time část je v pořádku, tam by to šlo, ale u ostatních dodavatelů by to představovalo problém.

Takže si myslím, že nikdy nepůjde vše aktualizovat několikrát denně či téměř reálném čase. Vždy tam zůstane část dat aktualizovaná D-1, s tím, že hlavní část už bude zpracovávaná real-time nebo near real-time, a pak budou i pomalejší části.
Tak se pojďme podívat, s čím tedy pracujete a jak celý proces zrychlujete.

Kdybyste chtěl, mohu pomoci i s dalšími částmi nebo s úpravou stylu textu, dejte vědět!

Tady je opravený a stylisticky upravený text:

Teď k tomu, co děláte vy a co může posluchač, který pracuje s databázemi a infrastrukturou, udělat, aby to fungovalo lépe. Říkáš, že jste nový tým, a jak jsem pochopil z našeho rozhovoru, tak jste do toho celkem šlápli a během posledního roku jste zvládli dokončit a posunout spoustu věcí. Jak jste k tomu přistupovali? Co byly ty klíčové momenty, na co jsi hrdý, že se vám povedlo za poslední rok?

Asi nejvíc jsem hrdý na celý tým, kterému se podařilo ustálit a který teď pracuje výborně. Podívali jsme se třeba na problém s dobíháním datového skladu, který v minulém roce často končil pomalu, třeba až kolem deváté hodiny ráno. Přistoupili jsme k tomu tím způsobem, že jsme identifikovali, jak já tomu říkám, „kritickou cestu“ – podívali jsme se od konce na ty nejdůležitější procesy a sledovali jsme, jak probíhají postupně od zdrojů až k dodavatelům.

Začali jsme dělat tři klíčové věci, které nám z toho vyplynuly. Ještě zastavím – jak se to vlastně dělá? Zní to hezky, podíváme se na celý proces end-to-end a zaměříme se na kritickou cestu. Co to přesně znamená? Sedli jsme si a udělali jsme analýzu, kde jsme vzali všechny ETL procesy v datovém skladu, analyzovali je a vytvořili graf, kde na jedné ose byl čas běhu a na druhé ose počet paralelně probíhajících úloh. Díky tomu jsme viděli, kdy jednotlivé ETL procesy běží, jaké jsou jejich vstupy a které části pipeline představují potenciální úzká místa.

Tahle analýza byla zaměřena jen na klíčové procesy, nezabývali jsme se daty, která nás tolik nezajímají, ale soustředili jsme se na „hlavní maso“. V grafu jsme například viděli dlouhý úsek trvající i přes dvě hodiny, kdy nic neprobíhalo, pak spoustu krátkých úloh, které běžely v pořádku, a jednoho velkého dlouhého úkonu, který celý běh zpomaloval. Takto jsme vypíchli ETL procesy, které běží pomalu a jsou kritické, protože zpomalují celý systém.

A jak jste k těm datům přišli, čím jste to vylistovali? Použili jste nějaký nástroj, nebo to bylo ruční?

My máme metadata o všech ETL procesech uložená v orchestration nástroji. Tam máme informace o časech spuštění, ukončení, úspěšnosti či chybovosti daných běhů. Takže jsme měli všechny potřebné podklady přímo z orchestrace. Jediné, co jsme udělali, bylo vytvoření aplikace – jednoduché webové stránky v JavaScriptu, kam jsme data nahráli a vizualizovali je do grafu.

Super. A než se pustíme do toho, co jste s tím potom dělali, byl tam nějaký aha moment, některé slepé skvrny? Třeba něco, co tě překvapilo?

Když to nyní dělám, přijde mi to hrozně logické a smysluplné. Překvapuje mě, že se takováto analýza nedělá pravidelně u všech infrastruktur, protože je to opravdu dobrý nápad. Nejčastější překvapení bylo, že jsem si myslel, že problém bude jinde, ale zjistili jsme, že za těmi dlouhými úseky čekání, které někdy trvaly i dvě hodiny, stála většinou jednoduchá chyba či možnost optimalizace.

Pokud chceš, mohu text ještě více upravit nebo víc oprostit od hovorového stylu. Stačí říct.

Jako ten největší aha moment bylo, že jsme věděli, že máme posunuté, nebo nám nechodí datové vstupy od dodavatelů tak, jak bychom si představovali. Některé přicházejí třeba ve tři ráno, ale některé až v šest, takže denní a noční rutina se moc nestíhá. A u jednoho dodavatele byl velký aha moment – jeho data přicházejí až v sedm ráno a vlastně celé toto zpoždění celý proces brzdí. V současném stavu, když už jsme to částečně vylepšili, bychom měli mít dopočítáno dejme tomu po páté ráno, ale musíme čekat až do sedmi hodin na jeden kritický datový vstup, který všechno zpomaluje. Máme tam vlastně dvouhodinové okno, kdy se čeká. Už půl roku to řeším s dodavatelem, abychom to nějakým způsobem posunuli, zatím se moc nedaří, ale teď to už snad bude na konci a doufám, že se nám to povede.

Je zajímavé, že problém není jen v legacy SQL, nějakých skrytých návaznostech nebo podobně, ale že jde o navázání na dodavatele. Fix není v kódu, ale ve volání na ně, jednaní a dohodě, aby posílali data dřív. Přesně tak. A to byla celá jedna oblast, kterou jsme řešili. První krok byl, že jsme posunuli vstupy od dodavatele S, kteří dříve chodili kolem třetí ráno – teď posílají co nejdřív to jde, někdy kolem půl jedné nebo půl druhé.

Zároveň je potřeba si dávat pozor na změny času, je to trochu tricky. Proč to bylo důležité? Protože na tyto vstupy jsou navázané další výpočty, a čím dřív data máme, tím více posuneme celou frontu zpracování. Přesně tak, celý proces tak není zpožděný a může začít dříve.

Začali jsme tedy tím, že jsme vytáhli data z ODS a dívali se pak na dodavatele. Některé věci šly úplně v pohodě, jinde to bylo horší. Některé dodavatele jsme zvládli domluvit a vše bylo hotové do tří týdnů, jinde byly větší úpravy a některé věci stále řešíme. Je to velmi různorodé.

Další věcí, kterou jsme dělali, byly jednoduché optimalizace dotazů, což byla druhá část překvapení – nejen posuny časů, ale i SQL samotné. Byly to vlastně poměrně jednoduché úpravy, ale na mnoha místech. Často šlo o non-searchable dotazy, kdy se ve VR používají funkce CAST nad daty, což znemožňuje SQL serveru použít indexy pod nimi a výrazně to zpomaluje dotazy. Řešení bylo velmi jednoduché – nahradit funkce CAST ve VR nad daty pomocí menšího/větší (less than/greater than) a tím umožnit použití indexů.

V tomto případě je na nás, nebo tedy na týmu, abychom se kódu analitikům podívali a vysvětlili jim, jak mají psát další dotazy, pokud pracují přímo ve VR. Je to obojí: nejdříve jsme začali u sebe, abychom měli věci v pořádku, a až potom jsme šli za ostatními s tím, že... „Já jsem to skopíroval od tebe.“ Takže nejdřív jsme začali u sebe a pak šli za analytiky.

Tady je opravený a stylisticky upravený text:

s nimi, a nějakým způsobem jsme to řešili, což je teď už úplně jinde, než tomu bylo dříve. A zároveň jsme nešli jen za analytiky, ale i za business uživateli. U nás mají i business uživatelé přístup do datového skladu, takže si tam mohou také psát různé selekty, a i s nimi jsme se o tom bavili. Asi si nechme téma, jestli pouštět business uživatele do datového skladu, na pozdější část, abychom tu optimalizační diskuzi nezahltit tímhle.

Když mluvíš o analytikech a lidech, kteří nemají na starosti warehouse, ale sahají do něj, máš nějakou obecnou radu pro analytiky a datové profesionály na vyšších úrovních? Z tvých zkušeností – co často nevidí a nemůžou vidět, a co by jim pomohlo si zlepšit pohled u jejich lídrů a ústředních vedoucích?

Za mě rozhodně nepsat CAST do VARCHARu. Ono je strašně pohodlné to tam napsat, nechce se ti přemýšlet, jak to napsat správně přes menší/větší, protože to je trochu složitější na myšlení, ale výkon to výrazně pomáhá.

Super, takže nepíšete CAST do VARCHARu.

Tak pojďme dál. Jednoduchá optimalizace SQL – první u sebe doma, potom u dotazů od ostatních. Byly tam nějaké větší architektonické či strukturální změny? Zatím mi to zní jako takový jarní úklid.

Jo, velký jarní úklid, akorát probíhal spíš od začátku podzimu minulého roku. Jedna velká změna, která tam nastala, je, že jsme zavedli columnstore indexy, které původně v datovém skladu vůbec nebyly. Je to skvělá věc – jiný typ indexů. Klasicky máme rowstore indexy, které se ukládají po řádcích, tohle je po sloupcích a má to velký potenciál šetřit místo díky vysoké kompresi na sloupcích.

Zpočátku jsme si nebyli úplně jistí, jak nám to pomůže s výkonem, ale ukázalo se, že to výrazně zrychlilo některé dotazy. Columnstore index díky kompresi sice má vyšší nároky na CPU, ale protože naše tabulky byly velmi velké, podařilo se nám je převést na columnstore indexy a dotazy na konkrétní časová období, případně inkrementální dávky, se značně zrychlily.

Takže je to lepší, když se díváme na dané období nebo časový úsek, vše běží rychleji.

Pokud to správně chápu, změnili jste logiku ukládání dat z řádkového formátu do sloupcového, což je samozřejmě určitý trade-off. Předpokládám, že to není univerzální řešení pro všechny případy, ale spíše pro specifické use case, jak jsi říkal, zejména pokud máte velmi velká data.

Není to něco, co by mohlo způsobit velké problémy třeba při chybě v jednom malém místě, nebo že by to bylo nesmírně složité z inženýrského hlediska, že?

Jaký je ten konkrétní use case? Komu bys columnstore indexy doporučil a komu naopak ne?

Columnstore indexy bych použil hlavně v datových skladech, nikdy bych je nepoužil v OLTP aplikacích, tam by podle mě byly nepoužitelné. Jsou vhodné tam, kde je extrémně velké množství dat a potřeba rychlých analytických dotazů.

Pokud chceš, můžu text ještě víc zjednodušit nebo rozšířit.

Jasně, tady je opravená verze textu s lepší strukturou a gramatikou:

Asi bych to používal jenom v datovém skladu, nikde jinde to nedává moc smysl. Tam si myslím, že to bylo spíš kvůli vkladu dat. A když mluvíme o nějakém datovém skladu – například takovém, který má brutální přirůstky a obrovské množství dat – tak asi spíš u toho většího. U menšího skladu by to bylo otázkou, jestli to použít jenom na vybrané tabulky, třeba ty největší. Jinak by to asi moc smysl nedávalo.

Ještě jedna věc – je to záležitost on-premise, nebo se to používá i v cloudu? Jde o úložiště a o to, že máš vlastní hardware, a když bys to dělal v cloudu například přes Azure, mohlo by se to celé rozbít, protože s tím nikdo nepočítá. Pravda je, že v cloudu jsem to zatím nezkoušel. MS Excel má určité funkce, takže nevím, jestli by to fungovalo třeba i v Excelu v cloudu, ale vím, že jiné datové platformy to podporují přímo na pozadí. Vývojáři tak nemusí myslet na optimalizace, protože se to určuje samo. Konkrétně u Microsoftu a SQL Serveru to netuším úplně přesně.

Super, tak jste tedy implementovali columnstore indexy. Co říkáš – menší nároky na data, větší nároky na CPU – byly tam ještě další kompromisy nebo věci, na které dát pozor?

Jo, columnstore index je specifický tím, že se obvykle nastavuje na celou tabulku, tedy na všechny sloupce. Proto jsou operace, jako přidání nebo odebrání sloupce, poměrně problematické. Je to časově náročné, protože je potřeba celý index rebuildnout, a vzhledem k velikosti dat to dlouho trvá. Je to vlastně trochu předvídatelná záležitost – musíš říct logiku dopředu. Kdybys to používal ve startupu, kde často přidáváš sloupce a měníš logiku, byl by to spíš problém. Když ale víš, co sleduješ, je to jednodušší.

Lze to udělat i na menší část tabulky, ale podle mě je nejlepší to mít na celé tabulce. Rozhodně je tu ale ten kompromis v podobě obtížnějších úprav.

Rozbilo vám to něco?

Pro mě to zní jako docela velký zásah do logiky ukládání dat.

Jo, máš pravdu, to jsem zapomněl zmínit. Máme za datovým skladem napojené OLAP kostky a ty s tím měly velký problémy. Moc jsme neuspěli v tom, proč se to dělo, ale jakmile jsme použili columnstore na největší transakční tabulce, která vstupuje do OLAP kostky, ta přestala fungovat. Došli jsme k závěru, že je to kvůli columnstore indexu a jeho nespolupráci s OLAP kostkami. Nakonec jsme ho museli na této tabulce zrušit.

Myslím si, že tenhle problém budete řešit čím dál méně, protože integrace s OLAP kostkami bude ubývat.

Jak dlouho vám trvalo to vyřešit? Bylo to jenom pár kliknutí a pak něco rozbili, nebo to byl opravdu zásadní problém?

My jsme udělali nějaký rychlý fix, který zabral asi půl dne…

Pokud chceš, mohu text ještě přeformulovat nebo zjednodušit.

Trvalo, než jsme přesně přišli na to, co to je, že to opravdu bylo tímto způsobem, takže nebylo to úplně rychlé. Ale jakmile jsme věděli, oč jde, už to šlo poměrně rychle. Myslím spíš ty indexy obecně. Takže jak velký projekt si to mám představit? Protože mi to zní jako dost zásadní změna.

Jo, dejme tomu, že to bylo na desítkách tabulek, asi tak kolem padesáti přibližně, a ta změna trvala poměrně dlouho, protože index se vytváří poměrně dlouho, a my jsme jich chtěli vytvořit hodně. Začali jsme proto v období menšího vytížení, respektive o Vánocích minulého roku, což je pro SASKu poměrně vysoká zátěž, ale na Warehouse už taková není, protože tam uživatelé nejsou. Takže jsme začali někdy od Vánoc a postupně se tam vytvářely Column Store indexy až do poloviny ledna. Trvalo to tedy poměrně dlouho a možná jsme to vzali s velkým soustem – vytvořili jsme jich moc najednou. Změnilo se hodně exekučních plánů a ne vždy si systém vybral úplně správný plán, takže třeba ten Column Store nebyl vždy využíván, například při non-clustered indexech. Asi bych to dělal ještě po menších částech a opatrněji, než udělat tolik najednou.

Pro mě je skvělá vizitka SASKy, že když řekneš, že jsme začali o Vánocích a skončili v polovině ledna, tak to sice trvalo dlouho, ale je to vlastně hodně rychlé. Myslím, že kolegové z jiných firem teď poslouchají a myslí si, že to je velmi rychlé.

Chápu. Co dalšího? To byla jedna změna. Jsou tam ještě nějaké další optimalizace, věci, na které se díváš, které teď řešíte a jsou zajímavé?

Ještě teď pracujeme na „opravení“ datového modelu, protože se u nás vyvíjel historicky a má poměrně dlouhou historii, takže by to potřebovalo trochu upravit. Datový model má totiž historický kontext – nejdřív byl jen landbase, terminály, pak přišel online svět a další věci, jako kukátko do dat a real-time informace. Proto bychom ho potřebovali trošku „učesat“, například v kvalitě produktů. Je tam spousta dodavatelů, každý má svoje ID, a může mít stejné produkty, takže potřebujeme to nějakým způsobem víc propojit. Také chceme lépe propojit svět online a landbase, a celkově „učesat“ ty „marty“, které tam máme.

To mi přijde hodně zajímavé, že váš tým na tom pracuje. Pro mě je datový model jako bible celého datového oddělení, ale chápu, že vy se s tím nejvíc potýkáte, jak data správně fungují a jakou mají strukturu.

Když říkáš, že chcete řešit datový model, co to podle tebe bude znamenat?

Ve výsledku budeme do něj muset sáhnout, ale zároveň probíhají diskuze a analýzy nad celým BI, jak k tomu přistoupit, rozhodnout se, co budeme dělat. Na nás pak bude to celé naprogramovat.

A jak moc podle tebe má datový model odpovídat abstrakci reality, tedy byznysové realitě, a jak moc infrastruktuře a jejím potřebám? Je to kompromis a musíte se někde potkat uprostřed?

Pro mě je to vždy kompromis, protože nikdy nelze jít ani jedním extrémem...

Tady je opravený text:

Protože tam vždycky dojde na něco, co nefunguje. Nějaký příklad? Kdybych dělal jenom byznys, tak neřeším vůbec performance, bude to strašně pomalé, data nebudou dostupná včas. Zároveň, když bych řešil jenom tohle, tak nemusím správně vůbec pokrývat byznysové požadavky. Je to opravdu o kompromisu, aby to běželo nějak dobře, včas a mělo požadovanou kvalitu, ale zároveň aby to pokrývalo byznysové požadavky.

A když se takhle bavíme, jak vlastně probíhá spolupráce s ostatními týmy? Kde máte předávky, máte nějaké společné porady, jak to organizujete a prioritizujete? Musíte pracovat jako jeden tým, ale každý z vás má na starosti jinou část stacku, tak jak to koordinujete?

Co se týče schůzek, tak jednou týdně máme hodinu s celým mým týmem, kde si synchronizujeme, co se děje, co je prioritní a co je potřeba dělat. Pokud z provozu něco vyvstalo, co se musí řešit, tak to tam také řešíme. Dále máme ještě s celým BI týmem asi půl hodiny schůzku, která je na podobné téma. Občas tam máme naše vstupy, co bychom potřebovali řešit, ale primárně se to řeší mimo tyhle meetingy, které jsou spíš řešitelské. Analytici jsou rozdělení, každý z nich má na starosti určitou oblast – například jeden má kurzové sázky, druhý kampaně, webovou analytiku – a ti už komunikují přímo s byznysem. Zároveň nám přinášejí vstupy, co bychom měli dělat, a o tom se pak bavíme i s byznysem dohromady.

Díky tomu analytik ví, kde ve warehouse vlastně sedí jeho data. Protože má na starosti úzce vymezenou oblast, má větší vhled i do nižších vrstev. Nemá tak detailní přehled o všem, například o indexech a podobně, to řešíme my, ale ví, jaké jsou tam tabulky, jak se data mezi sebou propojují, a funguje jakýmsi prostředníkem mezi mnou a byznysem. Rozumí byznysovým problémům lépe než já, ale zároveň někdy chápe i moje technické problémy a takto spolu komunikujeme.

Moc se mi líbí, že celý BI tým je kompaktní a ať už cokoli řešíme, vždy je to v přátelské atmosféře. To mě překvapilo – ve všech mých předchozích zkušenostech, ve firmách jako Saska nebo Staropramen, byla atmosféra vynikající. Čekal jsem, že by mohlo něco haprovat, ale nebylo to tak.

Máš štěstí, nebo dobrou ruku. Možná je to právě kombinací jednoho – piva, a druhého – her, tedy zábavy. Asi to bude pravda, protože ve Staropramenu kolem pivní kultury všechno žilo, a dodnes s kolegy máme pivní čtvrtek, občas vyrážíme na hory nebo na malé pivovary, takže se stále držíme přátelství i po mém odchodu. U nás v SASCe zase chodíme hodně hrát šipky po práci, a těším se, jak v létě budeme chodit na ping-pong.

Pokud chceš, mohu také pomoci s dalším formátováním nebo úpravou.

Zahrát po práci, takže úplně super. A na ty, když se...

Tak tím do té práce, takže nejvíc jsi v kontaktu s analytiky, tam je to nejvíc. Jak se teda dostáváš do kontaktu s byznysem? To přepoutáváš přes analytiky ten požadavek? Taky, ale zároveň se s nimi teď snažíme bavit i víc napřímo. U nás, jak už jsem říkal, byznys uživatelé mají přístup k databázi, mají tam i nějaký playground, celou databázi, kde si můžou i vytvářet objekty.

Počkej, tady tě zastavím. Playground, kde si můžou vytvářet objekty a nic ti nerozbijou? To je wow! Který byznysák může k tobě do databáze a jak tohle řešíš, kontroluješ? Pro mě už bylo dost nebezpečný připojit jim přímo jejich Excel, ale tak... libovolný obchodák ti může dát select do databáze a celý to nabourat?

Ne, ne, ne. Máme databáze oddělené, máme datový warehouse, kde jsou omezené přístupy podle toho, jaká data kdo potřebuje. Je tam poměrně složitý bezpečnostní proces pro žádosti o přístupy k tabulkám a tak. Tam dávají jen čtení, hlavně u vyšších vrstev dat, jako jsou marty. Rozhodně tam není stage nebo core, občas možná nějaká výjimka, ale moc ne. A mají reporty, které už jsou připravené analytiky. Myslím, že Vašek o tom mluvil – už probíhá nějaký self-service reporting.

A pak mají svůj playground, což je samostatná databáze, oddělená od těch ostatních. Tam mají práva vytvářet si svoje objekty, je to ale omezené, aby to nebylo tak, že by mohli všichni dát drop na všechno a tak.

Chápu. A chtějí to?

Chtějí. To je taky pro mě překvapení – v mnoha firmách je adopce a data-driven kultura tím, že vůbec donutit lidi otevřít vrstvu vizualizací. A ty teď říkáš, že si vytvářejí nové objekty v databázi.

Jo, myslím, že cesta k tomu je strašně složitá, protože to musíme i sami propagovat ve firmě, v SASce, aby to lidi chtěli používat. A chtějí to. Máme tam CRM analytiky, kteří používají právě takhle databáze, máme tam i compliance, co používají SQL. Takže máme hodně ambasadorů ve firmě, kteří SQL používají. Snažíme se to propagovat, aby to používali, ale zároveň je musíme v tom světě navigovat, aby to dělali správně, aby nám neběhali dotazy, které běží dlouho a zasekávají systém.

To řešíme tím, že máme nějakou prioritizaci – například dotazy, které nejsou prioritní, běží až poslední. Nejprve běží must-have věci. Propagujeme to tím, že děláme věci pro byznys, které jsou pro ně jako wow.

Třeba jsme nedávno dělali projekt na redesign kvartálního plánování, kdy každý kvartál pro celou technologickou divizi se plánuje, co bude v příštím kvartálu, a dělalo se to v Excelu...

Opravený text:

Ech, jakoby projekty kapacity? Jo, přesně tak. Kapacitní plánování spočívá v tom, co který tým má dělat za projekty a jestli na to má kapacitu. Ve výsledku to vypadá tak, že tam je graf, kde jsou v měsících na sloupečkách poskládané projekty, mají různé barvy, aby bylo vidět, který zabírá kolik času, lidí, a zároveň jsou oprioritizované. Proti tomu je červená čára, která ukazuje kapacitu daného týmu – přes tu čáru už to nezvládne, pod ní to zvládne. Pak jsou samozřejmě nějaké diskuze, co se týká meetingů, co když se něco nezvládne, nejde to nějak změnit nebo jak to přeprioritizovat jinak. A je to spíše takový vlastně ne formální proces.

Jak je to u nás postavené? Vlastně to jen sedí, má to databázi a je to power-upka spojená s Power BI, kdy uživatelé si tam ručně editují svoje kapacity, potom se upravují kapacity za projekty a pak se to jen porovnává navzájem. No a tohle je business aplikace, kterou uvádíte do provozu a která vznikla zase proto, abyste obhájili data. Mně přijde, že naopak ve chvíli, kdy controlling si vytváří vlastní objektivní databázi, tak zní, že data máte dobře obhájená, ale asi to budou spíše výjimky ambasadorů, power-userů a plánování kapacit na kvartál se týká vlastně všech. Jo, plánování na kvartál se týká v podstatě všech teamleadů a výš, ale oni do databáze vlastně vůbec nemají přístup, všechno je řešené přes frontend v Power BI nebo v té Power-upce, do které mají jediný přístup, a ta už to zpracovává k nám. To kapacitní plánování je tedy věc, kterou navíc přidáváme, nebo co velmi prodáváme biznisu, že vidí, že to pro ně má nějaký přínos, a je to jedna z propagačních věcí, kterými vlastně ukazujeme, že to děláme dobře a že data jsou důležitá. Tohle má totiž velký dopad na plánování a pro ně to byla super věc, a tím se dokážeme ukázat.

Zároveň pak tu máme další věci, kdy neříkal bych tomu obhajování naší práce, ale spíš jde o to, víc naznačit lidem, proč je to dobré a proč by to měli používat, protože vnímání naší práce je dobré, ale spíš musíme motivovat lidi, aby to dělali s námi v tom SQLku, psali si dotazy sami, uměli to a dělali to správně. Takže máme i takové myšlenky, že vydáváme články o tom, co se u nás změnilo, myslím, že zhruba jednou měsíčně, kde máme pro uživatele napsané novinky nejen přes DVH komponenty nebo věci od mého týmu, ale i celopodnikové, například že v těchto tabulkách přibyly ty a ty sloupečky, které se jim mohou hodit, mohou s nimi začít pracovat, nebo že se událo něco, co by jim mohlo pomoci v práci apod. Je to o tom, že většinou jeden člověk o tom ví, protože ho to zajímá, ale může se to hodit i někomu dalšímu. Tím pomáháme s adopcí.

Když se podíváš na ten stack a na business usery, bude potřeba pořád psát SQL? Vidíš, že si to generují přes ChatGPT nebo někde jinde. Mám pocit, že se ta struktura, ten stack, hrozně otvírá, že všechny ty platformy jdou stále výš a výš, a vás také čeká velký rozvoj...

Opravený text:

Hodně velký upgrade. Tak teď, když říkáš, že budeme učit lidi SQL a podobné věci, není to záležitost, která za dva roky nebude nutná, protože řeknou „hej, computer?“ Oni to už teď dělají. Dělají to tak, že jim připraví to SQL a pak ho jen musí správně upravit, aby jim fungovalo. Takže už se to děje určitě teď. Většina těch business uživatelů právě tohle dělá. A teď jde jenom o to, abychom je správně naučili, aby tam nepustili cokoliv, co jim chat vyplivne, aby to nějakým způsobem dobře fungovalo, aby to mohli supervizovat. Přesně tak. Super.

No a jak jsem naznačil, nejlepší přednáška celého data Dejarlenského byl Martin, který mluvil o tom, jak vybíráte novou platformu pro celý data stack. Jak to dopadá na vás? Jak velká část práce se vás dotýká? Jak do toho vstupujete? A až vyberete, co to bude znamenat pro tvůj tým? Kolik roků práce vás čeká předělat všechno? Nebo je to už vstup a vlastně je jedno, co to konzumuje, protože logika, datový model a tak je obecný a univerzální?

Tak datová platforma nás určitě dopadá, a to hodně. Teď jsme spíš ve fázi, kdy zjišťujeme, co pro nás je dobré. Měli jsme několik proof of conceptů, co se týká databázových nástrojů, ale i orchestračných nástrojů, které jsou velmi důležité pro náš tým. Vybíráme mezi třemi technologiemi: Fabric, Snowflake a Databricks. Co se týká Fabricu, ten jsme opustili, protože jsme došli k názoru, že systém není zatím dostatečně připravený, mění se tam věci pod rukama a pricing není úplně dobře nastavený.

Chtěl bych doplnit k přednášce, že všem imponuje, že opravdu děláte velká srovnání a proof of concepty, pilotní projekty se všemi třemi platformami – Databricks, Fabricem i Snowflake. Už jsem měl v živote hodně hostů a s mnoha lidmi jsem mluvil, ale nikdy jsem neslyšel o tom, že by někdo měl zkušenost s porovnáním a zároveň pilotními projekty všech tří velkých nástrojů současně, takže to je mimořádně zajímavé.

Teď říkáš, že Fabric není dostatečně zralý, což je taky velmi zajímavé. Takže se nyní rozhodujete mezi Databricks a Snowflake, je to tak? A samozřejmě čtvrtá varianta je zůstat na stávající platformě. Jo, ta samozřejmě pořád zůstává jako safe choice. Vaše týmy mají za sebou reálná produkční řešení, tak jste si to už ověřili na reálných datech. Nakonec je vlastně jedno, jestli se to zaplatí v jedné nebo druhé platformě, finančně to vychází podobně.

Zatím jste chtěli zkoušet reálná realtime data a kombinaci realtime světa s warehouse světem, což znamená, že část dat přichází s denním zpožděním (D-1). Zjistili jste, že něco je v jednom nástroji o něco lepší, něco v druhém, ale nakonec jste došli k názoru, že mezi Databricks a Snowflake nemůžete šlápnout vedle, protože oba jsou top nástroje.

Jasně, tady je upravený a opravovaný text:

Jedná se o systémy, které se malinko liší – například Snowflake má trochu horší real-time zpracování, ale zároveň je jednodušší na nastavování a podobné věci. Navíc je to nativní SQL platforma, zatímco například Databricks má za sebou Spark, kde se sice také dá psát SQL, ale už to není nativní SQL. Hodnotíme tedy hlavně z pohledu několika kritérií, přičemž jedním z hlavních je fit pro aktuální tým – tedy pro mě a analytiky. Díky rozsahu použití SQL, které má velký přesah do businessu, si myslím, že Snowflake má zde navrch.

Zároveň ale máme i Databricks a pokud by byla varianta Snowflake, Databricks by u nás určitě chvíli zůstal, protože máme i machine learningové úlohy. V té oblasti je však otázka integrace mezi těmito dvěma systémy, kde Snowflake může trochu pokulhávat. Nakonec nám tedy vyšlo, že Snowflake je interně o něco lepší – ale opravdu jen o malý kousek.

Martin na základě svých kritérií říkal, že hodnotit je třeba velmi komplexně. Z tvého pohledu člověka zodpovědného za warehouse – když do toho ještě přihodíme Microsoft Fabric a podíváme se na výsledky POC – jak to vidíš? Jsou tam nějaké zásadní rozdíly v přístupu, nebo je to víceméně straightforward a rozdíly jsou už jen na úrovni uživatelské vrstvy?

A co se týče chleba a Fabric – pokud bych to měl porovnat, Fabric je oproti těmhle dvěma platformám výrazně méně vyspělý. Už při konceptu proof-of-concept jsme narazili na spoustu problémů. Některé věci se během testování měnily, první den jsme dokonce vyčerpali veškerý alokovaný kredit, protože nastavení price modelu nebylo přesné.

Co se týče Databricks vs. Snowflake – jsou si velmi podobné. V Databricks mám větší možnosti si nastavovat třeba storage, tedy jak jsou data uložena. Na druhou stranu Snowflake má nativní formát. Aktuálně je také trend „open data“ formátů, kdy Databricks používá Delta, Snowflake zase Iceberg. Ale to je spíš potenciál do budoucna, teď to ještě není úplně zralé.

Je otázka, kam se vyvinou open data a integrace mezi systémy. Síla Snowflake je v jeho nativním formátu, kdežto Databricks nabízí více možností doladění. Je ale otázka, zda je to výhoda nebo nevýhoda – záleží na tom, jaký mám uživatele. Pokud mám zkušeného experta, s Databricks to dokáže nastavit perfektně. Pokud mám méně zkušené uživatele, může to být spíš komplikace.

A co migrace? Jak to bude fungovat, to je také klíčové kritérium. Předpokládám, že je důležité to dobře načasovat, a také zjistit, jak nám s tím pomáhají jednotlivé platformy a nástroje. Otázka je, jestli přeladíme data z jednoho systému do druhého během půl roku, nebo třeba za tři.

Pokud potřebuješ, můžu text ještě pružně upravit podle konkrétního zaměření nebo stylu.

Opravený text:

Formy s tou migrací jsou hodně podobné, ta pomoc s migrací je podobná. Snowflake má pravděpodobně navíc nějaký migrační nástroj, teď si přesně nevzpomínám, jak se to jmenuje, ale je to tool, který to dokáže o něco lépe usnadnit oproti Databricks. Přesto bych to viděl jako hodně srovnatelné, migrace bude podobná. Takže je to jedno, nebude to žádný velký rozdíl. Pokud to máme rychle doručit, je to v podstatě srovnatelné.

Co se týče časového harmonogramu, tak si to samozřejmě rozdělíme - nejdřív chceme migrovat ODS a teprve pak přejít na návazné systémy. Je to i z toho důvodu, že na ODS můžeme věci dobře otestovat, protože je to nejmenší část celého systému a můžeme tam případně zaznamenat nějaké problémy. Zároveň pořád není jasné, jestli to vůbec budeme dělat, protože záleží také na cloudové strategii firmy.

To byla moje další otázka - nyní jedete hodně on-prem. Tyto platformy budou pravděpodobně mít nějaké on-prem řešení, ale veškerý rozvoj, první nové funkce a tlak bude na cloud. Jak tohle vstupuje do rozhodování?

Tohle do toho velmi výrazně vstupuje. Je možné, že cloudová strategie bude nakonec mít zásadní vliv na výběr platformy. Z BI pohledu jsme tady možná řekli, že by nám Snowflake přišel o něco lepší, ale jsou zde i další faktory, které hrají roli. Především právě ta cloudová strategie, protože nevíme, jak bude vypadat situace za pár let. Řešíme i možnosti migrace mezi jednotlivými cloudy, zvažujeme, zda zůstat v Azure, nebo nakročit k AWS či Google Cloud. Tohle jsou stále otevřené a živé otázky, na které nedokážu úplně jednoznačně odpovědět. Ale cloudová strategie bude pravděpodobně hrát klíčovou roli.

Další věc je... A omlouvám se, mohu se zeptat, pokud byste zůstali on-prem a přesto zvolili jednu z těchto platforem, dává to smysl? Do jaké míry budou ty platformy funkční on-prem?

Plnohodnotný produkt je co – Databricks on-prem? Nebo Snowflake on-prem? To jsme popravdě vůbec nesplnili. Myslím si, že pokud zvolíme Databricks, či Snowflake, tak určitě chceme cloudovou variantu, tedy 100% cloud. To by znamenalo velkou změnu i pro vás, protože držet 40 terabajtů na vlastním hardware je něco jiného, než držet data ve storage v cloudu, kde za to platíte mnohem více.

Ano, cloudové storage ceny vycházejí většinou poměrně dobře, spíš problém je podle mě v compute, zatímco storage vychází lépe cenově. Sice teď máme data u sebe, ale i za to platíme, a platíme za nevyužitý výkon. Od cloudu si slibujeme, že v špičkách si můžeme připlatit za vyšší výkon a naopak se můžeme v době menší potřeby škálovat dolů. To je asi ta hlavní výhoda.

Další věc je, že musíme obhájit rozpočet a mít k dispozici zdroje, což je jedna z hlavních věcí vedle strategie cloudové a finančních aspektů, které ovlivní konečné rozhodnutí. Dále jsme také zkoušeli orchestrace nástroje, kr... (text nedokončený).

Jasně, tady je opravený text:

Omě těch datových platform jako takových. A teď konkrétně mluvím o tom, že jsme zkoušeli dbt a SQL Mesh, což jsou nástroje, které by měly nějakým způsobem orchestrat ETL procesy a všechno, co se vlastně v těch platformách bude dít. Což je vlastně pro můj tým daleko zásadnější než to, kde to vlastně bude sedět, z které platformy, protože v tomhle se budou vyvíjet ETL procesy, různé transformace a podobně.

Takže jsme si zkoušeli dbt a momentálně zkoušíme SQL Mesh. Dbt na mě asi působí tak, že je momentálně na trhu asi největším hráčem v tomhle směru, což je takový "vau" efekt. Ale v poslední době mi přijde, že SQL Mesh ho poměrně dohání. Oba mají cloudovou variantu a core variantu, kterou hostuješ sám někde na svém železe.

A došli jsme k tomu, že rozhodně nepůjdeme do té cloudové varianty, protože je na nás jako strašně drahá, alespoň tady v Česku. Na to, jak tady jsme, by to byl finanční overkill. To je zajímavé. Pro mě jsou to takové malé nástroje – malé nástroje, velká pomoc.

Na druhou stranu pořád říkám, že podobné nástroje budou ve stejné kvalitě přímo v Databricks nebo jiné platformě, protože jsou tak blízko, že se divím, že je ještě nepožrali. Já se taky divím, že to jsou pořád oddělené světy. Databricks i Snowflake mají nějaké svoje schedulovací věci, ale tohle je o úroveň jinde, tyhle nástroje.

A docela se divím, že někdo už něco z nich nekoupil. Cloudová varianta je bohužel fakt drahá, tam se platí za jednotlivé zdroje na měsíc a jsou to poměrně vysoké částky. Takže pravděpodobně, ať už jedno nebo druhé, půjdeme do té core varianty, kterou si budeme hostovat sami na nějaké virtuální mašině nebo kdekoli jinde. Uvidíme ještě, kde – zatím zkoušíme.

Kromě dbtčka zkoušíme i SQL Mesh, protože nám přišlo, že z designu dbt už trochu dochází dech a že SQL Mesh by mohl být trošku lepší. Je sice poměrně nový, ale funguje podobně jako dbt, je v podstatě jeho klon, jsou fakt strašně podobné. SQL Mesh vychází celý z open source, je tam do toho víc vidět, a přijde nám, že by ho možná i mohl za pár let předběhnout. Ale nikdy nevíme, co bude za pár let.

Z mého lidského pohledu přineslo dbt velikou kulturní změnu, revoluci v tom, jak se díváme na celý ten systém. Teď bych ale měl obavu, že platím za jméno, konferenci, komunitu a hezké věci kolem, a za platformizaci, protože aby rostli dál, potřebují zvyšovat počet funkcí. Možná ty core funkce někde jinde najdu ve stejné kvalitě a méně zabalené do prémiového pricingu. Ale na druhou stranu jsem to nikdy nezkusil, takže je to spíš moje domněnka.

Myslím si, že to tam je, ale zároveň jak se SQL Mesh dohání s dbt, tak si myslím, že ten náskok nebude tak velký. Zdá se, že na to docela šlapou a přijde mi, že se tam rozhoří docela konkurenční boj, který asi nepůjde úplně dlouho bez dalších změn.

Pokud chceš, můžu ještě upravit styl nebo zkrátit text.

Zde je opravený a stylisticky upravený text:

Dejte si pozor, aby to nebylo až takhle vyšponované. Pokud nás poslouchá někdo z velké datové platformy, cloudu nebo hyperscalera, doporučujeme koupit SQL Mesh – tady Honza. A nezdražujte nám to potom, prosím! Oni to totiž dají zadarmo do té platformy, do Fabriku. Bude to součástí Fabriku a nebude se to dát používat samostatně, což je podle mě nejpravděpodobnější varianta.

Mám pocit, že jsme prošli všechno. Je to super zajímavé a není to nějaký server ve sklepě, který běží a nesáhne se na něj. Kolik práce s tím máte? Dost mě baví, že mluvíte nejen s analytiky, ale i s byznysem – jak je to zapojené do těch procesů. Jsem ti moc vděčný, že jsi dal deep dive do těch konkrétních věcí, kde už se třeba ztrácím – jako column store, indexy a podobně.

Jsem hrozně zvědavý, co se stane s tou novou platformou, protože to je velký zásah a velká změna. Za ten rok a něco, co jsi s tím strávil, co jsou tvoje lessons learned? A co bys na závěr chtěl předat dál? Nebo je něco, co jsme neřekli, a co bys chtěl ještě vypíchnout?

Já bych asi zopakoval to, co jsme zmiňovali – nedávat do produkce kazdové (chyby). Přesně, pokud si z dnešního dílu vezmete jednu věc, tak ať nedáváte kazdové – protože Honza si vás najde. A použije na vás svoji sadu speciálních schopností, pokud jde o vývoj ve Warehouse.

Měl bych ještě jednu podobnou radu – nenasazovat v pátek. U nás už jsme na to vytrénovaní, že se to nedělá. Data samozřejmě chodí o víkendech, takže máme jednoho člověka v on callu i o víkendu. Když někdo nasadí v pátek, tak ten pak v sobotu ráno prožívá peklo. Většinou to bývá jen takové přejmenování, ale i to má často velký dopad.

Takže to je ještě jedna věc, kterou bych rád zmínil – nikdy nenasadit v pátek! To je univerzální pravidlo. Platilo to i ve staropravěku a není to ani dáno tím, že o víkendu někdo nepracuje. Je to prostě obecné pravidlo. U nás jsme na to docela vytrénovaní, ale protože máme hodně dodavatelů, někdo z nich to občas přesto nasadí v pátek, nebo i někdo z jiného oddělení. Tohle většinou nedělá dobrotu.

Co bych ještě zmínil, tak při těch větších změnách buďte opatrní. Kolik jsme se tu bavili o těch column store indexech – možná bych jich dělal méně najednou a opatrněji.

Ještě jednu věc tady mám, co jsme si letos otestovali – zkoušeli jsme optimalizace přes přesun dat do různých filegroupů na disku, tedy rozdělení databázových souborů. A došli jsme k tomu, že je to moc práce a je náročné to naplánovat, pak to správně udělat a časově to dělání taky trvá. Za ten efekt to podle nás nestojí a ani nám to moc nepřineslo.

To mě nepřekvapuje, nejsme Google. Moje oblíbená historka je, že Google šel úplně do detailu, jak zapisují data na fyzická úložiště, a až tam přišli na to, jak to správně optimalizovat. Takže to už je asi fixt.

Pokud chceš, mohu to ještě více upravit nebo rozčlenit do odstavců podle potřeby.

Jasně, tady je opravený text s lepší skladbou a interpunkcí:

Už můžeš abstrahovat asi tuto vrstvu, nebo máš pocit, že ještě jsou momenty, kdy dává smysl sahat do fyzické vrstvy, ne do abstrahované? V cloudu určitě ne. Na on-premisu jsme ale věděli, že to tam není úplně ideální — soubory tam rostou trochu náhodně a chtělo by to to nějak kočírovat, ale nestálo to za to.

No, já ti moc přeju, abyste si vybrali nějakou platformu a diskové pole a ukládání si nemuseli řešit. Děkuju, že jsi dneska sdílel svoje know-how a zkušenosti a že jsi nás pustil mnohem hlouběji do architektury, do vrstvy, kam se tak často v DataTalku nepodíváme, tak za to díky.

Doporučuji sledovat Sasku na LinkedInu — hrozně mě baví, jak mluví o datech a jaký obsah tam děláte. Umíte to udělat s nadhledem, zároveň nebanalizujete, a párkrát jsem se přistihl, že opravdu vysvětlujete velmi složité věci velmi přístupnou formou pro kohokoliv, i pro juniory.

Celkově mám Sasku a BI u vás moc rád, protože jste super banda a bavíte mě. Děkuju, že jsi tady dneska byl, a těším se, až se někde potkáme.

Díky, že jsem tu mohl být. Potkáme se asi na nějakém datameshi, možná na Data Day, pokud bude, a pak taky na VŠE na Data Festivalu. Tak snad se tam potkáme i s vámi.

Děkujeme, že posloucháte, a nechť vás provází data!

Děkujeme, že jste doposlouchali až sem, a díky také našim partnerům, členům DataTalk klubu — Intex, Saska, Bistreet, Colors of Data, Revolt BI, GoodData, Keboola, Emark, Carl Data Company, Datamind, Notino a Flo.

Pokud chcete zůstat v obraze, co se týče české datové scény a globálních datových technologií, nezapomeňte se registrovat k odběru našeho týdenního newsletteru na datatalk.cz.

Nechť vás provází data!

Pokud chceš, mohu text ještě víc zjednodušit nebo upravit styl.