Unified Namespace vs Data Lake: Qual Você Precisa?

O debate Unified Namespace vs data lake costuma começar quando a equipe de TI já tem um data lake e a equipe de TO propõe um UNS, e ambas se perguntam se um torna o outro redundante. Neste artigo você vai entender para que cada arquitetura realmente serve, onde elas se sobrepõem, por que funcionam melhor juntas e como levar dados de um namespace baseado em MQTT para o armazenamento do lake com um assinante pequeno e confiável.

Duas perguntas diferentes

A forma mais simples de separar os dois é pela pergunta que cada um responde.

Um Unified Namespace responde "o que está acontecendo agora?". É um hub orientado a eventos, normalmente um broker MQTT, onde cada máquina e sistema publica seu estado atual sob uma árvore de topics estruturada. Os consumidores assinam e reagem em milissegundos a segundos. O namespace guarda o valor mais recente de cada topic, geralmente como retained message, e não muito mais que isso.

Um data lake responde "o que aconteceu e o que isso significa?". É uma camada de armazenamento, geralmente object storage com arquivos em formatos abertos como Parquet, com motores de consulta por cima. Ele guarda meses ou anos de dados brutos e refinados para que analistas e cientistas de dados cruzem dados de produção com dados de qualidade, manutenção, ERP e energia.

Um é o sistema nervoso; o outro é a memória de longo prazo. Perguntar qual escolher é como perguntar se uma planta precisa do SCADA ou do banco de dados de relatórios.

Unified Namespace vs data lake em resumo

Dimensão	Unified Namespace	Data lake
Objetivo principal	Estado e eventos em tempo real	Analytics histórico e ML
Horizonte de tempo	Agora (valor mais recente)	Meses a anos
Padrão de acesso	Publicação e assinatura, push	Consultas em lote ou interativas, pull
Latência	Milissegundos a segundos	Minutos a horas são aceitáveis
Formato dos dados	Mensagens pequenas por topic	Grandes arquivos e tabelas colunares
Estrutura	Hierarquia de topics, muitas vezes ISA-95	Schemas, tabelas, partições
Consumidores típicos	IHMs, MES, alertas, dashboards, outras máquinas	Ferramentas de BI, notebooks, pipelines de ML
Responsável	Geralmente TO ou TO/TI em conjunto	Geralmente TI ou equipe de plataforma de dados
Impacto de falha	A operação ao vivo perde visibilidade	Relatórios e modelos ficam desatualizados

Leia qualquer linha e a conclusão é a mesma: são camadas, não alternativas.

De onde vem a confusão

Há três motivos compreensíveis para as pessoas tratarem os dois como concorrentes.

Primeiro, ambos prometem acabar com os silos de dados. Um UNS faz isso dando a cada sistema um único lugar para publicar e assinar; um data lake faz isso colocando os dados de todos os sistemas em uma única camada de armazenamento. Mesmo objetivo, escala de tempo diferente.

Segundo, alguns fornecedores confundem a fronteira. Brokers com persistência embutida e lakes com ingestão em streaming avançam em direção ao outro lado. Esses recursos existem, mas esticar demais qualquer ferramenta gera problemas: brokers não foram feitos para responder "temperatura média por turno no último trimestre", e lakes não foram feitos para enviar um sinal de parada a uma linha em menos de um segundo.

Terceiro, os primeiros projetos de UNS às vezes deixam o armazenamento de fora e depois descobrem que a operação quer tendências e os engenheiros querem análise de causa raiz. A solução não é abandonar o UNS; é adicionar um consumidor de armazenamento.

Como eles se encaixam

O padrão que funciona é simples: o UNS é a fonte única de dados ao vivo, e o data lake é um de seus assinantes, ao lado de dashboards, alertas ou de um gêmeo digital que espelha a planta.

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)

Vantagens desse arranjo:

Uma integração por fonte. Um gateway de CLP publica uma vez; o lake não precisa de um conector próprio para cada máquina.
O contexto vem de graça. Como os topics seguem a hierarquia ISA-95, o job de ingestão pode transformar site, área, linha e máquina em colunas sem tabela de consulta.
Evolução independente. Você pode trocar a plataforma do lake sem mexer na planta e adicionar novos dados da planta sem alterar o pipeline do lake.
Caminhos quente e frio. Um historiador guarda dados recentes de alta resolução para os operadores; o lake guarda a cauda longa para analytics. Nosso guia de historiador MQTT compara as opções de historiador.

Se você está começando do zero, construa primeiro o namespace. Nosso tutorial como construir um Unified Namespace mostra o caminho, e a ingestão para o lake abaixo se conecta diretamente a ele.

