Përshëndetje, Habr! Ne në Dodo Pizza Engineering e duam shumë të dhënat (kush nuk i do ato tani?). Tani do të ndajmë një histori se si të mbledhim të gjitha të dhënat e botës Dodo Pizza dhe t'i japim çdo punonjësi të kompanisë akses të lehtë në këtë masiv të dhënash. Detyra me yll: ruani nervat e ekipit të Inxhinierisë së të Dhënave.
Si Pliushkinë të vërtetë, ne mbledhim informacion të ndryshëm në lidhje me funksionimin e picerive tona:
- mbajmë mend të gjitha porositë e përdoruesve;
- dimë se sa kohë u desh për të bërë picën e parë në Syktyvkar;
- shohim se sa kohë po ftohet pica në raftin ngrohës në Voronezh pikërisht tani;
- ruajmë të dhënat për shkarkimin e produkteve;
- dhe shumë, shumë të tjera.
Për punën me të dhënat në Dodo Pizza tani janë përgjegjës disa ekipe, një prej tyre është ekipi i Inxhinierisë së të Dhënave. Tani para nesh (dmth. ne) qëndron detyra: të japim çdo punonjësi të kompanisë akses të lehtë në këtë masiv të dhënash.
Kur filluam të mendojmë për mënyrën se si ta realizojmë këtë dhe filluam të diskutojmë detyrën, gjetëm një qasje shumë interesante në menaxhimin e të dhënave - (në këtë lidhje do të gjeni një artikull të shkëlqyer). Idetë e tij përputhen shumë mirë me përfytyrimin tonë për mënyrën se si duam të ndërtojmë sistemin tonë. Më poshtë në artikull do të jetë rishikimi ynë i këtij Qasje dhe si e shohim zbatimin e tij në Dodo Pizza Engineering.
ĂfarĂ« nĂ«nkuptojmĂ« me "tĂ« dhĂ«nat"
Për fillim, le të përcaktojmë se çfarë nënkuptojmë me të dhënat në Dodo Pizza Engineering:
- Ngjarjet që dërgohen nga shërbimet (ne kemi një bus të përbashkët, të ndërtuar me RabbitMQ);
- Regjistrimet brenda bazës së të dhënave (për ne kjo është MySQL dhe CosmosDB);
- Klikimet nga aplikacioni mobil dhe faqja e internetit.
Në mënyrë që biznesi Dodo Pizza të mund të përdorë këto të dhëna dhe të besojë në to, është e rëndësishme që të përmbushen kushtet e mëposhtme:
- Ato duhet të jenë të plota. Ne duhet të jemi të sigurt që nuk po i ndryshojmë të dhënat gjatë procesit të përpunimit, ruajtjes dhe shfaqjes. Nëse biznesi nuk mund të besojë në të dhënat tona, atëherë ato nuk do të kenë asnjë dobi.
- Ato duhet të kenë një etiketë kohe dhe të mos fshihen. Kjo do të thotë që ne në çdo moment duam të kemi mundësinë të kthehemi mbrapa dhe të shohim të dhënat e asaj periudhe kohe. Për shembull, të dimë se sa pica janë shitur më 8 korrik 2018.
- Ato duhet të jenë të besueshme. Gjatë procesit të mbledhjes dhe ruajtjes së të dhënave, ne nuk duhet të humbasim vetëm integritetin, por edhe besueshmërinë. Ne nuk mund të humbasim të dhëna, segmente kohore, sepse me to humbasim besimin e klientëve tanë (si të jashtëm ashtu edhe të brendshëm).
- Ato duhet tĂ« jenĂ« me njĂ« skemĂ« tĂ« qĂ«ndrueshme â ne shkruajmĂ« kĂ«rkesa pĂ«r kĂ«to tĂ« dhĂ«na. Nuk do tĂ« donim qĂ« me ndryshimin e kodit tĂ« aplikacionit, me refaktorizimin, ato tĂ« ndryshonin aq shumĂ« sa qĂ« kĂ«rkesat tona tĂ« ndalonin sĂ« funksionuari. Ai qĂ« shkruan kĂ«rkesat kurrĂ« nuk do tĂ« mĂ«sojĂ« se ju keni bĂ«rĂ« refaktorizim, derisa gjithçka tĂ« shkatĂ«rrohet. Nuk do tĂ« doja ta merrja vesh kĂ«tĂ« nga klientĂ«t.
Duke pasur parasysh të gjitha këto kërkesa, arritëm në përfundimin se të dhënat në Dodo janë një produkt. Njësoj si API publik i shërbimit. Prandaj, ekipi që zotëron të dhënat duhet të jetë ai që zotëron shërbimin. Gjithashtu, ndryshimet në skemën e të dhënave duhet të jenë gjithmonë të rikthyeshme.
Qasja tradicionale â Data Lake
PĂ«r tĂ« zgjidhur problemet e ruajtjes dhe pĂ«rpunimit tĂ« besueshĂ«m tĂ« tĂ« dhĂ«nave tĂ« mĂ«dha, ekziston njĂ« qasje tradicionale, e pranuar nĂ« shumĂ« kompani qĂ« punojnĂ« me njĂ« sasi tĂ« tillĂ« informacioni â Data Lake. NĂ« kuadrin e kĂ«saj qasje, inxhinierĂ«t e tĂ« dhĂ«nave mbledhin informacion nga tĂ« gjithĂ« komponentĂ«t e sistemit dhe e ruajnĂ« 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 pĂ«rputhen me tĂ«).
Më pas, këta inxhinierë shkruajnë kërkesa për këtë depo. Realizimi i kësaj qasje në Dodo Pizza Engineering nënkupton që ekipi i Inxhinierisë së të Dhënave do të zotërojë skemën e të dhënave në depozita analitike.
Në këtë rast, ekipi bëhet shumë të mërzitur dhe ja pse:
- Ai duhet të ndjekë ndryshimet në Tà GJITHA shërbimet brenda kompanisë. Dhe ka shumë prej tyre dhe ndryshime shumë (në mesatare ne bashkojmë ~100 kërkesa të tërheqjes në javë, përveç që shumë shërbime nuk bëjnë kërkesa të tërheqjes fare).
- Me ndryshimin e skemĂ«s sĂ« tĂ« dhĂ«nave, produkt-udhĂ«heqĂ«si dhe ekipi qĂ« ndryshon skemĂ«n e tĂ« dhĂ«nave duhet tĂ« presin derisa Ekipi i InxhinierisĂ« sĂ« tĂ« DhĂ«nave tĂ« pĂ«rfundojĂ« kodin e nevojshĂ«m pĂ«r tĂ« mbĂ«shtetur ndryshimet. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, ne tashmĂ« kemi shumĂ« karakteristika dhe situata kur njĂ« ekip pret njĂ« tjetĂ«r â Ă«shtĂ« shumĂ« e rrallĂ«. Dhe ne nuk duam qĂ« kjo tĂ« bĂ«het njĂ« "pjesĂ« normale" e procesit tĂ« zhvillimit.
- Ai duhet tĂ« jetĂ« i pĂ«rfshirĂ« nĂ« TĂ GJITHA biznesi i kompanisĂ«. Rrjeti i picerive duket si njĂ« biznes i thjeshtĂ«, por kjo Ă«shtĂ« vetĂ«m njĂ« iluzion. ĂshtĂ« shumĂ« e vĂ«shtirĂ« tĂ« mblidhen nĂ« njĂ« ekip mjaftueshĂ«m 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Ă« duhet tĂ« ndryshohen tĂ« dhĂ«nat qĂ« shĂ«rbimi kthyer ose tĂ« shkruhet njĂ« kĂ«rkesĂ« â tĂ« gjitha kĂ«to detyra bien mbi ekipin e InxhinierisĂ« sĂ« tĂ« DhĂ«nave. NĂ« fund, ekipi ka njĂ« back-log tĂ« ngarkuar.
Pra, ekipi ndodhet në një pikë të kryqëzimit të një sërë nevojash dhe me siguri nuk do të jetë në gjendje t'i plotësojë ato. Në të njëjtën kohë, ata do të jenë në një presion të vazhdueshëm dhe stres. Ne nuk do të donim një gjë të tillë. Kështu që duhet të mendojmë se si t'i zgjidhim këto probleme dhe, në të njëjtën kohë, të kemi mundësi për të analizuar të dhënat.
Duke kaluar nga Data Lake në Data Mesh
Fatmirësisht, këtë pyetje nuk e kemi bërë vetëm ne. Në të vërtetë, një problem i tillë është zgjidhur tashmë në industri (hallelujah!). Por në një fushë tjetër: implementimi i aplikacioneve. Po, po flas për qasjen DevOps, ku ekipi përcakton se si duhet të implementohet produkti që ata krijojnë.
Një qasje e ngjashme për zgjidhjen e problemeve të Data Lake u ofrua nga Zhamak Dehghani, konsultante në ThoughtWorks. Duke vëzhguar se si kompani si Netflix dhe Spotify zgjidhin këto lloje problemesh, ajo shkroi një artikull të shkëlqyer (linku për të ishte në fillim të artikullit). Ide të shkurtra që ne nxorrëm nga ai janë:
- TĂ« ndahen Data Lake tĂ« mĂ«dha nĂ« domenet e tĂ« dhĂ«nave, tĂ« cilat ngjajnĂ« shumĂ« me domenet e dizajnuara nga domain-driven design. Ădo segment Ă«shtĂ« njĂ« kontekst i vogĂ«l i kufizuar.
- Ekipet e Karakteristikave, të cilat përgjigjen për domenet DDD, janë përgjegjëse edhe për domenet e përkatshme të të dhënave. Ata ruajnë skemën, bëjnë ndryshime në të dhe ngarkojnë të dhëna në të. Në të njëjtën kohë, ata dinë gjithçka: si të ndryshojnë ngarkimin e të dhënave dhe të mos prishin asgjë kur aplikacioni ndryshon. Njohuritë nuk humbasin kurrë. Për të hapur të dhënat, ata nuk kanë nevojë të shkojnë askund. Ekipi vetë menaxhon 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 â roli brenda Ekipit tĂ« Karakteristikave. Nuk Ă«shtĂ« domosdoshmĂ«risht njĂ« person i veçantĂ«, por Ă«shtĂ« e domosdoshme qĂ« ekipi tĂ« ketĂ« kĂ«tĂ« kompetencĂ«.
Dhe ndërkohë, ekipi i Inxhinierisë së të Dhënave...
Nëse imagjinojmë se e gjithë kjo zbatohet me një klik, atëherë mbetet të përgjigjemi në dy pyetje:
ĂfarĂ« do tĂ« bĂ«jĂ« tani ekipi i InxhinierisĂ« sĂ« Dateve? NĂ« Dodo Pizza Engineering tashmĂ« ekziston njĂ« ekip platforme/SRE. Detyra e tij Ă«shtĂ« tĂ« japĂ« zhvilluesve mjete pĂ«r njĂ« implementim tĂ« thjeshtĂ« tĂ« shĂ«rbimeve. Ekipi i InxhinierisĂ« sĂ« Dateve do tĂ« luajĂ« tĂ« njĂ«jtin rol, por pĂ«r tĂ« dhĂ«nat.
Konvertimi i të dhënave operacionale në të dhëna analitike është një proces i ndërlikuar. Të bësh që të dhënat analitike të jenë të qasshme për të gjithë kompaninë është edhe më e ndërlikuar. Pikërisht këtë problem do të trajtojë ekipi i Inxhinierisë së Dateve.
Ne planifikojmë të ofrojmë një grup të përshtatshëm mjetesh dhe praktikash për ekipin Feature Team, me të cilat ata do të kenë mundësi të publikojnë të dhëna nga shërbimi i tyre për pjesën tjetër të kompanisë. Gjithashtu, ne do të jemi përgjegjës për pjesët e infrastrukturës së përbashkët të data pipeline (rrethe, ruajtje të besueshme, klastere për kryerjen e transformimeve mbi të dhënat).
Si do të shfaqen aftësitë e Inxhinierisë së Dateve brenda ekipit Feature? Me ekipin Feature është më e ndërlikuar. Sigurisht, ne mund të përpiqemi të punësojmë nga një Inxhinier të Dhënash në secilën nga ekipet tona. Por kjo është shumë e vështirë. Të gjejmë një person me një përvojë të mirë në përpunimin e të dhënave dhe ta bindim atë të punojë brenda ekipit produkt është e vështirë.
Një përfitim i madh i Dodo është se ne e duam mësimin e brendshëm. Pra, plani ynë tani është ky: ekipi i Inxhinierisë së Dateve fillon të publikojë të dhënat e disa shërbimeve, qan, mbërthehet, por vazhdon të hajë kaktus. Sapo të kuptojmë se kemi një proces të gatshëm për publikimin, fillojmë t'i tregojmë për të ekipit Feature.
Ne kemi disa mënyra si ta bëjmë këtë:
- , në të cilin ne do të tregojmë si duket procesi që kemi krijuar, cilat janë mjetet dhe si t'i përdorim ato më efektivisht.
- Një paraqitje në DevForum do të na ndihmojë të mbledhim reagime nga zhvilluesit e produkteve. Pas kësaj, ne mund të shqiptuar me ekipet e produkteve dhe t'i ndihmojmë ata të zgjidhin problemet me publikimin e të dhënave, duke organizuar trajnime për ekipet.
Konsumimi i të dhënave
Tani kam folur shumĂ« pĂ«r publikimin e tĂ« dhĂ«nave. Por ka edhe konsumimin. ĂfarĂ« pĂ«r kĂ«tĂ« çështje?
Kemi njĂ« ekip tĂ« mrekullueshĂ«m BI, i cili shkruan raporte shumĂ« komplekse pĂ«r kompaninĂ« menaxhuese. Brenda Dodo IS ka shumĂ« raporte pĂ«r partnerĂ«t tanĂ« qĂ« i ndihmojnĂ« ata tĂ« menaxhojnĂ« piceritĂ«. NĂ« modelin tonĂ« tĂ« ri, ne mendojmĂ« pĂ«r ta si konsumatorĂ« tĂ« tĂ« dhĂ«nave, tĂ« cilĂ«t kanĂ« domenet e tyre tĂ« tĂ« dhĂ«nave. Dhe pikĂ«risht konsumatorĂ«t do tĂ« jenĂ« pĂ«rgjegjĂ«s pĂ«r domenet e tyre. NdonjĂ«herĂ«, domeni 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Ă«. Prandaj, ne dĂ«shirojmĂ« qĂ« platforma qĂ« do tĂ« krijojmĂ« pĂ«r ekipet e produktit tĂ« mund tĂ« pĂ«rdoret gjithashtu nga konsumatorĂ«t e tĂ« dhĂ«nave (sepse nĂ« rastin e raporteve brenda Dodo IS â do tĂ« jenĂ« ekipe tĂ« njĂ«jta).
Kështu e shohim punën me të dhëna në Dodo Pizza Engineering. Do të na pëlqente të lexonim mendimet tuaja rreth kësaj në komentet.
Burimi: habr.com
