Arquitectura Data Mesh — Propiedad de Datos Descentralizada

Overview

Data Mesh, introducido por Zhamak Dehghani, es un enfoque sociotécnico para la arquitectura de datos. En lugar de un equipo central de datos que posee todos los pipelines (el patrón del data lake monolítico), Data Mesh distribuye la propiedad a equipos de dominio que tratan sus datos como un producto. El equipo de plataforma provee infraestructura self-serve, permitiendo a los dominios publicar, descubrir y consumir datos sin cuellos de botella. Esto cambia el paradigma de “datos como subproducto” a “datos como producto”.

Cuándo Usar

• Tu equipo central de datos es un cuello de botella para toda la organización
• Los equipos de dominio entienden sus datos mejor que un equipo central
• Necesitas escalar operaciones de datos a través de muchos equipos
• La calidad y propiedad de datos son problemas persistentes
• La organización tiene límites de dominio maduros (microservicios, DDD)

Los Cuatro Principios

Principio	Significado	Implementación Práctica
Propiedad orientada a dominio	Datos propiedad del equipo de dominio que los produce	Cada equipo de microservicio posee sus productos de datos
Datos como producto	Los consumidores de datos son clientes; calidad y usabilidad importan	Esquemas documentados, SLAs y consultas de ejemplo
Plataforma de datos self-serve	La infraestructura es automatizada y accesible	Pipelines gestionados, catálogos de descubrimiento, herramientas de gobernanza
Gobernanza computacional federada	Estándares globales, implementación local	Políticas centrales de privacidad, cumplimiento local en cada dominio

Arquitectura

┌──────────────────────────────────────────────────────┐
│              Plataforma de Datos Self-Serve           │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐          │
│  │ Ingesta  │  │ Almacena │  │ Descubri-│          │
│  │ Pipelines│  │  Capa    │  │miento    │          │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘          │
└───────┼─────────────┼─────────────┼────────────────┘
        │             │             │
   ┌────┴────┐   ┌────┴────┐   ┌────┴────┐
   │ Órdenes │   │Pagos    │   │ Inventa-│
   │ Dominio │   │ Dominio │   │ rio     │
   │(Equipo A)│   │(Equipo B)│   │(Equipo C)│
   └────┬────┘   └────┬────┘   └────┬────┘
        │             │             │
        ▼             ▼             ▼
   Productos de  Productos de  Productos de
   Datos Órdenes Datos Pagos   Datos Inventario

Especificación de Producto de Datos

Un producto de datos debe incluir:

# data-product.yaml — metadata para catálogo de descubrimiento
name: orders.fact_order_events
owner: orders-team@company.com
description: Stream de eventos del ciclo de vida de órdenes (creada, pagada, enviada, entregada)
schema:
  - name: order_id
    type: UUID
    description: Identificador único de orden
  - name: event_type
    type: STRING
    description: Tipo de evento de orden
  - name: occurred_at
    type: TIMESTAMP
    description: Timestamp del evento
quality:
  freshness_sla: "5 minutos"
  completeness: "99.9%"
  schema_evolution: backward_compatible
access:
  classification: internal
  pii_fields: [customer_email, customer_address]
examples:
  - "SELECT * FROM orders.fact_order_events WHERE event_type = 'placed'"

Capas de Implementación

# Producto de datos de dominio — Equipo de Órdenes publica eventos
from datamesh_sdk import DataProductPublisher

publisher = DataProductPublisher(
    domain="orders",
    product="fact_order_events",
    registry_url="https://datacatalog.company.com"
)

@publisher.emit(schema="orders/order_event.avsc")
def on_order_placed(order: Order):
    return {
        "order_id": str(order.id),
        "event_type": "placed",
        "customer_id": str(order.customer_id),
        "total": float(order.total),
        "occurred_at": order.created_at.isoformat()
    }

# Consumidor — Equipo de Analytics lee datos cross-domain
from datamesh_sdk import DataProductConsumer

consumer = DataProductConsumer(registry_url="https://datacatalog.company.com")

# Descubrir y suscribirse a productos de datos
orders = consumer.subscribe("orders.fact_order_events")
payments = consumer.subscribe("payments.fact_payment_events")

# Join entre dominios en el entorno de cómputo del consumidor
revenue_report = orders.join(
    payments,
    on="order_id",
    how="inner"
).groupBy(
    window("occurred_at", "1 day")
).agg(
    sum("total")
)

Componentes de la Plataforma Self-Serve

Componente	Propósito	Herramientas de Ejemplo
Catálogo de Datos	Descubrir y entender productos de datos	DataHub, Collibra, Amundsen
Schema Registry	Forzar y evolucionar esquemas	Confluent Schema Registry, AWS Glue
Control de Acceso	Gestionar permisos entre dominios	Apache Ranger, AWS Lake Formation
Lineage Tracking	Trazar flujo de datos de fuente a consumidor	OpenLineage, Marquez
Monitoreo de Calidad	Alertar sobre violaciones de SLA	Great Expectations, Soda Core

Errores Comunes

• Declarar Data Mesh sin límites de dominio — necesitas dominios claros primero; de lo contrario solo creas caos
• Ignorar gobernanza — gobernanza federada no es “sin gobernanza”; define estándares globales de privacidad, seguridad e interoperabilidad
• Esperar ROI inmediato — los cambios culturales y organizacionales toman tiempo; planifica un viaje de 1-2 años
• Tratarlo como puramente técnico — Data Mesh es 70% cambio organizacional, 30% tecnología
• Construir la plataforma antes que los productos — empieza con 2-3 productos de datos piloto, luego construye la plataforma alrededor de necesidades reales

FAQ

Data Mesh vs Data Lake vs Data Warehouse? Un Data Lake es un enfoque de almacenamiento centralizado. Un Data Warehouse es un enfoque centralizado estructurado. Data Mesh es un enfoque organizacional descentralizado que puede usar lakes, warehouses o bases de datos como almacenamiento subyacente.

Necesito microservicios para implementar Data Mesh? No estrictamente, pero límites de dominio claros son esenciales. Las organizaciones con dominios bien definidos (de DDD o microservicios) tienen mucho más éxito adoptando Data Mesh.

Cómo manejo joins cross-domain? Los consumidores hacen joins en su propio entorno de cómputo después de suscribirse a múltiples productos de datos. La plataforma provee la infraestructura; el consumidor escribe la consulta.