Komence de decembro, mi faris fatalan eraron kaj faris turnopunkton en mia vivo kiel programisto kaj translokiĝis al la Datuma Inĝenierado (DE) teamo ene de la firmao. En ĉi tiu artikolo mi dividos kelkajn observojn, kiujn mi faris dum du monatoj da laborado en la DE-teamo.
Kial Datuma Inĝenierado?
Mia vojaĝo al DE komenciĝis en la somero de 2019, kiam ni ni iru al , kaj tie mi atingis kleriĝon. Mi komencis interesiĝi pri la temo, studi algoritmojn kaj eĉ pri ili , kaj tiam pensis pri la amplekso de aplikaĵo kaj rapide eksciis, ke la praktika apliko en nia kompanio estas distribuitaj datumbazoj.
Kion precize faras nia teamo? Ni, kiel ĉiuj modaj knaboj kaj knabinoj, volas fariĝi Daten Driven Company. Kaj por ke ĉi tio fariĝu ebla, ni devas almenaŭ konstrui fidindan stokejon, kiu povas esti uzata por konstrui ajnajn raportojn, kiujn la kompanio bezonas. Sed la plej grava afero estas, ke la datumoj en ĉi tiu stokado devas esti fidindaj. Krome, uzante ĉi tiujn datumojn, vi devas povi restarigi la staton de la sistemo je la tempo t. Ĉio ĉi estas komplikita de la fakto, ke ni vivas en kuraĝa nova mondo de mikroservoj, kaj ĉi tiu ideologio implicas, ke ĉiu servo efektivigas sian propran malgrandan funkciecon, ĝia datumbazo estas sia propra komerco, kaj ĝi povas forigi ĝin almenaŭ ĉiutage, sed je samtempe ni devas povi ricevi kaj prilabori la staton de la servo.
Se vi volas esti Datenmovita, unue fariĝu Event Driven
Ne tiel simpla. Eventoj estas malsamaj, kaj la programisto kaj datuma inĝeniero rigardas ilin malsame. Paroli pri eventoj estas temo por aparta artikolo, do mi ne eniros ĝin ĉi tie. Krome, tia artikolo jam havas certa Martin Fowler, mi ne forprenos liajn laŭrojn, li ankaŭ famiĝu.
Ĝenerale, estas multe por pensi kaj tial ĉi tiu areo estas alloga. Okazas, ke en nia kompanio, Datuma Inĝeniero estas multe pli larĝa areo de respondeco ol nur persono, kiu skribas ETL/ELT-duktojn (se vi ne scias, kion signifas ĉi tiuj mallongigoj, venu al . Kiel kunteksta reklamado).
Ni traktas stokan arkitekturon, datummodeladon, aferojn rilatajn al datumsekureco, kaj la duktoj mem, kompreneble. Ni ankaŭ devas certigi ke, unuflanke, nia ĉeesto ne estas tre ŝarĝa por produktprogramistoj kaj ili devas esti distritaj kiel eble plej malmulte de niaj postuloj dum tranĉado de novaj funkcioj en la sistemon, kaj aliflanke, ni bezonas provizi ilin oportune aranĝitaj en stokado-datumoj por analizistoj kaj BI-teamo. Tiel ni vivas.
Malfacilaĵoj dum transiro de evoluo
En mia unua labortago, mi renkontis kelkajn malfacilaĵojn, kiujn mi volas dividi kun vi.
1. La unua afero, kiun mi vidis, estis la foresto de tuling kaj kelkaj praktikoj. Prenu, ekzemple, kodan kovradon per testoj. Ni havas centojn da testaj kadroj en disvolviĝo. Kiam vi laboras kun datumoj, ĉio estas pli komplika. Jes, ni povas testi ETL-duktojn pri testaj datumoj, sed ni devas fari ĉion permane kaj serĉi solvojn por ĉiu specifa kazo. Kiel rezulto, testa kovrado estas multe pli malbona. Feliĉe, ekzistas alia tavolo de sugestoj en la formo de monitorado kaj protokoloj, sed ĉi tio jam postulas, ke ni reagu reaktive prefere ol proaktive, kio estas indigniga kaj maltrankviliga.
2. La mondo el DE-perspektivo tute ne estas tia, kia ĝi ŝajnas al ordinara produktoprogramisto (nu, kompreneble la leganto ne estas tia, kaj li jam scias ĉion, sed mi ne sciis kaj nun mi fiŝas). ĝi supren). Kiel programisto, mi kreas mian propran mikroservon, metas la datumojn en [datumbazon de via elekto], konservas mian staton tie, ricevas ion per identigilo kaj estas bone. La servo estas malrapida, mendoj estas konfuzaj, jen ĉio. Ili petas min serĉi mian staton en alia servo, do mi ĵetos eventon en iu RabbitMQ kaj jen ĝi. Kaj ĉi tie ni denove revenis al la temo de eventoj priskribitaj supre.
Kion la servo bezonas por funkcia laboro, ne konvenas al ni por historiaj datumoj, do komenciĝas la demando pri relaborado de servaj kontraktoj kaj proksima laboro kun evoluigaj teamoj. Vi eĉ ne povas imagi kiom da horoj ni bezonis por konsenti: kia Event Driven li estas en nia kompanio.
3. Vi devas pensi per via kapo. Ne, mi ne volas diri, ke programistoj ne pensas (kvankam kiu estas mi por paroli por ĉiuj), estas nur ke en produkta disvolviĝo tre ofte vi jam havas ian arkitekturon, kaj vi tranĉas malsamajn miksaĵojn de la restaro. Kompreneble, ĉi tio postulas planadon kaj penson, sed ĉi tio estas flua laboro, kie la ĉefa problemo estas simple fari ĝin bone kaj efike.
Por ni, ĝi ne estas tiel simpla ĉar la translokigo de diversaj sistemaj komponantoj de varma kaj komforta monolito en la mondon de la sovaĝa mikroserva ĝangalo ne estas tiel simpla. Kiam la servo komencas ŝpruci eventojn, vi devas rekonsideri la logikon por plenigi la stokadon, ĉar la datumoj nun aspektas malsama. Ĉi tie vi devas pensi multe kaj ĝisfunde, ne plu kiel programisto, sed kiel datuma inĝeniero. Estas normala rakonto kiam vi pasigas tagojn kun kajero kaj plumo aŭ kun markilo ĉe la tabulo. Ĝi estas tre malfacila, mi ne ŝatas pensi, ankaŭ mi amas produktadon.
4. Eble la plej grava afero estas informo. Kion ni faras kiam mankas al ni scio? Kiu diris stackoverflow? Prenu ĉi tiun personon el la ĉambro. Ni iras legi dokumentojn, librojn pri la temo, kaj ankaŭ ekzistas komunumo, kiu organizas forumojn, renkontiĝojn kaj konferencojn. Dokumentado estas bonega, sed bedaŭrinde ĝi povas esti nekompleta. Ni uzas Cosmos DB en kelkaj projektoj. Bonŝancon legante la dokumentaron por ĉi tiu produkto. Libroj estas la sola savo; feliĉe, ili ekzistas kaj troveblas, ili enhavas multajn fundamentajn sciojn kaj oni devas legi multe kaj konstante. Sed la problemo estas kun la komunumo.
Nun estas malfacile trovi almenaŭ unu taŭgan konferencon aŭ renkontiĝon en nia regiono. Ne, kompreneble, estas multaj renkontiĝoj kun la vorto Datumoj, sed apud ĉi tiu vorto estas kutime strangaj mallongigoj kiel ML aŭ AI. Do, ĉi tio ne estas por ni, ni parolas pri kiel konstrui stokejojn, kaj ne kiel ŝmiri nin per neŭronoj. Ĉi tiuj hipsteroj transprenis ĉion. Kiel rezulto, ni estas sen komunumo. Cetere, se vi estas Datuma Inĝeniero kaj konas bonajn komunumojn, bonvolu skribi en la komentoj.
Konkludoj kaj anonco de la renkontiĝo
Kion ni finas? Mia unua sperto diras al mi, ke sento en la ŝuoj de datuma inĝeniero estos utila por ĉiu programisto. Ĝi nur permesas al ni rigardi aferojn alimaniere kaj ne surpriziĝi, kiam niaj okuloj estas sangaj kiam ni vidas kiel programistoj traktas siajn datumojn. Do, se estas DE en via kompanio, nur parolu kun ĉi tiuj uloj, vi lernos multajn novajn aferojn (pri vi mem).
Kaj fine, la anonco. Ĉar estas malfacile trovi renkontiĝojn pri nia temo dum la tago, ni decidis fari nian propran. Kial ni estas pli malbonaj? Feliĉe ni havas mirindan kaj niaj amikoj de , kiuj, kiel ni, sentas, ke datumaj inĝenieroj estas maljuste senigitaj de atento.
Profitante ĉi tiun ŝancon, mi invitas ĉiujn, kiuj zorgas, veni al nia unua komunuma renkontiĝo kun la promesplena titolo "DE aŭ DIE", kiu okazos la 27.02.2020-an de februaro XNUMX ĉe la oficejo de Dodo Pizza. Detaloj ĉe .
Se io okazos, mi estos tie, vi povas diri al mi persone al mi, kiom mi eraras pri la programistoj.
fonto: www.habr.com