Get best of the week

Ingeniero de datos o morir: una sola historia de desarrollador

A principios de diciembre, cometí un error fatal , tomé una decisión fundamental en mi vida como desarrollador y me transferí al equipo de Ingeniería de Datos (DE) dentro de la empresa. En el artículo compartiré algunas de las observaciones que hice durante dos meses de trabajo en el equipo de DE.




¿Por qué ingeniería de datos?


Mi viaje a DE comenzó en el verano de 2019, cuando Xnegconduje a la Escuela de Computación Distribuida , y allí llegué a la iluminación. Comencé a interesarme por el tema, estudié algoritmos e incluso escribí sobre ellos , y luego pensé en el campo de aplicación y descubrí rápidamente que la aplicación práctica en nuestra empresa son las bases de datos distribuidas.

¿Qué hace nuestro equipo en general? Nosotros, como todos los niños y niñas de moda, queremos convertirnos en una empresa impulsada por datos. Y para que esto sea posible, necesitamos al menos construir un repositorio confiable, sobre el cual sea posible construir cualquier informe requerido por la compañía. Pero lo más importante es que los datos en este almacenamiento deben ser confiables. Además, según estos datos, uno debe poder restaurar el estado del sistema en el momento t. Todo esto se complica por el hecho de que vivimos en un mundo nuevo y valiente de microservicios, y esta ideología implica que cada servicio implementa su pequeña funcionalidad, su base de datos es su propio negocio y puede eliminarla al menos todos los días, pero al mismo tiempo tenemos que Poder recibir y procesar el estado del servicio.

Quiere ser impulsado por datos, primero conviértase en un evento impulsado


No es tan simple. Los eventos son diferentes, y el desarrollador y el ingeniero de fechas los miran de manera diferente. La conversación sobre eventos es el tema de un artículo separado, por lo que aquí no voy a entrar en él. Además, alguien que Martin Fowler ya escribió un artículo así , no le quitaré los laureles, dejaré que se haga famoso también.

En general, hay algo en qué pensar y el área es atractiva. Dio la casualidad de que en nuestra empresa Data Engineer es un área de responsabilidad mucho más amplia que solo una persona que escribe canalizaciones ETL / ELT (si no sabe lo que significan estas abreviaturas, venga a mitap . Como un anuncio contextual ).

Estamos comprometidos con la arquitectura de construir un almacén, modelar datos y temas relacionados con la seguridad de los datos y las tuberías en sí, por supuesto. Y debemos asegurarnos de que, por un lado, los desarrolladores de productos no sean muy pesados ​​con nuestra presencia y que tengan que distraerse lo menos posible por nuestros requisitos cuando vean nuevas características en el sistema, y ​​por otro lado, debemos proporcionar un almacenamiento convenientemente almacenado datos para analistas y equipos de BI. Así es como vivimos.

Dificultades para pasar del desarrollo


El primer día de mi trabajo, encontré una serie de dificultades que quiero compartir con ustedes.

1. Lo primero que vi fue la falta de ajuste y algunas prácticas. Tome, por ejemplo, la cobertura de código con pruebas. En desarrollo, tenemos cientos de marcos para pruebas. Cuando se trabaja con datos, todo es más complicado. Sí, podemos probar las tuberías de ETL en los datos de prueba, pero tenemos que hacer todo esto con nuestras propias manos y buscar soluciones para cada caso específico. Como resultado, la cobertura de la prueba es mucho peor. Afortunadamente, hay otra capa de retroalimentación en forma de monitoreo y registros, pero esto ya requiere que reaccionemos en lugar de ser proactivos, lo que nos enfurece .

2. El mundo desde la posición de DE, no es para nada lo que le parece a un desarrollador de productos ordinario (bueno, por supuesto, el lector no es así, y él ya lo sabe todo, pero yo no lo sabía y ahora está rastrillando). Como desarrollador, vi mi microservicio, puse los datos en [la base de datos de su elección], guardé mi estado allí, obtuve algo por ID y es normal. El servicio está girando, los pedidos se enturbian, eso es todo. Me piden en otro servicio que pierda mi estado, bueno, lanzaré un evento en RabbitMQ y eso es todo. Y aquí volvimos nuevamente al tema de los eventos descritos anteriormente.

