Andmevõrk: kuidas töötada andmetega ilma monoliidita

Tere, Habr! Me Dodo Pizza Engineeringus armastame andmeid (kes neid praegu ei armasta?). Hetkel räägime sellest, kuidas koguda kõik Dodo Pizza andmed ja anda igale töötajale mugav ligipääs sellele andmehulgale. Üks tähtis ülesanne on: hoida Data Engineering meeskonna närvid rahul.

Nagu tõelised Pljuškini, kogume me igasugust infot meie pitsakohvikute kohta:

• me mäletame kõiki kasutajate tellimusi;
• me teame, kui palju aega kulus esimese pitsa valmistamiseks Syktyvkari linnas;
• me näeme, kui kaua pitsa praegu Voronežis jahtub soojendusriiulil;
• me hoiame andmeid toodete arveldamise kohta;
• ja palju-palju muud.

Dodo Pizza andmete haldamisega tegeleb praegu mitu meeskonda, neist üks on Data Engineering meeskond. Praegu seisab meie (ehk siis meie) ees ülesanne: anda igale töötajale mugav ligipääs sellele andmehulgale.

Kui me hakkasime mõtlema, kuidas seda teha, ja arutama ülesannet, leidsime me väga huvitava lähenemise andmete haldamisele - Data Mesh (lingil leiate tohutu suure artikli). Selle ideed sobivad väga hästi meie ettekujutusega sellest, kuidas me tahame oma süsteemi üles ehitada. Edasi artiklis saab lugeda meie ümbermõtestamisest ja sellest, kuidas me näeme selle rakendamist Dodo Pizza Engineeringus.

Mida me mõtleme sõna „andmed” all

Esmalt, laske meil määratleda, mida me mõistame andmete all Dodo Pizza Engineeringus:

• Sündmused, mida teenused saadavad (meil on ühiselt ehitatud buss RabbitMQ abil);
• Kirjed andmebaasis (meie jaoks on see MySQL ja CosmosDB);
• Külastusvoog mobiilirakendusest ja veebisaidilt.

Kuna Dodo Pizza äri saab kasutada neid andmeid ja neile toetuda, on oluline, et oleksid täidetud järgmised tingimused:

• Need peavad olema terviklikud. Peame olema kindlad, et me ei muuda andmeid nende töötlemise, säilitamise ja kuvamise käigus. Kui äri ei saa meie andmetele usaldada, siis ei ole neist mingit kasu.
• Neil peavad olema ajatempli ja nad ei tohi kustutada. See tähendab, et me soovime igal ajal tagasi minna ja vaadata andmeid selle ajaperioodi kohta. Näiteks teada saada, kui palju pitzasid müüdi 8. juulil 2018.
• Need peavad olema usaldusväärsed. Andmete kogumise ja hoidmise protsessis peame säilitama mitte ainult terviklikkuse, vaid ka usaldusväärsuse. Me ei saa kaotada andmeid, ajablokeeringuid, sest koos nendega kaotame meie klientide (nii välistest kui sisemistest) usaldust.
• Need peavad olema stabiilse skeemiga – kirjutame nende andmete jaoks päringud. Me ei tahaks, et rakenduse koodi muutumise või refaktoreerimisega muutuksid need nii, et meie päringud lõpetaksid töötamise. See, kes kirjutab päringud, ei tea kunagi, et te tegite refaktoreerimise, kuni kõik ei lagune täiesti. Ei tahaks seda klientidelt teada saada.

Arvestades kõiki neid nõudeid, jõudsime järeldusele, et Dodo andmed on toode. Samasugune nagu teenuse avalik API. Seega peavad andmetega mahtuma samad inimesed, kes omavad teenust. Samuti peavad andmeskeemi muudatused olema alati tagasipööratavad.

Traditsiooniline lähenemine – Data Lake

Usaldusväärse suure andmete säilitamise ja töötlemise probleemide lahendamiseks on olemas traditsiooniline lähenemine, mida on rakendanud paljud ettevõtted, kes töötavad sellise teabe kogumiga – Data Lake. Selle lähenemise raames koguvad andmeinsenerid teavet kõigist süsteemi komponentidest ja salvestavad selle ühte suurde ladustamisse (see võib olla näiteks Hadoop, Azure Kusto, Apache Cassandra või isegi MySQL replikatsioon, kui andmed mahuvad sinna).

Seejärel kirjutavad samad insenerid päringud sellele ladustamisele. Dodo Pizza Engineeringus tähendab selle lähenemise rakendamine, et Data Engineeringi meeskond omab andmeskeemi analüütilises ladustamises.

Antud stsenaariumis muutub meeskond väga kurvaks kassiks ja siin on põhjused:

• Peab jälgima muudatusi KÕIKIDES ettevõtte teenustes. Ja neid on palju, ning muudatusi on väga palju (keskmiselt ühendame ~100 pull requesti nädalas, olles samas paljud teenused ei tee üldse pull requeste).
• Kui andmeskeem muutub, peab toodete omanik ja andmeskeemi muudatustega meeskond ootama, kuni Data Engineering kirjutab vajalikud koodimuudatused, et toetada muudatusi. Samuti oleme juba ammu saanud tuttavaks olukorraga, kus üks meeskond ootab teist – see on väga haruldane. Ja me ei taha, et see saaks arendusprotsessi „normaalseks“ osaks.
• Peab olema sügavalt seotud KÕIKIDE ettevõtte äri. Pizzaalade võrgustik näib olema lihtne äri, aga see on vaid pealispind. On äärmiselt keeruline koguda ühte meeskonda piisavalt teadmisi, et luua kõikehõlmav andmemudeli suhtes õige alus.
• See on ainus rikke punkt. Iga kord, kui on vaja muuta andmeid, mida teenus tagastab, või esitada päring, langevad kõik need ülesanded Data Engineering'i meeskonna kaela. Lõpuks on meeskond ülekoormatud tagasiside nimekirjaga.

