Paso a paso la arquitectura Data Mesh va ganando popularidad 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, aka Dominios de datos. Los equipos de dominio 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 de data o BI. Este nuevo paradigma facilita que se superen las principales dolencias de las arquitecturas centralizadas de datos: cuellos de botella y pérdida de oportunidades de negocio por conocimiento sesgado.
Cuando hablamos de Data mesh podemos decir que se ha trasladado el paradigma de la arquitectura de microservicios de software al mundo de los datos. Al igual que en el desarrollo software los microservicios son entidades autónomas e independientes que sirven a un propósito específico, en la arquitectura Data mesh los Data as a Product (Daap) se convierten en microservicios de datos. Son conjuntos de datos autónomos gestionados completamente por su dominio propietario y disponibles para el resto de dominios con el fin de facilitar la democratización del acceso a los datos. Para asumir esta nueva responsabilidad, los dominios se dotan de recursos técnicos con conocimientos en data capaces de crear y mantener los productos de datos.
La arquitectura Data Mesh supone evolucionar de una visión data-driven, la toma de decisiones gira en torno en los datos, a una visión domain-driven, basada en el conocimiento y comprensión del dominio o el problema que se está tratando de resolver. Este punto de vista también se denomina Domain Driven Design o DDD.
Data Mesh propone una arquitectura de datos descentralizada federando la propiedad de los datos a las áreas de negocio (dominios).
La arquitectura 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 (2010).
El concepto de Data Lakehouse (2020) surge como híbrido entre los Data Warehouse y Data Lake. Este modelo combina la capacidad de gestión y análisis de datos relacionales del Data Warehouse con la flexibilidad y escalabilidad del Data Lake. Para ello 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 BBDD relacional (data warehouse).
Data Mesh (2021) es un enfoque más reciente en la arquitectura de datos que se enfoca en la descentralización y la colaboración en la gestión de datos. Este modelo promueve la gestión de datos como un producto, con diferentes equipos responsables de diferentes conjuntos de datos, y permite una mayor flexibilidad y escalabilidad en la gestión de datos. En este año también surge otro paradigma, el 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 tránsito a crear una capa de abstracción de la ubicación de los datos y su explotación (virtualización de los 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.
¿Qué es un Data Mesh?
Un Data Mesh es una arquitectura de datos descentralizada que se enfoca en la entrega de servicios de datos a través de múltiples equipos independientes. Se divide la compañía en Data Domains, cada uno de los cuales son responsables de sus propios datos. Al ser los propietarios (ownerships) de sus datos, se encargan de su exploración, ingesta, transformación, generación, exposición, seguridad y compliance. Además, el convertir a las áreas de negocio en dueños de sus propios datos otorga una ventaja fundamental, y es que son los quienes poseen todo el conocimiento funcional con la mejor base para explotarlos y descubrir nuevas oportunidades de negocio. Esto permite a las organizaciones entregar servicios de datos de manera más rápida y eficiente, ya que cada Data domain se enfoca en un conjunto específico de datos y puede tomar decisiones y actuar con mayor autonomía. Se eliminan los cuellos de botella que suponen las arquitecturas de datos centralizadas donde un único equipo de data se encarga de trabajar todos los datos de la compañía.
Por ejemplo, podríamos segmentar una organización en dominios en base a sus departamentos o áreas de negocio (marketing, ventas, RRHH, producción). Los dominios a su vez podrían organizarse en subdominios (ventas dividirse en retail o wholesale). Cada dominio o subdominio sería el responsable de la gestión de sus propios datos: almacenarlos, transformarlos, mantener niveles de calidad/compliance y disponibilizarlos para su consumo (propio del dominio o por otros dominios). La exposición de los datos se hace a través de Data as a Product (DaaP), que serían subconjuntos de datos preparados para una respuesta específica. Un dominio puede tener tantos DaaP como necesite o le soliciten el resto de dominios/organización. Para democratizar el acceso y conocimiento de estos DaaP debe construirse un catálogo con meta información de cada producto de datos. Por último, para conservar la descentralización en unos parámetros homogéneos, representantes de cada dominio deben conformar un gobierno federado donde se tomen decisiones en común cross a todos los dominios (plataforma, reglas de calidad, interfaz de acceso…).
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. Se basa en 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.
- 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 áreas 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 patrón de arquitectura de datos que enfoca 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 de 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
Lo ideal es que la plataforma donde se almacenan, transforman y distribuyen los datos entre los dominios sea gestionada por un único equipo cross. 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 utiliza 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 o IBM Data Virtualization.
- 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 una arquitectura de 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 una arquitectura de Data Mesh presenta varios desafíos, algunos de los cuales son:
- Cambio en la cultura organizacional: Una arquitectura de Data Mesh 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: Una arquitectura de 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 una arquitectura de 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: Una arquitectura de Data Mesh puede requerir cambios en los procesos de negocio existentes para aprovechar al máximo los servicios de datos independientes.
En resumen, implantar una arquitectura de Data Mesh puede presentar varios desafíos, incluyendo cambios en la cultura organizacional, comunicación y colaboración entre equipos, seguridad y cumplimiento, escalabilidad, integración de datos, capacitación y habilidades, monitoreo y medición y cambios en los procesos de negocio. Es importante abordar estos desafíos de manera metódica y con un enfoque en el equipo para asegurar el éxito de la implementación.
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 nuestra organización tenemos la ventaja de que la arquitectura organizativa ya está orientada a una especie de dominios (aka tribus), por lo que hemos atajado y evitado el camino más rocoso, que es el cambio de cultura y estructura de la organización. Si bien no es una transformación 1:1, la actual distribución nos permite configurar los dominios de datos de una forma más suave.
Los dominios tienen capacidades funcional y técnica, si bien es cierto que la mayoría necesitará dotarse de recursos especializados en data para asumir el mantenimiento y desarrollo de los DaaP. Como comentaba al principio del párrafo, nuestros milestones son pequeños y asequibles. El objetivo no es hacer un big bang, es 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 para convencer al resto. Esto implica que en el short-term no vamos a disponer de una arquitectura Data Mesh pura:
- Definición clara del roadmap, tanto en el short como el long-term ¿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 6 características principales (seguro, descubrible, accesible, entendible, confiable e interoperable), dejando de lado la valioso y nativamente accesible, ya que son inherentes al objetivo a su creación Cuando digo que se han desarrollado, quiero decir que se ha trabajado en definir qué significa para nosotros como organización que un DaaP sea, por ejemplo, seguro y qué mecanismos podemos construir para conseguirlo.
- Se ha comenzado con un par de pilotos de DaaP. Es necesario partir el elefante en trocitos, por lo que se han identificado cuáles son los data a as product por los que podríamos empezar por resultar más fáciles o sencillamente, porque se trata de nuevas necesidades de datos/organizativas que nos permiten arrancar desde cero con el nuevo concepto.
- Hemos definido varios tipos de DaaP en función de cuál es el origen y como se persisten los datos. Por agilizar y asimilar la infraestructura que ya existe, el primer DaaP tiene como origen un datawarehouse de staging donde diariamente se replican datos de los operacionales.
- Seguimos manteniendo equipos de data centralizados.
- El ownership 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 disponibilizan a través de esquemas de BBDD (como si fueran datamarts). El objetivo long-term es crear una capa de APIs. No sólo los propios datos, si no todo el ecosistema que define un DaaP debería ser accesible o consumible por microservicios. Por ejemplo, la gobernanza, metadatos, monitorización, etc. Esto se puede conseguir fácilmente con una capa de virtualización que estamos explorando (Denodo).
- La seguridad de acceso a datos, la interoperabilidad, etc. por ahora se gestiona a nivel de configuración de base de datos (roles) ya que los datos están almacenados en datamarts de BBDD relacional.
- Con el fin de dar servicio al descubrimiento, el catálogo de Data as a Product se mantiene través de las herramientas que ya están implementadas en la organización, en este caso IBM InfoSphere Information Governance Catalog. Desde donde se pueden buscar los Data domains y DaaP, ver en detalle cada uno, qué contiene, sus SLA/SLO, ejemplos, linaje, ownership, etc.
El objetivo es poco a poco, a medida que se madura el diseño y propios dominios, se traslade el ownership y se democratice el acceso a los DaaPs.
