I början av december gjorde jag ett fatalt misstag och gjorde en vändpunkt i mitt liv som utvecklare och flyttade till Data Engineering (DE)-teamet inom företaget. I den här artikeln kommer jag att dela med mig av några observationer som jag gjorde under två månaders arbete i DE-teamet.
Varför Data Engineering?
Min resa till DE började sommaren 2019, när vi låt oss gå till , och där uppnådde jag upplysning. Jag började bli intresserad av ämnet, studera algoritmer och till och med om dem , och funderade sedan på tillämpningsområdet och fick snabbt reda på att den praktiska tillämpningen i vårt företag är distribuerade databaser.
Vad exakt gör vårt team? Vi, som alla fashionabla killar och tjejer, vill bli ett datadrivet företag. Och för att detta ska bli möjligt behöver vi åtminstone bygga ett pålitligt lager, som kan användas för att bygga vilka rapporter företaget behöver. Men det viktigaste är att data i denna lagring måste vara pålitlig. Genom att använda dessa data måste du dessutom kunna återställa systemets tillstånd vid tidpunkten t. Allt detta kompliceras av det faktum att vi lever i en modig ny värld av mikrotjänster, och denna ideologi innebär att varje tjänst implementerar sin egen lilla funktionalitet, dess databas är sin egen verksamhet, och den kan radera den åtminstone varje dag, men kl. samtidigt måste vi kunna ta emot och bearbeta tjänstens tillstånd.
Om du vill bli datadriven, bli först händelsedriven
Inte så enkelt. Händelser är olika, och utvecklaren och dataingenjören ser olika på dem. Att prata om händelser är ett ämne för en separat artikel, så jag går inte in på det här. Dessutom har en sådan artikel redan gjort det en viss Martin Fowler, jag tar inte ifrån honom lagrarna, låt honom också bli känd.
Generellt finns det mycket att tänka på och det är därför det här området är attraktivt. Det råkar vara så att i vårt företag är en dataingenjör ett mycket bredare ansvarsområde än bara en person som skriver ETL/ELT pipelines (om du inte vet vad dessa förkortningar betyder, kom till . Som kontextuell reklam).
Vi sysslar med lagringsarkitektur, datamodellering, frågor relaterade till datasäkerhet och själva pipelines, förstås. Vi måste också se till att vår närvaro å ena sidan inte är särskilt betungande för produktutvecklare och att de måste distraheras så lite som möjligt av våra krav när vi skär in nya funktioner i systemet, och å andra sidan måste tillhandahålla dem bekvämt upplagda i lagringsdata för analytiker och BI-team. Det är så vi lever.
Svårigheter vid övergång från utveckling
På min första arbetsdag stötte jag på ett antal svårigheter som jag vill dela med mig av.
1. Det första jag såg var frånvaron av tuling och några övningar. Ta till exempel kodtäckning med tester. Vi har hundratals testramar under utveckling. När man arbetar med data är allt mer komplicerat. Ja, vi kan testa ETL-pipelines på testdata, men vi måste göra allt manuellt och leta efter lösningar för varje specifikt fall. Som ett resultat är testtäckningen mycket sämre. Lyckligtvis finns det ytterligare ett lager av feedback i form av övervakning och loggar, men detta kräver redan att vi reagerar reaktivt snarare än proaktivt, vilket är irriterande och irriterande.
2. Världen ur ett DE-perspektiv är inte alls vad den ser ut för en vanlig produktutvecklare (nåja, läsaren är förstås inte sådan, och han vet redan allt, men jag visste inte och nu skruvar jag det upp). Som utvecklare skapar jag min egen mikrotjänst, lägger in data i [valfritt databas], sparar mitt tillstånd där, får något med ID och det är bra. Tjänsten är långsam, beställningar är förvirrande, det är allt. De ber mig att leta efter mitt tillstånd i en annan tjänst, så jag ska kasta en händelse i någon RabbitMQ och det är allt. Och här återvände vi åter till frågan om händelser som beskrivs ovan.
Vad tjänsten behöver för operativt arbete passar oss inte för historiska data, så frågan om omarbetning av servicekontrakt och nära arbete med utvecklingsteam börjar. Du kan inte ens föreställa dig hur många timmar det tog oss att komma överens: vilken typ av Event Driven han är i vårt företag.
3. Du måste tänka med huvudet. Nej, jag menar inte att utvecklare inte tänker (även om vem är jag att tala för alla), det är bara det att man inom produktutveckling väldigt ofta redan har någon form av arkitektur, och man klipper olika shufflar från eftersläpningen. Detta kräver förstås planering och eftertanke, men det här är strömarbete, där huvudproblemet helt enkelt är att göra det bra och effektivt.
För oss är det inte så enkelt eftersom överföringen av olika systemkomponenter från en varm och mysig monolit till den vilda mikroservicedjungelns värld inte är så enkel. När tjänsten börjar sprida händelser måste du ompröva logiken för att fylla lagringen, eftersom data nu ser annorlunda ut. Det är här du behöver tänka mycket och grundligt, inte längre som utvecklare, utan som dataingenjör. Det är en vanlig historia när du spenderar dagar med en anteckningsbok och penna eller med en markör vid tavlan. Det är väldigt svårt, jag gillar inte att tänka, jag älskar produktion också.
4. Det kanske viktigaste är information. Vad gör vi när vi saknar kunskap? Vem sa stackoverflow? Ta ut den här personen ur rummet. Vi går och läser dokument, böcker om ämnet, och det finns också en community som organiserar forum, möten och konferenser. Dokumentationen är bra, men tyvärr kan den vara ofullständig. Vi använder Cosmos DB i ett antal projekt. Lycka till med att läsa dokumentationen för denna produkt. Böcker är den enda räddningen, lyckligtvis finns de och kan hittas, de innehåller mycket grundläggande kunskap och du måste läsa mycket och ständigt. Men problemet ligger i samhället.
Nu är det svårt att hitta minst en lämplig konferens eller möte i vårt område. Nej, självklart finns det många möten med ordet Data, men bredvid detta ord finns det oftast konstiga förkortningar som ML eller AI. Så det här är inte för oss, vi pratar om hur man bygger lagringsanläggningar, och inte hur man smetar in oss med neuroner. Dessa hipsters har tagit över allt. Som ett resultat är vi utan en gemenskap. Förresten, om du är en dataingenjör och känner till bra gemenskaper, skriv gärna i kommentarerna.
Slutsatser och tillkännagivande av träffen
Vad slutar vi med? Min första erfarenhet säger mig att känslan i en dataingenjörs skor kommer att vara användbart för varje utvecklare. Det låter oss bara se på saker annorlunda och inte bli förvånade när våra ögon blir blodsprängda när vi ser hur utvecklare behandlar deras data. Så om det finns en DE i ditt företag, prata bara med dessa killar, du kommer att lära dig mycket nya saker (om dig själv).
Och till sist, tillkännagivandet. Eftersom det är svårt att hitta möten om vårt ämne under dagen, bestämde vi oss för att göra våra egna. Varför är vi sämre? Lyckligtvis har vi en fantastisk och våra vänner från , som liksom vi känner att dataingenjörer orättvist berövas uppmärksamhet.
Med detta tillfälle bjuder jag in alla som bryr sig att komma till vår första community-träff med den lovande titeln "DE or DIE", som kommer att äga rum den 27.02.2020 februari XNUMX på Dodo Pizza-kontoret. Detaljer på .
Om något händer kommer jag att vara där, du kan personligen berätta för mig hur fel jag har om utvecklarna.
Källa: will.com