Ahoj Habr! My v Dodo Pizza Engineering milujeme dáta (kto ich v dnešnej dobe nemiluje?). Teraz bude príbeh o tom, ako zhromaždiť všetky údaje vo svete Dodo Pizza a poskytnúť každému zamestnancovi spoločnosti pohodlný prístup k tomuto súboru údajov. Úloha pod hviezdičkou: udržať nervy tímu Data Engineering.
Ako skutoční Plyushkins zhromažďujeme všetky druhy informácií o práci našich pizzerií:
- zapamätať si všetky užívateľské objednávky;
- vieme, ako dlho trvalo vyrobiť úplne prvú pizzu v Syktyvkare;
- vidíme, ako dlho trvá, kým pizza vychladne na ohrievacej polici vo Voroneži práve teraz;
- Ukladáme údaje o odpisoch produktov;
- a mnoho mnoho ďalších.
Za prácu s údajmi v Dodo Pizza je teraz zodpovedných niekoľko tímov, jedným z nich je tím Data Engineering. Teraz oni (teda my) stoja pred úlohou poskytnúť každému zamestnancovi spoločnosti pohodlný prístup k tomuto množstvu údajov.
Keď sme začali premýšľať o tom, ako to urobiť, a začali sme diskutovať o probléme, našli sme veľmi zaujímavý prístup k správe údajov - (po kliknutí na odkaz nájdete obrovský, úžasný článok). Jej nápady veľmi dobre zapadajú do našej predstavy o tom, ako chceme vybudovať náš systém. Ďalej v článku bude naše prehodnotenie prístupu a ako vidíme jeho implementáciu v Dodo Pizza Engineering.
Čo rozumieme pod pojmom "údaje"
Najprv definujme, čo rozumieme pod údajmi v Dodo Pizza Engineering:
- Udalosti odosielané službami (máme spoločnú zbernicu postavenú pomocou RabbitMQ);
- Záznamy v databáze (pre nás je to MySQL a CosmosDB);
- Clickstream z mobilnej aplikácie a webovej stránky.
Aby spoločnosť Dodo Pizza mohla tieto údaje používať a spoľahnúť sa na ne, je dôležité, aby boli splnené nasledujúce podmienky:
- Musia byť úplné. Musíme si byť istí, že údaje nemeníme, kým sa spracúvajú, ukladajú a zobrazujú. Ak podniky nemôžu dôverovať našim údajom, nebude im to k ničomu.
- Musia mať časovú pečiatku a nesmú byť prepísané. To znamená, že kedykoľvek chceme byť schopní vrátiť sa späť a pozrieť sa na údaje z daného časového obdobia. Zistite napríklad, koľko pízz sa predalo 8. júla 2018.
- Musia byť spoľahlivé. V procese zhromažďovania a uchovávania údajov nesmieme stratiť len integritu, ale ani spoľahlivosť. Nemôžeme prísť o dáta, časové úseky, pretože spolu s nimi strácame dôveru našich klientov (externých aj interných).
- Musia byť so stabilným obvodom - na tieto údaje zapisujeme požiadavky. Naozaj by sme neboli radi, keby sa to zmenami v kóde aplikácie, refaktoringami zmenilo natoľko, že naše dotazy prestanú fungovať. Osoba, ktorá píše otázky, sa nikdy nedozvie, že ste vykonali refaktoring, kým sa všetko nepokazí. Nechcel by som o tom počuť od klientov.
Vzhľadom na všetky tieto požiadavky sme dospeli k záveru, že údaje v Dodo sú produktom. Rovnaké ako verejné API služby. Podľa toho by mal údaje vlastniť ten istý tím, ktorý vlastní službu. Zmeny v schéme údajov musia byť tiež vždy spätne kompatibilné.
Tradičný prístup – Data Lake
Na riešenie problémov spoľahlivého ukladania a spracovania veľkých dát existuje v mnohých spoločnostiach, ktoré pracujú s takýmto zdrojom informácií, tradičný prístup – Data Lake. V rámci tohto prístupu dátoví inžinieri zbierajú informácie zo všetkých komponentov systému a ukladajú ich do jedného veľkého úložiska (môže to byť napríklad Hadoop, Azure Kusto, Apache Cassandra alebo dokonca replika MySQL, ak sa dáta zmestia do to).
Potom tí istí inžinieri zapisujú požiadavky do takéhoto úložiska. Implementácia tohto prístupu v Dodo Pizza Engineering znamená, že tím Data Engineering bude vlastniť dátovú schému v analytickom sklade.
V tomto scenári sa tím stáva veľmi smutnými mačkami a tu je dôvod:
- Musí sledovať zmeny VŠETKY služby v rámci spoločnosti. A je ich veľa a veľa zmien (v priemere zlúčime ~ 100 žiadostí o stiahnutie za týždeň, zatiaľ čo mnohé služby nedávajú žiadosti o stiahnutie vôbec).
- Pri zmene dátovej schémy musí produktový vlastník a tím meniaci dátovú schému počkať, kým dátové inžinierstvo pridá kód potrebný na podporu zmien. Zároveň sme už dlho bohatí na funkcie a situácia, keď jeden tím čaká na druhý, je veľmi zriedkavá. A nechceme, aby sa to stalo „normálnou“ súčasťou vývojového procesu.
- Musí byť ponorený CELÝ podnikania spoločnosti. Sieť pizzerií vyzerá ako jednoduchý podnik, no len sa tak zdá. Je veľmi náročné nazbierať v jednom tíme dostatok kompetencií na vybudovanie adekvátneho dátového modelu pre celú spoločnosť.
- Je to jediný bod zlyhania. Zakaždým, keď potrebujete zmeniť údaje vrátené službou alebo napísať požiadavku, všetky tieto úlohy spadajú do tímu Data Engineering. V dôsledku toho má tím preťažené nevybavené veci.
Ukazuje sa, že tím je na priesečníku obrovského množstva potrieb a je nepravdepodobné, že by ich dokázal uspokojiť. Zároveň budete pod neustálym časovým tlakom a stresom. Toto naozaj nechceme. Preto musíme myslieť na to, ako tieto problémy vyriešiť a zároveň vedieť analyzovať dáta.
Prechod z Data Lake do Data Mesh
Našťastie sme si túto otázku nekládli len my. V skutočnosti sa podobný problém už v priemysle riešil (aleluja!). Len v inej oblasti: nasadzovanie aplikácií. Áno, hovorím o prístupe DevOps, kde tím určuje spôsob nasadenia produktu, ktorý vytvorí.
Podobný prístup k riešeniu problémov Data Lake navrhol Zhamak Dehghani, konzultant ThoughtWorks. Keď sledovala, ako Netflix a Spotify riešia podobné problémy, napísala úžasný článok (odkaz naň bol na začiatku článku). Hlavné myšlienky, ktoré sme si z toho odniesli:
- Rozdeľte veľké Data Lake na dátové domény, ktoré sú veľmi podobné doménovým doménam dizajnu. Každá doména je malý ohraničený kontext.
- Tímy funkcií, ktoré sú zodpovedné za domény DDD, sú tiež zodpovedné za príslušné dátové domény. Schému ukladajú, robia v nej zmeny a načítavajú do nej údaje. Zároveň vedia všetko: ako zmeniť načítanie údajov a nič nepokaziť pri zmene aplikácie. Vedomosti nezmiznú. Na otvorenie údajov nemusia nikam chodiť. Samotný tím vedie celý vývojový cyklus od zmeny prevádzkových údajov až po poskytovanie analytických údajov tretím stranám. Jeden tím vlastní všetko spojené s doménou (obchodnú doménu aj dátovú doménu).
- Dátový inžinier – rola v tíme funkcií. Nemusí to byť jednotlivec, ale je nevyhnutné, aby tím mal túto kompetenciu.
Medzitým tím dátového inžinierstva...
Ak si predstavujete, že toto všetko sa realizuje lusknutím prstov, potom vám stačí odpovedať na dve otázky:
Čo teraz urobí tím dátového inžinierstva? Dodo Pizza Engineering už má tím platformy/SRE. Jeho cieľom je poskytnúť vývojárom nástroje na jednoduché nasadenie služieb. Tím dátového inžinierstva bude vykonávať rovnakú úlohu iba pre dáta.
Premena prevádzkových údajov na analytické údaje je zložitý proces. Sprístupnenie analytických údajov celej spoločnosti je ešte náročnejšie. Práve týmito problémami sa bude tím Data Engineering zaoberať.
Tímu funkcií poskytneme pohodlnú súpravu nástrojov a postupov, aby mohol publikovať údaje zo svojej služby zvyšku spoločnosti. Budeme tiež zodpovedať za všeobecné časti infraštruktúry dátového potrubia (fronty, spoľahlivé úložiská, klastre na vykonávanie transformácií údajov).
Ako sa zručnosti Data Engineer prejavia v tíme funkcií? S tímom funkcií je všetko komplikovanejšie. Samozrejme, mohli by sme skúsiť najať jedného dátového inžiniera pre každý z našich tímov. Ale je to také ťažké. Nájsť niekoho s dobrým zázemím v oblasti dátovej vedy a presvedčiť ho, aby pracoval v produktovom tíme, je ťažké.
Veľkým plusom Doda je, že milujeme interné tréningy. Takže teraz je náš plán takýto: tím Data Engineering začne zverejňovať údaje z niektorých služieb, plače, vstrekuje si injekcie, ale naďalej jedáva kaktusy. Keď vieme, že máme zavedený proces publikovania, začneme ho komunikovať s tímom funkcií.
Máme na to niekoľko spôsobov:
- , kde vás prevedieme tým, ako vyzerá proces, ktorý sme vytvorili, aké nástroje sú k dispozícii a ako ich najefektívnejšie používať.
- Vystúpenie na DevForum nám pomôže získať spätnú väzbu od vývojárov produktov. Potom sa budeme môcť pripojiť k produktovým tímom a pomáhať im riešiť problémy so zverejňovaním údajov a organizovať pre tímy školenia.
Spotreba dát
Teraz som veľa hovoril o zverejňovaní údajov. Ale je tu aj spotreba. Čo s týmto problémom?
Máme úžasný BI tím, ktorý píše veľmi komplexné reporty pre správcovskú spoločnosť. Vo vnútri Dodo IS je veľa správ pre našich partnerov, ktoré im pomáhajú spravovať ich pizzérie. V našom novom modeli ich považujeme za spotrebiteľov údajov, ktorí majú svoje vlastné dátové domény. A práve spotrebitelia budú zodpovední za svoje domény. Niekedy môže byť doména spotrebiteľa opísaná v jednom dotaze do analytického skladu – a to je dobré. Ale chápeme, že to nebude vždy fungovať. Preto chceme, aby platformu, ktorú vytvoríme pre produktové tímy, mohli využívať aj spotrebitelia dát (napokon, v prípade reportov v rámci Dodo IS pôjde o tie isté tímy).
Takto vidíme prácu s dátami v Dodo Pizza Engineering. Radi si prečítame vaše názory na túto záležitosť v komentároch.
Zdroj: hab.com
