Sa simula ng Disyembre, nakagawa ako ng isang nakamamatay na pagkakamali at gumawa ng isang pagbabago sa aking buhay bilang isang developer at lumipat sa koponan ng Data Engineering (DE) sa loob ng kumpanya. Sa artikulong ito, ibabahagi ko ang ilang mga obserbasyon na ginawa ko sa loob ng dalawang buwang pagtatrabaho sa DE team.
Bakit Data Engineering?
Nagsimula ang aking paglalakbay sa DE noong tag-araw ng 2019, noong kami pumunta tayo sa , at doon ko nakamit ang kaliwanagan. Nagsimula akong maging interesado sa paksa, pag-aaral ng mga algorithm at maging tungkol sa kanila , at pagkatapos ay naisip ang tungkol sa saklaw ng aplikasyon at mabilis na nalaman na ang praktikal na aplikasyon sa aming kumpanya ay ipinamahagi na mga database.
Ano nga ba ang ginagawa ng aming koponan? Kami, tulad ng lahat ng naka-istilong lalaki at babae, ay gustong maging Data Driven Company. At upang ito ay maging posible, kailangan nating magtayo man lang ng isang mapagkakatiwalaang pasilidad ng imbakan, na maaaring magamit upang bumuo ng anumang mga ulat na kailangan ng kumpanya. Ngunit ang pinakamahalagang bagay ay dapat na mapagkakatiwalaan ang data sa storage na ito. Bukod dito, gamit ang data na ito, kailangan mong maibalik ang estado ng system sa oras na t. Ang lahat ng ito ay kumplikado sa pamamagitan ng katotohanan na tayo ay nabubuhay sa isang matapang na bagong mundo ng mga microservice, at ang ideolohiyang ito ay nagpapahiwatig na ang bawat serbisyo ay nagpapatupad ng sarili nitong maliit na pag-andar, ang database nito ay sarili nitong negosyo, at maaari nitong tanggalin ito kahit araw-araw, ngunit sa sa parehong oras dapat nating matanggap at maproseso ang estado ng serbisyo.
Kung gusto mong maging Data Driven, maging Event Driven muna
Hindi gaanong simple. Magkaiba ang mga kaganapan, at iba ang pagtingin sa kanila ng developer at data engineer. Ang pakikipag-usap tungkol sa mga kaganapan ay isang paksa para sa isang hiwalay na artikulo, kaya hindi ko ito isasaalang-alang dito. Bilang karagdagan, ang naturang artikulo ay mayroon na a certain Martin Fowler, I wonβt take away his laurels, hayaan mo ring sumikat siya.
Sa pangkalahatan, maraming dapat isipin at iyon ang dahilan kung bakit kaakit-akit ang lugar na ito. Nagkataon lang na sa aming kumpanya, ang Data Engineer ay isang mas malawak na lugar ng responsibilidad kaysa sa isang tao na nagsusulat ng mga pipeline ng ETL/ELT (kung hindi mo alam kung ano ang ibig sabihin ng mga pagdadaglat na ito, pumunta sa . Bilang advertising sa konteksto).
Nakikitungo kami sa arkitektura ng imbakan, pagmomodelo ng data, mga isyu na nauugnay sa seguridad ng data, at ang mga pipeline mismo, siyempre. Kailangan din nating tiyakin na, sa isang banda, ang ating presensya ay hindi masyadong mabigat para sa mga developer ng produkto at kailangan silang magambala nang kaunti hangga't maaari sa pamamagitan ng ating mga kinakailangan kapag pinuputol ang mga bagong feature sa system, at sa kabilang banda, tayo kailangang ibigay ang mga ito nang maginhawang inilatag sa data ng imbakan para sa mga analyst at BI team. Ganyan kami nakatira.
Mga paghihirap kapag lumipat mula sa pag-unlad
Sa aking unang araw ng trabaho, nakatagpo ako ng ilang mga paghihirap na nais kong ibahagi sa iyo.
1. Ang una kong nakita ay ang kawalan ng tuling at ilang mga kasanayan. Kunin, halimbawa, ang saklaw ng code na may mga pagsubok. Mayroon kaming daan-daang testing frameworks sa pagbuo. Kapag nagtatrabaho sa data, ang lahat ay mas kumplikado. Oo, maaari naming subukan ang mga pipeline ng ETL sa data ng pagsubok, ngunit kailangan naming gawin ang lahat ng ito nang manu-mano at maghanap ng mga solusyon para sa bawat partikular na kaso. Bilang resulta, mas malala ang saklaw ng pagsubok. Sa kabutihang palad, may isa pang layer ng feedback sa anyo ng pagsubaybay at mga log, ngunit nangangailangan na ito sa amin na tumugon nang reaktibo sa halip na proactive, na nakakainis at nakakatakot.
2. The world from a DE perspective is not at all what it seems to an ordinary product developer (well, siyempre hindi ganoon ang mambabasa, at alam na niya ang lahat, pero hindi ko alam at ngayon nalilito na ako. pataas). Bilang isang developer, gumagawa ako ng sarili kong microservice, inilalagay ang data sa [database na iyong pinili], i-save ang aking estado doon, kumuha ng isang bagay sa pamamagitan ng ID at ayos lang. Mabagal ang serbisyo, nakakalito ang mga order, iyon lang. Hinihiling nila sa akin na hanapin ang aking estado sa ibang serbisyo, kaya magtapon ako ng isang kaganapan sa ilang RabbitMQ at iyon na. At dito muli nating binalikan ang isyu ng mga pangyayaring inilarawan sa itaas.
Ang kailangan ng serbisyo para sa pagpapatakbo ng trabaho ay hindi angkop sa amin para sa makasaysayang data, kaya ang tanong ng muling paggawa ng mga kontrata ng serbisyo at malapit na pakikipagtulungan sa mga development team ay magsisimula. Hindi mo maisip kung ilang oras kaming sumang-ayon: anong klaseng Event Driven siya sa aming kumpanya.
3. Kailangan mong mag-isip gamit ang iyong ulo. Hindi, hindi ko ibig sabihin na ang mga developer ay hindi nag-iisip (bagama't sino ako para magsalita para sa lahat), ito lang ay sa pagbuo ng produkto napakadalas mayroon ka nang ilang uri ng arkitektura, at pinutol mo ang iba't ibang mga shuffle mula sa backlog. Siyempre, ito ay nangangailangan ng pagpaplano at pag-iisip, ngunit ito ay stream work, kung saan ang pangunahing problema ay upang gawin ito nang maayos at mahusay.
Para sa amin, hindi ito gaanong simple dahil ang paglipat ng iba't ibang bahagi ng system mula sa isang mainit at maaliwalas na monolith sa mundo ng wild microservice jungle ay hindi gaanong simple. Kapag nagsimula ang serbisyo sa pagbubuga ng mga kaganapan, kailangan mong muling isaalang-alang ang lohika para sa pagpuno sa imbakan, dahil iba na ang hitsura ng data. Dito kailangan mong mag-isip nang husto at maigi, hindi na bilang isang developer, kundi bilang isang data engineer. Ito ay isang normal na kuwento kapag gumugugol ka ng mga araw na may notebook at panulat o may marker sa pisara. Napakahirap, ayoko mag-isip, mahilig din ako sa production.
4. Marahil ang pinakamahalagang bagay ay ang impormasyon. Ano ang ginagawa natin kapag kulang tayo sa kaalaman? Sino ang nagsabing stackoverflow? Alisin ang taong ito sa silid. Nagbabasa kami ng mga dokumento, libro tungkol sa paksa, at mayroon ding komunidad na nag-oorganisa ng mga forum, pagkikita-kita at kumperensya. Mahusay ang dokumentasyon, ngunit sa kasamaang-palad, maaaring hindi ito kumpleto. Ginagamit namin ang Cosmos DB sa ilang mga proyekto. Good luck sa pagbabasa ng dokumentasyon para sa produktong ito. Ang mga libro ay ang tanging kaligtasan; sa kabutihang palad, ang mga ito ay umiiral at maaaring matagpuan, naglalaman ito ng maraming pangunahing kaalaman at kailangan mong magbasa ng marami at patuloy. Ngunit ang problema ay sa komunidad.
Ngayon ay mahirap na makahanap ng kahit isang sapat na kumperensya o pagpupulong sa aming lugar. Hindi, siyempre, maraming mga meetup na may salitang Data, ngunit sa tabi ng salitang ito ay kadalasang may mga kakaibang pagdadaglat tulad ng ML o AI. Kaya, hindi ito para sa amin, pinag-uusapan natin kung paano bumuo ng mga pasilidad ng imbakan, at hindi kung paano pahiran ang ating sarili ng mga neuron. Kinuha ng mga hipster na ito ang lahat. Bilang resulta, tayo ay walang komunidad. Sa pamamagitan ng paraan, kung ikaw ay isang Data Engineer at alam ang magagandang komunidad, mangyaring sumulat sa mga komento.
Mga konklusyon at anunsyo ng meetup
Ano ang ating matatapos? Sinasabi sa akin ng aking unang karanasan na ang pakiramdam sa kalagayan ng isang data engineer ay magiging kapaki-pakinabang para sa bawat developer. Nagbibigay-daan lang ito sa amin na tumingin sa mga bagay nang naiiba at hindi mabigla kapag namumula ang aming mga mata kapag nakita namin kung paano tinatrato ng mga developer ang kanilang data. Kaya, kung mayroong isang DE sa iyong kumpanya, makipag-usap lang sa mga taong ito, marami kang matututunan na mga bagong bagay (tungkol sa iyong sarili).
At sa wakas, ang anunsyo. Dahil mahirap makahanap ng mga pagkikita-kita sa aming paksa sa araw, nagpasya kaming gumawa ng sarili namin. Bakit tayo mas malala? Sa kabutihang palad mayroon kaming isang kamangha-manghang at ang aming mga kaibigan mula sa , na, tulad namin, ay nararamdaman na ang mga inhinyero ng data ay hindi patas na pinagkaitan ng pansin.
Sa pamamagitan ng pagkakataong ito, inaanyayahan ko ang lahat na nagmamalasakit na pumunta sa aming unang community meetup na may magandang titulong βDE or DIEβ, na magaganap sa Pebrero 27.02.2020, XNUMX sa opisina ng Dodo Pizza. Mga detalye sa .
Kung may mangyari, pupunta ako, maaari mong sabihin sa akin nang personal sa aking mukha kung gaano ako mali tungkol sa mga developer.
Pinagmulan: www.habr.com