Arquitecturas data mesh: ¿qué fue antes: el código o los datos?

Alejandro de Fuenmayor    27 mayo, 2022
data-mesh

Desde hace unos años hay un debate en curso sobre cómo modelar los datos: por su valor o para el código que los va a utilizar. Ahí radica en parte la diferencia entre las arquitecturas y aplicaciones basadas en una aproximación data centric o code centric. Hoy voy a escribir de data mesh como la clave para tomar decisiones data driven en una organización.

Las bases de datos relacionales fueron la primera aproximación de mover la semántica desde el código a los datos. Aún así, hoy en día cada aplicación acaba disponiendo de su propio modelo de datos. Hacen del dato una versión simplificada de dicha información disponible para el aplicativo, sin tener en cuenta que el dato en sí acaba siendo un activo de la empresa.

Tratamiento de los datos a lo largo del tiempo

Hace ya un par de décadas, la visión general de los datos de cada empresa empezó a centralizarse en diferentes niveles de almacenes de datos: los datamart o datawarehoses, creados a base de procesos de extracción y transformación del dato origen. Años más tarde empezaron a proliferar nuevas estructuras, departamentos y responsables – los famosos Chief Data Officer– para velar por el activo y valor de los datos que la empresa producía y almacenaba.

«Datos crudos» o «Diógenes de datos»

Dichas limitaciones se han resuelto parcialmente en los últimos años con la creación de grandes repositorios de datos puros, no tratados. Esos datos crudos (datos raw en inglés) permiten que dispongamos del dato al natural, sin transformar ni alterar lo más mínimo desde su fuente original, su creador.

Así, esos datos se pueden contener en diferentes formatos, estructurados o no. Por ejemplo, un fichero CDR para la tarificación de una llamada, la foto escaneada de una nota de gastos, la posición GPS de un dispositivo IoT o cualquier otro tipo de dato que pueda alimentar o generar valor para un negocio.

Esta aproximación, que podríamos denominar “Diógenes de los datos”, se basa en la acumulación de riqueza basada en los datos. Pero los datos al natural no sirven para mucho, ya que normalmente no suelen ser útiles o comprensibles para las aplicaciones. Es necesario volver a trasladar la semántica desde la capa de los datos a la de las aplicaciones.

Big data y silos sin sinergias

Para transformarla en conocimiento, esa capa se trata de forma paralela mediante big data. Gracias a técnicas estadísticas, modelos de regresión y otras disciplinas matemáticas es posible interpretar y sacar ideas o conclusiones, que proporcionan un valor agregado del procesado y tratamiento generalizado de dichos datos.

Pero el valor de esta aproximación sigue siendo escaso, ya que los procesos de almacenaje, tratamiento y explotación se siguen desarrollando en silos independientes. No hay sinergias entre ellos a la hora de extraer aprendizajes y ser usados por las diferentes aplicaciones.

Data mesh, la nueva aproximación a la gestión del dato

Así que, a priori, parece que, para ser una compañía centrada en el dato, la tecnología no es el único habilitador. La metodología, los procesos, las herramientas y la tecnología deben ser un todo que ayude a construir una plataforma capaz de agregar esos datos, entenderlos y permitir su activación por parte de las aplicaciones.

Requisitos de la plataforma

Los principios de diseño de esta plataforma deberían recoger, al menos, todos los aspectos positivos de los modelos anteriores. Por ejemplo, la capacidad de entender diferentes tipos de datos y semánticas, no permitir solo el acceso a la información sino la actualización de la misma en tiempo real y mantener desacopladas la capa de la lógica de la aplicación y la del dato. También deberíamos poder demandarle, como a cualquier otro sistema de propósito empresarial, seguridad, resiliencia y escalabilidad.

Además, a esta plataforma deberíamos exigirle un catálogo de datos. Y que, en este, el modelo centralizado de datos maestros, o metadatos, permita tener una descripción técnica y funcional de los mismos, así como las reglas de gobierno y mecanismos para lograr la consistencia, seguridad y modos disponibles para el acceso.

