I begynnelsen av desember gjorde jeg en fatal feil og gjorde et vendepunkt i livet mitt som utvikler og flyttet til Data Engineering (DE)-teamet i selskapet. I denne artikkelen vil jeg dele noen observasjoner som jeg gjorde i løpet av to måneders arbeid i DE-teamet.
Hvorfor Data Engineering?
Min reise til DE begynte sommeren 2019, da vi la oss gå til , og der oppnådde jeg opplysning. Jeg begynte å bli interessert i emnet, studere algoritmer og til og med om dem , og så tenkte på omfanget av applikasjonen og fant raskt ut at den praktiske applikasjonen i vårt selskap er distribuerte databaser.
Hva gjør teamet vårt egentlig? Vi, som alle fasjonable gutter og jenter, ønsker å bli et datadrevet selskap. Og for at dette skal bli mulig, må vi i det minste bygge et pålitelig lager, som kan brukes til å bygge opp eventuelle rapporter selskapet trenger. Men det viktigste er at dataene i denne lagringen må være klarert. Ved å bruke disse dataene må du dessuten være i stand til å gjenopprette tilstanden til systemet på tidspunktet 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 minst hver dag, men kl. samtidig skal vi kunne motta og behandle tjenestens tilstand.
Hvis du ønsker å være datadrevet, må du først bli hendelsesdrevet
Ikke så enkelt. Hendelser er forskjellige, og utvikleren og dataingeniøren ser annerledes på dem. Å snakke om hendelser er et tema for en egen artikkel, så jeg vil ikke gå inn på det her. I tillegg har en slik artikkel allerede en viss Martin Fowler, jeg vil ikke ta fra ham laurbærene, la ham også bli berømt.
Generelt er det mye å tenke på og derfor er dette området attraktivt. Det hender bare at i vårt selskap er en dataingeniør et mye bredere ansvarsområde enn bare en person som skriver ETL/ELT-rørledninger (hvis du ikke vet hva disse forkortelsene betyr, kom til . Som kontekstuell annonsering).
Vi tar for oss lagringsarkitektur, datamodellering, problemstillinger knyttet til datasikkerhet og selve rørledningene, selvfølgelig. Vi må også sørge for at vår tilstedeværelse på den ene siden ikke er særlig tyngende for produktutviklere, og at de må distraheres minst mulig av våre krav når vi skal kutte nye funksjoner inn i systemet, og på den andre siden trenger å gi dem praktisk lagt ut i lagringsdata for analytikere og BI-team. Det er slik vi lever.
Vanskeligheter ved overgang fra utvikling
På min første arbeidsdag møtte jeg en rekke vanskeligheter som jeg vil dele med dere.
1. Det første jeg så var fraværet av tuling og noen øvelser. Ta for eksempel kodedekning med tester. Vi har hundrevis av testrammeverk under utvikling. Når du jobber med data er alt mer komplisert. Ja, vi kan teste ETL-rørledninger 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 er det enda et lag med tilbakemeldinger i form av overvåking og logger, men dette krever allerede at vi reagerer reaktivt i stedet for proaktivt, noe som er irriterende og irriterende.
2. Verden fra et DE-perspektiv er ikke i det hele tatt hva den ser ut til for en vanlig produktutvikler (vel, selvfølgelig er ikke leseren slik, og han vet alt, men jeg visste ikke, og nå driter jeg det opp). Som utvikler lager jeg min egen mikrotjeneste, legger dataene i [databasen du velger], lagrer staten min der, får noe med ID og det er greit. Tjenesten er treg, bestillinger er forvirrende, det er alt. De ber meg se etter staten min i en annen tjeneste, så jeg kaster en begivenhet inn i en RabbitMQ og det er det. Og her kom vi igjen til spørsmålet om hendelser beskrevet ovenfor.
Hva tjenesten trenger av operativt arbeid passer ikke oss for historiske data, så spørsmålet om omarbeiding av tjenestekontrakter og tett arbeid med utviklingsteam starter. Du kan ikke engang forestille deg hvor mange timer det tok oss å bli enige: hva slags hendelsesdrevet han er i selskapet vårt.
3. Du må tenke med hodet. Nei, jeg mener ikke at utviklere ikke tenker (selv om hvem er jeg til å snakke for alle), det er bare det at man i produktutvikling veldig ofte allerede har en slags arkitektur, og man klipper forskjellige shuffles fra backlog. Dette krever selvfølgelig planlegging og omtanke, men dette er strømmearbeid, hvor hovedproblemet rett og slett er å gjøre det godt og effektivt.
For oss er det ikke så enkelt fordi overføringen av ulike systemkomponenter fra en varm og koselig monolitt til den ville mikroservicejungelens verden ikke er så enkel. Når tjenesten begynner å spy ut hendelser, må du revurdere logikken for å fylle lagringen, fordi dataene nå ser annerledes ut. Det er her du må tenke mye og grundig, ikke lenger som utvikler, men som dataingeniør. Det er en vanlig historie når du tilbringer dager med en notatbok og penn eller med en tusj ved tavlen. Det er veldig vanskelig, jeg liker ikke å tenke, jeg elsker produksjon også.
4. Det viktigste er kanskje informasjon. Hva gjør vi når vi mangler kunnskap? Hvem sa stackoverflow? Ta denne personen ut av rommet. Vi går og leser dokumenter, bøker om emnet, og det er også et fellesskap som organiserer fora, møter og konferanser. Dokumentasjonen er flott, men dessverre kan den være ufullstendig. Vi bruker Cosmos DB i en rekke prosjekter. Lykke til med å lese dokumentasjonen for dette produktet. Bøker er den eneste redningen, heldigvis eksisterer de og kan finnes, de inneholder mye grunnleggende kunnskap og du må lese mye og konstant. Men problemet ligger i samfunnet.
Nå er det vanskelig å finne minst én tilstrekkelig konferanse eller møte i vårt område. Nei, det er selvfølgelig mange møter med ordet Data, men ved siden av dette ordet er det vanligvis rare forkortelser som ML eller AI. Så, dette er ikke for oss, vi snakker om hvordan vi bygger lagringsanlegg, og ikke hvordan vi smører oss med nevroner. Disse hipsterne har tatt over alt. Som et resultat står vi uten et fellesskap. Forresten, hvis du er dataingeniør og kjenner til gode fellesskap, vennligst skriv i kommentarfeltet.
Konklusjoner og kunngjøring av møtet
Hva ender vi opp med? Min første erfaring forteller meg at det å føle seg i skoene til en dataingeniør vil være nyttig for alle utviklere. Det lar oss bare se annerledes på ting og ikke bli overrasket når øynene våre blir blodskutte når vi ser hvordan utviklere behandler dataene deres. Så hvis det er en DE i bedriften din, bare snakk med disse gutta, du vil lære mye nytt (om deg selv).
Og til slutt, kunngjøringen. Siden det er vanskelig å finne møter om emnet vårt i løpet av dagen, bestemte vi oss for å lage våre egne. Hvorfor er vi verre? Heldigvis har vi en fantastisk og våre venner fra , som i likhet med oss føler at dataingeniører er urettferdig fratatt oppmerksomhet.
Ved å benytte denne muligheten inviterer jeg alle som bryr seg om å komme til vårt første fellesskapstreff med den lovende tittelen "DE or DIE", som vil finne sted 27.02.2020. februar XNUMX på Dodo Pizza-kontoret. Detaljer på .
Hvis noe skjer, vil jeg være der, du kan fortelle meg personlig hvor feil jeg tar med utviklerne.
Kilde: www.habr.com