Saluton, Habr! Ĉe Dodo Pizza Engineering, ni amas datumojn (kaj kiu ne amas ĝin hodiaŭ?). Nun estos rakonto pri kiel amasigi ĉiujn datumojn en la mondo de Dodo Pizza kaj doni al iu ajn dungito de la kompanio oportunan aliron al ĉi tiu datuma aro. La tasko sub la asterisko: konservi la nervojn de la Datuma Inĝenieristiko.
Kiel veraj Plyushkins, ni amasigas ĉiajn informojn pri la laboro de niaj picejoj:
- memoru ĉiujn uzantmendojn;
- ni scias kiom longe necesis por fari la plej unuan picon en Syktyvkar;
- ni vidas kiom longe necesas por ke pico malvarmiĝas sur hejta breto en Voronezh ĝuste nun;
- Ni stokas datumojn pri produktaj forĵetoj;
- kaj multaj multaj aliaj.
Pluraj teamoj nun respondecas pri laborado kun datumoj ĉe Dodo Pizza, unu el ili estas la teamo de Datuma Inĝenierado. Nun ili (tio estas, ni) alfrontas la taskon doni al iu ajn dungito de la kompanio oportunan aliron al ĉi tiu aro da datumoj.
Kiam ni komencis pensi pri kiel fari tion kaj komencis diskuti la problemon, ni trovis tre interesan aliron al datuma administrado - (sekvu la ligilon vi trovos grandegan, mirindan artikolon). Ŝiaj ideoj tre bone kongruas en nia ideo pri kiel ni volas konstrui nian sistemon. Plue en la artikolo estos nia repripensado de la aliro kaj kiel ni vidas ĝian efektivigon en Dodo Pizza Engineering.
Kion ni volas diri per "datumoj"
Unue, ni difinu, kion ni signifas per datumoj en Dodo Pizza Engineering:
- Eventoj senditaj de servoj (ni havas komunan buson konstruitan uzante RabbitMQ);
- Rekordoj ene de la datumbazo (por ni ĉi tio estas MySQL kaj CosmosDB);
- Klakfluo de movebla aplikaĵo kaj retejo.
Por ke la komerco de Dodo Pizza uzu kaj fidi ĉi tiujn datumojn, gravas, ke la sekvaj kondiĉoj estas plenumitaj:
- Ili devas esti kompletaj. Ni devas esti certa, ke ni ne ŝanĝas la datumojn dum ĝi estas prilaborata, stokita kaj montrata. Se entreprenoj ne povas fidi niajn datumojn, ĝi ne utilos.
- Ili devas havi hormarkon kaj ne esti anstataŭitaj. Ĉi tio signifas, ke en ajna momento ni volas povi reveni kaj rigardi la datumojn de tiu tempodaŭro. Ekzemple, eksciu kiom da picoj estis venditaj la 8-an de julio 2018.
- Ili devas esti fidindaj. En la procezo de kolektado kaj stokado de datumoj, ni ne devas perdi ne nur integrecon, sed ankaŭ fidindecon. Ni ne povas perdi datumojn, tempotranĉaĵojn, ĉar kune kun ili ni perdas la fidon de niaj klientoj (kaj eksteraj kaj internaj).
- Ili devas esti kun stabila cirkvito - ni skribas petojn por ĉi tiuj datumoj. Ni vere ne ŝatus, ke ĝi ŝanĝiĝu tiom multe kun ŝanĝoj en la aplika kodo, kun refactorings, ke niaj demandoj ĉesu funkcii. La persono, kiu skribas la demandojn, neniam scios, ke vi faris refaktorigon ĝis ĉio rompiĝos. Mi ne volus aŭdi pri ĉi tio de klientoj.
Konsiderante ĉiujn ĉi tiujn postulojn, ni alvenis al la konkludo, ke la datumoj en Dodo estas produkto. Same kiel la publika API de la servo. Sekve, la sama teamo kiu posedas la servon devus posedi la datumojn. Ankaŭ, ŝanĝoj al la datumskemo ĉiam devas esti malantaŭen kongruaj.
Tradicia Aliro - Datuma Lago
Por solvi problemojn pri fidinda stokado kaj prilaborado de grandaj datumoj, ekzistas tradicia aliro adoptita en multaj kompanioj, kiuj laboras kun tia aro de informoj - Data Lake. Kiel parto de ĉi tiu aliro, datumaj inĝenieroj kolektas informojn de ĉiuj komponentoj de la sistemo kaj metas ilin en unu grandan deponejon (ĉi tio povus esti, ekzemple, Hadoop, Azure Kusto, Apache Cassandra, aŭ eĉ MySQL-repliko, se la datumoj konvenas al ĝi).
Tiam ĉi tiuj samaj inĝenieroj skribas petojn al tia stokado. Efektivigi ĉi tiun aliron en Dodo Pizza Engineering signifas, ke la Datuma Inĝenieristiko-teamo posedos la datuman skemon en la analiza magazeno.
En ĉi tiu scenaro, la teamo fariĝas tre malĝojaj katoj kaj jen kial:
- Ŝi devas monitori ŝanĝojn enen ĈIUJ servoj ene de la kompanio. Kaj estas multaj el ili kaj multaj ŝanĝoj (averaĝe ni kunfandas ~100 pull-petojn semajne, dum multaj servoj tute ne faras pull-petojn).
- Ŝanĝante la datumskemon, la produktposedanto kaj la teamo ŝanĝanta la datumskemon devas atendi ke Datuma Inĝenierado aldonu la kodon necesan por subteni la ŝanĝojn. Samtempe ni delonge estas riĉaj en funkcioj kaj la situacio, kiam unu teamo atendas alian, estas tre malofta. Kaj ni ne volas, ke ĉi tio iĝu "normala" parto de la evoluprocezo.
- Ĝi devas esti mergita en TUTO kompanio komerco. La pizzeria ĉeno aspektas kiel simpla komerco, sed nur tiel ŝajnas. Estas tre malfacile kolekti sufiĉajn kompetentecojn en unu teamo por konstrui taŭgan datummodelon por la tuta kompanio.
- Ĝi estas ununura punkto de fiasko. Ĉiufoje, kiam vi bezonas ŝanĝi la datumojn resenditajn de la servo aŭ skribi peton, ĉiuj ĉi tiuj taskoj falas al la teamo de Datumoj. Kiel rezulto, la teamo havas troŝarĝitan restaron.
Rezultas, ke la teamo estas ĉe la intersekco de grandega nombro da bezonoj kaj verŝajne ne povos kontentigi ilin. Samtempe, vi estos sub konstanta tempopremo kaj streso. Ni vere ne volas ĉi tion. Tial ni devas pensi pri kiel solvi ĉi tiujn problemojn kaj samtempe povi analizi la datumojn.
Moviĝante de Data Lake al Data Mesh
Feliĉe, ni ne estis la solaj, kiuj faris al ni ĉi tiun demandon. Fakte, simila problemo jam estis solvita en la industrio (haleluja!). Nur en malsama areo: aplikaĵo deplojo. Jes, mi parolas pri la aliro DevOps, kie la teamo determinas kiel disfaldi la produkton, kiun ili kreas.
Simila aliro al solvado de Data Lake-problemoj estis proponita de Zhamak Dehghani, konsilisto de ThoughtWorks. Rigardante kiel Netflix kaj Spotify solvas similajn problemojn, ŝi skribis mirindan artikolon (la ligo al ĝi estis komence de la artikolo). La ĉefaj ideoj, kiujn ni forprenis de ĝi:
- Dividu grandan Datuman Lagon en datumajn domajnojn, kiuj tre similas al domajnaj dezajnaj domajnoj. Ĉiu domajno estas malgranda limigita kunteksto.
- Ĉefaj Teamoj, kiuj respondecas pri DDD-domajnoj, ankaŭ respondecas pri la ekvivalentaj datumdomajnoj. Ili konservas la skemon, faras ŝanĝojn al ĝi kaj ŝarĝas datumojn en ĝi. Samtempe ili mem scias ĉion: kiel ŝanĝi la datuman ŝarĝon kaj ne rompi ion ajn kiam la aplikaĵo ŝanĝiĝas. Scio ne foriras. Ili ne devas iri ien por malfermi la datumojn. La teamo mem gvidas la plenan disvolvan ciklon de ŝanĝado de operaciaj datumoj ĝis disponigado de analizaj datumoj al triaj partioj. Unu teamo posedas ĉion asociitan kun la domajno (kaj la komerca domajno kaj la datuma domajno).
- Datuma Inĝeniero - rolo ene de la Karakterizaĵa Teamo. Ĉi tio ne devas esti individuo, sed estas nepre, ke la teamo havas ĉi tiun kompetentecon.
Dume, la teamo de Data Engineering...
Se vi imagas, ke ĉio ĉi realiĝas per klako de viaj fingroj, tiam vi nur devas respondi du demandojn:
Kion faros nun la teamo de Data Engineering? Dodo Pizza Engineering jam havas platformon/SRE-teamon. Ĝia celo estas doni al programistoj la ilojn por facile deploji servojn. La teamo de Datuma Inĝenierado plenumos la saman rolon nur por datumoj.
Transformi operaciajn datumojn en analizajn datumojn estas kompleksa procezo. Disponigi analizajn datumojn al la tuta kompanio estas eĉ pli malfacila. Estas ĉi tiuj problemoj, kiujn la teamo de Datumoj pri Inĝenierado traktos.
Ni donos al la Karakterizaĵa Teamo oportunan aron da iloj kaj praktikoj, por ke ili povu publikigi datumojn de sia servo al la resto de la kompanio. Ni ankaŭ respondecos pri la ĝeneralaj infrastrukturaj partoj de la datumdukto (vostoj, fidinda stokado, aretoj por plenumi transformojn pri datumoj).
Kiel aperos kapabloj de Data Engineer ene de la Karakterizaĵa Teamo? Kun la Feature Teamo ĝi estas pli komplika. Kompreneble, ni povus provi dungi unu Datuman Inĝenieron por ĉiu el niaj teamoj. Sed estas tiel malfacile. Trovi iun kun bona datuma fono kaj konvinki lin labori ene de produktteamo estas malfacile.
La granda pluso de Dodo estas, ke ni amas internan trejnadon. Do nun nia plano estas jena: la teamo de Datumoj-Inĝenierado komencas publikigi datumojn de iuj servoj, ploras, injektas sin, sed daŭre manĝas kakton. Post kiam ni scias, ke ni havas eldonprocezon en la loko, ni komencas komuniki ĝin al la Ĉefteamo.
Ni havas plurajn manierojn fari tion:
- , kie ni gvidos vin tra kiel aspektas la procezo, kiun ni kreis, kiaj iloj estas disponeblaj, kaj kiel uzi ilin plej efike.
- Paroli ĉe DevForum helpos nin kolekti komentojn de produktoprogramistoj. Post ĉi tio, ni povos aliĝi al produktaj teamoj kaj helpi ilin solvi problemojn pri eldonado de datumoj, kaj organizi trejnadojn por teamoj.
Konsumo de datumoj
Nun mi multe parolis pri eldonado de datumoj. Sed ekzistas ankaŭ konsumo. Kio pri ĉi tiu afero?
Ni havas mirindan BI-teamon, kiu skribas tre kompleksajn raportojn por la administra kompanio. Ene de Dodo IS estas multaj raportoj por niaj partneroj, kiuj helpas ilin administri siajn picejojn. En nia nova modelo, ni pensas pri ili kiel datumkonsumantoj, kiuj havas siajn proprajn datumajn domajnojn. Kaj estas konsumantoj kiuj respondecos pri siaj propraj domajnoj. Foje la domajno de konsumanto povas esti priskribita en unu demando al la analiza magazeno - kaj tio estas bona. Sed ni komprenas, ke ĉi tio ne ĉiam funkcios. Tial ni volas, ke la platformo, kiun ni kreos por produktaj teamoj, povu ankaŭ esti uzata de datumkonsumantoj (finfine, en la kazo de raportoj ene de Dodo IS, ĉi tiuj estos la samaj teamoj).
Jen kiel ni vidas labori kun datumoj en Dodo Pizza Engineering. Ni ĝojos legi viajn pensojn pri ĉi tiu afero en la komentoj.
fonto: www.habr.com
