Unified Namespace vs data lake: ¿cuál necesitas?

El debate Unified Namespace vs data lake suele surgir cuando un equipo de IT ya tiene un data lake y un equipo de OT propone un UNS, y ambos se preguntan si uno vuelve redundante al otro. En este artículo aprenderás para qué sirve realmente cada arquitectura, dónde se solapan, por qué funcionan mejor juntas y cómo llevar datos desde un namespace basado en MQTT a un almacenamiento de tipo lake con un suscriptor pequeño y fiable.

Dos preguntas distintas

La forma más sencilla de separarlos es por la pregunta que responde cada uno.

Un Unified Namespace responde a "¿qué está pasando ahora mismo?". Es un hub orientado a eventos, normalmente un broker MQTT, donde cada máquina y sistema publica su estado actual bajo un árbol de topics estructurado. Los consumidores se suscriben y reaccionan en milisegundos o segundos. El namespace conserva el último valor de cada topic, normalmente como retained message, y poco más.

Un data lake responde a "¿qué pasó y qué significa?". Es una capa de almacenamiento, normalmente almacenamiento de objetos con archivos en formatos abiertos como Parquet, con motores de consulta por encima. Guarda meses o años de datos brutos y refinados para que analistas y científicos de datos puedan cruzar los datos de producción con los de calidad, mantenimiento, ERP y energía.

Uno es un sistema nervioso; el otro, la memoria a largo plazo. Preguntar cuál elegir es como preguntar si una planta necesita su SCADA o su base de datos de informes.

Unified Namespace vs data lake de un vistazo

Dimensión	Unified Namespace	Data lake
Propósito principal	Estado y eventos en tiempo real	Analítica histórica y ML
Horizonte temporal	Ahora (último valor)	De meses a años
Patrón de acceso	Publicación y suscripción, push	Consultas por lotes o interactivas, pull
Latencia	De milisegundos a segundos	Son aceptables minutos u horas
Forma de los datos	Mensajes pequeños por topic	Grandes archivos y tablas columnares
Estructura	Jerarquía de topics, a menudo ISA-95	Esquemas, tablas, particiones
Consumidores típicos	HMI, MES, alertas, dashboards, otras máquinas	Herramientas de BI, notebooks, pipelines de ML
Propiedad	Normalmente OT o conjunta OT/IT	Normalmente IT o el equipo de plataforma de datos
Impacto de un fallo	Las operaciones en vivo pierden visibilidad	Los informes y modelos quedan desactualizados

Lee cualquier fila y la conclusión es la misma: son capas, no alternativas.

De dónde viene la confusión

Hay tres razones comprensibles por las que se les trata como rivales.

Primero, ambos prometen acabar con los silos de datos. Un UNS lo hace dando a todos los sistemas un único lugar donde publicar y suscribirse; un data lake lo hace reuniendo los datos de todos los sistemas en una sola capa de almacenamiento. Mismo objetivo, distinta escala temporal.

Segundo, algunos fabricantes difuminan la frontera. Los brokers con persistencia integrada y los lakes con ingesta en streaming se acercan al otro lado. Esas funciones existen, pero estirar demasiado cualquiera de las dos herramientas crea problemas: los brokers no están diseñados para responder "temperatura media por turno el último trimestre" y los lakes no están diseñados para enviar una señal de parada a una línea en menos de un segundo.

Tercero, los primeros proyectos UNS a veces omiten por completo el almacenamiento y luego descubren que operaciones quiere tendencias e ingeniería quiere análisis de causa raíz. La solución no es abandonar el UNS, sino añadir un consumidor de almacenamiento.

Cómo encajan

El patrón que funciona es sencillo: el UNS es la fuente única de los datos en vivo y el data lake es uno de sus suscriptores.

PLCs / gateways / Sparkplug edge nodes
              |
              v
   Unified namespace (MQTT broker, ISA-95 topics)
     |            |              |               |
     v            v              v               v
 Dashboards    Alerting     Historian      Lake ingestion
                            (hot data)     (raw files, then
                                            curated tables)

