DataOps primeros pasos, ¿cómo debe ser el pipeline de datos?

Vivimos en una época donde se generan datos a una velocidad nunca antes imaginada. Para poder tomar mejores decisiones y tener una ventaja competitiva, las empresas necesitan contar con la mayor cantidad de datos posibles en un ambiente centralizado, gobernado y de fácil acceso.

Como respuesta a esto, las arquitecturas clásicas de datos basadas en Data Warehousing evolucionaron para dar respuesta a las limitaciones inherentes a estas arquitecturas monolíticas, de esta manera, surgieron nuevas tecnologías:

· Data Lake: repositorios de objetos que permiten almacenar grandes volúmenes de datos a bajo costo. De esta manera se resuelven dos grandes problemas de los Data Warehouses: la imposibilidad de almacenar información no estructurada (por ejemplo, imágenes) y se reducen los costos debido a la posibilidad que ofrecen de escalar en volúmenes de datos.

· Lakehouse: evolución del Data Lake, este paradigma incorpora tecnologías que les otorgan capacidades de comportarse como una base de datos (transacciones, updates, etc.) y garantizan mejoras en los tiempos de respuestas al realizar consultas SQL sobre los mismos.

Por otra parte, el reto 🧗‍♀️ no es sólo tecnológico, la decisión de adoptar una cultura data-driven, ya sea en grandes corporaciones o pequeñas startups, conlleva la aparición de problemas que están más asociados a procesos deficientes o, incluso, inexistentes:

· Falta de gobierno de los datos.

· Proliferación de stacks tecnológicos incompatibles entre sí.

· Silos de información.

· Mala o nula capacidad de compartir datos entre áreas.

· Imposibilidad de saber a ciencia cierta qué datos están disponibles, su significado y si son confiables o no.

Estas cuestiones motivan el surgimiento de nuevos paradigmas como Data Fabric o Data Mesh, que en un próximo artículo estaremos discutiendo.

La importancia de la sistematización

Si consideramos a los datos como el activo más valioso 🤑 de una empresa, será fundamental contar con las estrategias y procesos necesarios para entregarlos en tiempo y forma al negocio. La disparidad, diversidad y gran cantidad de fuentes de datos a los que puede acceder una empresa, hacen que sea fundamental contar con un pipeline de datos sistemático que permita estandarizar el desarrollo, validación e implementación de procesos de extracción, carga y transformación de los datos.

Tradicionalmente, estos pipelines eran desarrollados con herramientas de ETL visuales que corrían en modo cliente-servidor (Informatica, Talend, Pentaho, etc.) El desarrollo visual, si bien facilitaba el desarrollo al disminuir la complejidad, limitaba en algún punto la flexibilidad y capacidad de estas herramientas.

Con la explosión en volumen de datos y, en respuesta a esto, la llegada de los sistemas distribuidos, en un primer momento Hadoop 🐘, ahora Apache Spark; las bases de datos MPP (masivamente paralelas), y las nuevas arquitecturas de datos mencionadas, hicieron que esa forma tradicional de construir pipelines haya mutado a un modelo de desarrollo basado en scripting (pySpark, python, SQL) sobre servicios en la nube.

El escenario se reconfiguró al punto tal que hasta el acrónimo ETL cambió a ELT 🙃: extraer de origen para cargar y transformar los datos en destino y aprovechar la capacidad de cómputo disponible.

Si bien este nuevo escenario brinda grandes beneficios respecto a la capacidad y flexibilidad de trabajo, también plantea grandes desafíos de cara al equipo de desarrollo. Es decir, la contención, estructura y método de trabajo que antes era impuesto por las herramientas de ETL tradicionales, desaparece por completo. Esto puede generar, muy fácilmente, grandes problemas a futuro sino es encarado siguiendo un esquema metodológico: cada ingeniero de datos tendrá su propio criterio a la hora de desarrollar un script, cómo implementarlo y, peor 😲, como mantenerlo.

Es por esto que se torna fundamental heredar y comenzar a adoptar buenas prácticas del desarrollo de software tradicional: modularización, integración y entrega continua, adopción de mecánicas de trabajo ágiles, etc.

DatOps al rescate💪

En el último tiempo, han tomado fuerza enfoques como DataOps que le dan un marco teórico y metodológico a esta necesidad de mejorar la manera en la que los equipos de datos trabajan en sus proyectos.

DataOps propone adoptar prácticas asociadas a: DevOps tradicional, Agile Development y Statistical Process Controls. El primer paso para poder adoptar estas prácticas es definir cómo implementarlas, en este sentido, y en base a la experiencia, consideramos que un pipeline debe cumplir con las siguientes características:

1. Todos los artefactos tienen que estar versionados utilizando un Sistema de Control de Versionado (VCS). De esta manera podremos trabajar de forma colaborativa, evitando problemas cuando más de un ingeniero de datos esté trabajando sobre el mismo concepto. Además, es posible llevar un control de cambios detallado, lo que asegura la trazabilidad y, en el caso de ser necesario, volver a un determinado estado en el tiempo.

2. El trabajo tiene que organizarse en sprints cortos que busquen la entrega de nuevas funcionalidades al final de cada uno. Se debe tener un backlog claro con tareas atómicas sin ambigüedades.

3. Se debe asegurar la calidad de:

a. Código: los scripts deben cumplir con reglas de sintaxis y seguridad predefinidas.

b. Datos: es fundamental que en cada estadio por el que atraviesa un dato a lo largo del flujo, se cuente con reglas que aseguren la calidad del mismo en todos los aspectos que se considere necesario: completitud, tipo, cantidad de registros, entre otros.

4. Es necesario que haya separación de ambientes, con al menos un ambiente de desarrollo, testing y otro productivo.

5. El desarrollo debe darse bajo un esquema de:

a. Integración continua (CI): esta práctica consiste en integrar de manera frecuente, a un único repositorio, los cambios desarrollados sobre el código de un proyecto de software. Además, dicho código debe pasar por una serie de pruebas automáticas que verifiquen su integridad.

b. Entrega continua (CD): en este caso, los cambios y pruebas se ejecutan en forma automática en un ambiente de testing (QA) que, en términos de volumen y calidad de datos, debe reflejar el ambiente productivo.

c. Despliegue continuo (CD): todos los cambios que hayan pasado las validaciones correspondientes en el ambiente de testing, se despliegan de manera automática en producción, sin intervención humana.

6. La dependencia y precedencia de ejecución de cada artefacto debe estar definida y documentada en forma clara.

7. Tiene que existir un registro de ejecución centralizado que facilite el proceso de auditoría y debugging.

Entonces, ¿qué hacemos? 🤔

Hoy más que nunca, es fundamental pensar las soluciones de datos, desde sus comienzos, orientadas a dar respuesta a las problemáticas de negocio de forma confiable y en el momento indicado.

El objetivo principal debe ser que, cualquier tomador de decisiones de la empresa, pueda hacerlo basado en datos fiables y actualizados. Además, se debe asegurar la democratización, facilitando tanto el acceso y descubrimiento, como la posibilidad de compartir datos entre individuos o áreas, todo esto sin perder nunca de vista el gobierno y la seguridad.

Para lograr estos objetivos, más allá de la arquitectura o tecnología a utilizar, lo más importante es definir una estrategia que reconozca la importancia de implementar una mecánica de trabajo centrada en aportar valor, que permita anticipar y reducir problemas de datos en base a metodologías bien establecidas.

En este artículo pueden leer una demostración práctica en la cual explicamos cómo implementar CI/CD en Databricks.