¿Cuál es el futuro del ingeniero de datos? - 6 conductores de la industria

En el mundo de la ingeniería de datos, Maxime Beauchemin es alguien que no necesita presentación.

Uno de los primeros ingenieros de datos en Facebook y Airbnb, escribió y abrió el código abierto del popular orquestador, Apache Airflow , seguido poco después por Apache Superset , una herramienta de exploración de datos que está conquistando el panorama de la visualización de datos. Actualmente, Maxime es CEO y cofundador de Preset .

Es justo decir que Maxime ha experimentado, e incluso diseñado, muchas de las tecnologías de ingeniería de datos más impactantes de la última década, y ha sido pionero en el papel en sí mismo a través de su histórica publicación de blog de 2017, The Rise of the Data Engineer , en la que relata muchas de sus observaciones.

En resumen, Maxime argumenta que para escalar de manera efectiva la ciencia y el análisis de datos, los equipos necesitaban un ingeniero especializado para administrar ETL , construir canalizaciones y escalar la infraestructura de datos. Entra, el ingeniero de datos.

Unos meses más tarde, Maxime siguió ese artículo con una reflexión sobre algunos de los mayores desafíos del ingeniero de datos: el trabajo era duro, el respeto era mínimo y la conexión entre su trabajo y los conocimientos reales generados era obvia, pero rara vez se reconocía.

Ser un ingeniero de datos era un trabajo ingrato pero cada vez más importante, con equipos que se encontraban a caballo entre la construcción de infraestructura, la ejecución de trabajos y el envío de solicitudes ad-hoc de los equipos de análisis y BI. Como resultado, ser ingeniero de datos fue tanto una bendición como una maldición.

De hecho, en opinión de Maxime, el ingeniero de datos era el "peor asiento en la mesa".

Entonces, cinco años después, ¿dónde estamos?

Me senté con Maxime para discutir el estado actual de las cosas, incluida la descentralización de la pila de datos moderna, la fragmentación del equipo de datos, el surgimiento de la nube y cómo todos estos factores han cambiado el rol del ingeniero de datos para siempre.

La velocidad de ETL y análisis ha aumentado

Maxime recuerda una época, no hace mucho, cuando los ingenieros de datos ejecutaban trabajos de Hive durante horas seguidas, lo que requería cambios de contexto frecuentes entre trabajos y la gestión de diferentes elementos de su canalización de datos.

Para decirlo sin rodeos, fue aburrido y agotador al mismo tiempo.

“Este cambio de contexto interminable y la gran cantidad de tiempo que llevó ejecutar las operaciones de datos llevaron al agotamiento”, dice. "Con demasiada frecuencia, 5 a 10 minutos de trabajo a las 11:30 p. m. podrían ahorrarle de 2 a 4 horas de trabajo al día siguiente, y eso no es necesariamente algo bueno".

En 2021, los ingenieros de datos pueden ejecutar grandes trabajos muy rápidamente gracias a la potencia informática de BigQuery, Snowflake, Firebolt, Databricks y otras tecnologías de almacenamiento en la nube. Este alejamiento de las soluciones locales y de código abierto hacia la nube y SaaS administrado libera recursos de ingeniería de datos para trabajar en tareas no relacionadas con la administración de bases de datos.

Por otro lado, los costos son más limitados.

“Solía ser bastante barato ejecutarlo en las instalaciones, pero en la nube, debe tener en cuenta los costos de cómputo”, dice Maxime. “Los recursos son elásticos, no finitos”.

Dado que los ingenieros de datos ya no son responsables de administrar la computación y el almacenamiento, su función está cambiando del desarrollo de infraestructura a elementos de la pila de datos más basados en el rendimiento, o incluso funciones especializadas.

“Podemos ver este cambio en el auge de la ingeniería de confiabilidad de datos, y el ingeniero de datos es responsable de administrar (no construir) la infraestructura de datos y supervisar el rendimiento de los sistemas basados en la nube”.