Ventajas de esta disposición:

Una integración por fuente. Un gateway de PLC publica una vez; el lake no necesita su propio conector hacia cada máquina.
El contexto viene gratis. Como los topics siguen la jerarquía ISA-95, el proceso de ingesta puede convertir sitio, área, línea y máquina en columnas sin tabla de correspondencias.
Evolución independiente. Puedes sustituir la plataforma del lake sin tocar la planta y añadir nuevos datos de planta sin cambiar el pipeline del lake.
Rutas caliente y fría. Un historian guarda los datos recientes de alta resolución para los operadores; el lake guarda la cola larga para la analítica. Nuestra guía sobre el historian MQTT compara las opciones de historian.

Si partes de cero, construye primero el namespace. Nuestro tutorial sobre cómo construir un Unified Namespace te guía paso a paso, y la ingesta hacia el lake que verás a continuación se conecta directamente a él.

Llevar datos del UNS a un data lake

La ingesta es simplemente otro cliente MQTT. El script siguiente se suscribe a una rama del namespace y escribe cada mensaje como una línea JSON en archivos particionados por fecha y hora, una disposición de landing zone habitual en un lake. Un proceso programado puede convertir después los archivos a Parquet y cargar tablas depuradas.

Supone topics con la forma <prefix>/<site>/<area>/<line>/<machine>/<kind> y payloads JSON. Instala el cliente con pip install "paho-mqtt>=2.0".

import json
import os
from datetime import datetime, timezone

import paho.mqtt.client as mqtt

BROKER = os.getenv("MQTT_HOST", "broker.connectmq.com")
PORT = int(os.getenv("MQTT_PORT", "1883"))
PREFIX = os.getenv("UNS_PREFIX", "connectmq/demo/k4p9")
LANDING = os.getenv("LANDING_DIR", "./landing/uns")

def on_connect(client, userdata, flags, reason_code, properties):
    print("ingestion connected:", reason_code)
    client.subscribe(f"{PREFIX}/+/+/+/+/telemetry", qos=1)

def on_message(client, userdata, msg):
    if msg.retain:
        return  # omite la reproducción de retenidos para que los reinicios no dupliquen filas
    levels = msg.topic[len(PREFIX) + 1:].split("/")
    if len(levels) != 5:
        return
    site, area, line, machine, _ = levels
    try:
        data = json.loads(msg.payload)
    except ValueError:
        print("skipping non-JSON payload on", msg.topic)
        return
    received = datetime.now(timezone.utc)
    row = {
        "received_at": received.isoformat(),
        "site": site, "area": area, "line": line, "machine": machine,
        **data,
    }
    folder = os.path.join(LANDING, f"date={received:%Y-%m-%d}", f"hour={received:%H}")
    os.makedirs(folder, exist_ok=True)
    with open(os.path.join(folder, f"{site}.jsonl"), "a", encoding="utf-8") as f:
        f.write(json.dumps(row) + "\n")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="lake-ingest-k4p9")
if os.getenv("MQTT_USERNAME"):
    client.username_pw_set(os.getenv("MQTT_USERNAME"), os.getenv("MQTT_PASSWORD"))
    client.tls_set()
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, PORT, keepalive=60)
client.loop_forever()

Después, convierte un día de archivos de landing a Parquet con pandas (pip install pandas pyarrow):

import glob
import pandas as pd

files = glob.glob("./landing/uns/date=2026-10-16/hour=*/*.jsonl")
df = pd.concat((pd.read_json(f, lines=True) for f in files), ignore_index=True)
df.to_parquet("./curated/telemetry_2026-10-16.parquet", index=False)
print(df.groupby(["site", "line", "machine"])["temperature_c"].mean())

