Data Mesh: kuidas töötada andmetega ilma monoliidita

Tere, Habr! Meie Dodo Pizza Engineeringus armastame andmeid (kes tänapäeval ei armastaks?). See on meie lugu sellest, kuidas koguda kõik Dodo Pizza maailma andmed ja anda igale töötajale lihtne juurdepääs sellele tohutule andmekogumile. Eesmärk on hoida andmetehnika meeskond valvel.

Nagu tõelised Pljuškinid ikka, kogume ka meie igasugust teavet oma pitsarestoranide tegevuse kohta:

• Me mäletame kõiki kasutajate korraldusi;
• me teame, kui kaua aega kulus kõige esimese pitsa valmistamiseks Sõktõvkaris;
• Me näeme, kui kaua aega võtab pitsa jahtumine Voronežis soojendusriiulil praegu;
• Me säilitame andmeid toodete mahakandmiste kohta;
• ja paljud paljud teised.

Dodo Pizzas vastutab andmetega töötamise eest praegu mitu meeskonda, millest üks on andmetehnika meeskond. Nende (st meie) praegune ülesanne on pakkuda igale ettevõtte töötajale mugavat juurdepääsu sellele tohutule andmekogumile.

Kui hakkasime mõtlema, kuidas seda teha, ja probleemi arutama, leidsime väga huvitava lähenemisviisi andmehaldusele – Andmevõrk (Lingilt leiate suurepärase ja mahuka artikli.) Tema ideed kõlasid väga hästi meie nägemusega sellest, kuidas me tahame oma süsteemi üles ehitada. Artikli ülejäänud osas uurime meie selle lähenemisviisi ümbermõtestamist ja seda, kuidas me näeme selle rakendamist Dodo Pizza Engineeringus.

Mida me "andmete" all mõtleme?

Kõigepealt defineerime, mida me Dodo Pizza Engineeringus andmete all mõtleme:

• Teenuste saadetud sündmused (meil on RabbitMQ abil ehitatud ühine siin);
• Andmebaasis olevad kirjed (meie puhul on need MySQL ja CosmosDB);
• Klõpsuvoog mobiilirakendusest ja veebisaidilt.

Selleks, et Dodo Pizza saaks neid andmeid kasutada ja neile tugineda, on oluline, et oleksid täidetud järgmised tingimused:

• Need peavad olema lahutamatud. Peame olema kindlad, et me ei muuda andmeid töötlemise, salvestamise ja kuvamise ajal. Kui ettevõtted ei saa meie andmeid usaldada, pole neist mingit kasu.
• Need peavad olema ajatempliga ja neid ei tohi üle kirjutada. See tähendab, et me tahame igal ajahetkel saada tagasiulatuvaid andmeid ja vaadata selle perioodi andmeid. Näiteks selleks, et teada saada, kui palju pitsasid müüdi 8. juulil 2018.
• Nad peavad olema usaldusväärsed. Andmete kogumisel ja säilitamisel peame säilitama mitte ainult terviklikkuse, vaid ka usaldusväärsuse. Me ei tohi kaotada andmeid ega ajalõike, sest nendega kaotame oma klientide (nii väliste kui ka sisemiste) usalduse.
• Neil peab olema stabiilne skeem – me kirjutame nende andmete jaoks päringuid. Meile ei meeldiks, kui ümbertöödeldud rakendus muudaks koodi nii palju, et päringud lakkaksid töötamast. Päringute kirjutaja ei saa enne täielikku lagunemist teada, et rakendus on ümbertöödeldud. Me ei tahaks oma klientidelt sellest kuulda.

Kõiki neid nõudeid arvesse võttes jõudsime järeldusele, et Dodo andmed on toode, nagu ka teenuse avalik API. Seega peaksid andmed kuuluma samale meeskonnale, kellele kuulub teenus. Samuti peaksid andmeskeemi muudatused alati olema tagasiühilduvad.

Traditsiooniline lähenemine – andmejärv

