La începutul lunii decembrie, am făcut o greșeală fatală și am făcut un punct de cotitură în viața mea de dezvoltator și m-am mutat în echipa Data Engineering (DE) din cadrul companiei. În acest articol voi împărtăși câteva observații pe care le-am făcut pe parcursul a două luni de lucru în echipa DE.
De ce ingineria datelor?
Călătoria mea către DE a început în vara lui 2019, când noi să mergem la , și acolo am atins iluminarea. Am început să devin interesat de subiect, să studiez algoritmi și chiar despre ei , și apoi s-a gândit la domeniul de aplicare și a aflat rapid că aplicația practică în compania noastră este bazele de date distribuite.
Ce face mai exact echipa noastră? Noi, la fel ca toți băieții și fetele la modă, vrem să devenim o companie Data Driven. Și pentru ca acest lucru să devină posibil, trebuie să construim cel puțin o unitate de depozitare de încredere, care să poată fi folosită pentru a construi orice rapoarte de care compania are nevoie. Dar cel mai important lucru este că datele din această stocare trebuie să fie de încredere. Mai mult, folosind aceste date, trebuie să puteți restabili starea sistemului la momentul t. Toate acestea sunt complicate de faptul că trăim într-o nouă lume curajoasă a microserviciilor, iar această ideologie implică faptul că fiecare serviciu își implementează propria mică funcționalitate, baza de date este propria sa afacere și o poate șterge cel puțin în fiecare zi, dar la în același timp trebuie să putem primi și procesa starea serviciului.
Dacă doriți să fiți bazat pe date, mai întâi deveniți bazat pe evenimente
Nu atât de simplu. Evenimentele sunt diferite, iar dezvoltatorul și inginerul de date le privesc diferit. Discuția despre evenimente este un subiect pentru un articol separat, așa că nu voi intra aici. În plus, un astfel de articol are deja un anume Martin Fowler, nu-i voi lua laurii, să devină și el celebru.
În general, sunt multe de gândit și de aceea această zonă este atractivă. Se întâmplă că, în compania noastră, un inginer de date este o zonă de responsabilitate mult mai largă decât o simplă persoană care scrie conducte ETL/ELT (dacă nu știi ce înseamnă aceste abrevieri, vino la . Ca publicitate contextuală).
Ne ocupăm de arhitectura de stocare, modelarea datelor, probleme legate de securitatea datelor și conductele în sine, desigur. De asemenea, trebuie să ne asigurăm că, pe de o parte, prezența noastră nu este foarte împovărătoare pentru dezvoltatorii de produse și că aceștia trebuie să fie distrași cât mai puțin posibil de cerințele noastre atunci când introducem noi funcții în sistem și, pe de altă parte, noi trebuie să le furnizeze aranjate convenabil în datele de stocare pentru analiști și echipa de BI. Așa trăim.
Dificultăți la trecerea de la dezvoltare
În prima mea zi de muncă, am întâmpinat o serie de dificultăți pe care vreau să le împărtășesc cu voi.
1. Primul lucru pe care l-am văzut a fost absența tulingului și a unor practici. Luați, de exemplu, acoperirea codului cu teste. Avem sute de cadre de testare în dezvoltare. Când lucrați cu date, totul este mai complicat. Da, putem testa conductele ETL pe datele de testare, dar trebuie să facem totul manual și să căutăm soluții pentru fiecare caz specific. Ca urmare, acoperirea testului este mult mai proastă. Din fericire, există un alt nivel de feedback sub forma monitorizării și a jurnalelor, dar acest lucru ne cere deja să reacționăm mai degrabă reactiv decât proactiv, ceea ce este enervant și enervant.
2. Lumea din perspectiva DE nu este deloc ceea ce i se pare unui dezvoltator de produs obisnuit (bine, bineinteles ca cititorul nu este asa, si el stie deja totul, dar eu nu stiam si acum ma bat sus). Ca dezvoltator, îmi creez propriul microserviciu, pun datele în [baza de date la alegere], îmi salvez starea acolo, iau ceva prin ID și este în regulă. Serviciul este lent, comenzile sunt confuze, asta-i tot. Ei îmi cer să-mi caut starea într-un alt serviciu, așa că voi arunca un eveniment într-un RabbitMQ și gata. Și aici am revenit din nou la problema evenimentelor descrise mai sus.
Ceea ce are nevoie serviciul pentru munca operațională nu ne convine pentru datele istorice, așa că începe problema reluării contractelor de servicii și a lucrului strâns cu echipele de dezvoltare. Nici nu vă puteți imagina câte ore ne-a luat să fim de acord: ce fel de Event Driven este în compania noastră.
3. Trebuie să gândești cu capul. Nu, nu vreau să spun că dezvoltatorii nu cred (deși cine sunt eu să vorbesc în numele tuturor), doar că în dezvoltarea de produse de foarte multe ori ai deja un fel de arhitectură și ai tăiat diferite amestecuri din restanță. Desigur, acest lucru necesită planificare și gândire, dar aceasta este munca în flux, în care principala problemă este pur și simplu să o faci bine și eficient.
Pentru noi, nu este atât de simplu, deoarece transferul diferitelor componente ale sistemului dintr-un monolit cald și confortabil în lumea junglei sălbatice de microservicii nu este atât de simplu. Când serviciul începe să emită evenimente, trebuie să reconsiderați logica pentru umplerea spațiului de stocare, deoarece datele acum arată diferit. Aici trebuie să te gândești mult și temeinic, nu mai ca dezvoltator, ci ca inginer de date. Este o poveste normală când petreci zilele cu un caiet și un pix sau cu un marker la tablă. Este foarte greu, nu-mi place să cred, și eu iubesc producția.
4. Poate cel mai important lucru este informația. Ce facem când ne lipsesc cunoștințele? Cine a spus stackoverflow? Scoateți această persoană din cameră. Mergem să citim documente, cărți pe această temă și există și o comunitate care organizează forumuri, întâlniri și conferințe. Documentarea este grozavă, dar, din păcate, poate fi incompletă. Folosim Cosmos DB într-o serie de proiecte. Succes la citirea documentației pentru acest produs. Cărțile sunt singura mântuire; din fericire, există și pot fi găsite, conțin multe cunoștințe fundamentale și trebuie să citești mult și constant. Dar problema este la comunitate.
Acum este dificil să găsești măcar o conferință sau o întâlnire adecvată în zona noastră. Nu, desigur, există o mulțime de întâlniri cu cuvântul Data, dar lângă acest cuvânt există de obicei abrevieri ciudate precum ML sau AI. Deci, acest lucru nu este pentru noi, vorbim despre cum să construim spații de depozitare și nu despre cum să ne ungem cu neuroni. Acești hipsteri au preluat totul. Drept urmare, suntem fără comunitate. Apropo, dacă sunteți inginer de date și cunoașteți comunități bune, vă rugăm să scrieți în comentarii.
Concluzii și anunțul întâlnirii
Cu ce ajungem? Prima mea experiență îmi spune că sentimentul în pielea unui inginer de date va fi util pentru fiecare dezvoltator. Ne permite doar să privim lucrurile diferit și să nu fim surprinși când ochii ni se injectează în sânge când vedem cum își tratează dezvoltatorii datele. Deci, dacă există un DE în compania ta, doar vorbește cu acești tipi, vei învăța o mulțime de lucruri noi (despre tine).
Și în sfârșit, anunțul. Deoarece este greu să găsim întâlniri pe tema noastră în timpul zilei, am decis să ne facem propriile noastre. De ce suntem mai rai? Din fericire, avem un uimitor si prietenii nostri din , care, ca și noi, consideră că inginerii de date sunt lipsiți de atenție în mod nedrept.
Profitând de această ocazie, invit pe toți cei cărora le pasă să vină la prima noastră întâlnire a comunității cu titlul promițător „DE sau DIE”, care va avea loc pe 27.02.2020 februarie XNUMX la biroul Dodo Pizza. Detalii la .
Dacă se întâmplă ceva, voi fi acolo, îmi puteți spune personal în față cât de greșit mă înșel cu dezvoltatorii.
Sursa: www.habr.com