All'inizio di dicembre ho commesso un errore fatale e ho dato una svolta alla mia vita di sviluppatore e sono passato al team Data Engineering (DE) all'interno dell'azienda. In questo articolo condividerò alcune osservazioni che ho fatto durante due mesi di lavoro nel team DE.
Perché l'ingegneria dei dati?
Il mio viaggio in DE è iniziato nell'estate del 2019, quando noi andiamo a , e lì ho raggiunto l'illuminazione. Ho iniziato a interessarmi all'argomento, a studiare gli algoritmi e anche a loro , quindi ho pensato all'ambito di applicazione e ho subito scoperto che l'applicazione pratica nella nostra azienda sono i database distribuiti.
Cosa fa esattamente il nostro team? Noi, come tutti i ragazzi e le ragazze alla moda, vogliamo diventare un'azienda basata sui dati. E affinché ciò diventi possibile, dobbiamo almeno costruire una struttura di archiviazione affidabile, che possa essere utilizzata per creare tutti i report di cui l'azienda ha bisogno. Ma la cosa più importante è che i dati in questo archivio siano affidabili. Inoltre, utilizzando questi dati, è necessario essere in grado di ripristinare lo stato del sistema al tempo t. Tutto ciò è complicato dal fatto che viviamo in un mondo nuovo e coraggioso di microservizi, e questa ideologia implica che ogni servizio implementa le proprie piccole funzionalità, il suo database è affar suo e può cancellarlo almeno ogni giorno, ma a allo stesso tempo dobbiamo essere in grado di ricevere ed elaborare lo stato del servizio.
Se vuoi essere Data Driven, diventa prima Event Driven
Non così semplice. Gli eventi sono diversi e lo sviluppatore e il data engineer li considerano in modo diverso. Parlare di eventi è un argomento per un articolo separato, quindi non entrerò nell’argomento qui. Inoltre, un articolo del genere è già stato fatto un certo Martin Fowler, non gli toglierò gli allori, lasciamo che diventi famoso anche lui.
In generale, c'è molto a cui pensare ed è per questo che questa zona è attraente. Si dà il caso che nella nostra azienda un Data Engineer sia un'area di responsabilità molto più ampia di una semplice persona che scrive pipeline ETL/ELT (se non sai cosa significano queste abbreviazioni, vieni a . Come pubblicità contestuale).
Ci occupiamo di architettura di storage, modellazione dei dati, questioni relative alla sicurezza dei dati e, ovviamente, delle pipeline stesse. Dobbiamo anche assicurarci che, da un lato, la nostra presenza non sia troppo gravosa per gli sviluppatori di prodotti e che essi debbano essere distratti il meno possibile dalle nostre esigenze quando inseriamo nuove funzionalità nel sistema, e dall'altro dobbiamo è necessario fornirli opportunamente disposti nei dati di archiviazione per gli analisti e il team BI. È così che viviamo.
Difficoltà nella transizione dallo sviluppo
Nel mio primo giorno di lavoro ho incontrato una serie di difficoltà che voglio condividere con voi.
1. La prima cosa che ho notato è stata l'assenza del tuling e di alcune pratiche. Prendiamo, ad esempio, la copertura del codice con i test. Abbiamo centinaia di framework di test in fase di sviluppo. Quando si lavora con i dati, tutto è più complicato. Sì, possiamo testare le pipeline ETL sui dati di test, ma dobbiamo fare tutto manualmente e cercare soluzioni per ogni caso specifico. Di conseguenza, la copertura dei test è molto peggiore. Fortunatamente, esiste un altro livello di feedback sotto forma di monitoraggio e registri, ma questo ci impone già di reagire in modo reattivo anziché proattivo, il che è esasperante e snervante.
2. Il mondo dal punto di vista DE non è affatto quello che sembra a un normale sviluppatore di prodotti (beh, ovviamente, il lettore non è così e sa già tutto, ma io non lo sapevo e ora lo so rovinandolo). Come sviluppatore, creo il mio microservizio, inserisco i dati in [database di tua scelta], salvo il mio stato lì, ottengo qualcosa tramite ID e va bene. Il servizio è lento, gli ordini sono confusi, tutto qui. Mi chiedono di cercare il mio stato in un altro servizio, quindi inserirò un evento in qualche RabbitMQ e il gioco è fatto. E qui siamo nuovamente tornati alla questione degli eventi sopra descritti.
Ciò di cui il servizio ha bisogno per il lavoro operativo non è adatto a noi per i dati storici, quindi inizia la questione della rielaborazione dei contratti di servizio e della stretta collaborazione con i team di sviluppo. Non puoi nemmeno immaginare quante ore ci sono volute per concordare: che tipo di Event Driven è nella nostra azienda.
3. Devi pensare con la tua testa. No, non intendo dire che gli sviluppatori non pensino (anche se chi sono io per parlare a nome di tutti), è solo che nello sviluppo del prodotto molto spesso hai già un qualche tipo di architettura e tagli diversi pezzi dal backlog. Naturalmente, ciò richiede pianificazione e riflessione, ma questo è un lavoro di flusso, in cui il problema principale è semplicemente farlo bene ed efficientemente.
Per noi non è così semplice, perché trasferire i vari componenti del sistema da un monolite caldo e accogliente al mondo della giungla selvaggia dei microservizi non è così semplice. Quando il servizio inizia a emettere eventi, è necessario riconsiderare la logica per riempire lo spazio di archiviazione, poiché i dati ora appaiono diversi. È qui che devi pensare molto e in modo approfondito, non più come sviluppatore, ma come ingegnere dei dati. È una storia normale quando passi le giornate con quaderno e penna o con un pennarello alla lavagna. È molto difficile, non mi piace pensare, amo anche la produzione.
4. Forse la cosa più importante è l'informazione. Cosa facciamo quando ci manca la conoscenza? Chi ha detto stackoverflow? Porta questa persona fuori dalla stanza. Andiamo a leggere documenti, libri sull'argomento, e c'è anche una community che organizza forum, incontri e conferenze. La documentazione è ottima, ma sfortunatamente può essere incompleta. Utilizziamo Cosmos DB in numerosi progetti. Buona fortuna nella lettura della documentazione di questo prodotto. I libri sono l’unica salvezza, per fortuna esistono e si possono trovare, contengono tante conoscenze fondamentali e bisogna leggere tanto e costantemente. Ma il problema è della comunità.
Adesso è difficile trovare almeno un convegno o un meetup adeguato nella nostra zona. No, certo, ci sono molti incontri con la parola Data, ma accanto a questa parola di solito ci sono strane abbreviazioni come ML o AI. Quindi, questo non fa per noi, stiamo parlando di come costruire strutture di stoccaggio e non di come imbrattarci di neuroni. Questi hipster hanno preso il controllo di tutto. Di conseguenza, siamo senza comunità. A proposito, se sei un Data Engineer e conosci buone community, scrivi nei commenti.
Conclusioni e annuncio del meetup
Con cosa finiamo? La mia prima esperienza mi dice che sentirsi nei panni di un data engineer sarà utile per ogni sviluppatore. Ci permette semplicemente di guardare le cose in modo diverso e di non sorprenderci quando i nostri occhi si riempiono di sangue quando vediamo come gli sviluppatori trattano i loro dati. Quindi, se c'è un DE nella tua azienda, parla con questi ragazzi, imparerai molte cose nuove (su te stesso).
E infine l'annuncio. Dato che è difficile trovare incontri sul nostro argomento durante il giorno, abbiamo deciso di crearne uno nostro. Perché siamo peggio? Per fortuna abbiamo un fantastico e i nostri amici di , che, come noi, ritengono che gli ingegneri dei dati siano ingiustamente privati dell'attenzione.
Cogliendo questa opportunità, invito tutti coloro che lo desiderano a venire al nostro primo incontro comunitario dal promettente titolo "DE or DIE", che si svolgerà il 27.02.2020 febbraio XNUMX presso l'ufficio di Dodo Pizza. Dettagli a .
Se succede qualcosa, sarò lì, potrai dirmi personalmente in faccia quanto mi sbaglio riguardo agli sviluppatori.
Fonte: habr.com