Es más difícil lograr un consenso sobre la gobernanza, y eso está bien

En una era anterior, la estructura del equipo de datos estaba muy centralizada, con ingenieros de datos y analistas expertos en tecnología que actuaban como "bibliotecarios" de los datos para toda la empresa. El gobierno de datos era un rol aislado, y los ingenieros de datos se convirtieron en los guardianes de facto de la confianza de los datos, les gustara o no.

Hoy en día, sugiere Maxime, se acepta ampliamente que la gobernanza está distribuida. Cada equipo tiene su propio dominio analítico propio, lo que fuerza a las estructuras de equipo descentralizadas en torno a definiciones ampliamente estandarizadas de cómo se ven los datos "buenos".

“Hemos aceptado que la búsqueda de consenso no es necesaria en todas las áreas, pero eso no lo hace más fácil”, dice. “El almacén de datos es el espejo de la organización en muchos sentidos. Si las personas no están de acuerdo sobre cómo llaman a las cosas en el almacén de datos o cuál es la definición de una métrica, entonces esta falta de consenso se reflejará en sentido descendente. Pero tal vez eso esté bien”.

Tal vez, argumenta Maxime, no es necesariamente responsabilidad exclusiva del equipo de datos encontrar un consenso para el negocio, particularmente si los datos se utilizan en toda la empresa de diferentes maneras. Esto conducirá inherentemente a la duplicación y la desalineación a menos que los equipos decidan qué datos son privados (en otras palabras, solo utilizados por un dominio comercial específico) o compartidos con la organización en general.

“Ahora, diferentes equipos son dueños de los datos que usan y producen, en lugar de tener un equipo central a cargo de todos los datos de la empresa. Cuando los datos se comparten entre grupos y se exponen a una escala más amplia, debe haber más rigor en cuanto a proporcionar una API para la gestión de cambios”, dice.

Lo que nos lleva a nuestro siguiente punto...

La gestión del cambio sigue siendo un problema, pero las herramientas adecuadas pueden ayudar

En 2017, cuando Maxime escribió su primer artículo, “cuando cambiaran los datos, afectaría a toda la empresa, pero nadie sería notificado”. Esta falta de gestión del cambio fue causada tanto por brechas técnicas como culturales.

Cuando se cambiaba o actualizaba el código fuente o los conjuntos de datos, se producían fallas en sentido descendente que hacían que los tableros, informes y otros productos de datos fueran efectivamente inválidos hasta que se resolvieran los problemas. Este tiempo de inactividad de los datos (períodos de tiempo en los que faltan datos, son inexactos o erróneos) fue costoso, requería mucho tiempo y era doloroso de resolver.

Con demasiada frecuencia, el tiempo de inactividad golpeaba en silencio y los equipos de datos se rascaban la cabeza tratando de averiguar qué salió mal, quién se vio afectado y cómo podrían solucionarlo.

Hoy en día, los equipos de datos confían cada vez más en las mejores prácticas de ingeniería de software y DevOps para crear herramientas y culturas más sólidas que prioricen la comunicación y la confiabilidad de los datos.

“La observabilidad y el linaje de los datos sin duda han ayudado a los equipos a identificar y solucionar problemas, e incluso sacar a la luz información sobre qué se rompió y quién se vio afectado”, dijo Maxime. “Aún así, la gestión del cambio es tan cultural como técnica. Si los equipos descentralizados no siguen los procesos y flujos de trabajo que mantienen informados a los consumidores intermedios o incluso al equipo de la plataforma central de datos, entonces es un desafío manejar el cambio de manera efectiva”.

Si no hay una delimitación entre qué datos son privados (utilizados solo por los propietarios del dominio de datos) o públicos (utilizados por la empresa en general), entonces es difícil saber quién usa qué datos y, si los datos se rompen, qué lo causó.

