Ing awal Desember, aku nggawe kesalahan fatal lan nggawe titik balik ing uripku minangka pangembang lan pindhah menyang tim Teknik Data (DE) ing perusahaan. Ing artikel iki, aku bakal nuduhake sawetara pengamatan sing ditindakake sajrone rong wulan kerja ing tim DE.
Kenapa Data Engineering?
Perjalanan menyang DE diwiwiti ing musim panas 2019, nalika kita ayo menyang , lan ing kana aku entuk pencerahan. Aku wiwit dadi kasengsem ing topik, sinau algoritma lan malah bab mau , banjur mikir babagan ruang lingkup aplikasi lan kanthi cepet ngerteni manawa aplikasi praktis ing perusahaan kita disebarake database.
Apa persis sing ditindakake tim kita? Kita, kaya kabeh bocah lanang lan wadon sing modis, pengin dadi Perusahaan sing Didorong Data. Lan supaya iki bisa ditindakake, kita kudu paling sethithik mbangun fasilitas panyimpenan sing bisa dipercaya, sing bisa digunakake kanggo nggawe laporan sing dibutuhake perusahaan. Nanging sing paling penting yaiku data ing panyimpenan iki kudu dipercaya. Menapa malih, nggunakake data iki, sampeyan kudu bisa mulihake negara sistem ing wektu t. Kabeh iki rumit dening kasunyatan sing kita manggon ing donya anyar wani microservices, lan ideologi iki gawe katut sing saben layanan ngleksanakake fungsi cilik dhewe, database sawijining bisnis dhewe, lan bisa mbusak ing paling saben dina, nanging ing ing wektu sing padha kita kudu bisa nampa lan ngolah kahanan layanan.
Yen sampeyan pengin dadi Data Driven, pisanan dadi Event Driven
Ora dadi prasaja. Acara beda-beda, lan pangembang lan insinyur data ndeleng kanthi beda. Ngomong babagan acara minangka topik kanggo artikel sing kapisah, mula aku ora bakal mlebu ing kene. Kajaba iku, artikel kasebut wis ana Martin Fowler tartamtu, Aku ora bakal njupuk adoh laurels, supaya wong uga dadi misuwur.
Umumé, ana akeh sing kudu dipikirake lan mulane wilayah iki apik banget. Mesthi wae, ing perusahaan kita, Insinyur Data minangka tanggung jawab sing luwih akeh tinimbang mung wong sing nulis saluran pipa ETL / ELT (yen sampeyan ora ngerti apa tegese singkatan kasebut, teka menyang . Minangka iklan kontekstual).
Kita ngatasi arsitektur panyimpenan, modeling data, masalah sing ana gandhengane karo keamanan data, lan pipa dhewe, mesthi. Kita uga kudu mesthekake yen, ing tangan siji, ngarsane kita ora banget beban kanggo pangembang produk lan padha kudu diganggu minangka sethitik sabisa dening syarat kita nalika nglereni fitur anyar menyang sistem, lan ing tangan liyane, kita kudu nyedhiyakake data panyimpenan kanthi gampang kanggo analis lan tim BI. Semono uga kita urip.
Kesulitan nalika transisi saka pembangunan
Ing dina pisanan kerja, aku nemoni sawetara kesulitan sing pengin dakkandhakake karo sampeyan.
1. Ingkang kapisan ingkang kula wêruhi inggih punika botên tuling tuwin sawatawis laku. Njupuk, contone, jangkoan kode karo tes. Kita duwe atusan kerangka testing ing pembangunan. Nalika nggarap data, kabeh luwih rumit. Ya, kita bisa nyoba pipa ETL babagan data tes, nanging kita kudu nindakake kabeh kanthi manual lan golek solusi kanggo saben kasus tartamtu. Akibaté, jangkoan tes luwih elek. Begjanipun, ana lapisan umpan balik liyane ing wangun ngawasi lan log, nanging iki wis mbutuhake kita reaksi reaktif tinimbang proaktif, kang nesu lan unnerving.
2. Donya saka perspektif DE ora kaya pangembang produk biasa (uga, mesthine sing maca ora kaya ngono, lan dheweke wis ngerti kabeh, nanging aku ora ngerti lan saiki aku ngaco. munggah). Minangka pangembang, aku nggawe microservice dhewe, sijine data ing [database Sampéyan], nyimpen negara ana, njaluk soko dening ID lan iku nggoleki. Layanan iki alon, pesenan sing mbingungake, iku kabeh. Dheweke njaluk aku goleki negaraku ing layanan liyane, mula aku bakal mbuwang acara menyang sawetara RabbitMQ lan mung. Lan ing kene maneh kita bali menyang masalah acara kasebut ing ndhuwur.
Apa sing dibutuhake layanan kanggo karya operasional ora cocog karo kita kanggo data historis, mula pitakonan babagan nggarap kontrak layanan lan kerja cedhak karo tim pangembangan diwiwiti. Sampeyan malah ora bisa mbayangno carane akeh jam iku njupuk kita setuju: apa jenis Event Driven ing perusahaan kita.
3. Sampeyan kudu mikir nganggo sirah. Ora, Aku ora ateges sing pangembang ora mikir (sanajan sing aku ngomong kanggo saben wong), iku mung ing pangembangan produk kerep banget wis sawetara jenis arsitektur, lan Cut shuffles beda saka backlog. Mesthi wae, iki mbutuhake perencanaan lan pamikiran, nanging iki minangka karya stream, ing ngendi masalah utama yaiku nindakake kanthi apik lan efisien.
Kanggo kita, iku ora supaya prasaja amarga transfer macem-macem komponen sistem saka monolith anget lan mulyo menyang donya alas microservice alam bébas ora supaya prasaja. Nalika layanan wiwit spewing acara, sampeyan kudu nimbang maneh logika kanggo ngisi panyimpenan, amarga data saiki katon beda. Iki ngendi sampeyan kudu mikir akeh lan sak tenane, ora maneh minangka pangembang, nanging minangka insinyur data. Iku crita normal yen sampeyan nglampahi dina karo notebook lan pena utawa karo spidol ing Papan. Iki angel banget, aku ora seneng mikir, aku uga seneng produksi.
4. Mbok menawa sing paling penting yaiku informasi. Apa sing kita lakoni nalika kita kekurangan ilmu? Sapa sing ngomong stackoverflow? Njupuk wong iki metu saka kamar. Kita maca dokumen, buku babagan topik kasebut, lan uga ana komunitas sing ngatur forum, rapat lan konferensi. Dokumentasi apik banget, nanging sayangé, bisa uga ora lengkap. Kita nggunakake Cosmos DB ing sawetara proyek. Good luck maca dokumentasi kanggo produk iki. Buku iku siji-sijine kawilujengan; untunge, ana lan bisa ditemokake, ngemot akeh kawruh dhasar lan sampeyan kudu maca akeh lan terus-terusan. Nanging masalahe ana ing masyarakat.
Saiki angel golek paling ora siji konferensi utawa meetup sing cukup ing wilayah kita. Ora, mesthi, ana akeh ketemu karo tembung Data, nanging ing jejere tembung iki biasane ana singkatan aneh kaya ML utawa AI. Dadi, iki dudu kanggo kita, kita ngomong babagan carane mbangun fasilitas panyimpenan, lan dudu carane smear awake dhewe karo neuron. Hipsters iki wis njupuk kabeh. Akibaté, kita tanpa komunitas. Miturut cara, yen sampeyan minangka Data Engineer lan ngerti komunitas sing apik, tulis ing komentar.
Kesimpulan lan pengumuman rapat
Apa kita mungkasi? Pengalaman pisananku ngandhani yen perasaan ing sepatu insinyur data bakal migunani kanggo saben pangembang. Iku mung ngidini kita kanggo ndeleng iku beda lan ora kaget nalika mripat kita nemu getih nalika ndeleng carane pangembang nambani data sing. Dadi, yen ana DE ing perusahaan sampeyan, ngomong karo wong-wong iki, sampeyan bakal sinau akeh perkara anyar (babagan sampeyan dhewe).
Lan pungkasane, pengumuman. Amarga angel golek rapat ing topik kita ing wayah awan, kita mutusake nggawe dhewe. Napa kita luwih elek? Untunge kita duwe sing apik tenan lan kanca-kanca saka , sing, kaya kita, ngrasa yen insinyur data ora entuk perhatian.
Kanthi kesempatan iki, aku ngajak kabeh wong sing pengin teka ing rapat komunitas sing pertama kanthi judhul "DE or DIE", sing bakal ditindakake tanggal 27.02.2020 Februari XNUMX ing kantor Dodo Pizza. Rincian ing .
Yen ana apa-apa, aku bakal ana ing kana, sampeyan bisa ngomong kanthi pribadi babagan aku salah babagan pangembang.
Source: www.habr.com