Recientemente, tuve la suerte de hablar con varios ingenieros y arquitectos de datos sobre los problemas que enfrentan con los datos en sus empresas. Los principales puntos críticos que escuché una y otra vez fueron:
- Sin saber por qué algo se rompió
- Quemarse con los altos costos de computación en la nube
- Tomar demasiado tiempo para crear soluciones de datos o completar proyectos de datos
- Necesita experiencia en muchas herramientas y tecnologías.
Estos problemas no son nuevos. Yo los he experimentado, y tú probablemente los hayas experimentado. Sin embargo, no parece que podamos encontrar una solución que resuelva todos estos problemas a largo plazo. Tal vez pienses: “Bueno, el punto uno se puede resolver con {insertar herramienta de observación de datos}”, o “el punto dos solo necesita un plan de gobernanza de datos más estricto”. El problema con este tipo de soluciones es que agregan capas adicionales de complejidad, lo que hace que los dos puntos críticos finales se vuelvan más graves. La suma total de los puntos críticos sigue siendo la misma, solo que hay una distribución diferente entre los cuatro puntos.
Este artículo pretende presentar un estilo contrario de resolución de problemas: la simplicidad radical.
Resumen
- Los ingenieros de software han logrado un éxito enorme al adoptar la simplicidad.
- La ingeniería excesiva y la búsqueda de la perfección pueden dar como resultado sistemas de datos inflados y de desarrollo lento, con costos altísimos para la empresa.
- Los equipos de datos deberían considerar sacrificar algunas funcionalidades en aras de la simplicidad y la velocidad.
Una lección de los chicos del software
En 1989, el científico informático Richard P. Gabriel Escribió un ensayo relativamente famoso sobre sistemas informáticos, paradójicamente llamado “Peor es mejor”. No entraré en detalles, puedes leer el ensayo. aquí Si se quiere, pero el mensaje subyacente era que la calidad del software no necesariamente mejora a medida que aumenta la funcionalidad. En otras palabras, en ocasiones se puede sacrificar la integridad por la simplicidad y terminar con un producto inherentemente “mejor” debido a ello.
Esta idea era extraña para los pioneros de la informática durante los años 1950 y 1960. La filosofía de la época era: un sistema informático debe ser puro, y solo puede serlo si tiene en cuenta todos los escenarios posibles. Esto probablemente se debió al hecho de que la mayoría de los principales científicos informáticos de la época eran académicos, que querían tratar la informática como una ciencia dura.
Los académicos del MIT, la institución líder en informática en ese momento, comenzaron a trabajar en el sistema operativo para la próxima generación de computadoras, llamado MulticsDespués de casi una década de desarrollo y millones de dólares de inversión, los chicos del MIT lanzaron su nuevo sistema. Sin lugar a dudas, era el sistema operativo más avanzado de la época, pero su instalación era complicada debido a los requisitos informáticos y las actualizaciones de funciones eran lentas debido al tamaño de la base de código. Como resultado, nunca se popularizó más allá de unas pocas universidades e industrias seleccionadas.
Mientras se estaba construyendo Multics, un pequeño grupo que apoyaba el desarrollo de Multics se sintió frustrado por los crecientes requisitos que exigía el sistema. Finalmente, decidieron abandonar el proyecto. Armados con esta experiencia, se propusieron crear su propio sistema operativo, uno con un cambio de filosofía fundamental:
El diseño debe ser simple, tanto en la implementación como en la interfaz. Es más importante que la implementación sea simple que la interfaz. La simplicidad es la consideración más importante en un diseño.
—Richard P. Gabriel
Cinco años después del lanzamiento de Multics, el grupo disidente lanzó su sistema operativo, UnixLentamente pero de manera constante, fue ganando terreno y en la década de 1990 Unix se convirtió en la opción preferida para las computadoras, con Más del 90% de las 500 supercomputadoras más rápidas del mundo usándolo. Hasta el día de hoy, Unix todavía se usa ampliamente, sobre todo como el sistema subyacente a macOS.
Obviamente, hubo otros factores más allá de su simplicidad que llevaron al éxito de Unix, pero su diseño liviano fue, y sigue siendo, un activo muy valioso del sistema. Eso sólo pudo lograrse porque los diseñadores estaban dispuestos a sacrificar funcionalidad. La industria de datos no debería tener miedo de pensar de la misma manera.
Regreso a los datos en el siglo XXI
Al recordar mis propias experiencias, la filosofía de la mayoría de los proyectos de ingeniería de big data en los que he trabajado era similar a la de Multics. Por ejemplo, había un proyecto en el que necesitábamos automatizar la estandarización de los datos sin procesar que llegaban de todos nuestros clientes. Se tomó la decisión de hacerlo en el almacén de datos a través de dbt, ya que así podríamos tener una vista completa del linaje de datos desde los archivos sin procesar hasta la versión de tabla única estandarizada y más allá. El problema fue que la primera etapa de transformación fue muy manual, requirió cargar cada archivo de cliente sin procesar individual en el almacén, luego dbt crea un modelo para limpiar el archivo de cada cliente. Esto llevó a que se necesitaran generar cientos de modelos dbt, todos usando esencialmente la misma lógica. Dbt se volvió tan inflado que tomó minutos para que el gráfico de linaje de datos se cargara en el sitio web de documentación de dbt, y nuestras Acciones de GitHub para CI (integración continua) tardó más de una hora en completarse para cada solicitud de extracción.
Esto podría haberse resuelto de manera bastante sencilla si el liderazgo nos hubiera permitido realizar la primera capa de transformaciones fuera del almacén de datos, utilizando AWS Lambda y Python. Pero no, eso habría significado que el linaje de datos producido por dbt no estaría 100 % completo. Eso fue todo. Esa fue la razón principal para no simplificar enormemente el proyecto. Al igual que el grupo que se separó del proyecto Multics, yo abandoné este proyecto a mitad de su desarrollo; era simplemente demasiado frustrante trabajar en algo que claramente podría haber sido mucho más simple. Mientras escribo esto, descubrí que todavía están trabajando en el proyecto.
Entonces, ¿qué diablos es la simplicidad radical?
La simplicidad radical en la ingeniería de datos no es un marco de trabajo ni un conjunto de herramientas de pila de datos, es simplemente una mentalidad. Una filosofía que prioriza las soluciones simples y directas por sobre los sistemas complejos y abarcativos.
Los principios clave de esta filosofía incluyen:
- Minimalismo: centrarse en las funcionalidades principales que aportan el mayor valor, en lugar de intentar adaptarse a todos los escenarios o requisitos posibles.
- Aceptar compensaciones: sacrificar voluntariamente cierto grado de integridad o perfección en favor de la simplicidad, la velocidad y la facilidad de mantenimiento.
- Pragmatismo por encima del idealismo: priorizar soluciones prácticas y viables que resuelvan problemas empresariales reales de manera eficiente, en lugar de buscar sistemas teóricamente perfectos pero excesivamente complejos.
- Carga cognitiva reducida: diseñar sistemas y procesos que sean más fáciles de entender, implementar y mantener, reduciendo así la experiencia requerida en múltiples herramientas y tecnologías.
- Rentabilidad: adoptar soluciones más simples que a menudo requieren menos recursos computacionales y capital humano, lo que se traduce en costos generales más bajos.
- Agilidad y adaptabilidad: crear sistemas que sean más fáciles de modificar y evolucionar a medida que cambian las necesidades del negocio, en lugar de soluciones rígidas y sobrediseñadas.
- Centrarse en los resultados: enfatizar los resultados finales y el valor comercial en lugar de quedar atrapado en las complejidades de los procesos de datos en sí.
Esta mentalidad puede estar en contradicción directa con las soluciones de ingeniería de datos modernas que implican agregar más herramientas, procesos y capas. Como resultado, se espera que defienda su posición. Antes de sugerir una solución alternativa más simple, prepárese con un conocimiento profundo del problema en cuestión. Recuerdo la cita:
Se necesita mucho trabajo duro para hacer algo sencillo, comprender verdaderamente los desafíos subyacentes y encontrar soluciones elegantes. […] No se trata solo de minimalismo o de ausencia de desorden. Se trata de explorar las profundidades de la complejidad. Para ser verdaderamente simple, hay que llegar muy profundo. […] Es necesario comprender profundamente la esencia de un producto para poder deshacerse de las partes que no son esenciales.
—Steve Jobs
Nota al margen: tenga en cuenta que adoptar una simplicidad radical no significa ignorar las nuevas herramientas y las tecnologías avanzadas. De hecho, una de mis soluciones favoritas para un almacén de datos en este momento es usar una nueva base de datos de código abierto llamada Pato DBÉchale un vistazo, es bastante genial.
Conclusión
Las lecciones de la historia de la ingeniería de software ofrecen información valiosa para el panorama de datos actual. Al adoptar una simplicidad radical, los equipos de datos pueden abordar muchos de los problemas que afectan a las soluciones de datos modernas.
No tenga miedo de promover la simplicidad radical en su equipo de datos. Sea el catalizador del cambio si ve oportunidades de optimizar y simplificar. El camino hacia la simplicidad no es fácil, pero las posibles recompensas pueden ser sustanciales.