Detsembri alguses tegin saatusliku vea ja tegin arendajana oma elus pöördepunkti ning siirdusin ettevõtte sees Data Engineering (DE) meeskonda. Selles artiklis jagan mõningaid tähelepanekuid, mida tegin kahe kuu jooksul DE meeskonnas töötades.
Miks andmetehnika?
Minu teekond DE-sse algas 2019. aasta suvel, kui me lähme juurde , ja seal ma saavutasin valgustatuse. Mind hakkas huvitama teema, uurima algoritme ja isegi neid , ja siis mõtlesin rakendusala üle ning saime kiiresti teada, et meie ettevõttes on praktiliseks rakenduseks hajutatud andmebaasid.
Millega meie meeskond täpsemalt tegeleb? Meie, nagu kõik moodsad poisid ja tüdrukud, tahame saada andmepõhiseks ettevõtteks. Ja selleks, et see saaks võimalikuks, peame ehitama vähemalt töökindla laohoone, millest saaks koostada kõik ettevõttele vajalikud aruanded. Kuid kõige tähtsam on see, et selles salvestusruumis olevaid andmeid tuleb usaldada. Pealegi peate neid andmeid kasutades suutma taastada süsteemi oleku ajahetkel t. Seda kõike raskendab asjaolu, et me elame uues vapras mikroteenuste maailmas ja see ideoloogia eeldab, et iga teenus rakendab oma väikest funktsionaalsust, tema andmebaas on tema enda äri ja ta saab seda vähemalt iga päev kustutada, kuid samal ajal peame suutma vastu võtta ja töödelda teenuse olekut.
Kui soovite olla andmepõhine, muutuge esmalt sündmustepõhiseks
Mitte nii lihtne. Sündmused on erinevad ning arendaja ja andmeinsener vaatavad neid erinevalt. Sündmustest rääkimine on eraldi artikli teema, nii et ma ei hakka seda siin käsitlema. Lisaks on selline artikkel juba olemas teatud Martin Fowler, ma ei võta temalt loorbereid ära, las ta saab ka kuulsaks.
Üldiselt on mõtlemisainet palju ja seetõttu on see piirkond atraktiivne. Juhtub nii, et andmeinsener on meie ettevõttes palju laiem vastutusala kui lihtsalt ETL/ELT torujuhtmete kirjutaja (kui te ei tea, mida need lühendid tähendavad, tulge . Kontekstuaalse reklaamina).
Tegeleme salvestusarhitektuuri, andmete modelleerimise, andmeturbega seotud küsimuste ja loomulikult torustike endaga. Peame ka veenduma, et ühest küljest ei oleks meie kohalolek tootearendajatele väga koormav ja et meie nõuded peavad neid süsteemi uute funktsioonide lõikamisel võimalikult vähe häirima, ja teisest küljest peavad need andma analüütikute ja BI-meeskonna jaoks mugavalt salvestusandmetesse. Nii me elame.
Raskused arengust üleminekul
Esimesel tööpäeval puutusin kokku mitmete raskustega, mida tahan teiega jagada.
1. Esimene asi, mida ma nägin, oli tulingu ja mõningate tavade puudumine. Võtame näiteks koodi katmise testidega. Meil on arendamisel sadu testimisraamistikke. Andmetega töötades on kõik keerulisem. Jah, me saame testida ETL torujuhtmeid testandmete põhjal, kuid me peame seda kõike käsitsi tegema ja iga konkreetse juhtumi jaoks lahendusi otsima. Selle tulemusena on testi katvus palju halvem. Õnneks on veel üks kiht tagasisidet jälgimise ja logide näol, kuid see juba nõuab meilt pigem reageerimist kui ennetavat reageerimist, mis ajab raevu ja ajab närvi.
2. Maailm DE vaatenurgast pole sugugi see, mis tavalisele tootearendajale tundub (no muidugi, lugeja ei ole selline ja ta teab juba kõike, aga mina ei teadnud ja nüüd olen keerates selle üles). Arendajana loon oma mikroteenuse, panen andmed [teie valitud andmebaasi], salvestan sinna oma oleku, hangin midagi ID-ga ja ongi korras. Teenindus on aeglane, tellimused on segased, see on kõik. Nad paluvad mul otsida oma olekut teisest teenusest, nii et ma viskan sündmuse mõnda RabbitMQ-sse ja kõik. Ja siin pöördusime taas tagasi ülalkirjeldatud sündmuste teema juurde.
See, mida teenus operatiivtööks vajab, ajalooliste andmete jaoks meile ei sobi, seega algab küsimus teenuslepingute ümbertöötamisest ja tihedast koostööst arendusmeeskondadega. Te ei kujuta ettegi, kui palju tunde meil kulus, et jõuda kokkuleppele: milline sündmustest juhitud ta meie ettevõttes on.
3. Sa pead mõtlema oma peaga. Ei, ma ei pea silmas seda, et arendajad ei mõtle (kuigi kes ma olen, et kõigi eest rääkida), lihtsalt tootearenduses on sul sageli juba mingi arhitektuur ja sa lõikad mahajäämust erinevaid segamisi. See nõuab muidugi planeerimist ja läbimõtlemist, aga see on vootöö, kus põhiprobleem on lihtsalt hästi ja tõhusalt teha.
Meie jaoks pole see nii lihtne, sest erinevate süsteemikomponentide üleviimine soojast ja hubasest monoliidist metsiku mikroteenuste džungli maailma pole nii lihtne. Kui teenus hakkab sündmusi välja paiskama, peate salvestusruumi täitmise loogika uuesti läbi vaatama, kuna andmed näevad nüüd välja teistsugused. Siin on vaja palju ja põhjalikult mõelda, mitte enam arendajana, vaid andmeinsenerina. See on tavaline lugu, kui veedad päevi märkmiku ja pastakaga või markeriga tahvli juures. See on väga raske, mulle ei meeldi mõelda, mulle meeldib ka tootmine.
4. Võib-olla on kõige olulisem teave. Mida me teeme, kui meil puuduvad teadmised? Kes ütles stackoverflow? Vii see inimene ruumist välja. Käime lugemas dokumente, teemakohaseid raamatuid, samuti on olemas kogukond, kes korraldab foorumeid, kohtumisi ja konverentse. Dokumentatsioon on suurepärane, kuid kahjuks võib see olla puudulik. Kasutame Cosmos DB-d paljudes projektides. Edu selle toote dokumentatsiooni lugemisel. Raamatud on ainuke pääste, õnneks on need olemas ja leitavad, need sisaldavad palju fundamentaalseid teadmisi ning lugema peab palju ja pidevalt. Aga probleem on kogukonnas.
Nüüd on meie piirkonnast raske leida vähemalt üht adekvaatset konverentsi või kohtumist. Ei, muidugi on palju kohtumisi sõnaga Data, kuid selle sõna kõrval on tavaliselt kummalised lühendid nagu ML või AI. Niisiis, see pole meie jaoks, me räägime sellest, kuidas ehitada hoidlaid, mitte sellest, kuidas end neuronitega määrida. Need hipsterid on kõik üle võtnud. Selle tulemusena oleme ilma kogukonnata. Muide, kui olete andmeinsener ja tunnete häid kogukondi, siis palun kirjutage kommentaaridesse.
Kokkutuleku kokkuvõte ja väljakuulutamine
Milleni me lõpuks jõuame? Minu esimene kogemus ütleb, et andmeinseneri nahas tunne on kasulik igale arendajale. See võimaldab meil lihtsalt vaadata asju erinevalt ja mitte olla üllatunud, kui meie silmad lähevad verd, kui näeme, kuidas arendajad oma andmeid kohtlevad. Seega, kui teie ettevõttes on DE, rääkige lihtsalt nende meestega, saate teada palju uusi asju (enda kohta).
Ja lõpuks teadaanne. Kuna päeva jooksul on meie teemal raske kohtumisi leida, otsustasime teha oma. Miks me oleme halvemad? Õnneks on meil imeline ja meie sõbrad , kes tunnevad sarnaselt meiega, et andmeinsenerid jäävad ebaõiglaselt tähelepanust ilma.
Kasutades võimalust, kutsun kõiki, kes vähegi soovivad, tulema meie esimesele kogukonnakohtumisele paljulubava pealkirjaga “DE või DIE”, mis toimub 27.02.2020. veebruaril XNUMX Dodo Pizza kontoris. Üksikasjad aadressil .
Kui midagi juhtub, olen kohal, võite mulle isiklikult näkku öelda, kui valesti ma arendajate suhtes olen.
Allikas: www.habr.com