El paradigma Data Mesh está ganando adeptos como un nuevo enfoque para la gestión de datos en las organizaciones. A diferencia de las arquitecturas monolíticas como Data Warehouse o Data Lake, el Data Mesh se enfoca en la descentralización, democratización y distribución de la propiedad de los datos entre las áreas de la organización. Las áreas de negocio se responsabilizan del ciclo de vida completo de sus propios datos, así como exponerlos al resto de la organización, sin depender de un equipo técnico central. Este nuevo enfoque facilita que se superen las principales dolencias de las arquitecturas de datos centralizadas: cuellos de botella, dependencia de terceros y pérdida de oportunidades por falta de conocimiento.
Cuando hablamos de Data mesh podemos decir que se ha trasladado la filosofía de la arquitectura de microservicios de software al mundo de los datos. Al igual que en el desarrollo software los microservicios son entidades independientes que se exponen para ser consumidos sin mostrar sus entresijos, en Data mesh los Data as a Product (DaaP) se convierten en microservicios de datos para su consumo por otros equipos en la organización en forma de APIs o BBDD. Podríamos decir que los Data products son datamarts vitaminados con dos grandes diferencias respecto a los tradicionales: los encargados de crearlos y mantenerlos son las unidades de negocio a las que pertenecen los datos, no equipos técnicos centrales; y por otro lado, son entidades autónomas que integran la seguridad, reglas de calidad, gobierno, consumo, etc. Para asumir esta nueva responsabilidad, los áreas de negocio se dotan de recursos técnicos con conocimientos en data capaces de crear y mantener los productos de datos.
El Data Mesh se inspira en principios similares al «Domain Driven Design» DDD al enfatizar la importancia de comprender a fondo el dominio o área de negocio que se está tratando de abordar. En lugar de tratar exclusivamente los datos como un recurso aislado, el Data Mesh reconoce la necesidad de involucrar a expertos en el dominio y diseñar soluciones de datos que se ajusten a las necesidades y desafíos específicos de ese dominio. Data Mesh se alinea con una perspectiva «domain-driven», pero no es una implementación directa del Domain Driven Design.
Data Mesh propone una gestión de datos descentralizada federando la propiedad de los mismos a las unidades de negocio a través de «dominios de datos»
La gestión de datos ha experimentado una gran evolución en las últimas décadas, y esto ha sido posible gracias a la creciente cantidad de información generada y al surgimiento de nuevas tecnologías.
Data Warehouse (finales de 1980) fue uno de los primeros modelos de arquitectura de datos en surgir. Se trata de un sistema centralizado diseñado para almacenar y gestionar grandes cantidades de datos relacionales, permitiendo la consolidación y el análisis de información de diferentes fuentes. Sin embargo, este modelo se enfrenta a limitaciones, como la complejidad y el tiempo requerido para la integración de nuevos datos.
El surgimiento de Data Lake (2000) trajo un nuevo enfoque en la arquitectura de datos. Este modelo se basa en el almacenamiento no estructurado de datos en su formato original, lo que permite una mayor flexibilidad y escalabilidad. Además, un Data Lake permite un procesamiento en paralelo de grandes cantidades de datos, mejorando la velocidad de procesamiento y la eficiencia. La evolución dentro de este paradigma fue trasladar la infraestructura on-premise a la nube, por lo que hablaríamos de Cloud Data Lake (2011).
El concepto de Data Lakehouse (finales del 2010) surge como híbrido entre los Data Warehouse y Data Lake. Este modelo combina la capacidad de gestión, estructura, gobierno y análisis de datos relacionales de los Data Warehouse con la capacidad, flexibilidad y escalabilidad de los Data Lake. Se crea una capa semántica entre los datos estructurados y no-estructurados almacenados en un repositorio (data lake) para consumirlos como si se tratase de una DWH.
Data Mesh (2019) es un enfoque más reciente en la gestión de datos que se basa en la descentralización y la colaboración. Este modelo promueve la gestión de datos como un producto, con equipos de negocio responsables de sus propios conjuntos de datos, otorgando mayor flexibilidad, escalabilidad en la gestión de datos y reduciendo el time-to-market de las iniciativas de datos al desaparecer las dependencias con otros actores (equipos centrales de datos). A finales de esta década también surge otro paradigma, Data Fabric, que a diferencia de Data Mesh, da continuidad a la arquitectura de datos centralizada pero poniendo foco en la tecnología que facilita el consumo de los datos implementando una capa de abstracción por encima de todos los orígenes de datos (virtualización de datos).
En conclusión, la arquitectura de datos ha evolucionado desde modelos centralizados y estructurados hasta enfoques más flexibles y descentralizados. Cada modelo tiene sus fortalezas y limitaciones, y la elección del modelo adecuado dependerá de las necesidades y objetivos específicos de cada organización. Sin embargo, es seguro decir que la arquitectura de datos continuará evolucionando a medida que surjan nuevas tecnologías y desafíos.
Data Mesh
En un Data Mesh los datos se organizan en Data Domains que representan áreas de negocio específicas, cada uno representa un conjunto de datos relacionados con un área de negocio o función específica de la organización. Por ejemplo, en un banco, podríamos tener Data Domains para transacciones bancarias, préstamos, seguridad, marketing, etc. Cada dominio es gestionado por un equipo de dominio autónomo, responsable de la calidad y disponibilidad de los datos compuesto por expertos en el área y responsables de la recopilación, transformación y gestión de los datos dentro de ese dominio. Estos equipos son independientes y tienen la propiedad de sus datos. Tienen la responsabilidad de garantizar la calidad y la disponibilidad de los datos en su dominio. Crean Data Products, subconjuntos de datos listos para su consumo que se presentan en forma de APIs, bases de datos, o servicios. Los Data Products son diseñados para ser utilizados por otros equipos en la organización. Para facilitar el acceso y su consumo se pueden implementar capas de servicios de datos. Estos servicios proporcionan una interfaz estandarizada para acceder a los datos en los Data Domains. Los equipos de dominio pueden exponer sus Data Products a través de estos servicios con una infraestructura que puede incluir tecnologías como Data Lakes, Data Warehouses, sistemas de streaming y es compartida y administrada de manera centralizada. La gobernanza y seguridad de los datos se aplican de manera uniforme en toda la organización para garantizar la integridad y privacidad de los datos.
Por ejemplo, en una empresa de comercio electrónico divide sus datos en Data Domains, como historiales de compras, preferencias de los clientes, inventario, y análisis de marketing. Cada Data Domain es gestionado por un equipo de dominio compuesto por expertos en esas áreas, quienes se encargan de recopilar, cocinar y gestionar los datos en su dominio. Estos equipos crean Data Products, como recomendaciones personalizadas para los clientes o análisis de tendencias de compras, que son compartidos a través de Data Services estandarizados para su uso en toda la organización. La infraestructura de datos subyacente se gestiona centralmente para garantizar la eficiencia y la seguridad, y las políticas de gobernanza y seguridad de datos se aplican de manera consistente en toda la empresa para proteger la integridad y la privacidad de la información.
Principios de Data Mesh
Una arquitectura Data Mesh orbita alrededor de estos cuatro principios:
- Propiedad de datos descentralizada: Las áreas de negocio aka dominios tienen la propiedad y responsabilidad de los datos que generan y utilizan, lo que les permite tomar decisiones informadas sobre su uso y gestión. Influenciado por el concepto de Diseño orientado al Dominio o Domain-driven design (DDD).
- Diseño basado en productos: Los datos son tratados como productos aka Data as a Product (DaaP), con equipos de desarrollo de datos responsables de su calidad, seguridad y valor. Los DaaPs se exponen al resto de la organización para su consumo.
- Plataforma de auto servicio: infraestructura transversal que articula la democratización del uso de los DaaPs, así como la gestión del ciclo de vida completo de cada uno. Este framework de componentes técnicos se gestiona desde un equipo central para facilitar la adopción del Data Mesh a las unidades de negocio.
- Gobierno federado: crea una capa de gobierno federada entre los dominios con un equipo formado por representantes de cada uno. Equilibra entre la autonomía y agilidad de los dominios frente a la interoperabilidad del propio data mesh.
¿Que es un Data as a Product?
En lugar de tratar los datos como un recurso interno, los datos se entregan como un producto independiente por parte de cada data domain dedicado a su desarrollo y mantenimiento. Como adelantábamos en la introducción del artículo, se trata de microservicios de datos y se denominan Data as a Product o DaaP. Para que un conjunto de datos se considere un producto de datos debe cumplir los siguientes atributos:
- Secure: Los datos deben estar protegidos contra accesos no autorizados y cumplir con las regulaciones y estándares de seguridad aplicables.
- Discoverable: Los datos deben ser fácilmente descubribles y accesibles para los usuarios autorizados. Cualquier usuario debe ser capaz de poder buscar y encontrar los Data as a Product creados en la organización para identificar cual de ellos debe utilizar, o si se diera el caso, solicitar al data domain propietario de los datos que necesita, la creación de uno nuevo.
- Addressable: Los datos deben tener una identidad única y una dirección para facilitar su acceso y uso.
- Understandable: Los datos deben ser comprensibles para los usuarios y contener metadatos para facilitar su uso.
- Trustworthy: Los datos deben ser precisos y confiables. Se pueden definir SLAs o como se refiere Zhamak en su literatura, SLOs (objetivos de nivel de servicio, o en inglés service level objectives) para determinar el nivel de disponibilidad y calidad de un Data as a Product. Por ejemplo, según la propia definición de Google, un SLO puede medir la latencia y la disponibilidad.
- Natively accessible: Los datos deben ser fácilmente accesibles en su formato nativo, sin la necesidad de transformaciones previas.
- Interoperable: Los datos deben ser interoperables con otros sistemas y formatos. Además, muchos Data as a Product consumidores se generan como DaaP derivados cruzando varios DaaP, por lo que es necesario que las claves o identificadores sean cross a toda la organización.
- Valuable: Los datos deben tener un valor comprobado para la organización y ser utilizados para tomar decisiones y mejorar los procesos de negocio.
Comparativa entre arquitecturas de datos
| Data Mesh vs Data Lake vs Data Warehouse | Data Mesh vs Data Fabric |
|---|---|
| En las arquitecturas centralizadas (Data Warehouse, Data Lake, Data Lakehouse), los datos se almacenan y administran bajo el mismo paraguas. Esto significa que todas las decisiones sobre los datos, desde la integración hasta el análisis, son tomadas por un único equipo o departamento (habitualmente el área de Data de la organización). En cambio, en una arquitectura de Data Mesh, la responsabilidad y la decisión sobre los datos se divide entre múltiples unidades de negocio o data domains independientes, cada uno enfocado en sus propios datos. Mientras que Data Warehouse, Data Lake o Data Lakehouse son soluciones centralizadas de gestión de datos para el análisis y toma de decisiones, Data Mesh se enfoca en la descentralización y la entrega de valor a los usuarios finales. | Data Mesh y Data Fabric son dos enfoques para la gestión de datos que comparten objetivos similares pero difieren en su enfoque y filosofía. Data Mesh es un modelo de gestión de datos enfocado en la entrega de valor a los usuarios finales y en la independencia de los equipos (dominios). Se basa en la idea de que los datos deben ser tratados como productos independientes con equipos propios responsables de ellos. Por otro lado, Data Fabric se refiere a una red de tecnologías y procesos que permiten la integración y acceso a datos a través una única capa a diferentes fuentes y sistemas. En este enfoque, los datos se gestionan de forma centralizada y se busca una visibilidad completa y un control total sobre los mismos. En resumen, Data Mesh se enfoca en la descentralización y la entrega de valor a los usuarios, mientras que Data Fabric se enfoca en la integración y la centralización de los datos. |
Infraestructura de un Data Mesh
La plataforma donde se almacenan, transforman y distribuyen los datos entre los data domains es administrada de forma central por un equipo técnico. Los Data Domains solo deben preocuparse de explorar y trabajar los datos, no de cómo persistirlos o distribuirlos.
- Almacenamiento de datos: Los datos se almacenan en múltiples instancias independientes, cada una enfocada en un dominio específico. Estas instancias pueden ser bases de datos (con esquemas o datamarts específcos por dominio), data lakes (distribución por directorios) o sistemas de archivos.
- Servicios de datos: Cada instancia de datos proporciona servicios de datos independientes, como integración, seguridad y acceso, a través de una interfaz de programación de aplicaciones (API). Estos servicios pueden ser desarrollados y mantenidos por los equipos de datos correspondientes.
- Virtualización de datos: Se puede utilizar una capa de virtualización de datos para aislar los servicios de datos de los sistemas operativos subyacentes y permitir un acceso independiente a los datos. Esta capa puede ser proporcionada por herramientas como Denodo.
- Red de servicios: Los diferentes servicios de datos se comunican y colaboran entre sí a través de una red de servicios. Esta red puede ser implementada utilizando tecnologías como Kubernetes o Docker.
- Automatización: Se utilizan herramientas y procesos automatizados para garantizar la seguridad, calidad, cumplimiento y escalabilidad de la arquitectura.
Sin embargo, implementar un Data Mesh también presenta algunos desafíos. Uno de los principales es la necesidad de establecer una estrategia clara para la gestión de datos en la organización, establecer procesos y herramientas para garantizar la seguridad, calidad y cumplimiento, y asegurar una comunicación y colaboración efectiva entre los diferentes equipos de datos.
Desafíos de la arquitectura Data Mesh
Implementar un Data Mesh presenta varios desafíos, algunos de los cuales son:
- Cambio en la cultura organizacional: implica un cambio en la forma en que se gestionan los datos y en la estructura de la organización. Es importante involucrar a todos los departamentos y equipos en el proceso de cambio para garantizar su éxito. Se debe dedicar mucho esfuerzo a la gestión del cambio.
- Comunicación y colaboración entre equipos: La descentralización de los datos y la responsabilidad de su gestión entre múltiples equipos independientes requiere una buena comunicación y colaboración entre ellos. Es necesario establecer procesos y herramientas para garantizar una comunicación y colaboración efectiva.
- Seguridad y cumplimiento: Es importante establecer procesos y herramientas para garantizar la seguridad y cumplimiento de los datos en una arquitectura descentralizada.
- Escalabilidad: Es importante garantizar que la arquitectura sea escalable para manejar grandes cantidades de datos y poder crecer con las necesidades de la organización.
- Integración de los datos: Un Data Mesh implica la integración de múltiples fuentes de datos, lo que puede ser desafiante debido a la variedad de formatos y sistemas de origen de los datos.
- Capacitación y habilidades: Es necesario capacitar al equipo en las nuevas tecnologías y procesos necesarios para implementar un Data Mesh. Al distribuir la responsabilidad end-to-end de los datos a los dominios, éstos se deben dotar de recursos técnicos.
- Monitoreo y medición: Es importante establecer procesos y herramientas para monitorear y medir el rendimiento y la disponibilidad de los servicios de datos, así como detectar problemas.
- Cambio en los procesos de negocio: puede requerir cambios en los procesos de negocio existentes para aprovechar al máximo los servicios de datos independientes.
Implementación Data Mesh
Una cosa es la literatura de Zhamak en Data Mesh: Deliverig Data-Driven value at scale y otra la realidad. Os recomiendo esta lectura donde se desarrollan los motivos por los que una organización no estaría preparada para implantar una arquitectura Data Mesh. Como tener un greenfield para implementar una arquitectura Data Mesh es utópico, el único camino para no ahogarse en el intento es definir un roadmap e ir adaptando poco a poco el entorno. En nuestro caso, nos hemos juntado varios equipos técnicos y de negocio para diseñar un framework que sea el habilitador a la adopción de la nueva cultura de datos al resto de la organización. Va a nacer acoplado a los sistemas que ya hay implantados para ir poco a poco evolucionando a herramientas o servicios independientes e interoperables para todos los dominios.
Por ahora los DaaP se están generando y manteniendo desde este pequeño grupo, con la idea de que a medida que los dominios de datos asuman su gestión se doten de recursos técnicos especializados para asumir el mantenimiento y desarrollo. Tenemos hitos alcanzables, el objetivo no es hacer un big bang; queremos ir implementando cambios poco a poco y llevar de la mano a las demás áreas. Además del trabajo técnico y de diseño, esta transformación lleva consigo una inmensa tarea evangelizadora. Esto implica que a corto y medio plazo se tenga que asumir mucha deuda técnica. Algunos comentarios sobre cómo lo estamos abordando:
- Definición clara del roadmap, tanto en el corto plazo como el objetivo final ¿qué queremos conseguir? ¿cómo? y ¿cuándo?
- Esfuerzo inicial en la definición de un DaaP, qué consideramos un Data as a product y las propiedades que debe cumplir (ver ¿Qué es un data as a product?). Para ello hemos desarrollado las 6 características principales (seguro, descubrible, accesible, entendible, confiable e interoperable), dejando de lado las de valioso y nativamente accesible, ya que son inherentes al objetivo a su creación. Se ha trabajado en definir qué significa para nosotros cada uno de estos atributos y como llevarlo al mundo real. Por ejemplo, como organización ¿qué necesitamos para que un DaaP sea seguro? ¿qué mecanismos podemos construir para conseguirlo? en nuestro caso, hemos creado dos capas de seguridad definidas por roles de nuestro LDAP y sobre la BD donde se almacenan los data products como esquemas de base de datos.
- Se ha comenzado con DaaP pilotos. Es necesario partir el elefante en trocitos, por lo que se han identificado cuáles son los que podríamos empezar por resultar más sencillos de implementar y tener un impacto en negocio. Se han aprovechado las nuevas necesidades de datos en la organización para que nazcan ya como data products.
- Hemos definido varios tipos de DaaP en función de cuál es el origen y como se persisten los datos en base a nuestra arquitectura beta:
- Tabla de BBDD
- Modelo de estrella en BBDD (tabla de hechos y sus dimensiones)
- Vista de BBDD
- Entidades virtualizadas
- Seguimos manteniendo equipos de data centralizados encargados de hacer nacer los primeros DaaP y construir el framework de la plataforma de auto servicio.
- Los propietarios de los data products siguen siendo los equipos de desarrollo que están empujando la iniciativa. Los dominios aun no están lo suficientemente maduros para asumir el desarrollo, mantenimiento y en general el ciclo de vida de los DaaP.
- Los DaaPs se consumen a través de esquemas de BBDD (como si fueran datamarts). El objetivo a largo plazo no está claro, podría ser crear una capa de API REST como propone Zhamak. No sólo los propios datos, todo el ecosistema que define un DaaP podría ser accesible o consumible por microservicios. Por ejemplo, la gobernanza, metadatos, monitorización, etc. Se está explorando la virtualización de datos para resolver este paradigma.
- La seguridad de acceso a datos, la interoperabilidad, etc. por ahora se gestiona a nivel dominio activo y de configuración de base de datos (roles) ya que los datos están almacenados en datamarts de BBDD.
- Con el fin de dar servicio al descubrimiento, el catálogo de Data as a Products o data martketplace se está construyendo aprovechando las herramientas que ya están implementadas en la organización. En el catálogo se describe cada DaaP en detalle con las evidencias a los atributos descritos previamente: qué datos contiene, SLA/SLO, ejemplos, linaje, ownership, etc.