Unified Namespace vs data lake : lequel choisir ?

Le débat Unified Namespace vs data lake commence généralement lorsqu'une équipe IT dispose déjà d'un data lake et qu'une équipe OT propose un UNS : chacun se demande alors si l'un rend l'autre superflu. Dans cet article, vous verrez à quoi sert réellement chaque architecture, où elles se recoupent, pourquoi elles fonctionnent mieux ensemble et comment transférer les données d'un namespace basé sur MQTT vers un stockage de type lake avec un petit abonné fiable.

Deux questions différentes

Le moyen le plus simple de distinguer les deux est de regarder la question à laquelle chacun répond.

Un Unified Namespace répond à la question « que se passe-t-il en ce moment ? ». C'est un hub piloté par les événements, normalement un broker MQTT, où chaque machine et chaque système publie son état courant sous une arborescence de topics structurée. Les consommateurs s'abonnent et réagissent en quelques millisecondes à quelques secondes. Le namespace conserve la dernière valeur de chaque topic, généralement sous forme de retained message, et guère plus.

Un data lake répond à la question « que s'est-il passé, et qu'est-ce que cela signifie ? ». C'est une couche de stockage, en général un stockage objet contenant des fichiers dans des formats ouverts comme Parquet, avec des moteurs de requête par-dessus. Il conserve des mois ou des années de données brutes et affinées, pour que les analystes et les data scientists puissent croiser les données de production avec la qualité, la maintenance, l'ERP et l'énergie.

L'un est un système nerveux ; l'autre, une mémoire à long terme. Demander lequel choisir revient à demander si une usine a besoin de son SCADA ou de sa base de reporting.

Unified Namespace vs data lake en un coup d'œil

Dimension	Unified Namespace	Data lake
Objectif principal	État et événements en temps réel	Analytique historique et ML
Horizon temporel	Maintenant (dernière valeur)	Des mois à des années
Mode d'accès	Publish/subscribe, push	Requêtes batch ou interactives, pull
Latence	Millisecondes à secondes	Minutes à heures acceptables
Forme des données	Petits messages par topic	Gros fichiers et tables en colonnes
Structure	Hiérarchie de topics, souvent ISA-95	Schémas, tables, partitions
Consommateurs typiques	IHM, MES, alertes, tableaux de bord, autres machines	Outils BI, notebooks, pipelines ML
Propriété	Généralement l'OT ou un binôme OT/IT	Généralement l'IT ou l'équipe plateforme data
Impact d'une panne	L'exploitation en direct perd sa visibilité	Les rapports et modèles deviennent obsolètes

Quelle que soit la ligne lue, la conclusion est la même : ce sont des couches, pas des alternatives.

D'où vient la confusion

Trois raisons compréhensibles poussent à les considérer comme concurrents.

D'abord, les deux promettent de casser les silos de données. Un UNS y parvient en donnant à chaque système un endroit unique où publier et s'abonner ; un data lake y parvient en plaçant les données de chaque système dans une même couche de stockage. Même objectif, échelle de temps différente.

Ensuite, certains éditeurs brouillent la frontière. Les brokers dotés de persistance intégrée et les lakes dotés d'ingestion en streaming empiètent chacun sur le terrain de l'autre. Ces fonctionnalités existent, mais pousser l'un ou l'autre outil trop loin crée des problèmes : les brokers ne sont pas conçus pour répondre à « température moyenne par équipe au dernier trimestre », et les lakes ne sont pas conçus pour envoyer un signal d'arrêt à une ligne en moins d'une seconde.

Enfin, les premiers projets UNS font parfois l'impasse sur le stockage, puis découvrent que l'exploitation veut des tendances et que les ingénieurs veulent des analyses de cause racine. La solution n'est pas d'abandonner l'UNS, mais d'ajouter un consommateur de stockage.

Comment ils s'articulent

Le schéma qui fonctionne est simple : l'UNS est la source unique des données en direct, et le data lake est l'un de ses abonnés, au même titre que les tableaux de bord, l'historian ou un jumeau numérique.

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)

Les avantages de cette organisation :

Une seule intégration par source. Une passerelle PLC publie une fois ; le lake n'a pas besoin de son propre connecteur vers chaque machine.
Le contexte est offert. Comme les topics suivent la hiérarchie ISA-95, le job d'ingestion peut transformer site, zone, ligne et machine en colonnes sans table de correspondance.
Évolution indépendante. Vous pouvez remplacer la plateforme du lake sans toucher à l'usine, et ajouter de nouvelles données d'usine sans modifier le pipeline du lake.
Chemins chaud et froid. Un historian conserve les données récentes à haute résolution pour les opérateurs ; le lake garde la longue traîne pour l'analytique. Notre guide sur l'historian MQTT compare les options d'historian.

Si vous partez de zéro, construisez d'abord le namespace. Notre tutoriel comment construire un Unified Namespace vous guide pas à pas, et l'ingestion vers le lake ci-dessous s'y branche directement.

Transférer les données de l'UNS vers un data lake

