Data Mesh: kuidas töötada andmetega ilma monoliidita

Tere, Habr! Dodo Pizza Engineeringis armastame andmeid (kes ei armasta?). Nüüd räägime loo sellest, kuidas koguda kokku kõik Dodo Pizza andmed ja anda igale töötajale mugav juurdepääs sellele andmemassiivile. Ülesanne tähtsusega: hoida Data Engineeringi meeskonna närve.

Meie, nagu tõelised Pliushkinid, kogume erinevat teavet meie pitsarestoranide kohta:

• mäletame kõiki kasutajate tellimusi;
• teame, kui kaua kulus esimesest pizzast valmistamiseks Syktyvkaris;
• näeme, kui kaua pitsad jahtuvad soojendushyllal Voronežis praegu;
• salvestame andmed toidukaupade mahakandmise kohta;
• ja palju muud.

Dodo Pizzas vastutab andmete haldamise eest mitmed meeskonnad, üks neist on Data Engineeringi meeskond. Praegu seisame silmitsi ülesandega: anda igale töötajale mugav juurdepääs sellele andmemassiivile.

Kui hakkasime mõtlema, kuidas seda teha ja arutasime ülesannet, leidsime väga huvitava lähenemise andmehaldusele - Data Mesh (link viib suurepärase artiklini). Selle ideed sobisid suurepäraselt meie ettekujutusega, kuidas soovime oma süsteemi üles ehitada. Edasi artiklis jagame meie uuendatud lähenemist ja seda, kuidas näeme selle rakendamist Dodo Pizza Engineeringis.

Mida mõtleme «andmete» all

Esiteks, määratleme, mida mõistame andmete all Dodo Pizza Engineeringis:

• Sündmused, mida teenused saadavad (meil on üldine andmebuss, mis on üles ehitatud RabbitMQ abil);
• Kirjed andmebaasis (meie jaoks on need MySQL ja CosmosDB);
• Klõpsu jälgimine mobiilirakendusest ja veebisaidilt.

Kuna Dodo Pizza ettevõte peab neid andmeid kasutama ja neile toetuma, on oluline, et järgida järgmisi tingimusi:

• Need peavad olema terviklikud. Peame olema kindlad, et ei muuda andmeid nende töötlemise, salvestamise ja kuvamise käigus. Kui ettevõte ei saa meie andmetele toetuda, ei ole nendest mingit kasu.
• Need peavad olema ajamärgistatud ja mitte kustutatavad. See tähendab, et soovime igal ajal tagasi minna ja vaadata andmeid teatud ajavahemiku kohta. Näiteks teada, kui palju pitsasid müüdi 8. juulil 2018.
• Need peavad olema usaldusväärsed. Andmete kogumise ja salvestamise protsessis peame säilitama mitte ainult terviklikkuse, vaid ka usaldusväärsuse. Me ei tohi kaotada andmeid, ajaklippe, sest koos nendega kaotame oma klientide (nii sisemiste kui ka välimiste) usalduse.
• Need peavad olema stabiilse struktuuriga – me kirjutame päringud nendele andmetele. Me ei sooviks, et rakenduskoodi muutumise, refaktoreerimise käigus need muutuksid nii palju, et meie päringud lakkavad töötamast. See, kes kirjutab päringud, ei saa kunagi teada, et olete teinud refaktoreerimise, kuni kõik on täielikult katki. Me ei tahaks seda klientidelt teada saada.

Arvestades nende nõuete kõiki, jõudsime järeldusele, et andmed Dodo's on toode. Sama nagu teenuse avalik API. Seega peab andmeid haldama sama meeskond, kes haldab teenust. Samuti peavad andmeskeemi muudatused olema alati tagasipöördumisega ühilduvad.

Traditsiooniline lähenemine – Andmejärv

Suurte andmete usaldusväärseks salvestamiseks ja töötlemiseks on olemas traditsiooniline lähenemine, mida paljud ettevõtted, kes töötavad sellise teabega, järgivad – Andmejärv. Selle lähenemisviisi raames koguvad andmeinsenerid teavet kõigist süsteemi komponentidest ja koguvad selle ühte suure hulka (näiteks võib see olla Hadoop, Azure Kusto, Apache Cassandra või isegi MySQL replikatsioon, kui andmed sinna mahuvad).

Edasi kirjutavad samad insenerid päringud sellele ladustamisele. Dodo Pizza Engineeringu rakendamine eeldab, et Data Engineeringi meeskond haldab analüütilise ladustamise andmeskeemi.

Sellise arengu korral muutub meeskond väga kurvaks, ja siin on, miks:

• Neil tuleb jälgida muutusi kõigis TEENUSTES ettevõttes. Ja neid on palju ning muudatusi on ka palju (keskmiselt sulandame ~100 pull request'i nädalas, samas kui paljud teenused ei tee pull request'e üldse).
• Andmeskeemi muutmisel peavad tootmise omanik ja meeskond, kes andmeskeemi muudetakse, ootama, kuni Data Engineering kirjutab koodi, mis on vajalik muudatuste toetamiseks. Olukord, kus üks meeskond ootab teist, on meil juba ammu olemas ja see, et see muutub „normaalseks” osaks arendusprotsessist, ei ole soovitav.
• Neil peab olema arusaam KOGU ettevõtte äri kohta. Pitsarestoranide ketti võib pidada lihtsaks äriharuks, kuid see on vaid väline mulje. Väga keeruline on koguda ühte meeskonda piisavalt pädevusi, et luua kogu ettevõtte jaoks adekvaatne andmemudel.
• See on ainus tõrkeallikas. Iga kord, kui on vaja muudatusi teha teenuse tagastatavates andmetes või kirjutada päring, langevad kõik need ülesanded andmeinseneride meeskonna õlgadele. Selle tulemusena on meeskond ülekoormatud backlog'iga.

