Unified Namespace vs. Data Lake: Was brauchen Sie?

Die Debatte Unified Namespace (UNS) vs. Data Lake beginnt meist dann, wenn ein IT-Team bereits einen Data Lake betreibt und ein OT-Team einen UNS vorschlägt – und beide sich fragen, ob das eine das andere überflüssig macht. In diesem Artikel erfahren Sie, wofür jede Architektur tatsächlich gedacht ist, wo sie sich überschneiden, warum sie zusammen am besten funktionieren und wie Sie Daten aus einem MQTT-basierten Namespace mit einem kleinen, zuverlässigen Subscriber in den Lake-Speicher bringen.

Zwei verschiedene Fragen

Am einfachsten lassen sich beide anhand der Frage unterscheiden, die sie jeweils beantworten.

Ein Unified Namespace beantwortet die Frage „Was passiert gerade?“. Er ist ein ereignisgesteuerter Hub, normalerweise ein MQTT-Broker, an den jede Maschine und jedes System seinen aktuellen Zustand unter einem strukturierten Topic-Baum publiziert. Consumer abonnieren und reagieren innerhalb von Millisekunden bis Sekunden. Der Namespace hält den letzten Wert jedes Topics, typischerweise als Retained Message, und nicht viel mehr.

Ein Data Lake beantwortet die Frage „Was ist passiert, und was bedeutet es?“. Er ist eine Speicherschicht, meist Object Storage mit Dateien in offenen Formaten wie Parquet, plus Abfrage-Engines darüber. Er hält Monate oder Jahre an Roh- und aufbereiteten Daten vor, damit Analysten und Data Scientists Produktionsdaten mit Qualitäts-, Instandhaltungs-, ERP- und Energiedaten verknüpfen können.

Das eine ist ein Nervensystem, das andere ein Langzeitgedächtnis. Zu fragen, welches man wählen soll, ist so, als würde man fragen, ob ein Werk sein SCADA oder seine Reporting-Datenbank braucht.

Unified Namespace vs. Data Lake im Überblick

Dimension	Unified Namespace	Data Lake
Hauptzweck	Echtzeit-Zustand und Ereignisse	Historische Analysen und ML
Zeithorizont	Jetzt (letzter Wert)	Monate bis Jahre
Zugriffsmuster	Publish und Subscribe, Push	Batch- oder interaktive Abfragen, Pull
Latenz	Millisekunden bis Sekunden	Minuten bis Stunden sind akzeptabel
Datenform	Kleine Nachrichten pro Topic	Große spaltenorientierte Dateien und Tabellen
Struktur	Topic-Hierarchie, oft ISA-95	Schemata, Tabellen, Partitionen
Typische Consumer	HMIs, MES, Alarmierung, Dashboards, andere Maschinen	BI-Tools, Notebooks, ML-Pipelines
Verantwortung	Meist OT oder gemeinsam OT/IT	Meist IT oder Datenplattform-Team
Auswirkung eines Ausfalls	Der laufende Betrieb verliert die Sicht	Berichte und Modelle veralten

Egal welche Zeile Sie lesen, das Fazit ist dasselbe: Es handelt sich um Schichten, nicht um Alternativen.

Woher die Verwirrung kommt

Es gibt drei nachvollziehbare Gründe, warum beide als Konkurrenten betrachtet werden.

Erstens versprechen beide, Datensilos aufzubrechen. Ein UNS erreicht das, indem er jedem System einen Ort zum Publizieren und Abonnieren bietet; ein Data Lake, indem er die Daten aller Systeme in einer Speicherschicht zusammenführt. Gleiches Ziel, andere Zeitskala.

Zweitens verwischen manche Anbieter die Grenze. Broker mit eingebauter Persistenz und Lakes mit Streaming-Ingestion greifen beide auf die jeweils andere Seite über. Diese Funktionen gibt es, aber wer eines der Werkzeuge zu weit dehnt, schafft Probleme: Broker sind nicht dafür gebaut, „Durchschnittstemperatur pro Schicht im letzten Quartal“ zu beantworten, und Lakes sind nicht dafür gebaut, in unter einer Sekunde ein Stoppsignal an eine Linie zu senden.