Nii et meeskond on tohutu vajaduste ristis ja tõenäoliselt ei saa neid rahuldada. Samal ajal peavad nad pidevalt olema ajapuuduses ja stressis. Me ei sooviks seda. Seetõttu peame mõtlema, kuidas neid probleeme lahendada ja samal ajal andmeid analüüsida.

Liikudes Data Lake'ist Data Mesh'i

Küll aga on see küsimus vaevanud mitte ainult meid. Tegelikult on sarnane probleem juba tööstuses lahendatud (halleluuja!). Kuid teises valdkonnas: rakenduste juurutamine. Jah, ma räägin DevOps'i lähenemisest, kus meeskond otsustab, kuidas tooteid juurutada, mida nad loovad.

Sarnase lähenemise andmete järve probleemide lahendamiseks pakkus välja Zhamak Dehghani, konsultant ThoughtWorks'is. 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 oli artikli alguses). Peamised ideed, mille me sealt välja tõime:

• Jagada suur Data Lake andme domeenideks, mis on väga sarnased domeenipõhisest disainist tulenevates domeenidesse. Iga domeen on väike bounded context.
• Funktsioonimeeskonnad, kes vastutavad DDD domeenide eest, vastutavad ka vastavate andme domeenide eest. Nad hoidavad skeemi, muudavad seda, laadivad andmeid sisse. Samuti teavad nad kõike: kuidas andmete laadimist muuta ja mitte midagi purustada, kui rakendus muutub. Teadmised ei kao kuhugi. Andmete avamiseks ei pea nad kuhugi minema. Meeskond viib läbi kogu arendustsükli alates operatiivandmete muutmisest kuni analüüsiandmete pakkumiseni kolmandatele isikutele. Üks meeskond omab kõike, mis on seotud domeeniga (nii äridomeeni kui ka andmedomeeni).
• Data Engineer – roll Funktsioonimeeskonnas. See ei pruugi olla eraldi inimene, kuid on oluline, et meeskond omaks selle valdkonna oskusi.

Ja sel ajal tegeleb Data Engineering'i meeskond...

Kui kujutada ette, et see kõik realiseerub sõrmenipsust, jääb vastata kahele küsimusele:

Millega hakkab nüüd tegelema Data Engineering'i meeskond? Dodo Pizza Engineering'is on juba olemas platvormi/SRE meeskond. Nende ülesanne on anda arendajatele tööriistad teenuste lihtsaks juurutamiseks. Data Engineering'i meeskond täidab sarnast rolli, kuid andmete jaoks.

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

Kavatseme pakkuda Feature Team'ile mugavat tööriistade ja praktikate komplekti, mille abil nad saavad oma teenusest andmeid ülejäänud ettevõttele esitada. Samuti vastutame andmevoogude (järjekorrad, usaldusväärne salvestamine, andmete töötlemise klastrid) üldiste infrastruktuuriosade eest.

Kuidas saavad Data Engineering'i oskused Feature Team'is ilmuda? Feature Team'iga on keerulisem. Loomulikult võiksime proovida igasse meie meeskonda palgata ühe Data Engineer'i. Kuid see on väga keeruline. Leiutada inimene, kellel on hea taust andmetöötluses, ja veenda teda töötama toote meeskonnas on raske.

Dodo suur pluss on see, et me armastame sisekoolitust. Nii et praegu on meie plaan selline: Data Engineering'i meeskond hakkab avaldama mõnede teenuste andmeid, nutab, torgib end, kuid jätkab kaktuse söömist. Niikaua kui me saame aru, et meil on valminud protsess avaldamiseks, hakkame sellest Feature Team'ile rääkima.

Meil on mitu võimalust, kuidas seda teha:

1. DevForum, kus räägime, milline on protsess, mille oleme loonud, millised on tööriistad ja kuidas neid kõige tõhusamalt kasutada.
2. Esinemine DevForum'il aitab meil saada tagasisidet tootearendajatelt. Pärast seda saame liituda tootemeeskondadega ja aidata neil andmete avaldamisega seotud ülesandeid lahendada, korraldada meeskondadele koolitusi.

Andmete tarbimine

Praegu olen ma palju rääkinud andmete avaldamisest. Kuid on veel ka tarbimine. Mis on sellega seoses?

Meil on suurepärane BI meeskond, kes koostab keerulisi aruandeid haldusettevõttele. Dodo IS sees on palju aruandeid meie partneritele, mis aitavad neil pizzeriate haldamisel. Meie uues mudelis näeme neid kui andmekasutajaid, kellel on oma andmevaldkonnad. Just need kasutajad vastutavad oma andmevaldkondade eest. Mõnikord võib kasutaja valdkonda kirjeldada ühe päringuga analüütilisse andmehoidlasse – ja see on hea. kuid me mõistame, et see ei pruugi alati toimida. Just seetõttu tahame, et platvorm, mille viime ellu tootemeeskondade jaoks, oleks samuti kasutatav andmekasutajate poolt (sest Dodo IS aruannete puhul toimetavad need vaid mõned meeskonnad).

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

Allikas: habr.com