Gruodžio pradžioje padariau lemtingą klaidą ir padariau lūžį savo, kaip kūrėjo, gyvenime ir perėjau į duomenų inžinerijos (DE) komandą įmonėje. Šiame straipsnyje pasidalinsiu kai kuriais pastebėjimais, kuriuos padariau per du mėnesius dirbdamas DE komandoje.
Kodėl duomenų inžinerija?
Mano kelionė į DE prasidėjo 2019 m. vasarą, kai mes Eime , ir ten pasiekiau nušvitimą. Pradėjau domėtis tema, studijuoti algoritmus ir net apie juos , o tada pagalvojo apie taikymo sritį ir greitai išsiaiškino, kad praktinis pritaikymas mūsų įmonėje yra paskirstytos duomenų bazės.
Ką tiksliai veikia mūsų komanda? Mes, kaip ir visi madingi berniukai ir merginos, norime tapti duomenimis pagrįsta įmone. O kad tai taptų įmanoma, turime bent jau pastatyti patikimą saugyklą, iš kurios būtų galima kurti bet kokias įmonei reikalingas ataskaitas. Tačiau svarbiausia yra tai, kad šioje saugykloje esančiais duomenimis reikia pasitikėti. Be to, naudodamiesi šiais duomenimis, turite sugebėti atkurti sistemos būseną momentu t. Visa tai apsunkina tai, kad gyvename drąsiame naujame mikropaslaugų pasaulyje, o ši ideologija suponuoja, kad kiekviena paslauga diegia savo nedidelį funkcionalumą, jos duomenų bazė yra jos reikalas ir ji gali ją ištrinti bent kasdien, bet tuo pat metu turime turėti galimybę gauti ir apdoroti paslaugos būseną.
Jei norite būti pagrįstas duomenimis, pirmiausia tapkite pagrįstu įvykiais
Ne taip paprasta. Įvykiai yra skirtingi, o kūrėjas ir duomenų inžinierius į juos žiūri skirtingai. Kalbėjimas apie įvykius yra atskiro straipsnio tema, todėl čia nesileisiu. Be to, toks straipsnis jau yra tam tikras Martinas Fowleris, neatimsiu jo laurų, tegul irgi išgarsėja.
Apskritai, yra apie ką galvoti ir dėl to ši sritis patraukli. Taip jau atsitiko, kad mūsų įmonėje duomenų inžinierius yra daug platesnė atsakomybė nei tik žmogus, kuris rašo ETL/ELT vamzdynus (jei nežinote, ką reiškia šios santrumpos, kreipkitės į . Kaip kontekstinė reklama).
Mes užsiimame saugyklos architektūra, duomenų modeliavimu, su duomenų saugumu susijusiais klausimais ir, žinoma, pačiais vamzdynais. Taip pat turime įsitikinti, kad, viena vertus, mūsų buvimas nėra labai apsunkinantis produktų kūrėjus ir juos turi kuo mažiau blaškyti mūsų reikalavimai diegdami sistemoje naujas funkcijas, kita vertus, mes reikia pateikti juos patogiai išdėstytus duomenų saugykloje analitikams ir BI komandai. Taip ir gyvename.
Sunkumai pereinant nuo vystymosi
Pirmąją savo darbo dieną susidūriau su daugybe sunkumų, kuriais noriu pasidalinti su jumis.
1. Pirmas dalykas, kurį pamačiau, buvo tulingo ir kai kurių praktikų nebuvimas. Paimkite, pavyzdžiui, kodo aprėptį su testais. Kuriame šimtus testavimo sistemų. Dirbant su duomenimis viskas yra sudėtingiau. Taip, mes galime išbandyti ETL vamzdynus pagal bandymų duomenis, bet turime visa tai daryti rankiniu būdu ir ieškoti sprendimų kiekvienu konkrečiu atveju. Dėl to testo aprėptis yra daug blogesnė. Laimei, yra ir kitas grįžtamojo ryšio lygmuo – stebėjimas ir žurnalai, tačiau tam jau reikia reaguoti ne aktyviai, o reaguoti, o tai erzina ir nervina.
2. Pasaulis iš DE perspektyvos visai ne toks, koks atrodo eiliniam produkto kūrėjui (na, aišku, skaitytojas ne toks, o jis jau viską žino, bet aš nežinojau, o dabar užsuku tai aukštyn). Kaip kūrėjas susikuriu savo mikropaslaugą, sudedu duomenis į [jūsų pasirinkta duomenų bazė], išsaugu ten savo būseną, gaunu ką nors pagal ID ir viskas gerai. Aptarnavimas lėtas, užsakymai painūs, tai viskas. Jie prašo manęs ieškoti savo būsenos kitoje tarnyboje, todėl įmesiu įvykį į kokį nors RabbitMQ ir viskas. Ir čia vėl grįžome prie aukščiau aprašytų įvykių klausimo.
Tai, ko reikia paslaugai operatyviniam darbui, mums netinka istoriniams duomenims, todėl prasideda paslaugų sutarčių perdirbimo ir glaudaus darbo su kūrimo komandomis klausimas. Net neįsivaizduojate, kiek valandų mums prireikė, kad susitartume: koks jis mūsų įmonėje yra įvykių varomas.
3. Reikia mąstyti galva. Ne, aš neturiu galvoje, kad kūrėjai negalvoja (nors kas aš toks, kad kalbu už visus), tiesiog gaminių kūrime labai dažnai jau turi kažkokią architektūrą, o iš atsilikimo iškarpai skirtingus maištus. Žinoma, tam reikia planuoti ir apgalvoti, bet tai srautinis darbas, kurio pagrindinė problema yra tiesiog tai padaryti gerai ir efektyviai.
Mums tai nėra taip paprasta, nes įvairių sistemos komponentų perkėlimas iš šilto ir jaukaus monolito į laukinių mikroservisų džiunglių pasaulį nėra taip paprasta. Kai paslauga pradeda skleisti įvykius, turite persvarstyti saugyklos užpildymo logiką, nes dabar duomenys atrodo kitaip. Čia reikia daug ir nuodugniai mąstyti, nebe kaip kūrėjui, o kaip duomenų inžinieriui. Tai įprasta istorija, kai dienas leidžiate su užrašų knygele ir rašikliu arba su žymekliu prie lentos. Labai sunku, nemėgstu galvoti, man irgi patinka gamyba.
4. Bene svarbiausia – informacija. Ką daryti, kai mums trūksta žinių? Kas pasakė stackoverflow? Išveskite šį asmenį iš kambario. Einame skaityti dokumentus, knygas šia tema, taip pat yra bendruomenė, kuri organizuoja forumus, susitikimus ir konferencijas. Dokumentacija yra puiki, bet, deja, ji gali būti neišsami. „Cosmos DB“ naudojame daugelyje projektų. Sėkmės skaitant šio gaminio dokumentus. Vienintelis išsigelbėjimas yra knygos, laimei, jos egzistuoja ir jas galima rasti, jose yra daug fundamentalių žinių ir reikia daug ir nuolat skaityti. Tačiau problema yra bendruomenėje.
Dabar mūsų rajone sunku rasti bent vieną tinkamą konferenciją ar susitikimą. Ne, žinoma, yra daug susitikimų su žodžiu Data, bet šalia šio žodžio paprastai yra keistų santrumpos, pavyzdžiui, ML ar AI. Taigi, tai ne mums, mes kalbame apie tai, kaip statyti saugyklas, o ne kaip išsitepti neuronais. Šie hipsteriai perėmė viską. Dėl to mes esame be bendruomenės. Beje, jei esate duomenų inžinierius ir pažįstate geras bendruomenes, rašykite komentaruose.
Išvados ir susitikimo paskelbimas
Kuo mes baigiame? Mano pirmoji patirtis rodo, kad pasijusti duomenų inžinieriaus kailyje pravers kiekvienam kūrėjui. Tai tiesiog leidžia mums pažvelgti į dalykus kitaip ir nenustebti, kai akys pasruva krauju, kai matome, kaip kūrėjai elgiasi su savo duomenimis. Taigi, jei jūsų įmonėje yra DE, tiesiog pasikalbėkite su šiais vaikinais, sužinosite daug naujų dalykų (apie save).
Ir pabaigai – anonsas. Kadangi dienos metu sunku rasti susitikimų mūsų tema, nusprendėme susikurti savo. Kodėl mes blogesni? Laimei, mes turime nuostabų ir mūsų draugai iš , kurie, kaip ir mes, mano, kad duomenų inžinieriams nesąžiningai atimamas dėmesys.
Naudodamasis proga, kviečiu visus, kuriems rūpi, atvykti į pirmąjį mūsų bendruomenės susitikimą daug žadančiu pavadinimu „DE or DIE“, kuris vyks 27.02.2020 m. vasario XNUMX d. Dodo Pizza biure. Išsamią informaciją adresu .
Jei kas atsitiks, aš būsiu šalia, galite man asmeniškai į akis pasakyti, kaip aš klystu dėl kūrėjų.
Šaltinis: www.habr.com