El análisis de linaje y causa raíz puede llevarte a la mitad del camino. Por ejemplo, mientras Maxime estaba en Airbnb, Dataportal se creó para democratizar el acceso a los datos y capacitar a todos los empleados de Airbnb para explorar, comprender y confiar en los datos. Aún así, aunque la herramienta les dijo quién se vería afectado por los cambios de datos a través del linaje de extremo a extremo, aún no facilitó la gestión de estos cambios.

Los datos deben ser inmutables, o de lo contrario se producirá el caos.

Las herramientas de datos se basan en gran medida en la ingeniería de software para inspirarse y, en general, eso es algo bueno. Pero hay algunos elementos de datos que hacen que trabajar con canalizaciones ETL sea muy diferente a un código base. ¿Un ejemplo? Edición de datos como código.

“Si quiero cambiar el nombre de una columna, sería bastante difícil hacerlo, porque tiene que volver a ejecutar su ETL y cambiar su SQL”, dijo Maxime. “Estas nuevas canalizaciones y estructuras de datos impactan en su sistema, y puede ser difícil implementar un cambio, particularmente cuando algo falla”.

Por ejemplo, si tiene un proceso incremental que carga datos periódicamente en una tabla muy grande y desea eliminar algunos de esos datos, debe pausar su canalización, reconfigurar la infraestructura y luego implementar una nueva lógica una vez que las nuevas columnas hayan terminado. se ha caído.

Las herramientas realmente no le ayudan mucho, particularmente en el contexto de las cargas diferenciales. Los rellenos aún pueden ser muy dolorosos, pero mantenerlos tiene algunos beneficios.

“En realidad, hay cosas buenas que resultan de mantener este registro histórico de sus datos”, dice. “La vieja lógica convive con la nueva lógica y se puede comparar. No tienes que romper y mutar un montón de activos que se han publicado en el pasado”.

Mantener activos de datos importantes (incluso si ya no están en uso) puede proporcionar un contexto útil. Por supuesto, el objetivo es que todos estos cambios se documenten explícitamente a lo largo del tiempo.

Entonces, ¿elige tu veneno? Deuda de datos o caos de canalización de datos.

El papel del ingeniero de datos se está fragmentando

Al igual que en la ingeniería de software, las funciones y responsabilidades de un ingeniero de datos están cambiando, en particular para las organizaciones más maduras. El ingeniero de bases de datos se está extinguiendo, las necesidades de almacenamiento de datos se están trasladando a la nube y los ingenieros de datos son cada vez más responsables de administrar el rendimiento y la confiabilidad de los datos.

Según Maxime, esto probablemente sea algo bueno. En el pasado, el ingeniero de datos era “ el peor asiento en la mesa ”, responsable de hacer operativo el trabajo de otra persona con herramientas y procesos que no estaban a la altura de las necesidades del negocio.

Ahora, están surgiendo todo tipo de roles nuevos que hacen que esto sea un poco más fácil. Caso en cuestión, el ingeniero de análisis. Acuñado por Michael Kaminsky , editor de Locally Optimistic , el ingeniero analítico es un rol que abarca la ingeniería de datos y el análisis de datos, y aplica un enfoque analítico orientado al negocio para trabajar con datos.

El ingeniero de análisis es como el susurrador de datos, responsable de garantizar que los datos no vivan aislados del análisis y la inteligencia empresarial.

“El ingeniero de datos se vuelve casi como el guardián de buenos hábitos de datos. Por ejemplo, si un ingeniero de análisis reprocesa el almacén en cada ejecución con dbt, puede desarrollar malos hábitos. El ingeniero de datos es el guardián, responsable de educar a los equipos de datos sobre las mejores prácticas, especialmente en torno a la eficiencia (manejo de cargas incrementales), el modelado de datos y los estándares de codificación, y confiar en la observabilidad de los datos y DataOps para garantizar que todos traten los datos con el mismo diligencia."

La fluencia operativa no ha desaparecido, solo se ha distribuido