Drittens verzichten frühe UNS-Projekte manchmal ganz auf Speicherung und stellen dann fest, dass die Produktion Trends und die Ingenieure Ursachenanalysen wollen. Die Lösung ist nicht, den UNS aufzugeben, sondern einen Speicher-Consumer hinzuzufügen.

Wie beide zusammenpassen

Das funktionierende Muster ist einfach: Der UNS ist die einzige Quelle für Live-Daten, und der Data Lake ist einer seiner Subscriber.

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)

Vorteile dieser Anordnung:

Eine Integration pro Quelle. Ein SPS-Gateway publiziert einmal; der Lake braucht keinen eigenen Connector zu jeder Maschine.
Kontext gibt es gratis. Da die Topics der ISA-95-Hierarchie folgen, kann der Ingestion-Job Standort, Bereich, Linie und Maschine ohne Lookup-Tabelle in Spalten umwandeln. Aus acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur werden so direkt die Spalten Enterprise, Site, Area, Line und Cell – die ISA-95-Ebenen sind im UNS bereits die Topic-Struktur.
Unabhängige Weiterentwicklung. Sie können die Lake-Plattform austauschen, ohne das Werk anzufassen, und neue Werksdaten hinzufügen, ohne die Lake-Pipeline zu ändern.
Hot und Cold Path. Ein Historian hält aktuelle, hochaufgelöste Daten für die Bediener; der Lake hält den langen Rest für Analysen. Unser Leitfaden zum MQTT-Historian vergleicht Historian-Optionen.

Wenn Sie bei null anfangen, bauen Sie zuerst den Namespace. Unser Tutorial Unified Namespace aufbauen führt Sie durch den Prozess, und die folgende Lake-Ingestion lässt sich direkt daran anschließen.

Daten aus dem UNS in einen Data Lake übertragen

Ingestion ist einfach ein weiterer MQTT-Client. Das folgende Skript abonniert einen Zweig des Namespace und schreibt jede Nachricht als JSON-Zeile in Dateien, die nach Datum und Stunde partitioniert sind – ein gängiges Landing-Zone-Layout für einen Lake. Ein geplanter Job kann die Dateien später in Parquet umwandeln und aufbereitete Tabellen laden.

Das Skript geht von Topics der Form <prefix>/<site>/<area>/<line>/<machine>/<kind> und JSON-Payloads aus. Installieren Sie den Client mit 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  # Retained-Replay überspringen, damit Neustarts keine doppelten Zeilen erzeugen
    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()

Wandeln Sie anschließend die Landing-Dateien eines Tages mit pandas in Parquet um (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())

Lassen Sie das Landing-Verzeichnis auf einen Ordner zeigen, der mit Ihrem Object Storage synchronisiert wird, oder ersetzen Sie das Schreiben in Dateien durch den Upload-Aufruf des SDKs Ihres Cloud-Anbieters. Testen Sie zuerst mit simulierten Daten gegen den öffentlichen MQTT-Broker; er ist für jeden lesbar und nur für Tests gedacht, daher gehören echte Werksdaten auf einen privaten Broker mit Zugangsdaten.

Ingestion zuverlässig machen

Ein Landing-Zone-Subscriber ist einfach, und das ist gut so – aber planen Sie folgende Details ein:

