Në fillim të dhjetorit, bëra një gabim fatal dhe bëra një pikë kthese në jetën time si zhvillues dhe kalova në ekipin e Inxhinierisë së të Dhënave (DE) brenda kompanisë. Në këtë artikull do të ndaj disa vëzhgime që kam bërë gjatë dy muajve të punës në ekipin e DE.
Pse Inxhinieria e të Dhënave?
Udhëtimi im për në DE filloi në verën e vitit 2019, kur ne Shkojmë , dhe aty arrita iluminimin. Fillova të interesohem për temën, për të studiuar algoritmet dhe madje edhe për to , dhe më pas menduam për shtrirjen e aplikimit dhe shpejt zbuluam se aplikimi praktik në kompaninë tonë është shpërndarë bazat e të dhënave.
Çfarë bën saktësisht ekipi ynë? Ne, si të gjithë djemtë dhe vajzat në modë, duam të bëhemi një kompani e drejtuar nga të dhënat. Dhe në mënyrë që kjo të bëhet e mundur, duhet të paktën të ndërtojmë një strukturë magazinimi të besueshme, e cila mund të përdoret për të ndërtuar çdo raport që i nevojitet kompanisë. Por gjëja më e rëndësishme është që të dhënat në këtë ruajtje duhet të besohen. Për më tepër, duke përdorur këto të dhëna, duhet të jeni në gjendje të rivendosni gjendjen e sistemit në kohën t. E gjithë kjo është e ndërlikuar nga fakti se ne jetojmë në një botë të re të guximshme mikroshërbimesh dhe kjo ideologji nënkupton që çdo shërbim zbaton funksionalitetin e tij të vogël, baza e të dhënave të tij është biznesi i tij dhe mund ta fshijë atë të paktën çdo ditë, por në në të njëjtën kohë ne duhet të jemi në gjendje të marrim dhe përpunojmë gjendjen e shërbimit.
Nëse dëshironi të jeni të drejtuar nga të dhënat, fillimisht bëhuni Drejtuar nga Ngjarjet
Jo aq e thjeshtë. Ngjarjet janë të ndryshme dhe zhvilluesi dhe inxhinieri i të dhënave i shikojnë ato ndryshe. Të flasësh për ngjarjet është një temë për një artikull të veçantë, kështu që nuk do të hyj në të këtu. Përveç kësaj, një artikull i tillë tashmë ka njëfarë Martin Fowler, nuk do t'i heq dafinat, le të bëhet edhe i famshëm.
Në përgjithësi, ka shumë për të menduar dhe kjo është arsyeja pse kjo zonë është tërheqëse. Ndodh që në kompaninë tonë, një Inxhinier i të Dhënave është një fushë përgjegjësie shumë më e gjerë sesa thjesht një person që shkruan tubacionet ETL/ELT (nëse nuk e dini se çfarë nënkuptojnë këto shkurtesa, ejani te . Si reklama kontekstuale).
Ne merremi me arkitekturën e ruajtjes, modelimin e të dhënave, çështjet që lidhen me sigurinë e të dhënave dhe vetë tubacionet, natyrisht. Ne gjithashtu duhet të sigurohemi që, nga njëra anë, prania jonë të mos jetë shumë e rëndë për zhvilluesit e produkteve dhe ata duhet të shpërqendrohen sa më pak të jetë e mundur nga kërkesat tona kur presin funksione të reja në sistem, dhe nga ana tjetër, ne duhet t'i ofrojë ato të vendosura në mënyrë të përshtatshme në të dhënat e ruajtjes për analistët dhe ekipin e BI. Kështu jetojmë.
Vështirësi gjatë kalimit nga zhvillimi
Në ditën time të parë të punës, kam hasur në një sërë vështirësish që dua t'i ndaj me ju.
1. Gjëja e parë që pashë ishte mungesa e tulingut dhe disa praktikave. Merrni, për shembull, mbulimin e kodit me teste. Ne kemi qindra korniza testimi në zhvillim. Kur punoni me të dhëna, gjithçka është më e ndërlikuar. Po, ne mund të testojmë tubacionet ETL në të dhënat e testimit, por duhet t'i bëjmë të gjitha manualisht dhe të kërkojmë zgjidhje për çdo rast specifik. Si rezultat, mbulimi i testit është shumë më i keq. Për fat të mirë, ekziston një shtresë tjetër reagimesh në formën e monitorimit dhe regjistrave, por kjo tashmë kërkon që ne të reagojmë në mënyrë reaguese dhe jo në mënyrë proaktive, gjë që është indinjuese dhe shqetësuese.
2. Bota nga perspektiva DE nuk është aspak ajo që duket për një zhvillues të zakonshëm produkti (epo, sigurisht që lexuesi nuk është i tillë, dhe ai tashmë di gjithçka, por unë nuk e dija dhe tani po e vidhos atë lart). Si zhvillues, unë krijoj mikroshërbimin tim, vendos të dhënat në [bazën e të dhënave sipas zgjedhjes suaj], ruaj shtetin tim atje, marr diçka me ID dhe është mirë. Shërbimi është i ngadaltë, porositë janë konfuze, kjo është e gjitha. Ata më kërkojnë të kërkoj gjendjen time në një shërbim tjetër, kështu që unë do të hedh një ngjarje në një RabbitMQ dhe kaq. Dhe këtu u kthyem përsëri në çështjen e ngjarjeve të përshkruara më lart.
Ajo që i nevojitet shërbimit për punën operative nuk na përshtatet për të dhënat historike, kështu që fillon çështja e ripërpunimit të kontratave të shërbimit dhe punës së ngushtë me ekipet e zhvillimit. Ju as nuk mund ta imagjinoni se sa orë na u deshën për të rënë dakord: çfarë lloj Event Driven është ai në kompaninë tonë.
3. Ju duhet të mendoni me kokën tuaj. Jo, nuk dua të them që zhvilluesit nuk mendojnë (edhe pse kush jam unë që të flas në emër të të gjithëve), është thjesht se në zhvillimin e produktit shumë shpesh ju tashmë keni një lloj arkitekture dhe shkurtoni ndryshime të ndryshme nga pjesa e mbetur. Natyrisht, kjo kërkon planifikim dhe mendim, por kjo është punë rrjedhëse, ku problemi kryesor është thjesht ta bësh mirë dhe me efikasitet.
Për ne, nuk është aq e thjeshtë, sepse transferimi i përbërësve të ndryshëm të sistemit nga një monolit i ngrohtë dhe komod në botën e xhunglës së egër të mikroshërbimeve nuk është aq i thjeshtë. Kur shërbimi fillon të shpërndajë ngjarje, duhet të rishikoni logjikën për mbushjen e hapësirës ruajtëse, sepse të dhënat tani duken ndryshe. Këtu duhet të mendoni shumë dhe tërësisht, jo më si zhvillues, por si inxhinier i të dhënave. Është një histori normale kur kaloni ditë me një fletore dhe stilolaps ose me një shënues në tabelë. Është shumë e vështirë, nuk më pëlqen të mendoj, gjithashtu e dua prodhimin.
4. Ndoshta gjëja më e rëndësishme është informacioni. Çfarë bëjmë kur na mungon njohuria? Kush tha se stackoverflow? Nxirreni këtë person nga dhoma. Ne shkojmë të lexojmë dokumente, libra për këtë temë, dhe ka gjithashtu një komunitet që organizon forume, takime dhe konferenca. Dokumentacioni është i madh, por për fat të keq, mund të jetë i paplotë. Ne përdorim Cosmos DB në një numër projektesh. Fat të mirë duke lexuar dokumentacionin për këtë produkt. Librat janë i vetmi shpëtim, për fat të mirë ekzistojnë dhe gjenden, përmbajnë shumë njohuri themelore dhe duhet të lexosh shumë dhe vazhdimisht. Por problemi është tek komuniteti.
Tani është e vështirë të gjesh të paktën një konferencë apo takim adekuat në zonën tonë. Jo, sigurisht, ka shumë takime me fjalën Data, por pranë kësaj fjale zakonisht ka shkurtesa të çuditshme si ML ose AI. Pra, kjo nuk është për ne, ne po flasim se si të ndërtojmë objekte magazinimi, dhe jo si të lyejmë veten me neurone. Këta hipsterë kanë marrë përsipër gjithçka. Si rezultat, ne jemi pa një komunitet. Meqë ra fjala, nëse jeni Inxhinier i të Dhënave dhe njihni komunitete të mira, ju lutemi shkruani në komente.
Konkluzionet dhe njoftimi i takimit
Me çfarë përfundojmë? Përvoja ime e parë më thotë se ndjenja në këpucët e një inxhinieri të dhënash do të jetë e dobishme për çdo zhvillues. Thjesht na lejon t'i shikojmë gjërat ndryshe dhe të mos habitemi kur sytë tanë gjakosen kur shohim se si zhvilluesit i trajtojnë të dhënat e tyre. Pra, nëse ka një DE në kompaninë tuaj, thjesht flisni me këta djem, do të mësoni shumë gjëra të reja (për veten tuaj).
Dhe në fund, njoftimi. Meqenëse është e vështirë të gjesh takime për temën tonë gjatë ditës, vendosëm të bëjmë tonën. Pse jemi me keq? Për fat kemi një të mahnitshme dhe miqtë tanë nga , të cilët, si ne, mendojnë se inxhinierët e të dhënave janë të privuar padrejtësisht nga vëmendja.
Duke përfituar nga ky rast, ftoj të gjithë ata që duan të vijnë në takimin tonë të parë të komunitetit me titullin premtues "DE or VDI", i cili do të zhvillohet më 27.02.2020 shkurt XNUMX në zyrën e Dodo Pizza. Detajet në .
Nëse ndodh ndonjë gjë, unë do të jem atje, ju mund të më tregoni personalisht se sa gabim e kam për zhvilluesit.
Burimi: www.habr.com