I begyndelsen af december begik jeg en fatal fejl og lavede et vendepunkt i mit liv som udvikler og flyttede til Data Engineering (DE) teamet i virksomheden. I denne artikel vil jeg dele nogle observationer, som jeg gjorde i løbet af to måneders arbejde i DE-teamet.
Hvorfor Data Engineering?
Min rejse til DE begyndte i sommeren 2019, da vi Lad os gå til , og der opnåede jeg oplysning. Jeg begyndte at blive interesseret i emnet, studere algoritmer og endda om dem , og så tænkte over anvendelsesområdet og fandt hurtigt ud af, at den praktiske anvendelse i vores virksomhed er distribuerede databaser.
Hvad gør vores team helt præcist? Vi, som alle moderigtige drenge og piger, ønsker at blive en datadrevet virksomhed. Og for at dette kan blive muligt, skal vi i det mindste bygge et pålideligt lager, som kan bruges til at opbygge de rapporter, virksomheden har brug for. Men det vigtigste er, at dataene i dette lager skal være tillid til. Ved at bruge disse data skal du desuden være i stand til at gendanne systemets tilstand på tidspunktet t. Alt dette kompliceres af det faktum, at vi lever i en modig ny verden af mikrotjenester, og denne ideologi indebærer, at hver tjeneste implementerer sin egen lille funktionalitet, dens database er sin egen virksomhed, og den kan slette den mindst hver dag, men kl. samtidig skal vi kunne modtage og behandle tjenestens tilstand.
Hvis du vil være datadrevet, skal du først blive begivenhedsdrevet
Ikke så simpelt. Begivenheder er forskellige, og udvikleren og dataingeniøren ser forskelligt på dem. At tale om begivenheder er et emne for en separat artikel, så jeg vil ikke komme ind på det her. Derudover har en sådan artikel allerede en vis Martin Fowler, jeg vil ikke tage hans laurbær, lad ham også blive berømt.
Generelt er der meget at tænke på, og derfor er dette område attraktivt. Det sker bare sådan, at i vores virksomhed er en dataingeniør et meget bredere ansvarsområde end blot en person, der skriver ETL/ELT pipelines (hvis du ikke ved, hvad disse forkortelser betyder, så kom til . Som kontekstuel reklame).
Vi beskæftiger os med lagringsarkitektur, datamodellering, spørgsmål relateret til datasikkerhed og selvfølgelig selve pipelines. Vi skal også sikre os, at vores tilstedeværelse på den ene side ikke er særlig byrdefuld for produktudviklere, og at de skal distraheres så lidt som muligt af vores krav, når vi skærer nye funktioner ind i systemet, og på den anden side skal vi behov for at give dem bekvemt lagt ud i lagringsdata til analytikere og BI-team. Sådan lever vi.
Vanskeligheder ved overgang fra udvikling
På min første arbejdsdag stødte jeg på en række vanskeligheder, som jeg gerne vil dele med jer.
1. Det første jeg så var fraværet af tuling og nogle øvelser. Tag for eksempel kodedækning med tests. Vi har hundredvis af testrammer under udvikling. Når man arbejder med data, er alt mere kompliceret. Ja, vi kan teste ETL-pipelines på testdata, men vi skal gøre det hele manuelt og lede efter løsninger til hvert enkelt tilfælde. Som følge heraf er testdækningen meget dårligere. Heldigvis er der endnu et lag af feedback i form af overvågning og logs, men det kræver allerede, at vi reagerer reaktivt frem for proaktivt, hvilket er irriterende og irriterende.
2. Verden set fra et DE-perspektiv er slet ikke, hvad den ser ud til for en almindelig produktudvikler (nå, sådan er læseren selvfølgelig ikke, og han ved allerede alt, men jeg vidste det ikke, og nu er jeg ved at skrue det op). Som udvikler opretter jeg min egen mikroservice, lægger dataene i [database efter eget valg], gemmer min tilstand der, får noget ved ID, og det er fint. Tjenesten er langsom, ordrer er forvirrende, det er alt. De beder mig om at lede efter min tilstand i en anden tjeneste, så jeg smider en begivenhed ind i en RabbitMQ, og det er det. Og her vendte vi igen tilbage til spørgsmålet om begivenheder beskrevet ovenfor.
Hvad servicen har brug for til operationelt arbejde, passer os ikke for historiske data, så spørgsmålet om omarbejdelse af servicekontrakter og tæt samarbejde med udviklingsteams begynder. Du kan slet ikke forestille dig, hvor mange timer det tog os at blive enige: hvilken slags Event Driven han er i vores virksomhed.
3. Du skal tænke med hovedet. Nej, jeg mener ikke, at udviklere ikke tænker (selvom hvem er jeg til at tale for alle), det er bare, at man i produktudvikling meget ofte allerede har en form for arkitektur, og man skærer forskellige shuffles fra efterslæbet. Det kræver selvfølgelig planlægning og omtanke, men det er strømarbejde, hvor hovedproblemet blot er at gøre det godt og effektivt.
For os er det ikke så enkelt, fordi overførslen af forskellige systemkomponenter fra en varm og hyggelig monolit til verden af den vilde mikroservice-jungle ikke er så enkel. Når tjenesten begynder at udsende hændelser, skal du genoverveje logikken for at fylde lageret, fordi dataene nu ser anderledes ud. Det er her, du skal tænke meget og grundigt, ikke længere som udvikler, men som dataingeniør. Det er en normal historie, når du tilbringer dage med en notesbog og kuglepen eller med en tusch ved tavlen. Det er meget svært, jeg kan ikke lide at tænke, jeg elsker også produktion.
4. Det vigtigste er måske information. Hvad gør vi, når vi mangler viden? Hvem sagde stackoverflow? Tag denne person ud af rummet. Vi læser dokumenter, bøger om emnet, og der er også et fællesskab, der arrangerer fora, møder og konferencer. Dokumentationen er fantastisk, men den kan desværre være ufuldstændig. Vi bruger Cosmos DB i en række projekter. Held og lykke med at læse dokumentationen til dette produkt. Bøger er den eneste redning, heldigvis findes de og kan findes, de indeholder en masse grundlæggende viden, og du skal læse meget og konstant. Men problemet ligger i samfundet.
Nu er det svært at finde mindst én passende konference eller møde i vores område. Nej, selvfølgelig er der mange meetups med ordet Data, men ved siden af dette ord er der normalt mærkelige forkortelser som ML eller AI. Så det er ikke for os, vi taler om, hvordan man bygger lagerfaciliteter, og ikke hvordan man smører os selv med neuroner. Disse hipstere har overtaget alt. Som følge heraf står vi uden et fællesskab. Hvis du i øvrigt er dataingeniør og kender til gode fællesskaber, så skriv gerne i kommentarerne.
Konklusioner og annoncering af mødet
Hvad ender vi med? Min første erfaring fortæller mig, at følelsen i en dataingeniørs sko vil være nyttig for enhver udvikler. Det giver os bare mulighed for at se anderledes på tingene og ikke blive overrasket, når vores øjne bliver blodskudte, når vi ser, hvordan udviklere behandler deres data. Så hvis der er en DE i din virksomhed, så tal bare med disse fyre, du vil lære en masse nye ting (om dig selv).
Og endelig meddelelsen. Da det er svært at finde møder om vores emne i løbet af dagen, besluttede vi at lave vores eget. Hvorfor er vi værre? Heldigvis har vi en fantastisk og vores venner fra , der ligesom os føler, at dataingeniører uretfærdigt bliver frataget opmærksomheden.
Ved at benytte denne mulighed inviterer jeg alle, der har lyst til at komme til vores første community-møde med den lovende titel "DE or DIE", som finder sted den 27.02.2020. februar XNUMX på Dodo Pizza-kontoret. Detaljer kl .
Hvis der sker noget, vil jeg være der, du kan fortælle mig personligt, hvor forkert jeg er med udviklerne.
Kilde: www.habr.com