Përshëndetje, Habr! Ne në Dodo Pizza Engineering e duam shumë të dhënat (e kush nuk i do ato tani?). Tani do të tregojmë një histori se si mund të përmbledhim të gjitha të dhënat e Dodo Pizza dhe t'i ofrojmë çdo punonjësi të kompanisë një qasje komode në këtë mori të dhënash. Detyra me yll: të ruajmë nervat e ekipit të Data Engineering.
Si të vërtetë mbledhës, ne grumbullojmë informacione të ndryshme rreth funksionimit të pizzerive tona:
- mbajmë të gjitha porositë e përdoruesve;
- dimë sa kohë u nevojit për të bërë picën e parë në Syktyvkar;
- shohim sa kohë zgjat që pizza të ftohet në raftin termik në Voronezh pikërisht tani;
- ruajmë të dhënat për humbjen e produkteve;
- dhe shumë, shumë të tjera.
Tani për punën me të dhënat në Dodo Pizza përgjigjen disa ekipe, një prej tyre është ekipi i Data Engineering. Aktualisht, para nesh (dmth. neve) qëndron detyra: t'i ofrojmë çdo punonjësi të kompanisë një qasje komode në këtë mori të dhënash.
Kur filluam tĂ« mendojmĂ« se si ta realizojmĂ« kĂ«tĂ« dhe tĂ« diskutonim detyrĂ«n, gjetĂ«m njĂ« qasje shumĂ« interesante pĂ«r administrimin e tĂ« dhĂ«nave â (nĂ« lidhje do tĂ« gjeni njĂ« artikull tĂ« madh tĂ« shkĂ«lqyer). IdetĂ« e saj u pĂ«rshtatĂ«n shumĂ« mirĂ« me pasqyrimin tonĂ« mbi atĂ« se si dĂ«shirojmĂ« ta ndĂ«rtojmĂ« sistemin tonĂ«. MĂ« tutje nĂ« artikull do tĂ« jetĂ« ripĂ«rpunimi ynĂ« i qasjes dhe si e shohim zbatimin e saj nĂ« Dodo Pizza Engineering.
ĂfarĂ« kuptojmĂ« me "tĂ« dhĂ«na"
Së pari, le të sqarojmë se çfarë nënkuptojmë me të dhëna në Dodo Pizza Engineering:
- Ngjarjet që dërgojnë shërbimet (kemi një autobus të përbashkët, i ndërtuar me RabbitMQ);
- Regjistrimet brenda bazës së të dhënave (për ne kjo janë MySQL dhe CosmosDB);
- Clickstream nga aplikacioni mobil dhe faqja e internetit.
Që biznesi i Dodo Pizza të mund të përdorë këto të dhëna dhe të mbështetet në to, është e rëndësishme që të plotësohen kushtet e mëposhtme:
- Duhet të jenë të plotë. Duhet të jemi të sigurt se nuk e ndryshojmë të dhënat gjatë përpunimit, ruajtjes dhe paraqitjes së tyre. Nëse biznesi nuk mund t'i besojë të dhënave tona, atëherë ato nuk do të kenë asnjë dobishmëri.
- Duhet të ketë një etiketë kohe dhe të mos fshihen. Kjo do të thotë që në çdo moment dëshirojmë të jemi në gjendje të kthehemi pas dhe të shohim të dhënat e asaj periudhe. Për shembull, të dimë sa pika u shitën më 8 korrik 2018.
- Duhet të jenë të besueshme. Gjatë procesit të mbledhjes dhe ruajtjes së të dhënave, nuk duhet të humbim jo vetëm integritetin, por edhe besueshmërinë. Nuk mund të humbim të dhëna, pjesë kohe, sepse së bashku me to humbim besimin e klientëve tanë (si të jashtëm, ashtu edhe të brendshëm).
- Duhet tĂ« kenĂ« njĂ« skemĂ« tĂ« stabilizuar â ne shkruajmĂ« pyetje pĂ«r kĂ«to tĂ« dhĂ«na. Na do tĂ« pĂ«lqente shumĂ« qĂ« me ndryshimin e kodit tĂ« aplikacionit, me refaktorizimin, ato tĂ« ndryshojnĂ« aq shumĂ« saqĂ« pyetjet tona tĂ« ndalen sĂ« funksionuari. Ai qĂ« shkruan pyetje nuk do ta dijĂ« kurrĂ« se ju keni bĂ«rĂ« refaktorizimin derisa gjithçka tĂ« prishet. Nuk do tĂ« dĂ«shironim ta dinim kĂ«tĂ« nga klientĂ«t.
Duke marrĂ« parasysh kĂ«to kĂ«rkesa, ne arritĂ«m nĂ« pĂ«rfundimin se tĂ« dhĂ«nat nĂ« Dodo â janĂ« njĂ« produkt. I njĂ«jtĂ« si njĂ« API publik i shĂ«rbimit. Prandaj, pronĂ«sia e tĂ« dhĂ«nave duhet tĂ« jetĂ« nga ekipi qĂ« zotĂ«ron shĂ«rbimin. Gjithashtu, ndryshimet e skemave tĂ« tĂ« dhĂ«nave duhet tĂ« jenĂ« gjithmonĂ« tĂ« pranuara mbrapsht.
Qasja tradicionale â Data Lake
PĂ«r tĂ« zgjidhur problemet e ruajtjes dhe pĂ«rpunimit tĂ« sigurt tĂ« tĂ« dhĂ«nave tĂ« mĂ«dha, ekziston njĂ« qasje tradicionale, e pranuar nĂ« shumĂ« kompani qĂ« punojnĂ« me njĂ« pool tĂ« tillĂ« informacioni â Data Lake. Brenda kĂ«saj qasje, inxhinierĂ«t e tĂ« dhĂ«nave mbledhin informacionin nga tĂ« gjithĂ« komponentĂ«t e sistemit dhe e ruajnĂ« atĂ« nĂ« njĂ« depo tĂ« madhe (kjo mund tĂ« jetĂ«, pĂ«r shembull, Hadoop, Azure Kusto, Apache Cassandra ose madje njĂ« kopje MySQL, nĂ«se tĂ« dhĂ«nat e saj janĂ« tĂ« mjaftueshme).
Pastaj këta inxhinierë shkruajnë pyetje për atë depo. Zbatimi i kësaj qasje në Dodo Pizza Engineering nënkupton që ekipi i Data Engineering do të zotërojë skemën e të dhënave në depozitat analitike.
Në këtë skenar, ekipi bëhet shumë macja e trishtuar dhe ja përse:
- Ata duhet të ndjekin ndryshimet në Tà GJITHA shërbimet brenda kompanisë. Dhe ka shumë dhe ndryshime janë shumë (në mesatare ne bashkojmë ~100 pull requests në javë, duke pasur parasysh se shumë shërbime nuk kryejnë pull requests fare).
- Kur ndryshon skema e tĂ« dhĂ«nave, produkti dhe ekipi qĂ« ndryshon skemĂ«n e tĂ« dhĂ«nave, duhet tĂ« presin qĂ« Data Engineering tĂ« pĂ«rfundojĂ« kodin e nevojshĂ«m pĂ«r tĂ« mbĂ«shtetur ndryshimet. Por ndodhemi gjithmonĂ« nĂ« situata ku njĂ« ekip po pret njĂ« tjetĂ«r â Ă«shtĂ« shumĂ« e rrallĂ«. Dhe ne nuk duam qĂ« kjo tĂ« bĂ«het njĂ« pjesĂ« "normale" e procesit tĂ« zhvillimit.
- Ata duhet tĂ« jenĂ« tĂ« thelluar nĂ« TĂ GJITHA biznesin e kompanisĂ«. Rrjeti i pizzerive duket si njĂ« biznes i thjeshtĂ«, por kjo Ă«shtĂ« vetĂ«m njĂ« iluzion. ĂshtĂ« shumĂ« e vĂ«shtirĂ« tĂ« mbledhĂ«sh nĂ« njĂ« ekip mjaft kompetenca pĂ«r tĂ« ndĂ«rtuar njĂ« model tĂ« pĂ«rshtatshĂ«m tĂ« tĂ« dhĂ«nave pĂ«r tĂ« gjithĂ« kompaninĂ«.
- Ajo Ă«shtĂ« njĂ« pikĂ« e vetme dĂ«shtimi. Ădo herĂ« qĂ« Ă«shtĂ« e nevojshme tĂ« ndryshohen tĂ« dhĂ«nat qĂ« shĂ«rbimi kthen ose tĂ« shkruhet njĂ« kĂ«rkesĂ«, tĂ« gjitha kĂ«to detyra bien mbi ekipin e InxhinierisĂ« sĂ« tĂ« DhĂ«nave. Si rezultat, ekipi ka njĂ« backlog tĂ« mbushur.
KĂ«shtu qĂ« ekipi ndodhet nĂ« njĂ« pikĂ« ndĂ«rfaqjeje tĂ« shumĂ« nevojave dhe me siguri nuk do tĂ« jetĂ« nĂ« gjendje t'i pĂ«rmbushĂ« ato. NjĂ«kohĂ«sisht, do tĂ« jetĂ« nĂ« njĂ« situatĂ« tĂ« vazhdueshme presioni dhe stresi. Ne nuk dĂ«shirojmĂ« qĂ« kjo tĂ« ndodhĂ«. Prandaj, na duhet tĂ« mendojmĂ« se si tâi zgjidhim kĂ«to probleme dhe tĂ« kemi mundĂ«si pĂ«r tĂ« analizuar tĂ« dhĂ«nat.
Duke kaluar nga Data Lake në Data Mesh
Fatmirësisht, ky pyetje nuk e kemi bërë vetëm ne. Në fakt, një problem i tillë është zgjidhur tashmë në industri (alleluja!). Vetëm në një fushë tjetër: implementimi i aplikacioneve. Po, flas për qasjen DevOps, ku ekipi përcakton se si duhet të implantohet produkti që ata krijojnë.
Një qasje e ngjashme për zgjidhjen e problemeve të Data Lake është propozuar nga Zhamak Dehghani, konsultante në ThoughtWorks. Duke vëzhguar se si Netflix dhe Spotify e zgjidhin këtë lloj problemi, ajo ka shkruar një artikull të shkëlqyer (linku për të ishte në fillim të artikullit). Ideja kryesore që ne nxorrëm nga ajo është:
- TĂ« ndahet Data Lake i madh nĂ« domene tĂ« dhĂ«nash, tĂ« cilat janĂ« shumĂ« tĂ« ngjashme me domene tĂ« dizajnuara nga domeni (domain-driven design). Ădo domen â njĂ« kontekst i vogĂ«l i kufizuar.
- Ekipet e veçanta, të cilat janë përgjegjëse për domene DDD, janë gjithashtu përgjegjëse për domene përkatëse të dhënash. Ato ruajnë skemën, e ndryshojnë atë, ngarkojnë të dhënat në të. Në të njëjtën kohë, ata dinë gjithçka: si të ndryshojnë ngarkimin e të dhënave pa prishur gjërat kur aplikacioni ndryshon. Njohuritë nuk humbasin. Për të hapur të dhënat, ata nuk kanë nevojë të shkojnë askund. Ekipi vetë udhëheq ciklin e plotë të zhvillimit nga ndryshimi i të dhënave operative deri te ofrimi i të dhënave analitike për palët e treta. Një ekip zotëron gjithçka që lidhet me domenin (si domenin e biznesit ashtu edhe domenin e të dhënave).
- Inxhinieri i tĂ« DhĂ«nave â njĂ« rol brenda Ekipit tĂ« Veçanta. Nuk Ă«shtĂ« e nevojshme qĂ« tĂ« jetĂ« njĂ« person i veçantĂ«, por Ă«shtĂ« e domosdoshme qĂ« ekipi tĂ« ketĂ« kĂ«tĂ« kompetencĂ«.
Në të njëjtën kohë, ekipi i Inxhinierisë së të Dhënave...
Nëse imagjinojmë se e gjithë kjo implementohet me një klik nganjëherë, do të mbetet të përgjigjemi në dy pyetje:
ĂfarĂ« do tĂ« bĂ«jĂ« tani ekipi i InxhinierisĂ« sĂ« tĂ« DhĂ«nave? NĂ« Dodo Pizza Engineering tashmĂ« ka njĂ« ekip platforme/SRE. Detyra e tyre Ă«shtĂ« tĂ« ofrojnĂ« zhvilluesve mjete pĂ«r implementimin e lehtĂ« tĂ« shĂ«rbimeve. Ekipi i InxhinierisĂ« sĂ« tĂ« DhĂ«nave do tĂ« luajĂ« njĂ« rol tĂ« ngjashĂ«m, por pĂ«r tĂ« dhĂ«nat.
Transformimi i të dhënave operative në të dhëna analitike është një proces i ndërlikuar. Të bësh të dhënat analitike të aksesueshme për të gjithë kompaninë është edhe më e ndërlikuar. Ekipi i Inxhinierisë së të Dhënave do të merret me zgjidhjen e këtyre problemeve.
Ne planifikojmë të ofrojmë Ekipit të Veçanta një grup të përshtatshëm mjetesh dhe praktikash, me të cilat ata mund të publikojnë të dhënat nga shërbimi i tyre për pjesën tjetër të kompanisë. Gjithashtu, do të jemi përgjegjës për pjesët e infrastrukturës së përgjithshme të pipeline-it të të dhënave (rrjetet, ruajtja e besueshme, klasteret për realizimin e transformimeve mbi të dhënat).
Si do të shfaqen aftësitë e Inxhinierit të të Dhënave brenda Ekipit të Veçanta? Me Ekipin e Veçanta është më e komplikuar. Sigurisht, mund të ishte një mundësi të provonim të punësojmë nga një Inxhinier të të Dhënave në çdo ekip tonin. Por kjo është shumë e komplikuar. Të gjejmë një person me një përvojë të mirë në përpunimin e të dhënave dhe ta bindim atë të punojë brenda një ekipi produktiv është e vështirë.
Një përparësi e madhe për Dodo është se ne e duam mësimin e brendshëm. Prandaj, plani ynë tani është: ekipi i Inxhinierisë së të Dhënave fillon të publikojë të dhënat e disa shërbimeve, qan, gjëmon, por vazhdon të hajë kaktus. Sa më shpejt të kuptojmë se kemi një proces të gatshëm për publikimin, të fillojmë t'i tregojmë atij në Ekipin e Veçanta.
Ne kemi disa mënyra se si të bëjmë këtë:
- , ku do tĂ« flasim pĂ«r procesin qĂ« kemi krijuar, cilat janĂ« mjetet dhe si tâi pĂ«rdorim ato mĂ« efektivisht.
- Një fjalim në DevForum do të na ndihmojë të mbledhim feedback nga zhvilluesit e produkteve. Pas kësaj, do të mund të bashkëveprojmë me ekipet e produkteve dhe t'u ndihmojmë atyre në zgjidhjen e problemeve të publikimit të të dhënave, organizimin e trajnimeve për ekipet.
Konsumimi i të dhënave
Tani kam folur shumĂ« pĂ«r publikimin e tĂ« dhĂ«nave. Por ka edhe konsumim. ĂfarĂ« ndodh me kĂ«tĂ« çështje?
Kemi njĂ« ekip tĂ« shkĂ«lqyer BI qĂ« shkruan raporte shumĂ« tĂ« ndĂ«rlikuara pĂ«r kompaninĂ« menaxhuese. Brenda Dodo IS, ka shumĂ« raporte pĂ«r partnerĂ«t tanĂ« qĂ« i ndihmojnĂ« ata tĂ« menaxhojnĂ« pizzeria. NĂ« modelin tonĂ« tĂ« ri, ne mendojmĂ« pĂ«r ta si konsumatorĂ« tĂ« tĂ« dhĂ«nave, tĂ« cilĂ«t kanĂ« domainet e tyre tĂ« tĂ« dhĂ«nave. Dhe pikĂ«risht konsumatorĂ«t do tĂ« jenĂ« pĂ«rgjegjĂ«s pĂ«r domainet e tyre. NdonjĂ«herĂ«, domaini i konsumatorit mund tĂ« pĂ«rshkruhet me njĂ« kĂ«rkesĂ« nĂ« magazinĂ«n analitike â dhe kjo Ă«shtĂ« e mirĂ«. Por ne e kuptojmĂ« se kjo nuk do tĂ« funksionojĂ« gjithmonĂ«. Kjo Ă«shtĂ« arsyeja pse ne duam qĂ« platforma qĂ« do tĂ« krijojmĂ« pĂ«r ekipet produktore tĂ« pĂ«rdoret gjithashtu nga konsumatorĂ«t e tĂ« dhĂ«nave (sepse nĂ« rastin e raporteve brenda Dodo IS â do tĂ« jetĂ« e njĂ«jta ekip).
Kështu e shohim punën me të dhënat në Dodo Pizza Engineering. Me kënaqësi do të lexojmë mendimet tuaja në lidhje me këtë në komentet.
Burimi: habr.com