Levando dados do UNS para um data lake

A ingestão é apenas mais um cliente MQTT. O script abaixo assina um ramo do namespace e grava cada mensagem como uma linha de JSON em arquivos particionados por data e hora, um layout comum de landing zone para um lake. Um job agendado pode depois converter os arquivos em Parquet e carregar tabelas curadas.

Ele pressupõe topics no formato <prefix>/<site>/<area>/<line>/<machine>/<kind> e payloads JSON. Instale o cliente com 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  # ignora o replay retido para que reinícios não dupliquem linhas
    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()

Em seguida, converta um dia de arquivos da landing zone em Parquet com 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())

Aponte o diretório de landing para uma pasta sincronizada com seu object storage ou troque a gravação em arquivo pela chamada de upload do SDK da sua nuvem. Teste primeiro com dados simulados no servidor MQTT público (gratuito); ele pode ser lido por qualquer pessoa, então dados reais da planta devem ficar em um broker privado com credenciais.

Tornando a ingestão confiável

Um assinante de landing zone é simples, o que é bom, mas planeje estes detalhes:

Use uma sessão persistente. Com um client ID fixo, clean_session=False (MQTT 3.1.1) ou um intervalo de expiração de sessão (MQTT 5), o broker enfileira mensagens QoS 1 durante breves interrupções da ingestão.
Escale com assinaturas compartilhadas. No MQTT 5, vários workers de ingestão podem compartilhar uma assinatura como $share/lake/<prefix>/#, de modo que cada mensagem seja processada uma única vez.
Registre os dois timestamps. Guarde o timestamp de origem do payload e o horário de recebimento, para detectar dados atrasados ou armazenados em buffer.
Não dependa do broker para o histórico. A fila de um broker cobre minutos de desconexão, não dias. Interrupções longas exigem buffer na borda, como store-and-forward.
Versione o schema. Adicione um campo de versão de schema aos payloads para que o lake consiga lidar com mudanças.

No ConnectMQ, assinaturas compartilhadas estão disponíveis a partir do plano Serverless (Paid), e o plano gratuito suporta QoS até 1, que é o que esse padrão de ingestão precisa. O ConnectMQ não inclui pontes nativas para bancos de dados ou data lakes; o padrão honesto e flexível é exatamente este, um assinante externo que você controla.

Qual construir primeiro?

Se você não tem nenhum dos dois, comece pelo namespace de uma linha, seja em uma fábrica em Campinas, em um frigorífico ou em uma mineradora, e depois adicione o armazenamento como primeiro consumidor. A visibilidade em tempo real entrega valor rapidamente e, mais tarde, fornece ao lake uma entrada limpa e contextualizada. Se você já tem um lake alimentado por exportações em lote do SCADA ou do MES, adicionar um UNS traz dados mais atuais e elimina conectores avulsos; aponte a ingestão do lake para o namespace e aposente as exportações uma a uma.

Para a arquitetura mais ampla, nosso guia de MQTT para IoT industrial mostra onde os dois se encaixam junto a CLPs, gateways e SCADA.

Conecte seu Unified Namespace ao armazenamento com o ConnectMQ

O namespace só alimenta o lake de forma confiável se o broker no meio do caminho for confiável. O ConnectMQ é um broker MQTT gerenciado, operado como broker MQTT na nuvem, com MQTT 3.1.1 e 5.0, TLS, retained messages e assinaturas compartilhadas nos planos pagos, além de detecção de topics ISA-95 no portal. Crie um broker no plano gratuito Serverless em app.connectmq.com, sem cartão de crédito, e rode hoje mesmo seu assinante de ingestão contra ele.

Perguntas frequentes

Um Unified Namespace pode substituir um data lake?

Não. Um UNS guarda o estado atual e transmite eventos; ele não foi projetado para armazenamento de longo prazo nem para consultas analíticas. Funciona melhor como a fonte que alimenta o lake.

Um data lake pode substituir um Unified Namespace?

Não para uso em tempo real. Lakes são otimizados para grandes consultas históricas, não para enviar valores ao vivo a IHMs, alertas e outras máquinas em segundos.

Como levo dados MQTT para um data lake?

Rode um assinante, como um script Python, Telegraf ou Node-RED, que consuma os topics do namespace e grave arquivos ou linhas no seu armazenamento. Particione por data e mantenha os níveis ISA-95 como colunas.

O historiador e o data lake devem assinar o UNS?

Muitas vezes, sim. O historiador atende os operadores com tendências recentes de alta resolução, enquanto o lake guarda dados de longo prazo para analytics e machine learning.

Unified Namespace vs Data Lake: Complementares ou Concorrentes?