La fluencia operativa, como se discutió en el artículo anterior de Maxime, se refiere al aumento gradual de responsabilidades a lo largo del tiempo y, desafortunadamente, es una realidad demasiado común para los ingenieros de datos. Si bien las herramientas modernas pueden ayudar a que los ingenieros sean más productivos, no siempre hacen que sus vidas sean más fáciles o menos onerosas. De hecho, a menudo pueden introducir más trabajo o deuda técnica con el tiempo.

Aun así, incluso con el surgimiento de roles más especializados y equipos de datos distribuidos, el avance lento de las operaciones no ha desaparecido. Parte de esto acaba de transferirse a otros roles a medida que crece el conocimiento técnico y más y más funciones invierten en la alfabetización de datos.

Por ejemplo, argumenta Maxime, lo que prioriza el ingeniero analítico no es necesariamente lo mismo que un ingeniero de datos.

“¿A los ingenieros analíticos les importa el costo de ejecutar sus tuberías? ¿Se preocupan por optimizar su pila o se preocupan principalmente por proporcionar la siguiente información? No sé." Él dice. “La lentitud operativa es un problema de la industria porque, lo más probable es que el ingeniero de datos aún tenga que administrar las cosas 'menos atractivas', como controlar los costos de almacenamiento o abordar la calidad de los datos”.

En el mundo del ingeniero analítico, también existe la fluencia operativa.

“Como ingeniero analítico, si todo lo que tengo que hacer es escribir una montaña de SQL para resolver un problema, probablemente usaré dbt, pero sigue siendo una montaña de SQL con plantillas, lo que dificulta escribir algo reutilizable o manejable. ”, dice Máximo. “Pero sigue siendo la opción que elegiría en muchos casos porque es sencillo y fácil”.

En un escenario ideal, sugiere, querríamos algo que se parezca aún más al código moderno porque podemos crear abstracciones de una manera más escalable.

Entonces, ¿qué sigue para el ingeniero de datos?

Mi conversación con Maxime me dejó mucho en qué pensar, pero, en general, tiendo a estar de acuerdo con sus puntos. Si bien la estructura de informes del equipo de datos y la jerarquía operativa se vuelven cada vez más verticales, el alcance del ingeniero de datos se vuelve cada vez más horizontal y se centra en el rendimiento y la confiabilidad, lo que en última instancia es algo bueno.

El enfoque genera innovación y velocidad, lo que evita que los ingenieros de datos intenten hervir el océano, girar demasiadas placas o, en general, quemarse. Más roles en el equipo de datos significan que las tareas tradicionales de ingeniería de datos (resultados de consultas ad-hoc, modelado, transformaciones e incluso creación de canalizaciones) no tienen que recaer únicamente sobre sus hombros. En cambio, pueden concentrarse en lo que importa: garantizar que los datos sean confiables, accesibles y seguros en cada punto de su ciclo de vida.

El cambiante panorama de las herramientas refleja este movimiento hacia un rol más enfocado y especializado. DataOps facilita la programación y ejecución de trabajos; los almacenes de datos en la nube facilitan el almacenamiento y el procesamiento de datos en la nube; los lagos de datos permiten casos de uso de procesamiento aún más matizados y complejos; y la observabilidad de datos , como el monitoreo de aplicaciones y la observabilidad anterior, automatiza muchas de las tareas rutinarias y repetitivas relacionadas con la calidad y confiabilidad de los datos, proporcionando un nivel básico de salud que permite que toda la organización de datos funcione sin problemas.

Con el surgimiento de estas nuevas tecnologías y flujos de trabajo, los ingenieros también tienen una oportunidad fantástica de hacerse cargo del movimiento hacia el tratamiento de los datos como un producto. La creación de sistemas de datos operativos, escalables, observables y resistentes solo es posible si los datos en sí se tratan con la diligencia de un producto iterativo en evolución.

Aquí es donde se usan los metadatos específicos de cada caso, el descubrimiento de datos impulsado por ML y las herramientas que pueden ayudarnos a comprender mejor qué datos realmente importan y qué puede seguir el camino de los dodos.

Al menos, eso es lo que vemos en nuestra bola de cristal.