Conceptos Básicos de Data Mesh

En mi artículo anterior, introducía el concepto de Data Mesh, definido por primera vez por
Zhamak Dehghani allá por la mitad del año 2019 y que podéis encontrar aquí How to Move
Beyond a Monolithic Data Lake to a Distributed Data Mesh (martinfowler.com) , y os decía que
este concepto bien merecía su propio espacio, y aquí estamos.

Desde el principio de los sistemas analíticos, siempre se han abordado las diferentes
arquitecturas con la mentalidad de proporcionar un único punto centralizado en el que consolidar
la información. Este punto centralizado ha ido evolucionando a tecnológicamente a lo largo del
tiempo, desde del Data Warehouse a los Data Lake y últimamente los Data Lakehouse. También
han evolucionado los sistemas de carga desde el origen a esos almacenes de datos, incorporando
variaciones de cuando se realizan las transformaciones, si durante la carga, o posteriormente en
la lectura, y se agregaron también posibilidades de análisis en tiempo real, a través de streaming
y las rutas de análisis “caliente” (Arquitecturas Kappa). Pero todas estas evoluciones, compartían
esa filosofía de arquitectura centralizada, y gestionada por el equipo de datos de la compañía,
donde se gestionaba tanto la parte analítica, como la gobernanza de la solución completa. La
arquitectura Data Mesh, intenta romper con estas filosofías, promulgando la idoneidad de
distribuir gran parte de las tareas necesarias para implementar una arquitectura de datos analítica.

Los principios de Data Mesh

Estos principios de Data Mesh, fueron definidos también por Zhamak Dehghani en el artículo
Data Mesh Principles and Logical Architecture (martinfowler.com), y que son:

 Arquitectura y propiedad de los datos distribuida, basada en dominios. Este principio se

basa en intentar evitar los sistemas monolíticos tradicionales, intentando aprovechar
también el conocimiento que los usuarios de un determinado área, departamento o
dominio tienen sobre la información tratada y generada por los sistemas de origen,
utilizando los casos de uso como “unidad de gestión”.
 Tratar los Datos como productos. Enlazando con el punto anterior, cada caso de uso será
autosuficiente y generará una salida de datos que será tratada como un producto, con los
usuarios de ese dominio como propietarios de ese producto. Este producto, se pone a
disposición del resto de la organización para su consumo
 Infraestructura de datos con capacidades de autoservicio. La clave de todo. Para que toda
esta arquitectura funcione adecuadamente, deberemos de disponer / implementar una
infraestructura en la que los usuarios de cada dominio puedan ser autosuficientes. Que el
sistema sea distribuido, no quiere decir que cada dominio despliegue su propia
infraestructura, puesto que acabaríamos con una arquitectura imposible de gestionar.
 Un Gobierno Federado. Como en toda arquitectura distribuida, tiene que haber algún
sistema de gobierno que se encargue de definir estándares, y que facilite el
descubrimiento de los productos generados por cada dominio.

Estos cuatro principios básicos intentan aprovechar las sinergias que puedan existir entre los
sistemas de origen, y las capas analíticas, dándole mucho más valor al conocimiento del negocio
y los datos, que a las tecnologías necesarias para el análisis de datos, intentando proporcionar
infraestructuras que permitan que esos equipos de dominio sean autosuficiente para crear
“productos de datos” que pongan a disposición de la organización, manteniendo la propiedad y el
control sobre los mismos.

Conclusiones

Todos estos conceptos, suenan muy bien desde un punto de vista teórico y lógico, pero creo que
existen bastantes “lagunas” o retos, que habrá que ver como podemos ir resolviendo, tanto
tecnológicos como de procedimiento o gobernanza. Es cierto que es una arquitectura que
facilitaría la flexibilidad por parte de los usuarios de negocio de realizar sus propios análisis, que
sería también más sencillo incorporar nuevas áreas o nuevos casos de uso al modelo, pero ¿cómo
se integra toda esa información? Al contrario de lo que pueda parecer, creo que es una
arquitectura que puede encajar mejor en compañías medianas, que no en las grandes, que ya de
algún modo, por complejidad y volumen, trabajan con sistemas distribuidos. Veremos como va
evolucionando, y si las tecnologías existentes van incorporando características que faciliten la
implementación de este tipo de Arquitecturas.