spinner

Data Mesh, una nueva aproximación para una arquitectura de datos transformacional

Data Mesh es una aproximación socio-técnica y descentralizada, de la gestión y acceso en escala de datos análiticos de una compañía u organización.

Para todos aquellos interesados en las plataformas de datos los últimos años están siendo muy interesantes. Estamos experimentando una evolución en los principios y guías de cómo diseñar arquitecturas más profundas y transformacionales que el salto que experimentamos con el mundo Big Data y los Data Lakes.

Vemos como surgen nuevos conceptos como Lake House, Data Fabric, Data Mesh y otros como Data Virtualization vuelven como habilitador de los anteriores. Dentro de todos estos nuevos conceptos hoy nos gustaría centrarnos en Data Mesh, ya no solo por su potencial tecnológico si no también por su capacidad transformacional.

Una nueva aproximación para una arquitectura de datos transformacional

En mayo de 2019 Zhamak Dehghani publicaba su artículo[1] presentando un nuevo concepto, el Data Mesh, proponiendo un cambio de paradigma de cómo pensar sobre los datos y que características debería tener una plataforma de datos moderna.

Visión

A grandes rasgos en las arquitecturas de Data Lake actuales tenemos tres capas diferenciadas:

  • Ingesta de datos.
  • Procesamiento (limpieza, enriquecimiento, transformación).
  • Publicación.

En este modelo existe una plataforma que está centralizada, monolítica, con un pipeline de datos estandarizado y gestionado por un único equipo hiper especializado en ella. Todo esto provoca una serie de ventajas y desventajas. Al ser centralizada el gobierno es en teoría más sencillo si bien el equipo de plataforma es agnóstico en cuanto a los datos por lo que depende de los originadores de los datos para poder completar el proceso de gobierno. Por otro lado, al ser una única plataforma monolítica la evolución tecnológica no es tan ágil ya que los cambios afectan a todos los procesos. Y por último, el ser un único equipo el que gestiona la plataforma se crea un silo de conocimiento y ,en muchos casos, un cuello de botella ya que este equipo debe atender no solo el gobierno de la plataforma si no también las peticiones de los originadores de datos y los consumidores de los mismos.

Conceptos

Para continuar con la explicación vamos a explicar algunos conceptos que utilizaremos más adelante en el artículo.

Uno de los cambios importantes es empezar a tratar los datos como producto y como tal estos productos deben mantenerse o proveer un cierto nivel de servicio. Ya no hablamos de conjuntos de datos si no de productos de datos que se ofrecen para su consumo.

Por otro lado hablamos de dominios de datos, heredando la filosofía del DDD, una forma de aproximar este concepto es pensar en los dominios de negocio, dónde vamos a modelar las entidades de datos y sus relaciones con otros dominios en términos de puntos de consumo de datos o servicios operacionales [2].

Pilares y características

Se propone un nuevo tipo de aproximación a una arquitectura para solucionar los problemas actuales. Veamos qué cuatro pilares de diseño debe comprender esta aproximación[2]:

  • Los datos como producto, distribuyendo la responsabilidad desde el equipo de plataforma al equipo responsable del dominio y dando la propiedad del producto y su control al dominio que tendrá que garantizar los acuerdos de servicios.
  • Un gobierno federado que permita que las decisiones estén los más próximas al dominio pero conservando un control centralizado.
  • El dominio como dueño de los datos, acompañado de una arquitectura que descentralice la propiedad de los datos centrada en los dominios.
  • Debe ser una plataforma en autoservicio no solo en la parte de consumo de datos si no también en la creación de nuevos productos de datos.

Además una arquitectura de este tipo debe ofrecer características como:

  • Interoperabilidad.
  • Seguridad y gobierno.
  • Auto descriptiva.
  • Transversal en equipos.
  • Cambio de paradigma.

Como vemos estos pilares tienen una implicación profunda en cómo una organización gestiona los datos y su plataforma. Estamos, de manera efectiva, distribuyendo las responsabilidades entre los dominios de manera que si bien el equipo de plataforma retiene la capacidad de control y supervisión la gestión de los productos de datos, su consumo y gobierno ahora recae en los dominios que los crean. Este cambio significa que los dominios deben contar en sus equipos con los perfiles adecuados para este trabajo, lo que además les dota de una mayor autonomía, también permite que el conocimiento de la plataforma no esté centralizado en un único equipo. Por otra parte se descarga al equipo de plataforma ya que no centraliza todas las peticiones y necesidades de los distintos dominios.

Algunas de las ventajas que detectamos son las siguientes:

  • Cada dominio es dueño de sus productos de datos, lo que debe redundar en un mejor gobierno de los mismos.
  • Los dominios son autónomos a la hora de desarrollar sus productos de datos por lo que hay una mayor agilidad.
  • El equipo de plataforma está enfocado en la plataforma y su evolución debido a la autonomía que se ha brindado a los dominios.
  • Es posible plantear una adopción incremental de este tipo de arquitecturas lo que permite iterar más rápido y elimina parcialmente el riesgo asociado al despliegue de grandes plataformas de datos.

Sin embargo también supone retos a resolver:

  • Gobierno: Si bien hablamos de un gobierno descentralizado esta parte atañe a los productos, es necesario también un control centralizado que garantice que los acuerdos de gobierno.
  • Federación: Necesidad de definir correctamente la federación de servicios. Esto incluye la gestión de permisos federados e Identidades global.
  • Lenguajes de consulta: Es necesario establecer alguno de los “idiomas” mínimos a cumplir para que haya interoperabilidad real.
  • Control: Se hace necesario que haya un sistema común que recoja esta información no dependiente de cada dominio federado.
  • Incentivos: Deben existir mecanismos que incentiven el cumplimiento de los interfaces federados y el buen gobierno.
  • Consultas entre dominios: Dependiendo del modelo de despliegue y arquitectura pueden surgir problemas técnicos a resolver como el cruce de datos entre diferentes dominios.

La mayoría de estos retos son de proceso, gobierno y cultura y no técnicos.

Un viaje hacia Data Mesh

Como hemos visto la adopción de este tipo de arquitecturas no es una cuestión meramente técnica ya que implica un gran cambio en los procesos organizacionales, empezando por la organización de los equipos implicados y la distribución de responsabilidades entre los participantes. Esto supone la necesidad de contar con equipos maduros y comprometidos para poder poder abordar la adopción con éxito. Sin embargo dada la naturaleza distribuida y parcialmente descentralizada es posible plantear una adopción incremental que permita que los equipos vayan desarrollando esta madurez.

Referencias:

[1] Zhamak Dehghani, 20 Mayo 2019, https://martinfowler.com/articles/data-monolith-to-mesh.html
[2] Zhamak Dehghani, 3 Diciembre 2020, https://martinfowler.com/articles/data-mesh-principles.html

Las opiniones vertidas por el autor son enteramente suyas y no siempre representan la opinión de BBVA Next Technologies.

¿Quieres saber que más cosas hacemos en BBVA Next Technologies?