La tecnología o arquitectura que permite implementar en gran medida este marco de referencia se conoce en el mercado como la malla de datos o data fabric. Y el marco metodológico (capa de procesos, cultura y organización) para implementar dicha práctica es lo que la industria y los diferentes analistas denominan data mesh.

Principios de actuación de data mesh

Sus cuatro principios de actuación son:

– Los propietarios del dominio de datos.

– El dato como producto.

– La infraestructura del dato en modo autoservicio (as a service).

– Y la federación y tratamiento orquestado de dichos datos.

Un cambio cultural, organizativo y de procesos

Esto requiere un cambio cultural, así como la mentalidad necesaria para pensar en “los datos como producto». La administración de los datos como un activo de capital tangible y real del negocio puede, a su vez, generar cambios organizativos y de procesos. Esto incluye nuevos perfiles en las organizaciones, como el productor y consumidor de datos, cuya responsabilidad engloba la certeza del dato en determinadas estructuras o dominios horizontales o verticales.

Una estructura tipo data mesh tiene como objetivo vincular a los productores de datos directamente con los consumidores y eliminar al intermediario del equipo de sistemas, de los procesos de ingesta, preparación y transformación de los recursos de datos. El enfoque supone la alineación de los dominios de datos operativos y analíticos. 

Datos en movimiento y una arquitectura distribuida

Y, por último pero no menos importante, es necesario adecuar la plataforma tecnológica a los «datos en movimiento». Que la plataforma comprometa en su evolución y mantenimiento a los productores y consumidores de dichos datos empresariales -como dos caras de la misma moneda- es un indicador clave del éxito.

Además, el núcleo de la malla muy posiblemente será una arquitectura distribuida, en la que deberán convivir datos locales y otros muchos alojados en múltiples proveedores cloud.

Casos de uso de data mesh

Pero ¿dónde y cuándo cobra sentido esta filosofía de trabajo? Aplicaciones hay muchas y muy variados, tanto para la gestión operativa de la información como desde su punto de vista de explotación y analítica. A continuación enumero siete casos de uso :

  • Modernización de aplicaciones. Las nuevas arquitecturas de microservicios requieren de un movimiento estructurado de datos, que independice el origen de los mismos y lo estructure por dominios y reciprocidad de la información.
  • Continuidad de negocio y disponibilidad del dato. En organizaciones globales es tremendamente complejo velar por la integridad del dato y su disponibilidad en diferentes regiones. Esta geodistribución del dato puede ser la solución para transacciones de baja latencia.
  • Modernización de aplicaciones. La integración de datos basada en eventos permite derribar las barreras de gestión de los mismos entre los diferentes contextos de cada grupo de microservicios.
  • Integración basada en eventos. Las grandes organizaciones tienen una mezcla de sistemas antiguos y nuevos, aplicaciones monolíticas y microservicios, almacenes de datos operativos y analíticos. Data mesh puede ayudar a unificar estos recursos a través de diferentes dominios de negocio y datos.
  • Ingesta de datos continua para analítica. En general hay dos formas de cargar datos en los almacenes de datos analíticos: con procesos batch o mediante ingesta continua (streaming). Una aproximación data mesh puede ayudar a resolver el problema de gestionar diferentes tipos de eventos como son los orígenes de datos, las propias aplicaciones o dispositivos.
  • Canalización continua de datos o streaming data pipelines. Una malla de datos puede añadir un gobierno del dato independiente que conecte con los almacenes de datos analíticos, proporcionando y descubriendo los datos, gestión entre dominios, preparación y consistencia del dato.
  • Streaming analytics. Hay eventos que ocurren continuamente y pueden analizarse por flujos en tiempo real, algo determinante para procesos como la telemetría o en contextos tan complejos como una carrera de Fórmula 1 o una competición marítima como el SailGP.

Imagen: Philippe_

Deja una respuesta

Tu dirección de correo electrónico no será publicada.