Desmitificando el Modern Data Stack
De un tiempo a esta parte venimos escuchando y leyendo mucho acerca del Modern Data Stack (MDS de ahora en más 😊), a tal punto que una de las empresas más preponderantes en el mundo de los datos (sino la más), Databricks, está impulsando el concepto junto con otros vendors. El término se popularizó — y deformó — hasta un punto en el que incluso se llega a hablar del post MDS.
Para evitar entrar en un espiral infinito de blog posts o búsquedas en Google, trataremos de alejarnos un poco de la moda para poner foco en entender en qué consiste un stack de datos moderno y, sobre todo, repasar los beneficios que nos puede otorgar implementarlo.
¿Qué hay de nuevo viejo 🐰?
Es importante comenzar aclarando que la implementación de un stack de este estilo está fundamentada en tres pilares de los que ya hemos hablado:
- Adopción de servicios en la nube para aprovechar todas sus ventajas: flexibilidad, pago por uso y escalabilidad para mencionar las más importantes. Por otra parte, nos vamos a encontrar con una oferta grande de servicios de propósito específico que implementaremos según necesidad.
- Separación de la arquitectura en capas de manera tal que podamos construirla y validarla de forma iterativa y modular, evitando soluciones monolíticas que no escalan.
- Cambio del paradigma ETL a EL-T, es decir, dejamos atrás los buenos viejos tiempos 🕰 donde una herramienta se encargaba de extraer los datos de origen, procesarlos y cargarlos a nuestro destino final, un Data Warehouse. La propuesta ahora es cargar nuestros datos tal como están en el origen a un repositorio central (Data Lake, Data Warehouse — sigue vigente — o Lakehouse) para luego transformarlos, así haremos uso de las bondades del almacenamiento y procesamiento distribuido de datos.
El hecho que los tres puntos mencionados se hayan establecido en la industria como una especie de estándar, hizo que, sobre esa base, se de una evolución evidenciada en el surgimiento de nuevas empresas abocadas a construir herramientas de propósito hiper específico. La novedad 🆕 entonces, es que nos encontramos sobre la mesa con una gran cantidad de herramientas para dar solución a problemas muy puntuales en la construcción de una arquitectura moderna de datos.
Para bajar esto a tierra, repasemos las distintas capas de estas arquitecturas. Para cada una veremos:
- Las características deseables en las que fijarnos.
- Algunas herramientas disponibles.
- Beneficios que podemos obtener.
Almacenamiento y cómputo
Tal como mencionamos, las arquitecturas modernas de datos cuentan con un repositorio central donde guardaremos nuestros datos, ya sea en su versión original (datos crudos) o en un estadio posterior, luego de aplicar transformaciones o lógica de negocio. Es por esto último que, además del almacenamiento, la tecnología que implementemos nos debe proveer del cómputo necesario para acceder a los datos de manera eficiente.
Sea cual sea la herramienta que elijamos, tengamos en cuenta que esta capa será el centro 🎯 de la arquitectura y, por ende, la que más influencia tendrá sobre el resto.
En cuanto a las características deseables en las que nos deberíamos fijar podemos listar:
- Separación de almacenamiento y cómputo: es fundamental que podamos escalarlos por separado según necesidad, el sólo hecho de ingestar más datos no es motivo para tener que adquirir más capacidad de cómputo, lo mismo para el caso contrario.
- Pago por uso: una de las características más destacadas de operar en la nube. Lo que paguemos tiene que estar directamente relacionado con el uso que le demos a los datos, sin necesidad de hacer inversiones anticipadas.
- Integración: si esta herramienta será el centro de la arquitectura, de más está decir que debe integrarse con, al menos:
- Herramientas ELT
- Herramientas de visualización.
- Formatos abiertos: es cada vez mayor la adopción de formatos de datos abiertos, ya sea tradicionales, como Parquet o JSON, como las evoluciones que permiten operaciones tipo base de datos (transacciones con características ACID), como Delta Lake o Apache Iceberg. Por esto es fundamental que podamos consumir estos tipos de archivos sin quedar atados a un formato propietario que genere vendor lock-in.
- Seguridad: si vamos a almacenar todos nuestros datos, de más está decir que la seguridad juega un rol clave. Entre otras cosas la herramienta tiene que permitir:
- Acceso granular: cada usuario accederá sólo a los datos sobre los que tenga permisos, con la posibilidad de aplicarlos hasta un nivel de fila y columna.
- Encriptación.
- Aislamiento: de requerirlo, podríamos configurar el entorno de manera tal que el intercambio de datos se de dentro de los recursos que estamos usando sin pasar por Internet.
- Rendimiento.
Las herramientas más populares en esta capa son:
Con respecto a los beneficios de implementar estas herramientas tenemos:
- Costo eficiencia asociado al pago por uso.
- Escalabilidad ya que podemos aumentar la capacidad de almacenamiento y/o cómputo a demanda y de manera sencilla.
- Disponibilidad de los datos al momento de cargarlos.
- Repositorio de datos unificado evitando silos de información.
De aquí en adelante nos referiremos a esta capa como el Data Warehouse (DW).
Ingestión
En esta capa nos encargaremos de alimentar la herramienta que vayamos a utilizar en la capa de almacenamiento y cómputo. Es decir, vamos a traer datos de distintas fuentes para luego utilizarlos de diversas maneras.
Dentro del ámbito del MDS, lo que más nos va a interesar encontrar es:
- Zero Coding: para no dedicar recursos de ingenieros/as de datos en tareas que podemos tener resueltas por la herramienta.
- Variedad de conectores: la forma en la que interactuaremos con estas herramientas es mediante el uso de conectores que configuraremos en una interfaz visual.
- Origen: cualquier aplicación o producto que genere datos, desde un CRM hasta herramientas de tracking.
- Destino: DW.
Algunas herramientas disponibles:
Los beneficios de utilizar estas herramientas: foco en el qué, no en el cómo. Es decir:
- Más datos en menos tiempo 🚄.
- Enfoque en aportar valor al negocio ya que el ahorro en recursos y en tiempo de desarrollo de integraciones lo podemos dedicar a tareas que aporten valor.
- Robustez.
- Escalabilidad.
Transformación
Los datos que ingestemos por sí solos no van a generar ningún valor, es necesario limpiarlos, enriquecerlos, cruzarlos entre sí y, por último, generar datasets que puedan ser explotados luego, ya sea por usuarios o por aplicaciones.
¿Qué características nos interesan en esta capa?
- Uso del DW como motor de procesamiento.
- Poder delegar en la herramienta tareas que no aportan valor.
- Validaciones automáticas.
- Documentación de metadatos: como estamos construyendo datasets que serán utilizados por otras personas, es importante — por no decir imprescindible — contemplar la documentación de los metadatos 📖 para que el uso y el descubrimiento sea más accesible.
- Data as Code para acercarnos a la adopción de DataOps, por eso necesitamos que la herramienta soporte:
- Reusabilidad.
- Versionado.
- CI/CD.
La herramienta estrella en esta capa es dbt que en los últimos dos años se ha consolidado casi como la única opción.
Los beneficios que obtendremos en este caso son:
- Menores tiempos de desarrollo.
- Mejoras en la calidad y disponibilidad de los datos. 📈
- Código mantenible y limpio.
- Comprensión aumentada a través de la documentación y linaje de datos.
Explotación
De nada nos servirá tener una arquitectura de datos si, a fin de cuentas, no usamos los datos que generamos.
Si bien hay muchas maneras de explotarlos, las más comunes son:
- Visualización.
- Machine Learning.
- Operacionalización (es más fácil hacerlo que decirlo 😵): esto también se conoce como reverse ETL, básicamente es accionar con los datos de forma directa retroalimentando las herramientas operativas. Por ejemplo, podríamos enviarle a los contactos del CRM un campo calculado en el DW.
La característica principal que hay que tener en cuenta es la capacidad de estas herramientas para conectarse y operar directamente con el DW. Si construimos nuestra arquitectura de datos alrededor de este repositorio unificado de información, lo más razonable es pensar nuestros procesos y desarrollos para utilizarlo, en la medida de lo posible, como la única fuente de explotación de datos.
En cuanto a la disponibilidad de herramientas, en visualización es donde más alternativas encontraremos, principalmente dentro del mundo del Business Intelligence tradicional (Power BI, Tableau, Superset, Metabase por nombrar algunas pagas y gratuitas). Vale la pena mencionar que es cada vez más fuerte la tendencia a desacoplar la capa semántica de estas herramientas para gestionarla por separado, esto lo encontraremos generalmente con el nombre de Headless BI. En pocas palabras, la definición de cómo se cruzan las tablas de nuestro modelo de datos y dónde encontrar métricas y dimensiones, o cómo se calculan los KPIs, se define en una herramienta para luego consumirla desde otro lado. La evolución y adopción de este paradigma, creemos, es el mejor camino para lograr el ideal de self service BI.
Con respecto a Machine Learning, si bien comienzan a surgir herramientas bajo el paraguas del MDS como Continual o Neptune, el progreso más importante es el reconocimiento de la falta de procesos y el caos que reina en el desarrollo e implementación (si es que tenemos suerte) de modelos. Para mejorar esta situación, los equipos comienzan a incorporar la práctica de MLOps que, como explicamos en este artículo, se trata más de una cuestión cultural que de las herramientas a utilizar, aunque seguramente surgirán nuevas tecnologías que, al igual que en las otras capas, nos permitan entregar valor mucho más rápido al solucionar cuestiones que hoy debemos resolver de forma manual.
Por último, mencionamos reverse ETL y cómo nos permite intervenir directamente en la operación del negocio. Las herramientas más populares hoy en día son: Grouparoo (Open Source), Census y Hightouch (pagas).
Orquestación
La capa final y la que aglutina todo nuestro stack.
Si los conectores son importantes en las otras capas, en esta se vuelven cruciales ya que la herramienta deberá comunicarse con cada una de las capas que detallamos.
También es importante aquí poder escribir nuestros pipelines como código para lograr reusabilidad, versionado y el resto de las características que ya mencionamos.
Otras dos características fundamentales en esta capa son:
- Observabilidad: tenemos que medir y monitorear cada paso de nuestro pipeline para anticipar errores y corregirlos preventivamente.
- Idempotencia: nuestro código tiene que estar preparado para que, en caso que haya necesidad de un reproceso (quien diga que no le pasó, miente 🤥), si ejecutamos con el mismo set de parámetros de entrada, obtengamos exactamente el mismo resultado.
La herramienta con mayor adopción hoy en día es Apache Airflow, con dos nuevos contendientes que fueron desarrollados con la promesa de resolver o mejorar problemas que podemos encontrar al utilizar Airflow: Dagster y Prefect.
Mito o realidad 🤔
Ya recorridas cada una de las capas de un MDS, como corolario veamos algunos de los mitos que suelen aparecer:
“Si incorporo las herramientas del MDS, modernizo mi arquitectura”.
Por un lado sí, pero la realidad es que debemos incorporarlas teniendo en cuenta las características y beneficios que queremos obtener. Si sumamos herramientas sin criterio, el remedio será peor que la enfermedad.
“Si no utilizo las herramientas del MDS, mi stack es obsoleto” .
A la inversa del mito anterior, la respuesta no dependerá de las herramientas que use, sino de qué tan rígida es mi arquitectura y, por sobre todo, qué tan rápido le estoy entregando valor al negocio.
“Hay una única manera de implementar el MDS”.
Por supuesto que no. Tenemos infinidad de alternativas, no sólo en herramientas (cada una con sus pros y sus contras) sino también en función del estado de madurez o incluso de la composición del equipo. Estas cuestiones pueden influir en que sea necesario prescindir de alguna capa.
“Con un MDS resuelvo todos mis casos de uso”.
Quizás sí, pero lo más probable es que queden afuera cuestiones como el procesamiento de datos en tiempo real o machine learning sobre datos no estructurados.
“El MDS es costoso”.
La ventaja de trabajar con servicios en la nube y de pensar la arquitectura de forma modular es que podemos enchufar y desenchufar herramientas según conveniencia y además pagar por lo que usamos. Tranquilamente podemos comenzar con un stack que requiera una inversión de menos de 100 dólares mensuales.
“El MDS es complejo”.
Puede ser todo lo complejo que queramos hacerlo, pero como siempre preferimos en Datalytics, mejor Keep It Simple Stupid 😝.
