Begin december maakte ik een fatale fout en maakte een keerpunt in mijn leven als ontwikkelaar en stapte over naar het Data Engineering (DE)-team binnen het bedrijf. In dit artikel zal ik enkele observaties delen die ik heb gemaakt tijdens mijn twee maanden werken in het DE-team.
Waarom data-engineering?
Mijn reis naar DE begon in de zomer van 2019, toen we laten we gaan naar , en daar bereikte ik verlichting. Ik begon geïnteresseerd te raken in het onderwerp, algoritmen te bestuderen en zelfs erover , en dacht toen na over het toepassingsgebied en kwam er al snel achter dat de praktische toepassing in ons bedrijf gedistribueerde databases is.
Wat doet ons team precies? Wij willen, net als alle modieuze jongens en meisjes, een Data Driven Company worden. En om dit mogelijk te maken, moeten we op zijn minst een betrouwbare opslagfaciliteit bouwen, die kan worden gebruikt om alle rapporten te maken die het bedrijf nodig heeft. Maar het allerbelangrijkste is dat de gegevens in deze opslag vertrouwd moeten worden. Bovendien moet u met behulp van deze gegevens de toestand van het systeem op tijdstip t kunnen herstellen. Dit alles wordt gecompliceerd door het feit dat we in een dappere nieuwe wereld van microservices leven, en deze ideologie houdt in dat elke service zijn eigen kleine functionaliteit implementeert, zijn database zijn eigen zaak is en deze op zijn minst elke dag kan verwijderen, maar op zijn minst tegelijkertijd moeten we de staat van de dienst kunnen ontvangen en verwerken.
Als je Data Driven wilt zijn, word dan eerst Event Driven
Niet zo makkelijk. Gebeurtenissen zijn anders, en de ontwikkelaar en data-engineer kijken er anders naar. Praten over evenementen is een onderwerp voor een apart artikel, dus daar ga ik hier niet op in. Bovendien is er al een dergelijk artikel verschenen een zekere Martin Fowler, ik zal zijn lauweren niet afnemen, laat hem ook beroemd worden.
Over het algemeen is er veel om over na te denken en daarom is dit gebied aantrekkelijk. Het gebeurt zo dat in ons bedrijf een Data Engineer een veel breder verantwoordelijkheidsgebied is dan alleen iemand die ETL/ELT-pijplijnen schrijft (als je niet weet wat deze afkortingen betekenen, ga dan naar . Als contextuele reclame).
We houden ons bezig met opslagarchitectuur, datamodellering, kwesties met betrekking tot gegevensbeveiliging en uiteraard de pijpleidingen zelf. We moeten er aan de ene kant ook voor zorgen dat onze aanwezigheid niet erg belastend is voor productontwikkelaars en dat ze zo min mogelijk worden afgeleid door onze eisen bij het toevoegen van nieuwe functies aan het systeem. Het is noodzakelijk om ze overzichtelijk op te slaan in opslaggegevens voor analisten en het BI-team. Zo leven wij.
Moeilijkheden bij de overgang van ontwikkeling
Op mijn eerste werkdag kwam ik een aantal moeilijkheden tegen die ik met jullie wil delen.
1. Het eerste wat ik zag was de afwezigheid van tuling en enkele praktijken. Neem bijvoorbeeld codedekking bij tests. We hebben honderden testframeworks in ontwikkeling. Bij het werken met data is alles ingewikkelder. Ja, we kunnen ETL-pijplijnen testen op testgegevens, maar we moeten het allemaal handmatig doen en voor elk specifiek geval naar oplossingen zoeken. Als gevolg hiervan is de testdekking veel slechter. Gelukkig is er nog een feedbacklaag in de vorm van monitoring en logboeken, maar dit vereist al dat we reactief reageren in plaats van proactief, wat irritant en zenuwslopend is.
2. De wereld vanuit DE-perspectief is helemaal niet wat het lijkt voor een gewone productontwikkelaar (nou ja, zo is de lezer natuurlijk niet, en hij weet alles al, maar ik wist het niet en nu ben ik aan het neuken het op). Als ontwikkelaar creëer ik mijn eigen microservice, plaats de gegevens in [database naar keuze], sla mijn staat daar op, haal iets op via ID en het is prima. De service is traag, bestellingen zijn verwarrend, dat is alles. Ze vragen me om mijn staat in een andere dienst te zoeken, dus ik gooi een evenement in een RabbitMQ en dat is alles. En hier keerden we opnieuw terug naar de kwestie van de hierboven beschreven gebeurtenissen.
Wat de service nodig heeft voor operationeel werk past niet bij ons op basis van historische gegevens, dus begint de kwestie van het herwerken van servicecontracten en nauw samenwerken met ontwikkelingsteams. Je kunt je niet eens voorstellen hoeveel uur het ons kostte om het eens te worden: wat voor Event Driven hij is in ons bedrijf.
3. Je moet met je hoofd denken. Nee, ik bedoel niet dat ontwikkelaars niet denken (hoewel wie ben ik om namens iedereen te spreken), het is gewoon dat je bij productontwikkeling heel vaak al een soort architectuur hebt, en dat je verschillende shuffles uit de backlog haalt. Natuurlijk vereist dit planning en nadenken, maar dit is gestroomlijnd werk, waarbij het grootste probleem eenvoudigweg is om het goed en efficiënt te doen.
Voor ons is dat niet zo eenvoudig, omdat de overdracht van verschillende systeemcomponenten van een warme en gezellige monoliet naar de wereld van de wilde microservice-jungle niet zo eenvoudig is. Wanneer de service gebeurtenissen begint te verspreiden, moet u de logica voor het vullen van de opslag heroverwegen, omdat de gegevens er nu anders uitzien. Hier moet je veel en grondig nadenken, niet langer als ontwikkelaar, maar als data engineer. Het is een normaal verhaal als je dagen met een notitieboekje en pen of met een stift op het bord zit. Het is heel moeilijk, ik denk niet graag, ik hou ook van productie.
4. Misschien wel het belangrijkste is informatie. Wat doen we als we kennis missen? Wie zei stackoverflow? Haal deze persoon uit de kamer. We gaan documenten en boeken over het onderwerp lezen, en er is ook een community die forums, meetups en conferenties organiseert. Documentatie is geweldig, maar helaas kan deze onvolledig zijn. Wij gebruiken Cosmos DB in een aantal projecten. Veel succes met het lezen van de documentatie voor dit product. Boeken zijn de enige redding; gelukkig bestaan ze en zijn ze te vinden, bevatten ze veel fundamentele kennis en moet je veel en constant lezen. Maar het probleem ligt bij de gemeenschap.
Nu is het moeilijk om minstens één geschikte conferentie of bijeenkomst in onze regio te vinden. Nee natuurlijk zijn er veel meetups met het woord Data, maar naast dit woord staan meestal vreemde afkortingen zoals ML of AI. Dit is dus niets voor ons, we hebben het over het bouwen van opslagfaciliteiten, en niet over hoe we onszelf kunnen besmeuren met neuronen. Deze hipsters hebben alles overgenomen. Het gevolg is dat we zonder gemeenschap zitten. Trouwens, als je een Data Engineer bent en goede communities kent, schrijf dan in de reacties.
Conclusies en aankondiging van de bijeenkomst
Waar eindigen we mee? Mijn eerste ervaring leert mij dat het gevoel in de schoenen van een data engineer voor iedere ontwikkelaar nuttig zal zijn. Het stelt ons gewoon in staat om anders naar de dingen te kijken en niet verbaasd te zijn als onze ogen bloeddoorlopen worden als we zien hoe ontwikkelaars met hun gegevens omgaan. Dus als er een DE in uw bedrijf is, praat dan gewoon met deze jongens, u zult veel nieuwe dingen leren (over uzelf).
En tot slot de aankondiging. Omdat het overdag moeilijk is om bijeenkomsten over ons onderwerp te vinden, hebben we besloten er zelf een te organiseren. Waarom zijn wij slechter? Gelukkig hebben we een geweldig en onze vrienden van , die net als wij vinden dat data-ingenieurs onterecht van de aandacht worden beroofd.
Ik maak van deze gelegenheid gebruik en nodig iedereen die het leuk vindt uit om naar onze eerste gemeenschapsbijeenkomst met de veelbelovende titel “DE or DIE” te komen, die zal plaatsvinden op 27.02.2020 februari XNUMX in het Dodo Pizza-kantoor. Details op .
Als er iets gebeurt, zal ik er zijn, je kunt me persoonlijk in mijn gezicht vertellen hoe verkeerd ik ben over de ontwikkelaars.
Bron: www.habr.com