A principios de decembro, cometin un erro fatídico (un punto de inflexión na miña vida como desenvolvedor) e unínme ao equipo de Enxeñaría de Datos (DE) da empresa. Neste artigo, compartirei algunhas observacións que fixen durante os dous meses que levo traballando no equipo de DE.
Por que a Enxeñaría de Datos?
A miña viaxe en Alemaña comezou no verán de 2019 cando imos a , e alí cheguei á iluminación. Comecei a interesarme polo tema, estudando algoritmos e mesmo sobre eles. , e despois pensei na área de aplicación e descubrín rapidamente que a aplicación práctica na nosa empresa son as bases de datos distribuídas.
Entón, que fai exactamente o noso equipo? Nós, como todos os homes e mulleres modernos, queremos converternos nunha empresa baseada en datos. E para facelo posible, necesitamos, como mínimo, construír un almacén de datos fiable capaz de xerar calquera informe que a empresa precise. Pero o máis importante é que os datos deste almacén deben ser fiables. Ademais, necesitamos ser capaces de reconstruír o estado do sistema nun momento dado utilizando estes datos. Todo isto complícase polo feito de que vivimos nun novo mundo de microservizos, e esta ideoloxía implica que cada servizo implementa a súa propia pequena funcionalidade, a súa base de datos é o seu propio negocio e pode eliminala diariamente. Non obstante, debemos ser capaces de recuperar e procesar o estado do servizo.
Se queres estar baseado en datos, primeiro convértete en eventos.
Non é tan sinxelo. Os eventos teñen diferentes formas, e os desenvolvedores e enxeñeiros de datos venos de xeito diferente. Os eventos son tema para un artigo separado, polo que non entrarei neles aquí. Ademais, xa se escribiu un artigo deste tipo. un tal Martin Fowler, non lle quitarei os loureiros, que tamén se faga famoso.
En resumo, hai moito en que pensar, e iso é o que fai que este campo sexa tan atractivo. Dá a casualidade de que na nosa empresa, un enxeñeiro de datos ten unha área de responsabilidade moito máis ampla que alguén que escribe canles ETL/ELT (se non sabes o que significan estas abreviaturas, consulta...) . Sobre os dereitos da publicidade contextual).
Estamos involucrados na arquitectura do almacén, na modelización de datos, nas cuestións de seguridade dos datos e, por suposto, nas propias canles de produción. Tamén precisamos garantir que, por unha banda, a nosa presenza non sexa demasiado onerosa para os desenvolvedores de produtos e que estean o menos distraídos posible polos nosos requisitos á hora de implementar novas funcionalidades no sistema, mentres que, por outra banda, precisamos proporcionar aos analistas e ao equipo de intelixencia empresarial datos convenientemente organizados no almacén. Así é como vivimos.
Dificultades na transición do desenvolvemento
No meu primeiro día de traballo, atopei unha serie de dificultades que quero compartir con vós.
1. O primeiro que notei foi unha falta de ferramentas e certas prácticas recomendadas. Tomemos como exemplo a cobertura das probas de código. En desenvolvemento, temos cento cincuenta marcos de probas. Traballar con datos é máis complicado. Si, podemos probar as canles ETL en datos de proba, pero temos que facelo todo manualmente e atopar solucións para cada caso específico. Como resultado, a cobertura das probas é moito peor. Afortunadamente, hai outra capa de retroalimentación en forma de monitorización e rexistro, pero isto require que sexamos reactivos en lugar de proactivos, o que é molesto e desconcertante.
2. O mundo desde a perspectiva dun desenvolvedor de produtos é completamente diferente de como llo parece ao desenvolvedor de produtos medio (por suposto, o lector non é así e xa o sabe todo, pero eu non o sabía e agora estou entendéndoo). Como desenvolvedor, estou construíndo o meu microservizo, colocando datos en [base de datos da túa elección], almacenando o meu estado alí, recuperando algo por ID e todo está ben. O servizo execútase, as ordes están desordenadas e todo iso. Alguén pídeme que busque o meu estado noutro servizo, así que simplemente envio o evento a algún RabbitMQ e listo. E aí é onde volvemos ao problema do evento descrito anteriormente.
O que o servizo precisa para o traballo operativo non nos serve para os datos históricos, polo que temos que reelaborar os contratos de servizo e traballar en estreita colaboración cos equipos de desenvolvemento. Nin sequera podedes imaxinar cantas horas pasamos intentando poñernos de acordo sobre o que é realmente Event Driven na nosa empresa.
3. Necesitas pensar coa cabeza. Non digo que os desenvolvedores non pensen (aínda que quen son eu para falar por todos), pero no desenvolvemento de produtos, a miúdo xa tes algún tipo de arquitectura e simplemente estás a xogar con varias tarefas do traballo pendente. Por suposto, isto require planificación e reflexión, pero é un proceso continuo, onde o principal desafío é simplemente facer as cousas ben e de forma eficiente.
Non é tan sinxelo para nós, porque migrar varios compoñentes do sistema desde un monolito cálido e acolledor ao mundo salvaxe dos microservizos non é doado. Cando un servizo comeza a xerar eventos, cómpre repensar a lóxica de poboar o almacenamento, porque os datos agora teñen un aspecto diferente. Isto require moita reflexión, non como desenvolvedor, senón como enxeñeiro de datos. É común pasar días cun caderno e un bolígrafo ou un rotulador nunha pizarra branca. É moi difícil; non me gusta pensar; prefiro simplemente facer bang-bang e pasar a produción.
4. Quizais o máis importante sexa a información. Que facemos cando carecemos de coñecemento? Quen dixo Stack Overflow? Sacamos a esa persoa da sala. Imos ler documentación, libros sobre o tema e logo está a comunidade que organiza foros, reunións e conferencias. A documentación é estupenda, pero por desgraza pode estar incompleta. Usamos Cosmos DB en varios proxectos. Boa sorte lendo a documentación deste produto. Os libros son a nosa única salvación; por sorte, existen e pódense atopar. Conteñen moito coñecemento fundamental e hai que ler moito e constantemente. Pero a comunidade é un desastre.
É difícil atopar unha soa conferencia ou reunión axeitada no noso campo agora mesmo. Claro, hai moitas reunións coa palabra "Datos", pero normalmente acaban con acrónimos estraños como "ML" ou "IA". Ben, iso non é o noso; estamos a falar de construír almacéns de datos, non de untarnos con redes neuronais. Estes hípsters apoderáronse de todo. Como resultado, estamos sen comunidade. Por certo, se es enxeñeiro/a de datos e coñeces algunha boa comunidade, por favor, avísame nos comentarios.
Conclusións e anuncio da reunión
Entón, cal é a conclusión? A miña experiencia inicial díxome que todos os desenvolvedores poden beneficiarse de experimentar o papel dun enxeñeiro de datos. Simplemente permítenos ver as cousas de forma diferente e non sorprendernos cando nos fagan sangue os ollos ao ver como os desenvolvedores xestionan os seus datos. Entón, se a túa empresa ten un enxeñeiro de datos, simplemente fala con el e aprenderás moito (sobre ti).
E, para rematar, un anuncio. Como non atopamos ningunha reunión sobre o noso tema, decidimos crear a nosa propia. Que ten de malo? Por sorte, temos unha incrible e os nosos amigos de , que, coma nós, consideran que os enxeñeiros de datos están a ser inxustamente desatendidos.
Gustaríame aproveitar esta oportunidade para convidar a todo o mundo que o desexe a vir á nosa primeira reunión comunitaria, titulada prometedoramente "DE ou DIE", que terá lugar o 27 de febreiro de 2020 na oficina de Dodo Pizza. Os detalles están dispoñibles en .
Se ocorre algo, estarei alí, e poderás dicirme persoalmente na miña cara o equivocado que estou sobre os desenvolvedores.
Fonte: www.habr.com