Suurandmete usaldusväärse salvestamise ja töötlemise probleemi lahendamiseks on paljude selliste teabekogumitega töötavate ettevõtete traditsiooniline lähenemisviis andmejärv (Data Lake). Selle lähenemisviisi puhul koguvad andmeinsenerid teavet kõigilt süsteemikomponentidelt ja salvestavad selle ühte suurde salvestusruumi (näiteks Hadoop, Azure Kusto, Apache Cassandra või isegi MySQL-i koopia, kui andmed sobivad).

Seejärel kirjutavad needsamad insenerid päringuid sellele andmelaole. Selle lähenemisviisi rakendamine Dodo Pizza Engineeringus tähendab, et andmetehnika meeskond omab analüütilise andmelao andmeskeemi.

Selles stsenaariumis muutuvad meeskonnad väga kurbadeks kassideks ja siin on põhjus, miks:

• Ta peab jälgima muutusi KÕIK ettevõttesisesed teenused. Ja neid on palju ning toimub palju muudatusi (keskmiselt ühendame ~100 pull requesti nädalas, samas kui paljud teenused ei tee üldse ühtegi pull requesti).
• Alati, kui andmeskeem muutub, peavad tooteomanik ja andmeskeemi muutev meeskond ootama, kuni andmetehnika kirjutab muudatuste toetamiseks vajaliku koodi. Oleme pikka aega olnud funktsioonikesksed ja olukord, kus üks meeskond ootab teist, on väga haruldane. Me ei taha, et sellest saaks arendusprotsessi "normaalne" osa.
• Ta peab olema sukeldunud KÕIK Ettevõtte äritegevus. Pitsarestoran tundub lihtsa ettevõttena, kuid see on vaid pealtnäha nii. On väga raske ühte meeskonda koondada piisavalt kompetentse, et luua kogu ettevõtte jaoks piisav andmemudel.
• See on ühekordne rike. Iga kord, kui teenuse tagastatud andmeid on vaja muuta või päringut kirjutada, langevad kõik need ülesanded andmetehnika meeskonna kanda. Selle tulemusel on meeskonnal ülekoormatud töömaht.

Selgub, et meeskond seisab silmitsi tohutu hulga vajadustega ja tõenäoliselt ei suuda neid kõiki rahuldada. Samal ajal on nad pideva ajalise surve ja stressi all. Me tõesti ei taha seda. Seetõttu peame mõtlema, kuidas neid probleeme lahendada, säilitades samal ajal andmete analüüsimise võimaluse.

Andmejärvest andmevõrku liikumine

Õnneks polnud me ainsad, kes seda küsimust esitasid. Tegelikult on sarnane probleem selles valdkonnas juba lahendatud (halleluuja!). Lihtsalt teises valdkonnas: rakenduste juurutamine. Jah, ma räägin DevOps-lähenemisest, kus meeskond määrab, kuidas toodet, mida nad loovad, juurutada.

Sarnase lähenemisviisi andmejärve probleemide lahendamiseks pakkus välja ThoughtWorksi konsultant Zhamak Dehghani. Pärast seda, kui ta oli vaadanud, kuidas Netflix ja Spotify sarnaste probleemidega toime tulid, kirjutas ta põneva artikli. Kuidas liikuda monoliitsest andmejärvest hajutatud andmevõrguni(Link sellele oli artikli alguses). Peamised ideed, mida me sealt õppisime:

