V začetku decembra sem naredil usodno napako in naredil prelomnico v svojem življenju kot razvijalec ter prestopil v ekipo Data Engineering (DE) v podjetju. V tem članku bom delil nekaj opažanj, ki sem jih dobil v dveh mesecih dela v ekipi DE.
Zakaj podatkovni inženiring?
Moja pot v DE se je začela poleti 2019, ko sva pojdimo k , in tam sem dosegel razsvetljenje. Začel sem se zanimati za temo, preučevati algoritme in celo o njih , nato pa razmišljal o obsegu uporabe in hitro ugotovil, da so praktična uporaba v našem podjetju porazdeljene baze podatkov.
Kaj točno počne naša ekipa? Tako kot vsi modni fantje in dekleta želimo postati podjetje, ki temelji na podatkih. In da bi to postalo mogoče, moramo zgraditi vsaj zanesljivo skladišče, ki ga je mogoče uporabiti za izdelavo vseh poročil, ki jih podjetje potrebuje. Najpomembneje pa je, da je treba podatke v tej shrambi zaupati. Poleg tega morate biti z uporabo teh podatkov sposobni obnoviti stanje sistema v času t. Vse to je zapleteno zaradi dejstva, da živimo v pogumnem novem svetu mikrostoritev in ta ideologija pomeni, da vsaka storitev izvaja svojo majhno funkcionalnost, njena baza podatkov je lastna stvar in jo lahko izbriše vsaj vsak dan, vendar ob hkrati pa moramo biti sposobni prejeti in obdelati stanje storitve.
Če želite biti usmerjeni v podatke, najprej postanite usmerjeni v dogodke
Ni tako preprosto. Dogodki so različni, razvijalec in podatkovni inženir pa nanje gledata drugače. Pogovor o dogodkih je tema za poseben članek, zato se tukaj ne bom spuščal v to. Poleg tega je tak članek že neki Martin Fowler, lovorik mu ne bom jemal, naj tudi on postane slaven.
Nasploh je treba veliko razmišljati in zato je to območje privlačno. Zgodi se, da je v našem podjetju podatkovni inženir veliko širše področje odgovornosti kot le oseba, ki piše ETL/ELT cevovode (če ne veste, kaj te kratice pomenijo, obiščite . Kot kontekstualno oglaševanje).
Ukvarjamo se z arhitekturo shranjevanja, modeliranjem podatkov, vprašanji, povezanimi z varnostjo podatkov, in seveda samimi cevovodi. Poskrbeti moramo tudi za to, da po eni strani naša prisotnost ni zelo obremenjujoča za razvijalce izdelkov in da jih čim manj motijo naše zahteve pri vrezovanju novih funkcij v sistem, po drugi strani pa analitikom in ekipi BI jih je treba zagotoviti na priročnem mestu v shrambi podatkov. Tako živimo.
Težave pri prehodu iz razvoja
Prvi delovni dan sem naletel na številne težave, ki jih želim deliti z vami.
1. Prva stvar, ki sem jo videl, je bila odsotnost tulinga in nekaterih praks. Vzemimo za primer pokritost kode s testi. V razvoju imamo na stotine testnih ogrodij. Pri delu s podatki je vse bolj zapleteno. Da, ETL cevovode lahko testiramo na testnih podatkih, vendar moramo vse to narediti ročno in iskati rešitve za vsak konkreten primer. Posledično je pokritost s testom veliko slabša. Na srečo obstaja še ena plast povratnih informacij v obliki spremljanja in dnevnikov, vendar to že od nas zahteva, da se odzovemo reaktivno in ne proaktivno, kar je jezno in vznemirjajoče.
2. Svet z vidika DE sploh ni tak, kot se zdi navadnemu razvijalcu izdelkov (no, bralec seveda ni tak in že vse ve, jaz pa nisem vedel in zdaj se zajebavam gor). Kot razvijalec ustvarim lastno mikrostoritev, dam podatke v [zbirko podatkov po vaši izbiri], tam shranim svoje stanje, dobim nekaj po ID-ju in je v redu. Storitev je počasna, naročila so zmedena, to je vse. Prosijo me, da poiščem svoje stanje v drugi storitvi, tako da vržem dogodek v kakšen RabbitMQ in to je to. In tu smo se spet vrnili k vprašanju zgoraj opisanih dogodkov.
Kar servis potrebuje za operativno delo, nam ne ustreza za zgodovinske podatke, zato se začne vprašanje predelave servisnih pogodb in tesnega sodelovanja z razvojnimi ekipami. Sploh si ne morete predstavljati, koliko ur je trajalo, da smo se strinjali: kakšen Event Driven je v naši družbi.
3. Morate razmišljati s svojo glavo. Ne, ne mislim, da razvijalci ne razmišljajo (čeprav kdo sem jaz, da govorim v imenu vseh), le da pri razvoju izdelkov zelo pogosto že imate neko arhitekturo in iz zaostankov režete različne premešaje. Seveda to zahteva načrtovanje in premislek, vendar je to pretočno delo, kjer je glavna težava le to, da ga naredimo dobro in učinkovito.
Za nas to ni tako preprosto, saj prenos različnih komponent sistema iz toplega in prijetnega monolita v svet divje mikrostoritvene džungle ni tako preprost. Ko storitev začne bruhati dogodke, morate ponovno razmisliti o logiki polnjenja pomnilnika, ker so podatki zdaj videti drugače. Tukaj morate veliko in temeljito razmišljati, ne več kot razvijalec, ampak kot podatkovni inženir. Običajna zgodba je, ko dneve preživljaš z zvezkom in pisalom ali s flomastrom ob tabli. Zelo težko je, ne maram razmišljati, rad imam tudi produkcijo.
4. Morda je najpomembnejša informacija. Kaj storimo, ko nam primanjkuje znanja? Kdo je rekel stackoverflow? Odpelji to osebo iz sobe. Gremo brati dokumente, knjige na to temo, obstaja pa tudi skupnost, ki organizira forume, srečanja in konference. Dokumentacija je odlična, vendar je lahko na žalost nepopolna. Cosmos DB uporabljamo v številnih projektih. Vso srečo pri branju dokumentacije za ta izdelek. Knjige so edina rešitev, na srečo obstajajo in jih je mogoče najti, vsebujejo veliko temeljnega znanja in brati je treba veliko in nenehno. Toda problem je v skupnosti.
Sedaj je težko najti vsaj eno primerno konferenco ali srečanje pri nas. Ne, seveda obstaja veliko srečanj z besedo Data, vendar so poleg te besede običajno čudne okrajšave, kot sta ML ali AI. Torej, to ni za nas, govorimo o tem, kako zgraditi skladišča, ne pa o tem, kako se mazati z nevroni. Ti hipsterji so prevzeli vse. Posledično smo brez skupnosti. Mimogrede, če ste podatkovni inženir in poznate dobre skupnosti, napišite v komentarje.
Zaključki in napoved srečanja
Kaj dobimo na koncu? Moja prva izkušnja mi pravi, da bo občutek v koži podatkovnega inženirja koristen za vsakega razvijalca. Omogoča nam le, da na stvari pogledamo drugače in ne bomo presenečeni, ko se nam zalijejo oči, ko vidimo, kako razvijalci ravnajo s svojimi podatki. Torej, če je v vašem podjetju DE, se le pogovorite s temi fanti, izvedeli boste veliko novega (o sebi).
In končno, obvestilo. Ker je čez dan težko najti srečanja na našo temo, smo se odločili, da pripravimo svojega. Zakaj smo slabši? Na srečo imamo neverjetno in naši prijatelji iz , ki tako kot mi menimo, da so podatkovni inženirji neupravičeno prikrajšani za pozornost.
Ob tej priložnosti vabim vse, ki vam je mar, da pridete na naš prvi community meetup z obetavnim naslovom “DE or DIE”, ki bo 27.02.2020. februarja XNUMX v pisarni Dodo Pizza. Podrobnosti na .
Če se kaj zgodi, bom tam, lahko mi osebno v obraz poveste, kako se motim glede razvijalcev.
Vir: www.habr.com