Zum Hauptinhalt springen
Version: 5.5

„Snowflake AI Data Cloud”-Plugin

Das Snowflake Plug-in ermöglicht den bidirektionalen Datenaustausch zwischen dem OPC Router und der Cloud-Datenplattform Snowflake. Daten können sowohl in Snowflake geschrieben als auch aus Snowflake gelesen werden. Dabei stehen verschiedene Methoden zur Verfügung, um Kosten, Performance und Latenz gezielt zu steuern.

Architektur und Betriebsweise​

Alle Operationen werden grundsätzlich über ein Snowflake Warehouse ausgeführt.
Das Warehouse übernimmt die Verarbeitung und Berechnung aller SQL-Abfragen und Schreibvorgänge.

warnung

Kostenhinweis: Jeder Lese- oder Schreibvorgang über das Warehouse verursacht Snowflake-Credits. Das gilt auch bei aktiviertem Auto Resume / Suspend – Kosten fallen an, sobald das Warehouse aktiv ist.

Für reine Ingest-Szenarien ohne Abfragen empfiehlt sich eine kostenoptimierte Alternative über Snowpipe.

Kostenoptimierte Ingest-Varianten (write-only)​

Für Write-only-Szenarien, bei denen der OPC Router ausschließlich Daten in Snowflake einfügt, stehen zwei Wege zur Verfügung:

1. REST Plug-in → Snowpipe​

Über das REST Plug-in kann der OPC Router JSON- oder CSV-Daten an einen Snowpipe-Endpunkt senden.
Snowpipe lädt diese Daten asynchron in die Zieltabellen, ohne ein Warehouse aktiv zu halten.

Vorteile

  • Kein aktives Warehouse notwendig
  • Hohe Kosteneffizienz für kontinuierliches Ingest
  • Unterstützt Event-getriebene Transfers (z. B. aus Produktionssystemen)

2. Cloud File Access Plug-in → S3 / Stage​

Alternativ kann der OPC Router Daten direkt in eine Cloud Stage (z. B. Amazon S3) schreiben. Snowpipe oder ein Copy-Command in Snowflake liest die Daten anschließend automatisiert ein.

Vorteile

  • Stapelverarbeitung größerer Datenmengen
  • Ideal für periodisches oder gepuffertes Schreiben
  • Keine dauerhafte Warehouse-Auslastung

Bidirektionale Nutzung​

Das Snowflake Plug-in unterstützt nicht nur das Schreiben, sondern auch das Lesen und Rückführen von Daten. Damit lassen sich Closed-Loop-Szenarien (z. B. Feedback aus Cloud-Analysen zurück an Maschinen) umsetzen.

Zwei gängige Ansätze stehen zur Verfügung:

1. Trigger über Transfer-State-Spalte​

Der Snowflake-Transferstatus-Trigger löst einen Transfer aus, wenn in der überwachten Tabelle ein Wert als noch nicht transferiert gekennzeichnet ist. Nach Abschluss des Transfers wird der Datensatz als transferiert oder als fehlgeschlagen markiert. Fehlgeschlagene Transfers können optional über einen weiteren Zähler beliebig oft wiederholt werden.

Ablauf

  1. Der Trigger überwacht eine definierte Tabelle in der Datenbank.
  2. Ein Datensatz wird als nicht transferiert markiert (z. B. mit 0) oder bereits so hinzugefügt.
  3. Sobald ein solcher Datensatz erkannt wird, wird ein Transfer ausgelöst.
  4. Nach erfolgreichem Transfer wird der Datensatz als transferiert (z. B. 1) oder fehlgeschlagen (z. B. 2) markiert.
  5. Fehlgeschlagene Transfers können optional mehrfach wiederholt werden, gesteuert über eine Wiederholungsspalte und -anzahl.

Vorteile

  • Automatisierter Transferprozess basierend auf Statuswerten.
  • Wiederholungsmechanismus für fehlgeschlagene Transfers erhöht Zuverlässigkeit.
  • Flexible Konfiguration der Statuswerte und Wiederholungslogik.
  • Möglichkeit zur Begrenzung der Transfermenge pro Durchlauf.

Hinweise

  • Die überwachte Tabelle muss über einen einzelnen Primärschlüssel verfügen.
  • Die Statusspalte und Wiederholungsspalte müssen mit 0 bzw. dem konfigurierten Wert initialisiert sein – NULL-Werte sind nicht zulässig.
  • Sortierung und Filterung der zu transferierenden Datensätze sind konfigurierbar.

2. Trigger über Data-Change in Tabelle​

Alternativ kann der OPC Router Datenänderungen erkennen, indem er eine Spalte wie updated_at oder sequence_id auswertet.

Ablauf

  1. Periodisches Polling auf geänderte Datensätze.
  2. Verarbeitung der neuen oder geänderten Datensätze.
  3. Speicherung des letzten Checkpoints im Router.

Vorteile

  • Kein zusätzliches Statusfeld nötig
  • Einfach in bestehende Strukturen integrierbar

Hinweise

  • Die überwachte Tabelle muss über einen einzelnen Primärschlüssel verfügen.
  • Eindeutige Sortierung (z. B. ORDER BY updated_at, id) empfohlen.
  • Duplikaterkennung über Hash oder eindeutige ID.
  • Bei hoher Änderungsrate kleine Batchgrößen wählen.
  • Optional kann ein Transfer direkt bei DB-Verbindung ausgelöst werden.

Best Practices​

  • Warehouse-Größe bewusst wählen: kleinere Cluster für kontinuierliche Streams, größere nur für Batch-Loads.
  • Suspend aktiv nutzen: automatische Deaktivierung reduziert laufende Kosten erheblich.
  • Ingest asynchron auslagern, wenn Echtzeit nicht erforderlich ist (Snowpipe, REST).
  • Schemaänderungen versionieren, um stabile Transfers sicherzustellen.
SzenarioMethodeWarehouse benötigtKostenoptimiertEmpfohlen für
Synchrone Inserts/SelectsWarehouse-Verbindung✅❌Validierungen, kleine Datenmengen
Asynchrones Ingest (REST)REST Plug-in → Snowpipe❌✅Event-/Log-Daten, Edge → Cloud
Batch-Ingest (File Upload)Cloud File Access → S3/Stage❌✅Große Datenmengen, periodische Uploads
Daten aus Snowflake lesenSQL-Trigger, State- oder Timestamp-Spalte✅❌Rücktransfer oder Data-Feedback

Siehe auch​