Si busca una definición clara de qué es realmente la ingeniería de datos, obtendrá tantas propuestas diferentes que le dejarán más preguntas que respuestas.
Pero como quiero explicar lo que necesita redefinirse, mejor utilizaré una de las definiciones más populares que representa claramente el estado actual y el desastre que todos enfrentamos:
La ingeniería de datos es el desarrollo, la implementación y el mantenimiento de sistemas y procesos que toman datos sin procesar y producen información consistente y de alta calidad que respalda casos de uso posteriores, como análisis y aprendizaje automático. La ingeniería de datos es la intersección de la seguridad, la gestión de datos, DataOps, la arquitectura de datos, la orquestación y la ingeniería de software. Un ingeniero de datos administra el ciclo de vida de la ingeniería de datos, comenzando por obtener datos de los sistemas de origen y terminando por proporcionar datos para casos de uso, como análisis o aprendizaje automático.
– Joe Reis y Matt Housley en “Fundamentos de la ingeniería de datos”
Esa es una buena definición y ahora, ¿cuál es el lío?
Veamos la primera frase, donde destaco la parte importante en la que debemos profundizar:
…tomar datos sin procesar y producir información consistente y de alta calidad que respalde casos de uso posteriores…
En consecuencia, la ingeniería de datos toma datos sin procesar y transforma para (producir) información que respalde los casos de uso. Solo se dan dos ejemplos, como análisis o aprendizaje automático, pero supongo que esto incluye todos los demás casos de uso potenciales.
El transformación de datos es lo que nos vuelve locos a mí y a todos mis compañeros ingenieros de datos. La transformación de datos es la tarea monumental de aplicando la lógica correcta a datos sin procesar para transformarlos en información que permita todo tipo de casos de uso inteligentes.
Aplicar la lógica correcta es en realidad la principal tarea de aplicaciones. Las aplicaciones son los sistemas que implementan la lógica que impulsa el negocio (casos de uso). Sigo refiriéndose a ellas como una aplicación e implícitamente también me refiero a servicios que son lo suficientemente pequeños como para encajar en la arquitectura de microservicios. Las aplicaciones suelen ser creadas por desarrolladores de aplicaciones (ingenieros de software, si lo desea). Pero para cumplir con nuestra definición actual de ingeniería de datos, los ingenieros de datos ahora deben implementar la lógica empresarial. Todo el lío comienza con este enfoque equivocado.
He escrito un artículo sobre ese tema, donde destaco que “Ingeniería de datos es Ingeniería de software…”Lamentablemente, ya contamos con millones de canales de datos frágiles que han sido implementados por ingenieros de datos. Estos canales a veces (o lamentablemente, incluso muchas veces) no tienen la misma calidad de software que se esperaría de una aplicación. Pero el problema más grande es el hecho de que estos canales a menudo contienen una lógica empresarial descoordinada y, por lo tanto, incorrecta y, a veces, incluso oculta.
Sin embargo, la solución no es que todos los ingenieros de datos se conviertan en desarrolladores de aplicaciones. Los ingenieros de datos deben seguir siendo ingenieros de software cualificados, pero de ningún modo deben convertirse en desarrolladores de aplicaciones. En cambio, propongo una redefinición de la ingeniería de datos como “Todo sobre el movimiento, manipulación y gestión de datos”Esta definición proviene del libro “¿Qué es la ingeniería de datos? Luis Gavin (O’Reilly, 2019)”. Sin embargo, y esto supone una clara diferencia con las prácticas actuales, deberíamos Limitar la manipulación a las puramente técnicas..
Ya no deberíamos permitir el desarrollo y uso de la lógica empresarial fuera de las aplicaciones.
Para ser muy claro, la ingeniería de datos debe no Implementar la lógica empresarial. La tendencia en el desarrollo de aplicaciones modernas es, en realidad, mantener la lógica de la aplicación sin estado separada de la gestión del estado. No ponemos la lógica de la aplicación en la base de datos y no ponemos el estado (o los datos) persistente en la aplicación. En la comunidad de programación funcional, bromean: “Creemos en la separación de la iglesia y el estado”. Si ahora piensas: “¿Dónde está el chiste?”, entonces esto podría ayudar. Pero ahora sin bromas: “Deberíamos creer en la separación entre la lógica empresarial y los datos empresariales”. En consecuencia, creo que deberíamos dejar explícitamente las preocupaciones sobre los datos al ingeniero de datos y las preocupaciones sobre la lógica al desarrollador de aplicaciones.
¿Cuáles son las “manipulaciones técnicas” que todavía están permitidas para el ingeniero de datos?, podría preguntarse. Yo definiría esto como cualquier manipulación de datos que no cambie ni agregue nueva información comercial. Todavía podemos particionar, agrupar, reformatear, normalizar, indexar, agregar técnicamente, etc., pero tan pronto como sea necesaria una lógica empresarial real, debemos dirigirla a los desarrolladores de aplicaciones en el dominio empresarial responsables del conjunto de datos respectivo.
¿Por qué nos hemos alejado de este principio simple y obvio?
Creo que este cambio puede atribuirse a la rápida evolución de las bases de datos hacia sistemas multifuncionales. Inicialmente, las bases de datos servían como soluciones de almacenamiento simples y duraderas para datos comerciales. Proporcionaron abstracciones muy útiles para descargar la funcionalidad y conservar datos de la lógica empresarial real en las aplicaciones. Sin embargo, los proveedores mejoraron rápidamente estos sistemas incorporando funcionalidades de desarrollo de software en sus productos de bases de datos para atraer a los desarrolladores de aplicaciones. Esta integración transformó las bases de datos de meros repositorios de datos a plataformas integrales, incorporando lenguajes de programación sofisticados y herramientas para el desarrollo de software completo. En consecuencia, las bases de datos evolucionaron hasta convertirse en potentes motores de transformación que permitieron a los especialistas en datos implementar lógica empresarial fuera de las aplicaciones tradicionales. La demanda de este cambio se amplificó aún más con la llegada de almacenes de datos a gran escala, diseñados para consolidar el almacenamiento de datos dispersos, un problema que se volvió más pronunciado con el surgimiento de la arquitectura de microservicios. Esta progresión tecnológica hizo que fuera práctico y eficiente combinar la lógica empresarial con los datos comerciales dentro de la base de datos.
Al final, no todos los ingenieros de software sucumbieron a la tentación de agrupar la lógica de su aplicación dentro de la base de datos, manteniendo la esperanza de una separación más limpia. A medida que los datos siguieron creciendo en volumen y complejidad, surgieron herramientas de big data como Hadoop y sus sucesores, que incluso reemplazaron a las bases de datos tradicionales en algunas áreas. Este cambio presentó una oportunidad para sacar la lógica empresarial de la base de datos y devolverla a los desarrolladores de aplicaciones. Sin embargo, la noción de que la ingeniería de datos abarca algo más que el simple movimiento y gestión de datos ya se había arraigado. Habíamos desarrollado numerosas herramientas para respaldar la inteligencia empresarial, el análisis avanzado y los procesos de transformación complejos, lo que permitió la implementación de una lógica empresarial sofisticada.
Estas herramientas se han convertido en componentes integrales de la pila de datos moderna (MDS), estableciendo la ingeniería de datos como su propia disciplina. El MDS comprende un conjunto completo de herramientas para la manipulación y transformación de datos, pero estas herramientas siguen siendo en gran medida desconocidas para el típico desarrollador de aplicaciones o ingeniero de software. A pesar del potencial para “Dale la vuelta a la base de datos” y reubicar la lógica empresarial nuevamente en la capa de aplicación, no pudimos aprovechar plenamente esta oportunidad. La desafortunada práctica de implementar la lógica empresarial persiste entre los ingenieros de datos hasta el día de hoy.
Definamos con mayor precisión qué “Todo sobre el movimiento, manipulación y gestión de datos” implica.
Los ingenieros de datos pueden y deben proporcionar las herramientas y plataformas más maduras para que las utilicen los desarrolladores de aplicaciones para manejar datos. Esta es también la idea principal con el “plataforma de datos de autoservicio” en la malla de datos. Sin embargo, la responsabilidad de definir y mantener la lógica empresarial sigue estando dentro de los dominios empresariales. Estas personas conocen mucho mejor el negocio y qué lógica de transformación empresarial se debe aplicar a los datos.
Bien, ¿qué pasa con estas buenas ideas como los sistemas de almacenamiento de datos y, en términos más generales, el conjunto? “ciclo de vida de la ingeniería de datos” ¿Según lo definen Joe Reis y Matt Housley?