Apunta el directorio de landing a una carpeta que se sincronice con tu almacenamiento de objetos o sustituye la escritura en archivo por la llamada de subida del SDK de tu nube. Prueba primero contra el servidor MQTT público gratuito con datos simulados; es solo para pruebas y cualquiera puede leerlo, así que los datos reales de planta deben ir a un broker privado con credenciales.

Cómo hacer fiable la ingesta

Un suscriptor de landing zone es sencillo, lo cual es bueno, pero planifica estos detalles:

Usa una sesión persistente. Con un client ID fijo, clean_session=False (MQTT 3.1.1) o un intervalo de expiración de sesión (MQTT 5), el broker encola los mensajes QoS 1 durante cortes breves de la ingesta.
Escala con suscripciones compartidas. En MQTT 5, varios workers de ingesta pueden compartir una suscripción como $share/lake/<prefix>/# para que cada mensaje se procese una sola vez.
Registra ambos timestamps. Conserva el timestamp de origen del payload y la hora de recepción para poder detectar datos tardíos o almacenados en búfer.
No confíes al broker el histórico. La cola de un broker cubre minutos de desconexión, no días. Los cortes largos requieren búfer en el edge, por ejemplo store-and-forward.
Versiona el esquema. Añade a los payloads un campo de versión de esquema para que el lake pueda gestionar los cambios.

En ConnectMQ, las suscripciones compartidas están disponibles en el plan Serverless de pago y superiores, y el plan gratuito admite QoS hasta 1, que es lo que necesita este patrón de ingesta. ConnectMQ no incluye puentes integrados hacia bases de datos o data lakes; el patrón honesto y flexible es exactamente este, un suscriptor externo que tú controlas.

¿Cuál deberías construir primero?

Si no tienes ninguno, ya sea en una mina en Chile o en una planta química en Tarragona, empieza con el namespace para una línea y añade después el almacenamiento como primer consumidor. La visibilidad en tiempo real aporta valor rápidamente y más adelante proporciona al lake una entrada limpia y contextualizada. Si ya tienes un lake alimentado por exportaciones por lotes desde SCADA o MES, añadir un UNS te da datos más frescos y elimina conectores ad hoc; apunta la ingesta del lake al namespace y retira las exportaciones una a una.

Para la arquitectura más amplia, nuestra guía de MQTT para IoT industrial muestra dónde encajan ambos junto a PLC, gateways y SCADA.

Conecta tu Unified Namespace al almacenamiento con ConnectMQ

El namespace solo alimenta el lake de forma fiable si el broker que está en medio es robusto. ConnectMQ es un broker MQTT gestionado, un broker MQTT en la nube con MQTT 3.1.1 y 5.0, TLS, retained messages y suscripciones compartidas en los planes de pago, además de detección de topics ISA-95 en el portal. Crea un broker en el plan gratuito Serverless en app.connectmq.com, sin tarjeta de crédito, y ejecuta hoy mismo tu suscriptor de ingesta contra él.

Preguntas frecuentes

¿Puede un Unified Namespace sustituir a un data lake?

No. Un UNS contiene el estado actual y transmite eventos; no está diseñado para el almacenamiento a largo plazo ni para consultas analíticas. Funciona mejor como la fuente que alimenta un lake.

¿Puede un data lake sustituir a un Unified Namespace?

No para el uso en tiempo real. Los lakes están optimizados para grandes consultas históricas, no para enviar valores en vivo a HMI, alertas y otras máquinas en cuestión de segundos.

¿Cómo llevo datos MQTT a un data lake?

Ejecuta un suscriptor, como un script de Python, Telegraf o Node-RED, que consuma los topics del namespace y escriba archivos o filas en tu almacenamiento. Particiona por fecha y conserva los niveles ISA-95 como columnas.

¿Deben suscribirse al UNS tanto el historian como el data lake?

A menudo, sí. El historian sirve a los operadores tendencias recientes de alta resolución, mientras que el lake conserva los datos a largo plazo para analítica y machine learning.

Unified Namespace vs data lake: ¿complementarios o rivales?