Begjin desimber makke ik in fatale flater en makke in kearpunt yn myn libben as ûntwikkelder en ferhuze nei it team fan Data Engineering (DE) binnen it bedriuw. Yn dit artikel sil ik wat observaasjes diele dy't ik makke yn twa moannen fan wurkjen yn it DE-team.
Wêrom Data Engineering?
Myn reis nei DE begon yn 'e simmer fan 2019, doe't wy litte wy nei , en dêr berikte ik ferljochting. Ik begon ynteressearre te wurden yn it ûnderwerp, studearje algoritmen en sels oer har , en doe tocht oer de omfang fan tapassing en gau fûn út dat de praktyske tapassing yn ús bedriuw is ferspraat databases.
Wat docht ús team krekt? Wy wolle, lykas alle modieuze jonges en famkes, in Data Driven Company wurde. En om dit mooglik te wurden, moatte wy op syn minst in betroubere opslachfoarsjenning bouwe, dy't brûkt wurde kin om alle rapporten te bouwen dy't it bedriuw nedich is. Mar it wichtichste is dat de gegevens yn dizze opslach fertroud wurde moatte. Boppedat, mei help fan dizze gegevens, jo moatte by steat wêze om te herstellen de steat fan it systeem op tiid t. Dit alles wurdt yngewikkeld troch it feit dat wy libje yn in dappere nije wrâld fan mikrotsjinsten, en dizze ideology ymplisearret dat elke tsjinst syn eigen lytse funksjonaliteit ymplementearret, syn database is syn eigen bedriuw, en it kin it op syn minst elke dei wiskje, mar by tagelyk moatte wy de steat fan 'e tsjinst kinne ûntfange en ferwurkje.
As jo Data Driven wolle wurde, wurde earst Event Driven
Net sa ienfâldich. Eveneminten binne oars, en de ûntwikkelder en data-yngenieur sjogge der oars nei. Prate oer eveneminten is in ûnderwerp foar in apart artikel, dat ik gean hjir net op. Boppedat hat sa'n artikel al in sekere Martin Fowler, ik sil syn lauweren net ôfnimme, lit him ek ferneamd wurde.
Oer it algemien is der in soad te tinken en dêrom is dit gebiet oantreklik. It bart sa dat yn ús bedriuw in Data Engineer in folle breder gebiet fan ferantwurdlikens is dan allinich in persoan dy't ETL / ELT pipelines skriuwt (as jo net witte wat dizze ôfkoartings betsjutte, kom dan nei . As kontekstuele reklame).
Wy dogge mei opslacharsjitektuer, gegevensmodellering, problemen yn ferbân mei gegevensfeiligens, en de pipelines sels, fansels. Wy moatte der ek foar soargje dat, oan 'e iene kant, ús oanwêzigens net heul lestich is foar produktûntwikkelders en dat se sa min mooglik ôfliede moatte troch ús easken by it snijden fan nije funksjes yn it systeem, en oan 'e oare kant moatte wy moatte se handich oanlein wurde yn opslachgegevens foar analysten en BI-team. Sa libje wy.
Swierrichheden by de oergong fan ûntwikkeling
Op myn earste wurkdei kaam ik in oantal swierrichheden tsjin dy't ik mei jo diele wol.
1. It earste ding dat ik seach wie it ûntbrekken fan tuling en guon praktiken. Nim bygelyks koade dekking mei tests. Wy hawwe hûnderten testkaders yn ûntwikkeling. By it wurkjen mei gegevens is alles yngewikkelder. Ja, wy kinne ETL-pipelines testen op testgegevens, mar wy moatte it allegear mei de hân dwaan en sykje nei oplossingen foar elk spesifyk gefal. As resultaat is de testdekking folle slimmer. Gelokkich is d'r in oare laach fan feedback yn 'e foarm fan tafersjoch en logs, mar dit fereasket al fan ús om reaktyf te reagearjen ynstee fan proaktyf, wat ferfelend en nervend is.
2. De wrâld út in DE-perspektyf is hielendal net wat it liket foar in gewoane produktûntwikkelder (no, de lêzer is fansels net sa, en hy wit alles al, mar ik wist it net en no bin ik oan it skroeven it op). As ûntwikkelder meitsje ik myn eigen mikrotsjinst, set de gegevens yn [database fan jo kar], bewarje myn steat dêr, krij wat mei ID en it is goed. De tsjinst is stadich, oarders binne betiizjend, dat is alles. Se freegje my om myn steat te sykjen yn in oare tsjinst, dus ik sil in evenemint yn guon RabbitMQ smite en dat is it. En hjir kamen wy wer werom nei de hjirboppe beskreaune kwestje fan eveneminten.
Wat de tsjinst nedich is foar operasjoneel wurk, past ús net foar histoaryske gegevens, dus begjint de fraach fan werynrjochting fan tsjinstkontrakten en nau wurk mei ûntwikkelingsteams. Jo kinne jo net iens foarstelle hoefolle oeren it ús duorre om iens te wurden: wat foar Event Driven hy is yn ús bedriuw.
3. Jo moatte tinke mei jo holle. Nee, ik bedoel net dat ûntwikkelders net tinke (hoewol't wa bin ik om foar elkenien te sprekken), it is gewoan dat jo yn produktûntwikkeling heul faak al in soarte fan arsjitektuer hawwe, en jo snije ferskate shuffles út 'e efterstân. Dat freget fansels plannen en tinken, mar dit is streamwurk, dêr't it wichtichste probleem gewoan is om it goed en effisjint te dwaan.
Foar ús is it net sa ienfâldich, om't de oerdracht fan ferskate systeemkomponinten fan in waarme en gesellige monolith yn 'e wrâld fan' e wylde mikroservice-jungle net sa ienfâldich is. As de tsjinst eveneminten begjint te spuien, moatte jo de logika foar it ynfoljen fan de opslach opnij besjen, om't de gegevens no oars sjogge. Dit is wêr't jo in protte en yngeand tinke moatte, net langer as ûntwikkelder, mar as data-yngenieur. It is in normaal ferhaal as jo dagen trochbringe mei in notebook en pinne of mei in marker oan it boerd. It is hiel lestich, ik tink net graach, ik hâld ek fan produksje.
4. Miskien is it wichtichste ynformaasje. Wat dogge wy as wy gjin kennis hawwe? Wa sei stackoverflow? Nim dizze persoan út 'e keamer. Wy geane dokuminten, boeken oer it ûnderwerp te lêzen, en d'r is ek in mienskip dy't foarums, gearkomsten en konferinsjes organisearret. Dokumintaasje is geweldich, mar spitigernôch kin it ûnfolslein wêze. Wy brûke Cosmos DB yn in oantal projekten. Good luck it lêzen fan de dokumintaasje foar dit produkt. Boeken binne it iennichste heil, gelokkich bestean se en binne se te finen, se befetsje in protte fûnemintele kennis en jo moatte in protte en konstant lêze. Mar it probleem sit by de mienskip.
No is it lestich te finen op syn minst ien adekwate konferinsje of meetup yn ús gebiet. Nee, fansels, d'r binne in protte moetings mei it wurd Data, mar neist dit wurd steane meastentiids nuvere ôfkoartings lykas ML of AI. Dat, dit is net foar ús, wy prate oer hoe't jo opslachfoarsjenningen bouwe, en net hoe't wy ússels mei neuroanen smeerje. Dizze hipsters hawwe alles oernommen. Dêrtroch sitte wy sûnder mienskip. Trouwens, as jo in Data Engineer binne en goede mienskippen kenne, skriuw dan asjebleaft yn 'e opmerkings.
Konklúzjes en oankundiging fan 'e gearkomste
Wat komme wy mei? Myn earste ûnderfining fertelt my dat gefoel yn 'e skuon fan in data-yngenieur nuttich wêze sil foar elke ûntwikkelder. It lit ús gewoan oars nei dingen sjen en net ferrast wurde as ús eagen bloedshot krije as wy sjogge hoe't ûntwikkelders har gegevens behannelje. Dus, as d'r in DE yn jo bedriuw is, praat gewoan mei dizze jonges, jo sille in protte nije dingen leare (oer josels).
En as lêste, de oankundiging. Om't it oerdei lestich is om gearkomsten te finen oer ús ûnderwerp, hawwe wy besletten om ús eigen te meitsjen. Wêrom binne wy slimmer? Gelokkich hawwe wy in amazing en ús freonen út , dy't, lykas ús, fiele dat data-yngenieurs ûnrjochtfeardich fan oandacht ûntnommen wurde.
Troch dizze kâns te nimmen, noegje ik elkenien út dy't it jout om nei ús earste mienskipsgearkomste te kommen mei de kânsrike titel "DE or DIE", dy't plakfine sil op 27.02.2020 febrewaris XNUMX by it Dodo Pizza-kantoar. Details by .
As der wat bart, sil ik der wêze, jo kinne my persoanlik oan myn gesicht fertelle hoe ferkeard ik bin oer de ûntwikkelders.
Boarne: www.habr.com