Aan die begin van Desember het ek 'n noodlottige fout gemaak en 'n keerpunt in my lewe as 'n ontwikkelaar gemaak en na die Data Engineering (DE)-span binne die maatskappy oorgeskuif. In hierdie artikel sal ek 'n paar waarnemings deel wat ek gemaak het gedurende twee maande van werk in die DE-span.
Hoekom Data Engineering?
My reis na DE het in die somer van 2019 begin, toe ons kom ons gaan na , en daar het ek verligting bereik. Ek het begin belangstel in die onderwerp, algoritmes bestudeer en selfs daaroor , en het toe oor die omvang van die toepassing gedink en vinnig uitgevind dat die praktiese toepassing in ons maatskappy verspreide databasisse is.
Wat presies doen ons span? Ons, soos alle modieuse seuns en meisies, wil 'n datagedrewe maatskappy word. En om dit moontlik te maak, moet ons ten minste 'n betroubare bergingsfasiliteit bou, wat gebruik kan word om enige verslae te bou wat die maatskappy benodig. Maar die belangrikste ding is dat die data in hierdie berging vertrou moet word. Verder, met behulp van hierdie data, moet jy in staat wees om die toestand van die stelsel te herstel op tyd t. Dit alles word gekompliseer deur die feit dat ons in 'n dapper nuwe wΓͺreld van mikrodienste leef, en hierdie ideologie impliseer dat elke diens sy eie klein funksionaliteit implementeer, sy databasis is sy eie besigheid, en dit kan dit ten minste elke dag uitvee, maar by terselfdertyd moet ons die stand van die diens kan ontvang en verwerk.
As jy datagedrewe wil wees, word eers Gebeurtenisgedrewe
Nie so eenvoudig nie. Gebeurtenisse is anders, en die ontwikkelaar en data-ingenieur kyk anders daarna. Om oor gebeure te praat is 'n onderwerp vir 'n aparte artikel, so ek gaan nie hier in nie. Daarbenewens het so 'n artikel reeds 'n sekere Martin Fowler, ek sal nie sy louere wegneem nie, laat hom ook beroemd word.
Oor die algemeen is daar baie om oor na te dink en daarom is hierdie area aantreklik. Dit gebeur net so dat 'n Data-ingenieur in ons maatskappy 'n baie groter verantwoordelikheidsgebied is as net 'n persoon wat ETL/ELT-pyplyne skryf (as jy nie weet wat hierdie afkortings beteken nie, kom na . As kontekstuele advertensies).
Ons hanteer bergingsargitektuur, datamodellering, kwessies wat verband hou met datasekuriteit, en die pyplyne self, natuurlik. Ons moet ook seker maak dat, aan die een kant, ons teenwoordigheid nie baie lastig vir produkontwikkelaars is nie en hulle aandag so min as moontlik deur ons vereistes afgelei moet word wanneer nuwe kenmerke in die stelsel insny, en aan die ander kant, ons moet dit gerieflik uiteengesit word in stoordata vir ontleders en BI-span verskaf. Dis hoe ons leef.
Moeilikhede tydens die oorgang van ontwikkeling
Op my eerste dag van werk het ek 'n aantal probleme ondervind wat ek met jou wil deel.
1. Die eerste ding wat ek gesien het, was die afwesigheid van tuling en 'n paar praktyke. Neem byvoorbeeld kodedekking met toetse. Ons het honderde toetsraamwerke in ontwikkeling. As u met data werk, is alles meer ingewikkeld. Ja, ons kan ETL-pyplyne op toetsdata toets, maar ons moet dit alles met die hand doen en oplossings soek vir elke spesifieke geval. Gevolglik is toetsdekking baie erger. Gelukkig is daar nog 'n laag terugvoer in die vorm van monitering en logboeke, maar dit vereis reeds van ons om reaktief te reageer eerder as proaktief, wat woedend en ontstellend is.
2. Die wΓͺreld vanuit 'n DE-perspektief is glad nie wat dit vir 'n gewone produkontwikkelaar lyk nie (wel, natuurlik, die leser is nie so nie, en hy weet reeds alles, maar ek het nie geweet nie en nou is ek skroef dit op). As 'n ontwikkelaar skep ek my eie mikrodiens, plaas die data in [databasis van jou keuse], stoor my staat daar, kry iets per ID en dit is goed. Die diens is stadig, bestellings is verwarrend, dit is al. Hulle vra my om my staat in 'n ander diens te soek, so ek sal 'n geleentheid in 'n RabbitMQ gooi en dit is dit. En hier het ons weer teruggekeer na die kwessie van gebeure wat hierbo beskryf is.
Wat die diens nodig het vir operasionele werk, pas ons nie vir historiese data nie, so die kwessie van die herbewerking van dienskontrakte en noue werk met ontwikkelingspanne begin. Jy kan jou nie eers indink hoeveel ure dit ons geneem het om saam te stem nie: watter soort Event Driven hy in ons maatskappy is.
3. Jy moet met jou kop dink. Nee, ek bedoel nie dat ontwikkelaars nie dink nie (alhoewel wie is ek om namens almal te praat), dit is net dat jy in produkontwikkeling baie dikwels reeds 'n soort argitektuur het, en jy sny verskillende skommelinge uit die agterstand. Dit verg natuurlik beplanning en deurdagte, maar dit is stroomwerk, waar die hoofprobleem bloot is om dit goed en doeltreffend te doen.
Vir ons is dit nie so eenvoudig nie, want die oordrag van verskeie stelselkomponente van 'n warm en knus monoliet na die wΓͺreld van die wilde mikrodiens-oerwoud is nie so eenvoudig nie. Wanneer die diens gebeure begin spoeg, moet jy die logika vir die vul van die stoor heroorweeg, want die data lyk nou anders. Dit is waar jy baie en deeglik moet dink, nie meer as 'n ontwikkelaar nie, maar as 'n data-ingenieur. Dit is 'n normale storie wanneer jy dae spandeer met 'n notaboek en pen of met 'n merker by die bord. Dit is baie moeilik, ek hou nie daarvan om te dink nie, ek hou ook van produksie.
4. Miskien is die belangrikste inligting. Wat doen ons as ons kennis ontbreek? Wie het gesΓͺ stapeloorvloei? Neem hierdie persoon uit die kamer. Ons gaan lees dokumente, boeke oor die onderwerp, en daar is ook 'n gemeenskap wat forums, ontmoetings en konferensies reΓ«l. Dokumentasie is wonderlik, maar ongelukkig kan dit onvolledig wees. Ons gebruik Cosmos DB in 'n aantal projekte. Sterkte met die lees van die dokumentasie vir hierdie produk. Boeke is die enigste redding; gelukkig bestaan ββen kan hulle gevind word, dit bevat baie fundamentele kennis en jy moet baie en voortdurend lees. Maar die probleem is by die gemeenskap.
Nou is dit moeilik om ten minste een voldoende konferensie of ontmoeting in ons area te vind. Nee, natuurlik, daar is baie ontmoetings met die woord Data, maar langs hierdie woord is daar gewoonlik vreemde afkortings soos ML of AI. So, dit is nie vir ons nie, ons praat oor hoe om stoorfasiliteite te bou, en nie hoe om onsself met neurone te smeer nie. Hierdie hipsters het alles oorgeneem. Gevolglik is ons sonder 'n gemeenskap. Terloops, as jy 'n data-ingenieur is en goeie gemeenskappe ken, skryf asseblief in die kommentaar.
Gevolgtrekkings en aankondiging van die ontmoeting
Waarmee eindig ons? My eerste ervaring sΓͺ vir my dat voel in die skoene van 'n data-ingenieur nuttig sal wees vir elke ontwikkelaar. Dit laat ons net anders na dinge kyk en nie verbaas wees as ons oΓ« bloedbelope word as ons sien hoe ontwikkelaars hul data hanteer nie. So, as daar 'n DE in jou geselskap is, praat net met hierdie ouens, jy sal baie nuwe dinge (van jouself) leer.
En laastens, die aankondiging. Aangesien dit moeilik is om ontmoetings oor ons onderwerp gedurende die dag te vind, het ons besluit om ons eie te maak. Hoekom is ons erger? Gelukkig het ons 'n wonderlike en ons vriende van , wat, soos ons, voel dat data-ingenieurs onregverdig van aandag ontneem word.
Met hierdie geleentheid nooi ek almal wat omgee om na ons eerste gemeenskapsbyeenkoms met die belowende titel βDE or DIEβ te kom, wat op 27.02.2020 Februarie XNUMX by die Dodo Pizza-kantoor sal plaasvind. Besonderhede by .
As iets gebeur, sal ek daar wees, jy kan vir my persoonlik vertel hoe verkeerd ek is oor die ontwikkelaars.
Bron: will.com