Tidlig i desember gjorde jeg en fatal feil og tok en avgjørende avgjørelse i livet mitt som utvikler, og jeg flyttet til Data Engineering (DE)-teamet i selskapet. I denne artikkelen vil jeg dele noen observasjoner jeg gjorde meg i løpet av mine to måneder i DE-teamet.
Hvorfor datateknikk?
Reisen min i DE begynte sommeren 2019, da vi la oss gå til , og der nådde jeg opplysning. Jeg begynte å interessere meg for emnet, studere algoritmer og til og med om dem , og så tenkte jeg på anvendelsesområdet og fant raskt ut at den praktiske anvendelsen i vårt selskap er distribuerte databaser.
Hva gjør teamet vårt egentlig? Vi, som alle moteriktige gutter og jenter, ønsker å bli et datadrevet selskap. Og for at dette skal være mulig, må vi i det minste bygge en pålitelig lagring som kan brukes til å bygge alle rapporter selskapet trenger. Men det viktigste er at dataene i denne lagringen må være pålitelige. Dessuten må vi ved å bruke disse dataene kunne gjenopprette systemets tilstand på tidspunkt t. Alt dette kompliseres av det faktum at vi lever i en modig ny verden av mikrotjenester, og denne ideologien innebærer at hver tjeneste implementerer sin egen lille funksjonalitet, databasen er sin egen virksomhet, og den kan slette den hver dag, men samtidig må vi kunne motta og behandle tjenestens tilstand.
Hvis du vil være datadrevet, må du først bli hendelsesdrevet.
Det er ikke så enkelt. Hendelser er forskjellige, og en utvikler og en dataingeniør ser på dem på forskjellige måter. Å snakke om hendelser er et tema for en egen artikkel, så jeg vil ikke gå inn på det her. Dessuten er en slik artikkel allerede skrevet. en viss Martin Fowler, jeg vil ikke ta fra ham laurbærene, la ham også bli berømt.
Generelt sett er det noe å tenke på, og det er det som gjør dette området attraktivt. Det har seg slik at i vårt selskap er dataingeniør et mye bredere ansvarsområde enn bare en person som skriver ETL/ELT-pipelines (hvis du ikke vet hva disse forkortelsene betyr, kom til ...) . Om rettighetene til kontekstuell annonsering).
Vi håndterer arkitekturen til lagringskonstruksjonen, datamodellering, problemstillinger knyttet til datasikkerhet og selve pipelinene, selvfølgelig. Og vi må også sørge for at vår tilstedeværelse på den ene siden ikke er for byrdefull for produktutviklere, og at de må bli distrahert så lite som mulig av våre krav når de integrerer nye funksjoner i systemet, og på den andre siden må vi tilby data som er praktisk plassert i lagringen for analytikere og BI-teamet. Det er slik vi lever.
Vanskeligheter med overgangen fra utvikling
På min aller første dag på jobben møtte jeg på en rekke utfordringer som jeg vil dele med deg.
1. Det første jeg la merke til var mangelen på verktøy og noen fremgangsmåter. Ta for eksempel kodedekning med tester. I utvikling har vi hundre og femti rammeverk for testing. Når vi jobber med data, er alt mer komplisert. Ja, vi kan teste ETL-pipelines på testdata, men vi må gjøre alt manuelt og se etter løsninger for hvert enkelt tilfelle. Som et resultat er testdekningen mye dårligere. Heldigvis finnes det et ekstra lag med tilbakemeldinger i form av overvåking og logger, men dette krever allerede at vi reagerer reaktivt, ikke proaktivt, noe som er irriterende og urovekkende.
2. Verden fra DE-perspektivet er slett ikke den samme som den ser ut for en vanlig produktutvikler (vel, selvfølgelig er ikke leseren sånn, og han vet allerede alt, men jeg visste ikke det, og nå forstår jeg det). Som utvikler sager jeg mikrotjenesten min, legger dataene i [database du velger], lagrer tilstanden min der, får noe med ID-en min, og alt er i orden. Tjenesten kjører, ordrene blir grumsete, alt det der. De ber meg rote gjennom tilstanden min i en annen tjeneste, vel, jeg legger inn en hendelse i en eller annen RabbitMQ, og det er det. Og her er vi tilbake til problemet med hendelser beskrevet ovenfor.
Det tjenesten trenger av operativt arbeid passer ikke for oss med historiske data, spørsmålet om å omarbeide servicekontraktene og samarbeide tett med utviklingsteamene begynner. Du kan ikke engang forestille deg hvor mange timer det tok oss å bli enige: hva er denne hendelsesdrevne utviklingen i vårt selskap?
3. Du må tenke med hodet. Nei, jeg mener ikke at utviklere ikke tenker (men hvem er jeg til å snakke for alle), det er bare det at i produktutvikling har du ofte allerede en slags arkitektur, og du sager forskjellige ting fra etterslepet. Dette krever selvfølgelig planlegging og tenkning, men dette er et flytarbeid, hvor hovedproblemet rett og slett er å gjøre det bra og med høy kvalitet.
Det er ikke så lett for oss, fordi overføringen av ulike systemkomponenter fra en varm og koselig monolitt til en verden av ville mikrotjenestejungler ikke er så lett. Når en tjeneste begynner å sende ut hendelser, må man revurdere logikken bak å fylle lagringsplassen, fordi dataene nå ser annerledes ut. Her må man tenke mye og grundig, ikke som utvikler, men som dataingeniør. Det er en vanlig historie når man tilbringer dager med en notatbok og en penn eller en tusj ved tavlen. Det er veldig vanskelig, jeg liker ikke å tenke, jeg liker pang-pang og inn i produksjon.
4. Det kanskje viktigste er informasjon. Hva gjør vi når vi mangler kunnskap? Hvem sa stackoverflow? Få den personen ut av rommet. Vi går og leser dokumentasjon, bøker om emnet, og det finnes også et fellesskap som organiserer forum, møter og konferanser. Dokumentasjonen er flott, men dessverre er den noen ganger ufullstendig. Vi bruker Cosmos DB i en rekke prosjekter. Lykke til med å lese dokumentasjonen for dette produktet. Bøker er den eneste redningen, heldigvis finnes de og kan finnes, de inneholder mye grunnleggende kunnskap, og du må lese mye og konstant. Men fellesskapet er en katastrofe.
Det er vanskelig å finne én eneste passende konferanse eller møte innen vårt felt nå. Selvfølgelig finnes det mange møter med ordet data, men vanligvis står det merkelige forkortelser som ML eller AI ved siden av dette ordet. Vel, dette er ikke noe for oss, vi snakker om hvordan man bygger lagringsfasiliteter, ikke hvordan man smører ut nevrale nettverk. Disse hipsterne har fylt alt. Som et resultat er vi uten et fellesskap. Forresten, hvis du er en dataingeniør og kjenner til gode fellesskap, skriv gjerne i kommentarfeltet.
Konklusjoner og kunngjøring av møtet
Hva har vi til slutt? Min første erfaring forteller meg at det vil være nyttig for alle utviklere å føle seg i en dataingeniørs sko. Det lar deg se ting annerledes og ikke bli overrasket når øynene våre blør når vi ser hvordan utviklere håndterer dataene sine. Så hvis det finnes en dataingeniør i bedriften din, snakk bare med disse gutta, du vil lære mye nytt (om deg selv).
Og til slutt, en kunngjøring. Siden det knapt er noen møter om temaet vårt, bestemte vi oss for å lage våre egne. Hva, er vi noe verre? Heldigvis har vi en fantastisk og våre venner fra , som i likhet med oss føler at dataingeniører blir urettferdig neglisjert.
Jeg benytter anledningen til å invitere alle som ikke er likegyldige til å komme til vårt første samfunnsmøte med det lovende navnet «DE or DIE», som finner sted 27.02.2020 på kontoret til Dodo Pizza. Detaljer på .
Hvis noe, så vil jeg være der, du kan fortelle meg personlig rett i ansiktet hvor feil jeg tar om utviklerne.
Kilde: www.habr.com
