3 Data Engineering Pitfalls

Cuando diseñamos o mantenemos una infraestructura de datos hay múltiples pain points que pueden resolverse antes de que sea muy tarde… algunos de ellos son bastante obvios pero quizás no les damos importancia, otros son más difíciles de reconocer, hasta que ya estamos muy dentro y la dificultad para salir de ello es gigantesca. Partiendo de esta base, a lo largo de este artículo les describo tres de las trampas más comunes en ingeniería de datos.

1. Arquitectura completamente serverless

Antes que nada debo aclarar que en este caso específico me refiero a serverless del tipo AWS Lambda. ya que actualmente existen una gran cantidad de soluciones efectivas en las distintas clouds que son serverless pero enfocadas a Data workflows como Data flow o AWS Glue.

Las principales ventajas de los servicios serverless (como Lambda) son el fácil despliegue de la lógica de negocio en un «contenedor» listo para escalar de forma automática y a demás lo barato que puede ser pagar unicamente por el tiempo de ejecución, pero…

Es justo allí donde está la trampa, porque hasta ahora todas las ventajas que trae consigo serverless suena genial pero que sucede cuando la pequeña lógica de negocio que utilizamos al inicio dentro del serverless empieza a crecer en tamaño y en complejidad?

Anteriormente mencionamos que el costo de serverless es únicamente por el tiempo de ejecución, pero que sucede si el tiempo de ejecución es tan largo que el servicio casi nunca esta en modo «reposo» o sin consumo de recursos. Y luego claro para poder solventar la complejidad de los pipelines empezamos a crear más y más apps serverless con dependencias entre sí.

Aunado a todo esto, reintentar la ejecución de un pipeline que ha fallado ya sea parcial o completamente, tomando en cuenta todas estas dependencias es en la mayoría de los casos una tarea manual y muy desgastante.

¡Boom!

Sí, boom… cuando se rompe la infraestructura porque es casi imposible mantenerlo a largo plazo a medida que sigue creciendo y solamente queda migrar a una infraestructura más robusta.

2. Monitoreo

Muchos de ustedes habrán sentido ya esa satisfacción de deployar finalmente la última pieza de su genial pipeline, luego de meses de trabajar en ella y arreglar los errores, finalmente está funcionando y los stakeholders están satisfechos con el servicio que se completó.

Parece que ya no hay mucho más que hacer acá, hasta que se requieran cambios o agregar características nuevas al servicio.

¡Cuidado!

Esta es una trampa que sucede principalmente en proyectos o equipos que están en sus comienzos y tienen demasiado trabajo. Y entonces pensamos que es suficiente con guardar los logs de los distintos procesos y dejamos para después la integración de un verdadero sistema de monitoreo.

Estrategias para monitoreo hay muchas, lo importante es darles el tiempo adecuado para analizar en que partes del proyecto es crucial tener un monitoreo activo que pueda ayudarnos a prevenir o al menos a identificar rápidamente los errores que posiblemente ocurrirán.

La mayoría de las veces tardamos mucho más tiempo buscando una solución a un error que montando un sistema de monitoreo que agilizará la solución de estos errores, incluso es muy probable que podamos evitar las consecuencias de un error que puede impactar muchos otros sistemas con tan solo montar alertas adecuadas en el sistema de monitoreo.

3. Arquitectura de datos sin gobernanza

Aunque el tema de la gobernanza de datos no es algo nuevo, aún se nos hace difícil acostumbrarnos a darle el tiempo necesario a establecer y mantener una gobernanza de datos adecuada.

Así que empezaremos por identificar si en su infraestructura existe una gobernanza de datos o no.

Los principales síntomas de una falta de gobernanza son los siguientes:

• Toda la data cae al mismo bucket o espacio.
• Data de múltiples versiones con estructuras distintas en el mismo espacio.
• No existen reglas o políticas establecidas sobre cómo y dónde guardar la data.
• Los pipelines mezclan workflows que no tienen relación directa en tema o dominio.
• Es difícil hacer modificaciones en los workflows existentes.
• No hay documentación sobre los catálogos de datos.
• No existen entornos (como data lake, data warehouse, etc) específicamente para desarrollo/pruebas.

Algunas de las consecuencias de la falta de gobernanza son por ejemplo tener una gran cantidad de data duplicada dentro del data lake debido a que la falta de orden hace casi imposible identificar estos duplicados. Cuando hablamos de Big Data esta duplicación puede impactar directamente en los costos no solo de almacenamiento de datos sino también en costos de ejecución ya que mientras más data tengas, más tardan los procesos en transformar y por ende gastan más recursos.

Gobernanza es el proceso de manejar la disponibilidad, usabilidad, integridad y seguridad de los datos en un sistema, basado en estándares internos y políticas de control de los datos.

• Disponibilidad: Asegurarse de que los datos sean accesibles de una forma fácil y eficiente dependiendo de quien sea el consumidor de estos.
• Usabilidad: Esto implica que los datos resultantes al final del proceso realmente se puedan utilizar para lo que sean necesarios por ejemplo, si son archivos xml o protobufs, poder convertirlos a un formato en el que sea posible consumirlos con queries o por medio de alguna interfáz a la que los consumidores tengan acceso.
• Integridad: Debemos estar seguros de que los datos que obtuvimos están completos y no están sucios.
• Consistencia: Asegurarse de que en caso de haber diferentes versiones o cambios repentinos, por ejemplo al consumir datos desde una fuente externa, esto no debe afectar el actual funcionamiento y pueda existir una transición hacia nuevas versiones.
• Seguridad: No solo mantener los sistemas, conexiones y servers seguros con firewalls, vpns y muchas otras herramientas que tenemos ahora en la nube sino también poder estar seguros de que a pesar de que tengamos un data lake privado, se limite el acceso a datos de producción sensibles a los usuarios que realmente los necesitan y en caso de ser datos muy delicados, tener una estrategia como la encriptación. También tener la opción de borrar los datos en caso de que un cliente lo pida ya que es su información y que “el desorden” no sea impedimento.

Algunas de las estrategias para implementar o mejorar la gobernanza de datos son las siguientes:

• Establecer políticas de uso de los datos.
• Crear y actualizar los catálogos de datos.
• Crear y actualizar las definiciones/diccionarios de datos.
• Establecer políticas de Seguridad de los datos.
• Reconocer los Data Domains dentro de la organización.

¿Un Data Domain?

Es una colección de información y procesos relacionados a esa información que son independientes de otras colecciones o procesos y se consume por medio de su propia interfaz.

Conclusiones

En base a lo comentado, estas son algunas de las conclusiones que he obtenido:

• Empieza pequeño (Metodología Lean). Solo puedes controlar lo que puedes medir. Define quienes son las personas responsables de cada proyecto o dominio.
• La Gobernanza es un trabajo en equipo que requiere de todas las partes involucradas para que pueda funcionar.
• Educa a las personas involucradas en los proyectos para que siempre estén al tanto de las políticas y planificación.
• Mapea y documenta.
• Desarrolla definiciones estandarizadas.
• Identifica los dominios de datos.

Originalmente publicado en:
https://planetachatbot.com/3-trampas-en-ingenieria-de-datos/