Maschinendaten entstehen an der Anlage. Ihren vollen Wert entfalten sie jedoch oft erst in der Cloud. Denn werksübergreifende Analytik, OEE-Kennzahlen und KI-Modelle brauchen eine zentrale, skalierbare Datenbasis. Genau hier setzt die Snowflake Integration im Industrial IoT an. Snowflake ist zunächst ein Cloud-Data-Warehouse. Dabei führt es OT-Daten von der Fertigung mit IT-Daten aus ERP und MES zusammen. Somit entsteht eine gemeinsame Grundlage für Reporting, Analyse und Machine Learning.
Dieser Artikel zeigt zunächst, wo Snowflake in einer modernen Datenarchitektur sitzt. Anschließend beschreibt er die vier technischen Wege der Datenübernahme. Außerdem erklärt er den UNS-nativen Pfad über MQTT und liefert klare Kriterien für die Wahl zwischen Batch und Streaming. Die Zielgruppe sind schließlich IT/OT-Architekten, Data Engineers und Digitalisierungsverantwortliche in der Fertigung.
Wo Snowflake in der UNS-Architektur sitzt
Eine Snowflake Integration ersetzt weder den Broker noch den Historian. Vielmehr sitzt Snowflake als Analytics-Sink hinter der UNS-Schicht. Der Unified Namespace (UNS) bleibt dabei die zentrale Echtzeit-Drehscheibe. Er verteilt Maschinendaten per MQTT an alle Consumer. Snowflake ist somit einer dieser Consumer, und zwar der analytische.
Der Datenfluss ist damit klar. Zunächst publizieren Sensoren und Steuerungen über OPC UA oder MQTT in den UNS. Von dort verzweigen sich die Daten. Ein Zweig bleibt dabei lokal am Edge, ein zweiter Zweig fließt in die Cloud. Snowflake steht schließlich am Ende dieses zweiten Zweigs. Dort dient es der Auswertung, nicht der Steuerung.
Diese Trennung ist wichtig. Der UNS bedient Echtzeit-Use-Cases mit niedriger Latenz. Snowflake bedient analytische Use-Cases über große Zeiträume. Beide Schichten haben unterschiedliche Aufgaben. Sie ergänzen sich, statt zu konkurrieren.
Ein zentraler Treiber der Snowflake Integration ist die IT/OT-Datenzusammenführung. In der Fertigung liegen Daten nämlich oft in getrennten Silos. Maschinendaten stecken beispielsweise in Steuerungen und Historian-Systemen. Auftrags- und Materialdaten liegen hingegen in ERP und MES. Erst die Zusammenführung erlaubt daher aussagekräftige Kennzahlen. Snowflake bietet dafür die zentrale, elastisch skalierbare Plattform. Zudem lassen sich Rechenleistung und Speicher getrennt und bedarfsgerecht skalieren.
Snowflake vs. Data Historian – Ergänzung statt Ersatz
Ein Data Historian und Snowflake lösen verschiedene Probleme. Der Historian sitzt zunächst nah an der Anlage. Dabei erfasst er hochfrequente Zeitreihen, sichert die Datenintegrität und komprimiert Rohsignale effizient. Somit ist er auf lokale Verfügbarkeit und schnelle Abfragen optimiert.
Snowflake dagegen ist werksübergreifend ausgelegt. Dabei verbindet es Maschinendaten mit ERP-, MES- und Qualitätsdaten. Darauf laufen anschließend OEE-Berechnungen, Reporting und ML-Modelle. Wer die Rollen von Time-Series-Datenbank und Historian im UNS vergleicht, erkennt das Muster. Der Historian ist somit die Aufnahmeschicht am Shopfloor. Snowflake ist hingegen die Analyseschicht darüber. Beide zusammen ergeben schließlich ein vollständiges Bild.
Die vier Wege, wie Maschinendaten nach Snowflake kommen
Für die Snowflake Integration gibt es vier etablierte Methoden. Sie unterscheiden sich dabei in Datenform, Latenz und Aufwand. Die richtige Wahl hängt somit vom Use Case ab.
Staging und COPY INTO
Der klassische Weg nutzt zunächst einen Object Store als Zwischenspeicher. Maschinendaten landen dort als Dateien in S3, Azure Blob Storage oder Google Cloud Storage. Anschließend greift Snowflake über eine External Stage darauf zu. Die Stage ist ein benannter Verweis auf deinen Bucket. Die Authentifizierung läuft zudem über eine Storage Integration, nicht über eingebettete Zugangsdaten. Bucket und Snowflake-Konto sollten außerdem in derselben Cloud-Region liegen.
Der Befehl COPY INTO lädt die Dateien anschließend in eine Tabelle. Er läuft dabei manuell oder per Zeitplan auf einem Warehouse. Somit passt dieser Weg gut für historische Backfills und große Batch-Ladungen. Der Object Store fungiert hierbei als Landing Zone. Wie diese Staging-Schicht in der Praxis aussieht, zeigt schließlich der Artikel zur AWS-S3-Integration.
Snowpipe
Snowpipe automatisiert genau diesen Ladevorgang. Es überwacht eine External Stage auf neue Dateien. Sobald eine Datei ankommt, lädt Snowpipe sie serverlos in die Zieltabelle. Ein eigenes Warehouse ist dafür nicht nötig.
Snowpipe arbeitet dateibasiert und im Micro-Batch. Die typische Latenz liegt bei etwa ein bis drei Minuten. Damit eignet es sich für regelmäßige, aber nicht zeitkritische Datenströme. Man kann Snowpipe als automatisiertes COPY INTO verstehen.
Snowpipe Streaming
Snowpipe Streaming verfolgt hingegen einen anderen Ansatz. Es arbeitet nämlich zeilenbasiert statt dateibasiert. Über das Snowflake Ingest SDK schreiben Anwendungen einzelne Zeilen direkt in Tabellen. Zwischendateien im Object Store entfallen somit komplett.
Das senkt die Latenz drastisch. Daten stehen dadurch im Sub-Sekunden-Bereich zur Verfügung. Für Telemetrie und IoT-Events ist dies deshalb der passende Weg. Kontinuierliche Messwerte fließen so ohne Umweg in die Analyse. Für die meisten Maschinendaten in Snowflake ist Snowpipe Streaming daher die erste Wahl.
Snowflake Connector for Kafka
Viele Industrieumgebungen nutzen Apache Kafka als Event-Backbone. Der Snowflake Connector for Kafka verbindet beide Welten. Intern nutzt er Snowpipe Streaming. Pro Kafka-Partition öffnet er einen eigenen Channel und schreibt die Zeilen über insertRows.
Damit erbt der Connector die niedrige Latenz des Streaming-Ansatzes. Wer Kafka bereits im Einsatz hat, integriert Snowflake ohne zusätzliche Pipeline. Die Abgrenzung zwischen Kafka und MQTT im Industrial IoT hilft bei der Frage, wann sich dieser Weg lohnt.
Die folgende Tabelle fasst die vier Methoden zusammen. Sie liefert die Faktenbasis für die Wahl des richtigen Ingestion-Wegs.
| Methode | Datenform | Latenz | Typischer IIoT-Use-Case |
|---|---|---|---|
| Staging + COPY INTO | Dateien | Batch, manuell/geplant | Historische Backfills, große Ladungen |
| Snowpipe | Dateien | Micro-Batch, ~1–3 min | Regelmäßige, nicht zeitkritische Ströme |
| Snowpipe Streaming | Zeilen | Sub-Sekunde | Telemetrie und IoT-Events |
| Kafka Connector | Zeilen | Sub-Sekunde | Bestehender Kafka-Event-Backbone |
Der UNS- und MQTT-native Weg nach Snowflake
Im Unified Namespace liegen Maschinendaten bereits als MQTT-Nachrichten vor. Eine Snowflake-Integration kann diesen Strom deshalb direkt anzapfen. Eine MQTT-Bridge liest zunächst aus dem Broker und schreibt über Snowpipe Streaming nach Snowflake. So bleibt der UNS die Quelle der Wahrheit. Snowflake wird somit zum nachgelagerten Consumer.
Mehrere Broker-Hersteller bieten dafür fertige Bausteine. Die HiveMQ Enterprise Extension for Snowflake leitet Nachrichten beispielsweise über das Snowpipe Streaming SDK weiter. EMQX unterstützt hingegen zwei Modi. So kann es per Stage und Pipe im Batch laden oder direkt die Snowpipe Streaming API nutzen. Beide Lösungen halten die Konfiguration zudem im Broker.
Sparkplug B mit Cirrus Link und Ignition
Ein Sonderfall ist die IoT Bridge for Snowflake von Cirrus Link. Sie arbeitet mit Ignition und MQTT Sparkplug B. Sparkplug kodiert Nutzdaten als Protobuf. Die Bridge wandelt diese in JSON um und schreibt sie per Snowpipe Streaming SDK. Details zum Protokoll erklärt der Artikel zu Sparkplug B und seinen Vor- und Nachteilen.
Die Bridge flacht die Daten in geräte-orientierte „As-Of“-Views ab. Diese zeigen den jeweils letzten bekannten Zustand eines Geräts. Sparkplug arbeitet zudem nach dem Prinzip Report-by-Exception. Es sendet nur bei tatsächlichen Änderungen. Das reduziert das Datenvolumen deutlich. Für Nicht-Sparkplug-Quellen bietet die Bridge einen Roh-MQTT-Modus.
Batch vs. Streaming: Welche Latenz braucht welcher Use Case
Nicht jeder Use Case braucht jedoch Sub-Sekunden-Latenz. Die Wahl zwischen Batch und Streaming ist vielmehr eine Abwägung. Sie richtet sich nämlich nach dem Bedarf des Anwendungsfalls, nicht nach dem technisch Machbaren.
Tages-Reporting und OEE-Dashboards sind gut planbar. Sie werten Zeiträume von Stunden oder Tagen aus. Hier reicht ein Batch-Ladevorgang mit COPY oder Snowpipe. Eine Latenz von Minuten spielt keine Rolle.
Anders liegt der Fall bei Condition Monitoring und Anomalie-Erkennung. Hier zählt jede Sekunde. Ein Modell muss auf frische Messwerte reagieren. Dafür braucht es Snowpipe Streaming oder den Kafka Connector. Die Kosten und die Komplexität steigen dabei Richtung Streaming. Wer den Bedarf realistisch einschätzt, vermeidet unnötigen Aufwand.
Eine gute Faustregel hilft bei der Einordnung. Frage zuerst, wie frisch die Daten sein müssen. Ein Tages-KPI verträgt Minuten Verzögerung problemlos. Eine Alarmierung bei Grenzwertüberschreitung verträgt sie nicht. Viele Architekturen kombinieren beide Wege. Kritische Signale laufen über Streaming, planbare Auswertungen über Batch. Diese Mischung hält die Kosten der Snowflake-Integration im Rahmen.
Datenmodellierung und Kontext in Snowflake
Rohe Maschinendaten allein reichen nicht. Erst der Kontext macht sie auswertbar. Snowflake bietet dafür passende Werkzeuge. Semi-strukturierte JSON-Daten speichert der Datentyp VARIANT. So landen verschachtelte MQTT-Payloads ohne starres Schema in einer Tabelle. Abfragen greifen später gezielt auf einzelne Felder zu.
Für die kontinuierliche Aufbereitung eignen sich Dynamic Tables. Sie transformieren Rohdaten automatisch in analysefertige Strukturen. Die Transformation läuft deklarativ und inkrementell. Neue Zeilen fließen ohne manuelle Orchestrierung nach. So entsteht aus rohem VARIANT-Input eine saubere, abfragbare Faktentabelle.
Der entscheidende Schritt ist schließlich die Anreicherung mit Kontext. Denn ein Messwert braucht Bezug zu Anlage, Linie und Standort. Diesen Kontext liefert der UNS bereits über eine ISA-95-orientierte Struktur. Dabei kodiert die Topic-Hierarchie Standort, Bereich und Maschine.
Wie man ihn sauber modelliert, zeigt zunächst der Leitfaden zur Datenmodellierung im Unified Namespace. Wer diesen Kontext bei der Snowflake Integration mitführt, macht somit aus Rohdaten belastbare Kennzahlen. Ergänzend lohnt zudem ein Blick auf Industrial DataOps im Unified Namespace. Dort geht es um Governance und Qualität der Datenströme.
Fazit und typische Fehler
Die Snowflake Integration im Industrial IoT gelingt, wenn die Rollen klar sind. Snowflake ist somit die Analyse- und KI-Schicht hinter dem UNS. Zudem ergänzt es Broker und Historian, statt sie zu ersetzen. Der passende Ingestion-Weg richtet sich schließlich nach der benötigten Latenz. Für IoT-Telemetrie ist Snowpipe Streaming daher meist die richtige Wahl.
In der Praxis tauchen drei Fehler immer wieder auf. Diese Kernaussagen fassen sie zusammen.
- Snowflake ist kein Historian-Ersatz: Wer die Anlagen-nahe Erfassung durch das Warehouse ersetzt, verliert Echtzeit-Nähe und Integrität. Beide Schichten haben eigene Aufgaben.
- Nicht jede Rohnachricht gehört ins Streaming: Ungefiltertes Streamen aller Nachrichten treibt Kosten und Volumen. Filterung und Report-by-Exception halten die Last niedrig.
- Ohne Kontext keine Analyse: Maschinendaten in Snowflake ohne Asset-Bezug bleiben Zahlen ohne Bedeutung. Der ISA-95-Kontext aus dem UNS macht sie erst nutzbar.
