Detsembri alguses tegin saatusliku vea ja oma elus arendajana pöördelise otsuse ning siirdusin ettevõtte andmetehnika (DE) meeskonda. Selles artiklis jagan mõningaid tähelepanekuid, mida tegin kahekuulise töö jooksul andmetehnika meeskonnas.
Miks just andmetehnika?
Minu teekond Saksamaal algas 2019. aasta suvel, kui me lähme ja seal ma jõudsin valgustatusele. Hakkasin teemast huvituma, algoritme uurima ja isegi nende kohta rääkima. , ja siis mõtlesin rakendusvaldkonnale ning sain kiiresti teada, et meie ettevõttes on praktiliseks rakenduseks hajusandmebaasid.
Mida meie meeskond üldse teeb? Meie, nagu kõik moodsad poisid ja tüdrukud, tahame saada andmepõhiseks ettevõtteks. Ja selleks, et see oleks võimalik, peame vähemalt looma usaldusväärse salvestusruumi, mida saab kasutada ettevõtte vajalike aruannete loomiseks. Kõige tähtsam on aga see, et selles salvestusruumis olevad andmed oleksid usaldusväärsed. Lisaks peame neid andmeid kasutades suutma taastada süsteemi oleku ajahetkel t. Kõike seda teeb keeruliseks asjaolu, et elame uues mikroteenuste maailmas ja see ideoloogia eeldab, et igal teenusel on oma väike funktsionaalsus, selle andmebaas on omaette asi ja see saab seda iga päev kustutada, kuid samal ajal peame suutma teenuse olekut vastu võtta ja töödelda.
Kui soovid olla andmepõhine, siis hakka kõigepealt sündmustepõhiseks.
See pole nii lihtne. Sündmused on erinevad ning arendaja ja andmeinsener vaatavad neid erinevalt. Sündmustest rääkimine on eraldi artikli teema, seega ma ei hakka seda siin käsitlema. Pealegi on selline artikkel juba kirjutatud. teatud Martin Fowler, ma ei võta temalt loorbereid ära, las temagi kuulsaks saab.
Üldiselt on siin midagi, mille üle mõelda, ja see teebki selle valdkonna atraktiivseks. Meie ettevõttes on andmeinsener palju laiem vastutusvaldkond kui lihtsalt ETL/ELT torujuhtmete kirjutamine (kui te ei tea, mida need lühendid tähendavad, siis tulge...). . Kontekstuaalse reklaami õiguste kohta).
Tegeleme salvestusruumi arhitektuuri, andmete modelleerimise, andmeturbega seotud küsimuste ja loomulikult ka torujuhtmete endi-ga. Samuti peame seda tegema nii, et ühelt poolt ei oleks meie kohalolek tootearendajatele liiga koormav ja et meie nõuded ei segaks neid uute funktsioonide süsteemi integreerimisel nii vähe kui võimalik, ning teiselt poolt peaksime analüütikutele ja ärianalüütika meeskonnale andmeid salvestusruumis mugavalt paigutama. Nii me elamegi.
Raskused üleminekul arengust
Juba oma esimesel tööpäeval kohtasin mitmeid raskusi, mida tahan teiega jagada.
1. Esimene asi, mida märkasin, oli tööriistade ja mõnede praktikate puudumine. Võtame näiteks koodi katvuse testidega. Arenduses on meil testimiseks sada viiskümmend raamistikku. Andmetega töötades on kõik keerulisem. Jah, me saame testida ETL-torustikke testandmetel, aga peame seda kõike käsitsi tegema ja otsima lahendusi iga konkreetse juhtumi jaoks. Selle tulemusena on testide katvus palju halvem. Õnneks on olemas veel üks tagasisidekiht jälgimise ja logide näol, aga see nõuab meilt juba reaktiivset, mitte ennetavat reageerimist, mis on tüütu ja närvesööv.
2. DE vaatenurgast pole maailm üldse sama, mis tavalisele tootearendajale paistab (no loomulikult pole lugeja selline ja ta teab juba kõike, aga mina ei teadnud ja nüüd ma saan aru). Arendajana saein oma mikroteenust, panin andmed [teie valitud andmebaasi], salvestasin sinna oma oleku, sain ID järgi midagi kätte ja kõik on korras. Teenus töötab, tellimused lähevad segaseks ja kõik see värk. Nad paluvad mul oma olekut teises teenuses uurida, noh, ma viskan RabbitMQ-sse sündmuse ja ongi kõik. Ja siin oleme tagasi eespool kirjeldatud sündmuste teema juures.
See, mida teenus vajab operatiivseks tööks, ei sobi meile ajalooliste andmete jaoks, algab küsimus teenuslepingute ümbertöötamisest ja tihedast koostööst arendusmeeskondadega. Te ei kujuta ettegi, mitu tundi meil kulus, et kokku leppida: mis asi see sündmustepõhine süsteem meie ettevõttes on.
3. Sa pead oma peaga mõtlema. Ei, ma ei taha öelda, et arendajad ei mõtleks (kuigi kes mina olen, et kõigi eest rääkida), lihtsalt tootearenduses on sul väga sageli juba mingi arhitektuur olemas ja sa saagid mahajäänud töödest erinevaid asju välja. Muidugi nõuab see planeerimist ja mõtlemist, aga see on sujuv töö, kus peamine probleem on lihtsalt asja hea ja kvaliteetse tegemine.
Meie jaoks pole see nii lihtne, sest erinevate süsteemikomponentide ülekandmine soojast ja hubasest monoliidist metsikute mikroteenuste džunglite maailma pole nii lihtne. Kui teenus hakkab sündmusi välja viskama, tuleb ümber mõelda salvestusruumi täitmise loogika, sest andmed näevad nüüd teistsugused välja. Siin tuleb palju ja põhjalikult mõelda, mitte arendajana, vaid andmeinsenerina. See on tavaline lugu, kui veedad päevi tahvli ääres märkmiku ja pastaka või markeriga. See on väga keeruline, mulle ei meeldi mõelda, mulle meeldib pauk-pauk ja tootmiskeskkonda minna.
4. Võib-olla kõige olulisem on informatsioon. Mida me teeme, kui meil teadmistest napib? Kes ütles stackoverflow? Saage see inimene ruumist välja. Me käime lugemas dokumentatsiooni, teemakohaseid raamatuid ja on ka kogukond, mis korraldab foorumeid, kohtumisi ja konverentse. Dokumentatsioon on suurepärane, kuid kahjuks on see mõnikord puudulik. Kasutame Cosmos DB-d mitmes projektis. Edu selle toote dokumentatsiooni lugemisel. Raamatud on ainus pääste, õnneks on need olemas ja neid saab leida, need sisaldavad palju fundamentaalseid teadmisi ja lugema peab palju ja pidevalt. Aga kogukond on katastroof.
Meie valdkonnas on praegu raske leida isegi ühte adekvaatset konverentsi või kohtumist. Muidugi on palju kohtumisi sõnaga "andmed", aga tavaliselt on selle sõna kõrval kummalised lühendid nagu ML või AI. Noh, see pole meie jaoks, me räägime sellest, kuidas ehitada salvestusruume, mitte kuidas närvivõrke määrida. Need hipsterid on kõik täitnud. Selle tulemusena oleme ilma kogukonnata. Muide, kui olete andmeinsener ja teate häid kogukondi, siis kirjutage palun kommentaaridesse.
Kokkuvõte ja kohtumise väljakuulutamine
Mis meil lõpuks on? Minu esimene kogemus ütleb, et iga arendaja jaoks on kasulik tunda end andmeinseneri kingades. See võimaldab asjadele lihtsalt teistmoodi vaadata ja mitte imestada, kui meie silmad veritsevad, kui näeme, kuidas arendajad oma andmeid käitlevad. Seega, kui teie ettevõttes on andmeinseneri amet, siis rääkige lihtsalt nende tüüpidega, saate teada palju uut (enda kohta).
Ja lõpuks teadaanne. Kuna meie teemal kohtumisi peaaegu üldse ei toimu, otsustasime ise teha. Kas me oleme siis veel halvemad? Õnneks on meil hämmastav ja meie sõbrad , kes tunnevad, nagu meiegi, et andmeinsenerid on ebaõiglaselt unarusse jäetud.
Kasutades võimalust, kutsun kõiki, kes pole ükskõiksed, meie esimesele kogukonnakohtumisele paljulubava nimega "DE or DIE", mis toimub 27.02.2020 Dodo Pizza ettevõtte kontoris. Lisateavet leiate aadressilt .
Kui midagi, siis olen kohal, saate mulle isiklikult näkku öelda, kui valesti ma arendajate suhtes eksin.
Allikas: www.habr.com
