, el paso de un almacén de datos tradicional a Data Mesh se siente menos como una evolución y más como una crisis de identidad.
Un día, todo funciona (tal vez “funciona” es exagerado, pero todos conocen la situación). Al día siguiente, llega un nuevo CDO con noticias emocionantes: “Nos mudamos a Data Mesh”. Y, de repente, se cuestionan años de procesos, modelos y convenciones cuidadosamente diseñados.
En este artículo, quiero alejarme de la teoría y las palabras de moda y recorrer una transición práctica, desde un “monolito” de datos centralizado a una malla de datos basada en contratos, usando un ejemplo concreto: el análisis de sitios web.
El contrato de datos estandarizado se convierte en el facilitador fundamental de esta transición. Al adherirse a una especificación de contrato estructurada y abierta, las definiciones de esquema, la semántica empresarial y las reglas de calidad se expresan en un formato coherente que las herramientas ETL y de calidad de datos pueden interpretar directamente. Debido a que el contrato sigue un estándar, estas plataformas externas pueden generar pruebas mediante programación, aplicar validaciones, orquestar transformaciones y monitorear el estado de los datos sin integraciones personalizadas.
El contrato pasa de una documentación estática a una capa de control ejecutable que integra perfectamente la gobernanza, la transformación y la observabilidad. El Contrato de Datos es realmente el pegamento que mantiene la integridad de la Malla de Datos.
Por qué el almacenamiento de datos tradicional se convierte en un monolito
Cuando la gente escucha "monolito", a menudo piensa en mala arquitectura. Pero la mayoría de las plataformas de datos monolíticas no comenzaron así, sino que evolucionaron hasta convertirse en una sola.
Un almacén de datos empresarial tradicional suele tener:
Un equipo central responsable de la ingesta, el modelado, la calidad y la publicación Una arquitectura central con canalizaciones y patrones compartidos Componentes estrechamente acoplados, donde un cambio en un modelo puede tener repercusiones en todas partes Ciclos de cambio lentos, porque la demanda siempre excede la capacidad Contexto de dominio limitado, ya que los modeladores a menudo están muy alejados del negocio Problemas de escalamiento, a medida que llegan más fuentes de datos y casos de uso
Esto no es incompetencia, es un resultado natural de la centralización y años de consecuencias no deseadas. Al final, el almacén se convierte en el cuello de botella.
Qué cambia realmente Data Mesh (y qué no)
Data Mesh a menudo se malinterpreta como "no más almacén" o "cada uno hace lo suyo".
En realidad, se trata de un cambio de red, no necesariamente de un cambio tecnológico.
En esencia, Data Mesh se basa en cuatro pilares:
Propiedad de dominio Datos como producto Plataforma de datos de autoservicio Gobernanza federada
La diferencia clave es que en lugar de un gran sistema propiedad de un equipo, se obtienen muchos productos de datos pequeños y conectados, propiedad de dominios y vinculados entre sí mediante contratos claros.
Y aquí es donde los contratos de datos se convierten en el héroe silencioso de la historia.
Contratos de datos: el estabilizador que falta
Los contratos de datos toman prestada una idea familiar de la ingeniería de software: los contratos API, aplicados a los datos.
Fueron popularizados en la comunidad Data Mesh entre 2021 y 2023, con aportes de personas y proyectos como:
Andrew Jones, quien introdujo ampliamente el término contrato de datos a través de blogs y charlas y su libro, que se publicó en 20231 Chad Sanderson (gable.ai) The Open Data Contract Standard, que fue introducido por el proyecto Bitol
Un contrato de datos define explícitamente el acuerdo entre un productor de datos y un consumidor de datos.
El ejemplo: análisis de sitios web
Basemos esto en un escenario concreto.
Imagine un minorista en línea, PlayNest, una juguetería en línea. La empresa quiere analizar el comportamiento de los usuarios en nuestro sitio web.
Hay dos departamentos principales que son relevantes para este ejercicio. Experiencia del Cliente, que es responsable del recorrido del usuario en nuestro sitio web; Cómo se siente el cliente cuando navega por nuestros productos.
Luego está el dominio de Marketing, quienes realizan campañas que llevan a los usuarios a nuestro sitio web, e idealmente hacen que se interesen en comprar nuestro producto.
Existe una superposición natural entre estos dos departamentos. Los límites entre dominios suelen ser confusos.
A nivel operativo, cuando hablamos de sitios web, se captan cosas como:
Visitantes Sesiones Eventos Dispositivos Navegadores Productos
Un modelo conceptual para este ejemplo podría verse así:
Sin embargo, desde una perspectiva de marketing, nadie quiere eventos crudos. Ellos quieren:
Clientes potenciales de marketing Rendimiento del embudo Efectividad de la campaña Carros abandonados En qué tipo de productos hicieron clic las personas para retargeting, etc.
Y desde la perspectiva de la experiencia del cliente, quieren saber:
Puntuaciones de frustración Métricas de conversión (por ejemplo, cuántos usuarios crearon listas de deseos, qué señales están interesadas en ciertos productos, un tipo de conversión de usuario aleatorio a usuario interesado)
El enfoque centralizado (pre-Mesh)
Usaré un marco Medallion para ilustrar cómo se construiría esto en una arquitectura de casa de lago centralizada.
Bronce: datos sin procesar e inmutables de herramientas como Google Analytics Plata: modelos limpios, estandarizados e independientes del origen Oro: conjuntos de datos seleccionados y alineados con el negocio (hechos, dimensiones, mercados)
Aquí, en la capa Bronce, los objetos CSV o JSON sin formato se almacenan, por ejemplo, en un almacén de objetos como S3 o Azure Blob. El equipo central es responsable de la ingesta de datos, asegurándose de que se sigan las especificaciones de la API y se supervisen las canalizaciones de ingesta.
En la capa Plata, el equipo central comienza a limpiar y transformar los datos. Quizás el modelado de datos seleccionado fue Data Vault y, por lo tanto, los datos se estandarizan en tipos de datos específicos, se identifican objetos comerciales y ciertos conjuntos de datos similares se conforman o se acoplan libremente.
En la capa Gold, los requisitos reales del usuario final se documentan en guiones gráficos y los equipos de TI centralizados implementan las dimensiones y los hechos necesarios para los propósitos analíticos de los diferentes dominios.
Reformulemos ahora este ejemplo, pasando de un modelo operativo centralizado a un enfoque descentralizado y de propiedad del dominio.
Análisis de sitios web en una malla de datos
Un modelo de datos típico de Data Mesh podría representarse así:
Un Producto de Datos es propiedad de un Dominio, con un tipo específico, y los datos entran por puertos de entrada y salen por puertos de salida. Cada puerto se rige por un contrato de datos.
Como organización, si ha optado por Data Mesh, tendrá que decidir constantemente entre los dos enfoques siguientes:
¿Organiza su paisaje con estos bloques de construcción reutilizables donde se consolida la lógica, O:
¿Deja que todos los consumidores de los productos de datos decidan por sí mismos cómo implementarlos, con el riesgo de duplicar la lógica?
La gente mira esto y me dice que es obvio. Por supuesto, deberías elegir la primera opción, ya que es la mejor práctica y estoy de acuerdo. Excepto que en realidad las dos primeras preguntas que se harán son:
¿Quién será el propietario del producto de datos fundamental? ¿Quién pagará por ello?
Estas son preguntas fundamentales que a menudo obstaculizan el impulso de Data Mesh. Porque se puede diseñar en exceso (tener muchas piezas reutilizables, pero al hacerlo obstaculizar la autonomía y aumentar los costos) o crear una red de muchos pequeños productos de datos que no se comunican entre sí. Queremos evitar ambos extremos.
Por el bien de nuestro ejemplo, supongamos que en lugar de que cada equipo ingiera Google Analytics de forma independiente, creamos uno o más productos fundamentales compartidos, por ejemplo, productos y comportamiento del usuario del sitio web.
Estos productos pertenecen a un dominio específico (en nuestro ejemplo, será propiedad de Customer Experience) y son responsables de exponer los datos en puertos de salida estándar, que deben regirse por contratos de datos. La idea es que estos productos deberían ser reutilizables en la organización al igual que los conjuntos de datos externos son reutilizables a través de un patrón API estandarizado. Los dominios posteriores, como Marketing, crean productos de datos del consumidor en la parte superior.
Comportamiento del usuario del sitio web Producto de datos fundamentales
Diseñado para la reutilización Estable, bien gobernado A menudo se construye utilizando Data Vault, 3NF o modelos resilientes similares Optimizado para el cambio, no para paneles de control
Las dos fuentes se tratan como puertos de entrada al producto de datos fundamental.
Las técnicas de modelado utilizadas para construir el producto de datos nuevamente están abiertas al dominio para decidir, pero la motivación es la reutilización. Por lo tanto, he visto a menudo utilizar una técnica de modelado más flexible como Data Vault en este contexto.
Los puertos de salida también están diseñados para su reutilización. Por ejemplo, aquí puede combinar los objetos de Data Vault en un formato más fácil de consumir O, para consumidores más técnicos, simplemente puede exponer las tablas de datos sin procesar. Estos simplemente se dividirán lógicamente en diferentes puertos de salida. También puede decidir publicar un resultado separado para exponerlo a LLM o agentes autónomos.
Métricas de conversión de clientes potenciales de marketing Producto de datos del consumidor
Diseñado para casos de uso específicos. Moldeado por las necesidades del dominio consumidor. A menudo dimensional o altamente agregado. Se permite (y se espera) duplicar la lógica si es necesario.
Aquí ilustro cómo optamos por utilizar otros productos de datos fundamentales como puertos de entrada. En el caso del comportamiento del usuario del sitio web, optamos por utilizar las tablas Snowflake normalizadas (ya que queremos seguir construyendo en Snowflake) y crear un Producto de datos que esté listo para nuestras necesidades de consumo específicas.
Nuestros principales consumidores serán los análisis y la creación de paneles, por lo que tiene sentido optar por un modelo dimensional. Está optimizado para este tipo de consultas analíticas dentro de un panel.
Acercándonos a los contratos de datos
El Contrato de Datos es realmente el pegamento que mantiene la integridad de la Malla de Datos. El contrato no sólo debe especificar algunas de las expectativas técnicas sino también los requisitos legales y de calidad y todo lo que pueda interesar al consumidor.
El Estándar de Contratos de Datos Abiertos de Bitol2 se propuso abordar algunas de las brechas que existían con los contratos específicos de proveedores que estaban disponibles en el mercado. Es decir, un estándar abierto y compartido para describir contratos de datos de una manera que sea legible por humanos, legible por máquinas e independiente de las herramientas.
¿Por qué centrarse tanto en un estándar compartido?
Idioma compartido entre dominios
Cuando cada equipo define los contratos de manera diferente, la federación se vuelve imposible.
Un estándar crea un vocabulario común para productores, consumidores y equipos de plataforma.
Interoperabilidad de herramientas
Un estándar abierto permite que las herramientas de calidad de datos, los marcos de orquestación, las plataformas de metadatos y los canales de CI/CD consuman la misma definición de contrato, en lugar de que cada uno requiera su propio formato de configuración.
Los contratos como artefactos vivos
Los contratos no deberían ser documentos estáticos. Con un estándar, se pueden versionar, validar automáticamente, probar en canalizaciones y comparar a lo largo del tiempo. Esto hace que los contratos pasen de ser “documentación” a acuerdos ejecutables.
Evitar el bloqueo de proveedores
Muchos proveedores ahora admiten contratos de datos, lo cual es fantástico, pero sin un estándar abierto, cambiar de herramienta se vuelve costoso.
ODCS es una plantilla YAML que incluye los siguientes componentes clave:
Fundamentos: propósito, propiedad, dominio y consumidores previstos Esquema: campos, tipos, restricciones y reglas de evolución Expectativas de calidad de los datos: actualidad, integridad, validez, umbrales Acuerdos de nivel de servicio (SLA): frecuencia de actualización, disponibilidad, latencia Canales de soporte y comunicación: a quién contactar cuando algo falla Equipos y roles: responsabilidades del productor, propietario y administrador Acceso e infraestructura: cómo y dónde se exponen los datos (tablas, API, archivos) Reglas de dominio personalizadas: lógica de negocios o semántica que los consumidores debe entender
No todos los contratos necesitan todas las secciones, pero la estructura importa porque hace que las expectativas sean explícitas y repetibles.
Contratos de datos que permiten la interoperabilidad
En nuestro ejemplo, tenemos un contrato de datos en el puerto de entrada (producto de datos fundamentales), así como en el puerto de salida (producto de datos de consumo). Desea hacer cumplir estas expectativas de la manera más fluida posible, tal como lo haría con cualquier contrato entre dos partes. Dado que el contrato sigue un formato estandarizado y legible por máquina, ahora puede integrarlo con ETL de terceros y herramientas de calidad de datos para hacer cumplir estas expectativas.
Plataformas como dbt, SQLMesh, Coalesce, Great Expectations, Soda y Monte Carlo pueden generar pruebas mediante programación, aplicar validaciones, orquestar transformaciones y monitorear el estado de los datos sin integraciones personalizadas. Algunas de estas herramientas ya han anunciado su soporte para el Estándar de Contrato de Datos Abiertos.
LLM, servidores MCP y contratos de datos
Al utilizar metadatos estandarizados, incluidos los contratos de datos, las organizaciones pueden utilizar de forma segura LLM y otras aplicaciones de inteligencia artificial para interactuar con sus joyas de la corona: los datos.
Entonces, en nuestro ejemplo, supongamos que Peter de PlayNest quiere comprobar cuáles son los productos más visitados:
Este es contexto suficiente para que el LLM utilice los metadatos para determinar qué productos de datos son relevantes, pero también para ver que el usuario no tiene acceso a los datos. Ahora puede determinar quién y cómo solicitar acceso.
Una vez concedido el acceso:
El LLM puede interpretar los metadatos y crear la consulta que coincida con la solicitud del usuario.
Asegurarse de que los agentes autónomos y los LLM tengan barreras estrictas bajo las cuales operar permitirá a la empresa escalar sus casos de uso de IA.
Varios proveedores están implementando servidores MCP para proporcionar un enfoque bien estructurado para exponer sus datos a agentes autónomos. Obligar a que la interfaz funcione a través de estándares y protocolos de metadatos (como estos contratos de datos) permitirá implementaciones más seguras y escalables de estos casos de uso.
El servidor MCP proporciona el conjunto de herramientas y las barreras de seguridad para operar. Los metadatos, incluidos los contratos de datos, proporcionan las políticas y reglas aplicables bajo las cuales cualquier agente puede operar.
En este momento hay un tsunami de casos de uso de IA solicitados por las empresas. La mayoría de ellos todavía no añaden valor. Ahora tenemos una excelente oportunidad para invertir en el establecimiento de las barreras de seguridad correctas para que estos proyectos operen. Llegará un momento de masa crítica en el que llegará el valor, pero primero necesitamos los componentes básicos.
Me atreveré a decir esto: un Data Mesh sin contratos es simplemente un caos descentralizado. Sin acuerdos claros y ejecutables, la autonomía se convierte en silos, la TI en la sombra se multiplica y la inconsistencia crece más rápido que el valor. En ese punto, no has construido una malla, has distribuido el desorden. También se podría volver a la centralización.
Los contratos reemplazan la suposición con la rendición de cuentas. Construya en pequeño, conéctese de manera inteligente, gobierne con claridad, no se mezcle.
[1]Jones, A. (2023). Impulsar la calidad de los datos con contratos de datos: una guía completa para crear plataformas de datos confiables, confiables y efectivas. Medios O'Reilly.
[2]Bitol. (Dakota del Norte). Estándar de contrato de datos abiertos (v3.1.0). Obtenido el 18 de febrero de 2026 de https://bitol-io.github.io/open-data-contract-standard/v3.1.0/
Todas las imágenes de este artículo fueron creadas por el autor.