Kasutatakse, et meeskond asub tohutu vajaduste ristumiskohas ja tõenäoliselt ei suuda neid kõiki rahuldada. Samuti on nad pidevas ajapuuduses ja stressis. Me ei sooviks seda. Seega peame mõtlema, kuidas neid probleeme lahendada ja samas võimaldada andmete analüüsi.

Liikudes Data Lake'ist Data Mesh'i

Õnneks pole me selle küsimuse esitanud üksnes meie. Tõepoolest, sarnane probleem on tööstuses juba lahendatud (alleluuja!). Ainult teises valdkonnas: rakenduste juurutamises. Jah, räägin DevOps'i lähenemisest, kus meeskond määrab, kuidas toota oma loodud toodet.

Sarnast lähenemist Data Lake'i probleemide lahendamiseks pakkus Zhamak Dehghani, ThoughtWorksi konsultant. Vaadates, kuidas sarnaseid ülesandeid lahendavad Netflix ja Spotify, kirjutas ta suurepärase artikli How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh(link sellele oli artikli alguses). Peamised ideed, mida me sellest välja tõime:

• Jagada suur Data Lake andme domeenideks, mis sarnanevad domeenide ülesehitusele. Iga domeen on väike bounded context.
• Feature Team'id, mis vastutavad DDD domeenide eest, vastutavad ka vastavate andme domeenide eest. Nad haldavad skeemi, teevad selles muudatusi, laadivad andmeid. Samuti teavad nad, kuidas andmete laadimist muuta ilma, et rakendus puruneks. Teadmised ei kao kuhugi. Andmete avamiseks ei pea nad kuhugi minema. Meeskond juhib kogu arendusprotsessi operatiivsete andmete muutmisest kuni analüütiliste andmete esitamiseni teistele osapooltele. Üks meeskond haldab kõike, mis seondub domeeniga (nii äri domeeni kui ka andme domeeni).
• Data Engineer – roll Feature Team'is. See ei pea olema tingimata eraldi isik, kuid meeskonnal peab olema see oskus.

Ja samal ajal töötab Data Engineering'i meeskond...

Kui kujutame ette, et kõik see teostatakse sõrmenipsuga, jääb vastata kahele küsimusele:

Millega hakkab nüüd tegelema Data Engineering'i meeskond? Dodo Pizza Engineering'is on juba platvormi/SRE meeskond. Nende ülesanne on pakkuda arendajatele tööriistu teenuste lihtsaks juurutamiseks. Data Engineering'i meeskond täidab sama rolli, vaid andmete jaoks.

Operatiivsete andmete muutmine analüütilisteks on keeruline protsess. Muuta analüütilised andmed kergesti kättesaadavaks kogu ettevõttele on veelgi keerulisem. Just nende probleemide lahendamisega tegeleb Data Engineering'i meeskond.

Kavatseme anda Feature Team'ile mugava tööriistade ja praktikate komplekti, millega nad saavad oma teenusest andmeid kogu ettevõttele avaldada. Samuti vastutame andmeprotsessi (järjekorrad, usaldusväärne salvestus, klastrid andmete töötlemiseks) üldiste infrastruktuuri osade eest.

Kuidas saavad Data Engineer'i oskused ilmuda Feature Team'is? Feature Team'iga on keerulisem. Loomulikult võiksime proovida värbata igaühte meie tiimidesse Data Engineer'iks. Kuid see on väga keeruline. Leida inimene, kellel on hea andmete töötlemise taust, ja veenda teda töötama toote meeskonnas on raske.

Dodo suur eelis on see, et me armastame sisemist koolitust. Nii et meie plaan on selline: Data Engineering'i meeskond alustab teatud teenuste andmete avaldamist, nutses, astudes, kuid jätkab kaktuse neelamist. Kui me saame aru, et meil on avaldamiseks valmis protsess, hakkame sellest rääkima Feature Team'ile.

Meil on mitmeid viise, kuidas seda teha:

1. DevForum, kus räägime, kuidas välja näeb protsess, mille me oleme loonud, millised on tööriistad ja kuidas neid kõige efektiivsemalt kasutada.
2. Esinemine DevForum'il aitab meil koguda tagasisidet tootearendajatelt. Pärast seda saame liituda tootemeeskondadega ja aidata neil andmete avaldamisega seotud probleeme lahendada, korraldada meeskondadele koolitusi.

Andmete tarbimine

Olen praegu palju rääkinud andmete avaldamisest. Kuid on ka andmete tarbimine. Mis on selle kohta?

Meil on suurepärane BI meeskond, kes kirjutab juhtivale ettevõttele väga keerulisi aruandeid. Dodo IS sees on palju aruandeid meie partneritele, mis aitavad neil pizzeriaid juhtida. Meie uues mudelis mõtleme neile kui andmete tarbijatele, kellel on oma andmevaldkonnad. Ja just tarbijad vastutavad oma valdkondade eest. Mõnikord võib tarbija domeen olla kirjeldatud ühe päringuga analüütika andmelaos – ja see on hea. Kuid mõistame, et see ei pruugi alati toimida. Just seetõttu soovime, et platvorm, mille loome toote meeskondadele, võiks kasutada ka andmete tarbijad (sest Dodo IS aruannete puhul on need samad meeskonnad).

Nii näeme me andmetega töötamist Dodo Pizza Engineeringus. Ootame huviga teie mõtteid selle kohta kommentaarides.

Allikas: habr.com