Persistente Session verwenden. Mit fester Client ID und clean_session=False (MQTT 3.1.1) oder einem Session Expiry Interval (MQTT 5) puffert der Broker QoS-1-Nachrichten bei kurzen Ausfällen der Ingestion.
Mit Shared Subscriptions skalieren. Unter MQTT 5 können sich mehrere Ingestion-Worker ein Abonnement wie $share/lake/<prefix>/# teilen, sodass jede Nachricht genau einmal verarbeitet wird.
Beide Zeitstempel speichern. Behalten Sie den Quellzeitstempel aus der Payload und die Empfangszeit, damit verspätete oder gepufferte Daten erkannt werden können.
Sich für die Historie nicht auf den Broker verlassen. Die Warteschlange eines Brokers überbrückt Minuten an Verbindungsabbrüchen, keine Tage. Lange Ausfälle erfordern Pufferung an der Edge, etwa Store-and-Forward.
Das Schema versionieren. Ergänzen Sie die Payloads um ein Feld für die Schemaversion, damit der Lake mit Änderungen umgehen kann.

Bei ConnectMQ sind Shared Subscriptions ab dem kostenpflichtigen Serverless-Plan verfügbar, und der kostenlose Plan unterstützt QoS bis 1 – genau das, was dieses Ingestion-Muster braucht. ConnectMQ enthält keine eingebauten Datenbank- oder Data-Lake-Bridges; das ehrliche und flexible Muster ist genau dieses: ein externer Subscriber, den Sie selbst kontrollieren.

Was sollten Sie zuerst aufbauen?

Wenn Sie keines von beiden haben, beginnen Sie mit dem Namespace für eine Linie und fügen Sie dann die Speicherung als ersten Consumer hinzu. Echtzeit-Transparenz liefert schnell Nutzen und versorgt den Lake später mit sauberem, kontextualisiertem Input. Wenn Sie bereits einen Lake haben, der per Batch-Export aus SCADA oder MES befüllt wird, liefert ein zusätzlicher UNS aktuellere Daten und ersetzt Einzel-Connectoren; richten Sie die Lake-Ingestion auf den Namespace aus und schalten Sie die Exporte nacheinander ab.

Für die Gesamtarchitektur zeigt unser Leitfaden zu Industrial IoT mit MQTT, wo beide neben SPS, Gateways und SCADA ihren Platz haben.

Verbinden Sie Ihren Unified Namespace mit ConnectMQ mit dem Speicher

Der Namespace speist den Lake nur dann zuverlässig, wenn der Broker in der Mitte verlässlich ist. ConnectMQ ist ein Cloud-MQTT-Broker mit MQTT 3.1.1 und 5.0, TLS, Retained Messages und Shared Subscriptions in den kostenpflichtigen Plänen sowie ISA-95-Topic-Erkennung im Portal. Erstellen Sie einen Broker im kostenlosen Serverless-Plan unter app.connectmq.com, ohne Kreditkarte, und lassen Sie Ihren Ingestion-Subscriber noch heute dagegen laufen.

Häufig gestellte Fragen

Kann ein Unified Namespace einen Data Lake ersetzen?

Nein. Ein UNS hält den aktuellen Zustand und streamt Ereignisse; er ist nicht für Langzeitspeicherung oder analytische Abfragen ausgelegt. Am besten funktioniert er als Quelle, die einen Lake speist.

Kann ein Data Lake einen Unified Namespace ersetzen?

Nicht für den Echtzeiteinsatz. Lakes sind für große historische Abfragen optimiert, nicht dafür, Live-Werte innerhalb von Sekunden an HMIs, Alarmierung und andere Maschinen zu pushen.

Wie bekomme ich MQTT-Daten in einen Data Lake?

Betreiben Sie einen Subscriber, etwa ein Python-Skript, Telegraf oder Node-RED, der Namespace-Topics konsumiert und Dateien oder Zeilen in Ihren Speicher schreibt. Partitionieren Sie nach Datum und behalten Sie die ISA-95-Ebenen als Spalten.

Sollten Historian und Data Lake beide den UNS abonnieren?

Oft ja. Der Historian versorgt die Bediener mit aktuellen, hochaufgelösten Trends, während der Lake Langzeitdaten für Analysen und Machine Learning vorhält.

Unified Namespace vs. Data Lake: Ergänzung oder Konkurrenz?