Lo que el servicio necesita para el trabajo operativo no nos conviene para los datos históricos, comienza la cuestión de procesar contratos de servicio y trabajar en estrecha colaboración con los equipos de desarrollo. Ni siquiera puede imaginar cuántas horas nos llevó estar de acuerdo: qué tipo de evento es Driven en nuestra empresa.

3. Necesitas pensar con la cabeza. No, no quiero decir que los desarrolladores no piensen (aunque quién soy yo para hablar por todos), es solo que en el desarrollo de productos a menudo ya tienes algún tipo de arquitectura, y estás cortando varios retrasos. Por supuesto, esto requiere planificación y reflexión, pero este es un trabajo de transmisión, donde el problema principal es simplemente bueno y de alta calidad.

No es tan simple aquí porque la transferencia de varios componentes del sistema desde un monolito cálido y confortable al mundo de la selva salvaje de microservicios no es tan simple. Cuando el servicio comienza a rociarse con eventos, debe revisar la lógica de llenar el almacenamiento, porque los datos ahora se ven diferentes. Aquí debe pensar mucho y a fondo, no como desarrollador, sino como ingeniero de datos. Es una historia normal cuando pasas días con un cuaderno y un bolígrafo o con un marcador cerca del tablero. Es muy difícil, no me gusta pensar, me encantan los higos y la producción.

4. Quizás lo más importante es la información. ¿Qué hacemos cuando nos falta conocimiento? ¿Quién dijo stackoverflow? Saca a esta persona de la habitación. Vamos a leer documentos, libros sobre el tema, y ​​todavía hay una comunidad que organiza foros, reuniones y conferencias. La documentación es genial, pero desafortunadamente está incompleta. Estamos utilizando Cosmos DB en varios proyectos. Buena suerte leyendo la documentación de este producto. Los libros son la única salvación, afortunadamente, existen y se pueden encontrar, tienen muchos conocimientos fundamentales y hay que leer mucho y constantemente. Pero la comunidad está en problemas.

Ahora, en nuestra dirección, es difícil encontrar al menos una conferencia o reunión adecuada. Por supuesto, hay muchos mitaps con la palabra Datos, pero las abreviaturas extrañas como ML o AI generalmente aparecen junto a esta palabra. Entonces, esto no es para nosotros, estamos hablando de cómo construir instalaciones de almacenamiento, y no cómo untarnos con neuronas. Estos hipsters llenaron todo. Como resultado, estamos sin una comunidad. Por cierto, si usted es un ingeniero de datos y conoce buenas comunidades, escriba los comentarios.

Conclusiones y anuncio del mitap


¿Qué tenemos al final? Mi primera experiencia me dice que sentirme en el lugar de la cita de un ingeniero será útil para todos los desarrolladores. Simplemente le permite ver las cosas de manera diferente y no sorprenderse cuando nuestros ojos están sangrando al ver cómo los desarrolladores tratan sus datos. Entonces, si su empresa tiene DE, solo chatee con estos tipos y aprenda mucho (sobre usted).

Y finalmente, el anuncio. Dado que es imposible encontrar mitaps en nuestro tema durante el día, decidimos hacer el nuestro. ¿Y qué, qué somos peores? Afortunadamente tenemos un increíbleSchvepsssy nuestros amigos de New Professions Lab , quienes, como nosotros, piensan que los ingenieros de citas están injustamente privados de atención.

Aprovecho esta oportunidad para invitar a todos los interesados ​​a venir a nuestra primera reunión comunitaria con el prometedor nombre "DE or DIE", que se llevará a cabo el 27/02/2020 en la oficina de Dodo Pizza. Detalles en TimePad .

En todo caso, estaré allí, personalmente puede decirme en persona, cuán equivocado estoy con los desarrolladores.

More articles:


All Articles