Data Engineer or die: příběh jednoho vývojáře

Začátkem prosince jsem udělal osudovou chybu a udělal zlom ve svém životě jako vývojář a přešel do týmu Data Engineering (DE) v rámci společnosti. V tomto článku se podělím o několik postřehů, které jsem učinil během dvou měsíců práce v DE týmu.

Proč datové inženýrství?

Moje cesta do DE začala v létě 2019, kdy jsme Xneg Pojďme Škola distribuovaného počítánía tam jsem dosáhl osvícení. Začal jsem se o téma zajímat, studovat algoritmy a dokonce i o nich psát, a poté se zamyslel nad rozsahem aplikace a rychle zjistil, že praktickou aplikací v naší společnosti jsou distribuované databáze.

Co přesně náš tým dělá? My, stejně jako všichni módní chlapci a dívky, se chceme stát Data Driven Company. A aby to bylo možné, musíme alespoň vybudovat spolehlivé úložiště, které lze použít k vytváření jakýchkoli reportů, které společnost potřebuje. Nejdůležitější ale je, že datům v tomto úložišti je třeba důvěřovat. Navíc pomocí těchto dat musíte být schopni obnovit stav systému v čase t. To vše je komplikováno skutečností, že žijeme ve skvělém novém světě mikroslužeb a z této ideologie vyplývá, že každá služba implementuje svou malou funkcionalitu, její databáze je její vlastní záležitostí a může ji minimálně každý den smazat, ale např. zároveň musíme být schopni přijímat a zpracovávat stav služby.

Pokud chcete být řízeni daty, nejprve se staňte řízenými událostmi

Není to tak jednoduché. Události jsou různé a vývojář a datový inženýr se na ně dívají jinak. Povídání o událostech je téma na samostatný článek, takže to zde nebudu rozebírat. Navíc takový článek už ano napsal jistý Martin Fowler, nebudu mu brát vavříny, ať se také proslaví.

Obecně je o čem přemýšlet a proto je tato oblast atraktivní. Náhodou se stává, že v naší společnosti je datový inženýr mnohem širší oblastí odpovědnosti než jen člověk, který píše ETL/ELT pipeline (pokud nevíte, co tyto zkratky znamenají, přijďte setkání. Jako kontextová reklama).

Zabýváme se architekturou úložišť, datovým modelováním, otázkami bezpečnosti dat a samozřejmě i samotnými pipelines. Musíme také zajistit, aby naše přítomnost na jedné straně nebyla pro vývojáře produktů příliš zatěžující a museli být co nejméně rozptylováni našimi požadavky při zařezávání nových funkcí do systému, a na druhé straně potřebují je poskytnout analytikům a BI týmům vhodně rozmístěnými v úložištích. Tak žijeme.

Obtíže při přechodu z vývoje

První den v práci jsem se setkal s řadou potíží, o které se s vámi chci podělit.

1. První, co jsem viděl, byla absence tulingu a některých praktik. Vezměte si například pokrytí kódu pomocí testů. Máme stovky testovacích frameworků ve vývoji. Při práci s daty je vše složitější. Ano, můžeme testovat ETL potrubí na testovacích datech, ale musíme to všechno dělat ručně a hledat řešení pro každý konkrétní případ. V důsledku toho je pokrytí testem mnohem horší. Naštěstí existuje další vrstva zpětné vazby ve formě monitorování a protokolů, ale to už vyžaduje, abychom reagovali spíše reaktivně než proaktivně, což je k vzteku a znervózňování.

2. Svět z pohledu DE vůbec není takový, jak se zdá běžnému vývojáři produktů (no, samozřejmě, čtenář takový není a už všechno ví, ale já jsem nevěděl a teď jsem pokazit to). Jako vývojář si vytvořím vlastní mikroslužbu, vložím data do [databáze dle vašeho výběru], uložím tam svůj stav, získám něco podle ID a je to v pořádku. Služba je pomalá, objednávky jsou matoucí, to je vše. Požádají mě, abych hledal svůj stav v jiné službě, takže hodím událost do nějakého RabbitMQ a je to. A zde jsme se opět vrátili k výše popsané problematice událostí.

