Unified Namespace ve Veri Gölü: Tamamlayıcı mı, Rakip mi?

Unified namespace ile veri gölü tartışması genellikle BT ekibinin zaten bir veri gölü olduğu ve OT ekibinin bir UNS önerdiği anda başlar; iki taraf da birinin diğerini gereksiz kılıp kılmadığını merak eder. Bu yazıda her mimarinin gerçekte ne işe yaradığını, nerelerde örtüştüklerini, neden birlikte en iyi sonucu verdiklerini ve MQTT tabanlı bir namespace'ten veri gölü depolamasına küçük ve güvenilir bir aboneyle nasıl veri taşınacağını öğreneceksiniz.

İki Farklı Soru

İkisini ayırmanın en basit yolu, her birinin hangi soruyu yanıtladığına bakmaktır.

Unified namespace "şu anda ne oluyor?" sorusunu yanıtlar. Her makinenin ve sistemin güncel durumunu yapılandırılmış bir topic ağacı altında yayınladığı, olay güdümlü bir merkezdir; normalde bir MQTT broker. Tüketiciler abone olur ve milisaniyeler ile saniyeler içinde tepki verir. Namespace her topic'in son değerini, tipik olarak bir retained message olarak tutar; çok daha fazlasını değil.

Veri gölü "ne oldu ve bunun anlamı ne?" sorusunu yanıtlar. Genellikle Parquet gibi açık formatlarda dosyalar barındıran nesne depolama ile üzerindeki sorgu motorlarından oluşan bir depolama katmanıdır. Analistlerin ve veri bilimcilerin üretim verisini kalite, bakım, ERP ve enerji verileriyle birleştirebilmesi için aylarca veya yıllarca ham ve işlenmiş veriyi saklar.

Biri sinir sistemi, diğeri uzun süreli bellektir. Hangisini seçmek gerektiğini sormak, bir tesisin SCADA'sına mı yoksa raporlama veritabanına mı ihtiyaç duyduğunu sormaya benzer.

Bir Bakışta Unified Namespace ve Veri Gölü

Hangi satırı okursanız okuyun sonuç aynıdır: bunlar alternatif değil, katmandır.

Karışıklık Nereden Kaynaklanıyor?

İnsanların bunları rakip olarak görmesinin anlaşılır üç nedeni vardır.

Birincisi, ikisi de veri silolarını yıkmayı vaat eder. UNS bunu her sisteme yayın yapıp abone olacağı tek bir yer sunarak; veri gölü ise her sistemin verisini tek bir depolama katmanına koyarak yapar. Amaç aynı, zaman ölçeği farklı.

İkincisi, bazı satıcılar sınırı bulanıklaştırır. Yerleşik kalıcılığa sahip broker'lar ve akış alımı sunan veri gölleri karşı tarafa doğru uzanır. Bu özellikler vardır, ancak iki aracı da fazla zorlamak sorun yaratır: broker'lar "geçen çeyrekte vardiya başına ortalama sıcaklık" sorusunu yanıtlamak için tasarlanmamıştır; veri gölleri de bir hatta bir saniyeden kısa sürede durdurma sinyali göndermek için tasarlanmamıştır.

Üçüncüsü, ilk UNS projeleri bazen depolamayı tamamen atlar, ardından operasyonun trend, mühendislerin de kök neden analizi istediğini fark eder. Çözüm UNS'den vazgeçmek değil, bir depolama tüketicisi eklemektir.

Birbirlerini Nasıl Tamamlarlar?

İşe yarayan desen basittir: UNS canlı verinin tek kaynağıdır, veri gölü ise abonelerinden biridir.

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)

Bu düzenin faydaları:

• Kaynak başına tek entegrasyon. Bir PLC gateway'i bir kez yayın yapar; veri gölünün her makineye ayrı bir bağlayıcıya ihtiyacı olmaz.
• Bağlam bedavaya gelir. Topic'ler ISA-95 hiyerarşisini izlediğinden, alım işi saha, alan, hat ve makineyi bir eşleme tablosu olmadan sütunlara dönüştürebilir.
• Bağımsız gelişim. Tesise dokunmadan veri gölü platformunu değiştirebilir, veri gölü hattını değiştirmeden yeni tesis verisi ekleyebilirsiniz.
• Sıcak ve soğuk yollar. Historian, operatörler için yakın dönemin yüksek çözünürlüklü verisini tutar; veri gölü ise analitik için uzun kuyruğu saklar. MQTT historian rehberimiz historian seçeneklerini karşılaştırıyor.

Sıfırdan başlıyorsanız önce namespace'i kurun. Unified namespace nasıl kurulur rehberimiz bunu adım adım anlatıyor; aşağıdaki veri gölü alımı da doğrudan ona bağlanıyor.

UNS'den Veri Gölüne Veri Taşımak

Veri alımı, yalnızca bir MQTT istemcisi daha demektir. Aşağıdaki betik bir namespace dalına abone olur ve her mesajı, tarih ve saate göre bölümlenmiş dosyalara bir JSON satırı olarak yazar; bu, veri gölleri için yaygın bir iniş bölgesi (landing zone) düzenidir. Zamanlanmış bir iş daha sonra dosyaları Parquet'e dönüştürüp düzenlenmiş tabloları yükleyebilir.