L'ingestion n'est qu'un client MQTT de plus. Le script ci-dessous s'abonne à une branche du namespace et écrit chaque message sous forme de ligne JSON dans des fichiers partitionnés par date et par heure, une organisation de landing zone courante pour un lake. Un job planifié peut ensuite convertir les fichiers en Parquet et charger des tables curées.

Il suppose des topics de la forme <prefix>/<site>/<area>/<line>/<machine>/<kind> et des payloads JSON. Installez le client avec 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  # ignorer la relecture des messages retenus pour éviter les doublons au redémarrage
    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()

Convertissez ensuite une journée de fichiers de la landing zone en Parquet avec 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())

Pointez le répertoire de landing vers un dossier synchronisé avec votre stockage objet, ou remplacez l'écriture de fichier par l'appel d'upload du SDK de votre cloud. Testez d'abord avec des données simulées sur le serveur MQTT public gratuit ; il est lisible par tous et réservé aux tests et prototypes, donc les vraies données d'usine doivent aller sur un broker privé avec identifiants.

Fiabiliser l'ingestion

Un abonné de landing zone est simple, ce qui est une bonne chose, mais prévoyez ces détails :

Utilisez une session persistante. Avec un client ID fixe, clean_session=False (MQTT 3.1.1) ou un intervalle d'expiration de session (MQTT 5), le broker met en file d'attente les messages QoS 1 pendant les courtes interruptions de l'ingestion.
Montez en charge avec les abonnements partagés. En MQTT 5, plusieurs workers d'ingestion peuvent partager un abonnement comme $share/lake/<prefix>/#, de sorte que chaque message n'est traité qu'une fois.
Enregistrez les deux horodatages. Conservez l'horodatage source issu du payload et l'heure de réception, afin de détecter les données tardives ou mises en tampon.
Ne comptez pas sur le broker pour l'historique. La file d'un broker couvre des minutes de déconnexion, pas des jours. Les longues coupures exigent une mise en tampon à l'edge, par exemple en store-and-forward.
Versionnez le schéma. Ajoutez un champ de version de schéma aux payloads pour que le lake puisse gérer les évolutions.

Sur ConnectMQ, un broker MQTT managé, les abonnements partagés sont disponibles à partir de l'offre Serverless payante, et l'offre gratuite prend en charge la QoS jusqu'à 1, ce dont ce modèle d'ingestion a besoin. ConnectMQ n'inclut pas de passerelles intégrées vers des bases de données ou des data lakes ; le modèle honnête et flexible est exactement celui-ci, un abonné externe que vous maîtrisez.

Lequel construire en premier ?

Si vous n'avez ni l'un ni l'autre, commencez par le namespace pour une ligne, puis ajoutez le stockage comme premier consommateur. La visibilité en temps réel apporte rapidement de la valeur et fournira plus tard au lake des données propres et contextualisées. Si vous avez déjà un lake alimenté par des exports batch depuis le SCADA ou le MES, ajouter un UNS vous donne des données plus fraîches et supprime des connecteurs ad hoc ; pointez l'ingestion du lake vers le namespace et retirez les exports un par un.

Pour l'architecture d'ensemble, notre guide MQTT pour l'IoT industriel montre où les deux s'insèrent aux côtés des PLC, des passerelles et du SCADA.

Reliez votre Unified Namespace au stockage avec ConnectMQ

Le namespace n'alimente le lake de manière fiable que si le broker au milieu est solide. ConnectMQ est un broker MQTT cloud avec MQTT 3.1.1 et 5.0, TLS, retained messages et abonnements partagés sur les offres payantes, ainsi que la détection des topics ISA-95 dans le portail. Créez un broker avec l'offre gratuite Serverless sur app.connectmq.com, sans carte bancaire, et faites tourner votre abonné d'ingestion dès aujourd'hui.

Questions fréquentes

Un Unified Namespace peut-il remplacer un data lake ?

Non. Un UNS conserve l'état courant et diffuse des événements ; il n'est pas conçu pour le stockage à long terme ni pour les requêtes analytiques. Il est plus efficace comme source qui alimente un lake.

Un data lake peut-il remplacer un Unified Namespace ?

Pas pour un usage temps réel. Les lakes sont optimisés pour de grosses requêtes historiques, pas pour pousser des valeurs en direct vers les IHM, les alertes et d'autres machines en quelques secondes.

Comment faire entrer des données MQTT dans un data lake ?

Exécutez un abonné, par exemple un script Python, Telegraf ou Node-RED, qui consomme les topics du namespace et écrit des fichiers ou des lignes dans votre stockage. Partitionnez par date et conservez les niveaux ISA-95 sous forme de colonnes.

L'historian et le data lake doivent-ils tous deux s'abonner à l'UNS ?

Souvent, oui. L'historian sert les opérateurs avec des tendances récentes à haute résolution, tandis que le lake conserve les données à long terme pour l'analytique et le machine learning.

Unified Namespace vs data lake : complémentaires ou concurrents ?