To, co služba potřebuje pro operativní práci, nám u historických dat nevyhovuje, a tak začíná otázka přepracování servisních smluv a úzké spolupráce s vývojovými týmy. Ani si nedokážete představit, kolik hodin nám trvalo, než jsme se shodli: jaký je Event Driven v naší společnosti.

3. Je potřeba myslet hlavou. Ne, nechci říct, že vývojáři nepřemýšlejí (i když kdo jsem, abych mluvil za všechny), jde jen o to, že při vývoji produktů už velmi často máte nějakou architekturu a z nevyřízených věcí řežete různé míchání. To samozřejmě vyžaduje plánování a přemýšlení, ale toto je streamová práce, kde je hlavním problémem jednoduše dělat to dobře a efektivně.

Pro nás to není tak jednoduché, protože přenos různých systémových komponent z teplého a útulného monolitu do světa divoké mikroservisní džungle není tak jednoduchý. Když služba začne chrlit události, musíte přehodnotit logiku plnění úložiště, protože data nyní vypadají jinak. Tady je potřeba hodně a důkladně přemýšlet, už ne jako vývojář, ale jako datový inženýr. Je to normální příběh, kdy trávíte dny se sešitem a perem nebo s fixem na tabuli. Je to velmi těžké, nerad přemýšlím, také miluji produkci.

4. Snad nejdůležitější jsou informace. Co děláme, když nám chybí znalosti? Kdo řekl stackoverflow? Odveďte tuto osobu z místnosti. Chodíme číst dokumenty, knihy na toto téma a existuje také komunita, která pořádá fóra, meetingy a konference. Dokumentace je skvělá, ale bohužel může být neúplná. Cosmos DB používáme v řadě projektů. Hodně štěstí při čtení dokumentace k tomuto produktu. Knihy jsou jedinou záchranou, naštěstí existují a lze je najít, obsahují spoustu zásadních znalostí a musíte hodně a neustále číst. Problém je ale v komunitě.

Nyní je těžké najít v našem okolí alespoň jednu adekvátní konferenci nebo setkání. Ne, samozřejmě, existuje spousta setkání se slovem Data, ale vedle tohoto slova se obvykle objevují podivné zkratky jako ML nebo AI. Takže to není pro nás, mluvíme o tom, jak vybudovat skladovací prostory, a ne o tom, jak se namazat neurony. Tihle hipsteři převzali všechno. V důsledku toho jsme bez komunity. Mimochodem, pokud jste Data Engineer a znáte dobré komunity, napište do komentářů.

Závěry a oznámení o setkání

S čím skončíme? Moje první zkušenost mi říká, že pocit v kůži datového inženýra se bude hodit každému vývojáři. Jen nám to umožňuje dívat se na věci jinak a nebýt překvapeni, když nám tečou oči krví, když vidíme, jak vývojáři zacházejí se svými daty. Takže pokud je ve vaší firmě DE, stačí si s těmito kluky promluvit, dozvíte se spoustu nových věcí (o sobě).

A nakonec vyhlášení. Protože je těžké najít během dne setkání na naše téma, rozhodli jsme se udělat vlastní. Proč jsme horší? Naštěstí máme úžasný Schvepsss a naši přátelé z Laboratoř nových profesí, kteří mají stejně jako my pocit, že jsou datoví inženýři nespravedlivě ochuzeni o pozornost.

Při této příležitosti zvu všechny, kteří mají o chuť přijít na naše první komunitní setkání se slibným názvem „DE or DIE“, které se uskuteční 27.02.2020. února XNUMX v kanceláři Dodo Pizza. Podrobnosti na TimePad.

Pokud se něco stane, budu tam, můžete mi osobně říct do očí, jak se mýlím ohledně vývojářů.

Zdroj: www.habr.com