• Jaga suur andmejärv andmevaldkondadeks, mis on väga sarnased valdkonnapõhiste disainivaldkondadega. Iga valdkond on väike, piiratud kontekst.
• DDD-domeenide eest vastutav funktsioonide meeskond vastutab ka vastavate andmedomeenide eest. Nad haldavad skeemi, teevad selles muudatusi ja laadivad sinna andmeid. Nad teavad ka kõike ise: kuidas muuta andmete laadimise protsessi ja vältida rikkeid rakenduse muutumisel. See teadmine on alati olemas. Nad ei pea andmetele juurdepääsuks kuhugi minema. Meeskond ise haldab kogu arendustsüklit, alates operatiivandmete muutmisest kuni analüütiliste andmete edastamiseni kolmandatele osapooltele. Üks meeskond omab kõike, mis on seotud valdkonnaga (nii äri- kui ka andmedomeen).
• Andmeinsener on üks roll funktsioonide meeskonnas. See ei pea tingimata olema eraldi inimene, kuid see eeldab meeskonnalt selle pädevuse olemasolu.

Samal ajal andmetehnika meeskond…

Kui kujutame ette, et seda kõike saab ühe sõrmenipsuga teostada, siis jääb veel vastuseta kaks küsimust:

Mida andmetehnika meeskond nüüd teeb? Dodo Pizza Engineeringul on juba platvormi/SRE meeskond. Selle eesmärk on pakkuda arendajatele tööriistu teenuste hõlpsaks juurutamiseks. Andmetehnika meeskond täidab sarnast rolli, aga andmete osas.

Operatiivandmete analüütilisteks andmeteks muutmine on keeruline protsess. Analüütiliste andmete kättesaadavaks tegemine kogu ettevõttele on veelgi keerulisem. Just nende väljakutsetega andmetehnika meeskond tegelebki.

Plaanime pakkuda funktsioonide meeskonnale kasutajasõbraliku tööriistade ja tavade komplekti, mis võimaldab neil avaldada oma teenuse andmeid ülejäänud ettevõttele. Samuti vastutame andmekanali jagatud infrastruktuuri komponentide eest (järjekorrad, usaldusväärne salvestusruum ja klastrid andmete teisendamiseks).

Kuidas andmeinseneri oskused funktsioonimeeskonnas kajastuvad? Funktsioonimeeskond on keerulisem. Muidugi võiksime proovida palgata igale meeskonnale andmeinseneri. Aga see on väga keeruline. Raske on leida kedagi, kellel on tugev andmeteaduse taust, ja veenda teda tootemeeskonnas töötama.

Dodo suur eelis on see, et me armastame sisekoolitust. Seega on meie praegune plaan järgmine: andmetehnika meeskond hakkab avaldama andmeid mõnest teenusest ja samal ajal jätkame proovimist. Kui oleme kindlad, et meil on avaldamiseks valmis protsess, hakkame seda funktsioonide meeskonnaga jagama.

Selleks on meil mitu võimalust:

1. DevFoorum, kus selgitame, milline meie loodud protsess välja näeb, millised tööriistad meil on ja kuidas neid kõige tõhusamalt kasutada.
2. DevForumil esinemine aitab meil tootearendajatelt tagasisidet koguda. Pärast seda saame liituda tootemeeskondadega ja aidata neil lahendada andmete avaldamise probleeme ning korraldada meeskondadele koolitusi.

Andmete tarbimine

Olen palju rääkinud andmete avaldamisest. Aga on ka tarbimine. Kuidas on lood sellega?

Meil on suurepärane BI-meeskond, kes kirjutab haldusfirmale väga keerukaid aruandeid. Dodo IS sisaldab ka palju aruandeid meie partneritele, aidates neil oma pitsabaare hallata. Meie uues mudelis mõtleme neist kui andmetarbijatest, kellel kõigil on oma andmedomeenid. Ja just need tarbijad vastutavad oma domeenide eest. Mõnikord saab tarbijadomeeni kirjeldada ühe päringuga analüütilisele ladule – ja see on okei. Aga me mõistame, et see ei toimi alati. Seetõttu tahame, et tootemeeskondadele loodav platvorm oleks kasutatav ka andmetarbijate jaoks (sest Dodo IS-i aruannete puhul on need samad meeskonnad).

Nii näeme meie Dodo Pizza Engineeringus andmetöötlust. Tahaksime teie mõtteid kommentaarides kuulda.

Allikas: www.habr.com