Betik, <prefix>/<site>/<area>/<line>/<machine>/<kind> biçimindeki topic'leri ve JSON payload'ları varsayar. İstemciyi pip install "paho-mqtt>=2.0" ile kurun.

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  # yeniden başlatmalarda satırlar çoğalmasın diye retained tekrarını atla
    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()

Ardından bir günlük iniş dosyalarını pandas ile Parquet'e dönüştürün (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())

İniş dizinini nesne depolamanızla senkronize olan bir klasöre yönlendirin veya dosya yazma işlemini bulut SDK'nızın yükleme çağrısıyla değiştirin. Önce simüle verilerle herkese açık MQTT test broker'ı üzerinde test edin; orası herkes tarafından okunabilir, bu yüzden gerçek tesis verisi kimlik bilgileri olan özel bir broker'a aittir.

Veri Alımını Güvenilir Hale Getirmek

Bir iniş bölgesi abonesi basittir ve bu iyidir; ancak şu ayrıntıları planlayın:

1. Kalıcı oturum kullanın. Sabit bir client ID ile clean_session=False (MQTT 3.1.1) veya bir oturum sona erme aralığı (MQTT 5) kullandığınızda broker, kısa alım kesintileri sırasında QoS 1 mesajlarını kuyrukta tutar.
2. Paylaşımlı aboneliklerle ölçeklendirin. MQTT 5'te birden fazla alım çalışanı $share/lake/<prefix>/# gibi tek bir aboneliği paylaşabilir; böylece her mesaj bir kez işlenir.
3. İki zaman damgasını da kaydedin. Payload'daki kaynak zaman damgasını ve alınma zamanını saklayın; böylece geç gelen veya tamponlanmış veriler tespit edilebilir.
4. Geçmiş için broker'a güvenmeyin. Bir broker'ın kuyruğu günleri değil, dakikalarca süren bağlantı kesintilerini karşılar. Uzun kesintiler, store-and-forward gibi saha tarafında tamponlama gerektirir.
5. Şemayı sürümleyin. Veri gölünün değişiklikleri yönetebilmesi için payload'lara bir şema sürümü alanı ekleyin.

ConnectMQ'da paylaşımlı abonelikler ücretli Serverless plan ve üzerinde sunulur; ücretsiz plan ise bu alım deseninin ihtiyaç duyduğu QoS 1'e kadar destek verir. ConnectMQ yerleşik veritabanı veya veri gölü köprüleri içermez; dürüst ve esnek desen tam olarak budur: kontrolü sizde olan harici bir abone.

Önce Hangisini Kurmalısınız?

İkisi de yoksa tek bir hat için namespace ile başlayın, ardından ilk tüketici olarak depolamayı ekleyin. Gerçek zamanlı görünürlük hızla değer üretir ve ileride veri gölüne temiz, bağlamlandırılmış girdi sağlar. SCADA veya MES'ten toplu dışa aktarmalarla beslenen bir veri gölünüz zaten varsa, bir UNS eklemek size daha taze veri verir ve tek seferlik bağlayıcıları ortadan kaldırır; veri gölünün alımını namespace'e yönlendirin ve dışa aktarmaları tek tek emekliye ayırın.

Daha geniş mimari için endüstriyel IoT MQTT rehberimiz, ikisinin PLC'ler, gateway'ler ve SCADA ile birlikte nereye oturduğunu gösteriyor.

Unified Namespace'inizi ConnectMQ ile Depolamaya Bağlayın

Namespace, veri gölünü ancak ortadaki broker güvenilirse sağlıklı biçimde besler. ConnectMQ; MQTT 3.1.1 ve 5.0, TLS, retained message'lar, ücretli planlarda paylaşımlı abonelikler ve portalda ISA-95 topic algılama sunan bir bulut MQTT broker hizmetidir. app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz Serverless planla bir broker oluşturun ve alım abonenizi bugün çalıştırın.

Sık Sorulan Sorular

Unified namespace bir veri gölünün yerini alabilir mi?

Hayır. UNS güncel durumu tutar ve olayları akış halinde iletir; uzun vadeli depolama veya analitik sorgular için tasarlanmamıştır. En iyi, bir veri gölünü besleyen kaynak olarak çalışır.

Veri gölü bir unified namespace'in yerini alabilir mi?

Gerçek zamanlı kullanım için hayır. Veri gölleri büyük geçmiş sorguları için optimize edilmiştir; canlı değerleri saniyeler içinde HMI'lara, alarm sistemlerine ve diğer makinelere iletmek için değil.

MQTT verisini bir veri gölüne nasıl aktarırım?

Namespace topic'lerini tüketen ve depolamanıza dosya veya satır yazan bir abone çalıştırın; örneğin bir Python betiği, Telegraf veya Node-RED. Tarihe göre bölümleyin ve ISA-95 seviyelerini sütun olarak tutun.

Historian ve veri gölünün ikisi de UNS'ye abone olmalı mı?

Çoğu zaman evet. Historian, operatörlere yakın dönemin yüksek çözünürlüklü trendlerini sunarken veri gölü analitik ve makine öğrenmesi için uzun vadeli veriyi saklar.