English version

Ist Databricks das Richtige für 5-Minuten-SCADA-Daten?

Du bekommst alle 5 Minuten Telemetrie aus einem SCADA-System und brauchst am Ende eine Erzeugungsprognose für Solar und Wind. Deine Frage ist genau die, die ein Tech Lead stellen sollte, bevor das Team baut: Ist Databricks dafür das richtige Werkzeug — oder zwingen wir gerade eine Batch-Analyseplattform in eine Rolle, für die sie nie gedacht war?

Diese Lektion gibt dir eine belastbare Antwort, die Belege dahinter und — noch wichtiger — den Denkrahmen, den du bei der nächsten Latenzfrage wiederverwenden kannst.

Die kurze Antwort

Schritt 1: Trenne die zwei Zahlen, die alle vermischen

„5-Minuten-Daten“ ist eine Aussage über den Ankunftstakt. Über deine Latenzanforderung sagt sie nichts. Beides ist unabhängig voneinander, und die Verwechslung ist die mit Abstand häufigste Ursache überkonstruierter Energiedatenplattformen.

Bei einer Erzeugungsprognose lautet die Frist fast nie „so schnell wie physikalisch möglich“. Sie ist ein Kalender: die Intraday-Gate-Closure (Handelsschluss), der Fahrplan, den du beim ÜNB einreichen musst, die Redispatch-Anforderung, die Stunden-Nominierung. Wenn deine Prognose auf jemandes Schreibtisch liegen muss, bevor ein Gate 15 Minuten vor Lieferung schließt, liegt dein Ende-zu-Ende-Budget im Minutenbereich — und genau in diesem Bereich ist Databricks am günstigsten und am einfachsten.

Schritt 2: Kenne die drei Latenzstufen, die Databricks tatsächlich anbietet

Databricks hat nicht eine Streaming-Antwort. Es hat drei, mit deutlich unterschiedlichen Kosten- und Komplexitätsprofilen. Zu wissen, welche du gerade kaufst, ist bereits der größte Teil der Architekturentscheidung.

Die Zahlen hinter dieser Tabelle, direkt vom Hersteller:

• Real-Time Mode erreicht eine Ende-zu-Ende-Latenz unter 1 Sekunde im Tail, typischerweise rund 300 ms und im besten Fall bis hinunter zu 5 ms. [Real-time mode concepts]
• Databricks empfiehlt dir ausdrücklich Micro-Batch statt Real-Time Mode für „analytische Verarbeitung: ETL-Pipelines, Datentransformationen und Implementierungen der Medaillon-Architektur, bei denen Latenzanforderungen in Sekunden oder Minuten gemessen werden“ sowie zur „Kostenoptimierung … Real-Time Mode benötigt dedizierte Compute-Ressourcen.“ [dieselbe Quelle]
• Der getriggerte Pipeline-Modus wird als beste Wahl beschrieben, wenn „Daten-Updates alle 10 Minuten, stündlich oder täglich laufen“; der Continuous-Modus für „alle 10 Sekunden bis wenige Minuten“. Continuous „benötigt ein dauerhaft laufendes Cluster, was teurer ist, aber die Verarbeitungslatenz senkt.“ [Triggered vs. continuous pipeline mode]
• „Ein per Zeitplan ausgeführter Trigger.AvailableNow()-Job ist das kosteneffizienteste Streaming-Muster auf Serverless Compute, wenn Latenz im Minutenbereich akzeptabel ist. Das Compute startet in Sekunden, verarbeitet den Batch und fährt herunter.“ [Streaming on serverless compute]

Schritt 3: Erkenne die zwei Takte in deiner Pipeline

Das ist die Einsicht, die die Kosten einer Wetter-zu-Strom-Prognose überhaupt tragfähig macht. Dein System hat zwei unabhängige Aktualisierungsraten, und beide auf der schnelleren laufen zu lassen ist reine Verschwendung.

Numerische Wettervorhersage aktualisiert sich ein paar Mal am Tag. Dein SCADA-Feed aktualisiert sich 288 Mal am Tag. Der 5-Minuten-Pfad sollte nur das tun, was frische Telemetrie überhaupt verändern kann: gemessene Erzeugung, Verfügbarkeit und Abregelungszustand sowie eine Bias-/Persistenz-Korrektur mit kurzem Horizont auf die stehende NWP-getriebene Prognose. Das ist ein kleiner, günstiger, inkrementeller Job — und genau deshalb passt die getriggerte Stufe.

Schritt 4: Wisse, wo Databricks die falsche Antwort ist

Glaubwürdig „nein“ sagen zu können, ist das, was dein „ja“ gegenüber Stakeholdern wertvoll macht. Vier Dinge gehören nicht durchs Lakehouse:

Schritt 5: Die empfohlene Bauform

Konkret, für deinen Fall:

1. Edge → Bus. SCADA/Historian veröffentlicht über ein Gateway nach Kafka / Event Hubs oder legt 5-Minuten-Dateien im Cloud-Storage ab. Databricks spricht keine SCADA-Protokolle.
2. Bronze. Auto Loader (Dateien) oder die Kafka-Quelle, die Rohereignisse an eine Streaming Table anhängt. Roh bleibt roh — du brauchst es für das Backtesting des Prognosefehlers.
3. Silver. Deduplizieren, QC anwenden (klemmende Sensoren, Werte außerhalb des Bereichs, Plausibilität des Gondel-Anemometers), Verfügbarkeit und Abregelung kennzeichnen, an die Asset-Hierarchie aus Lektion 2 joinen.
4. Feature + Scoring der schnellen Spur. Nur die inkrementelle Korrektur. Der schwere NWP-getriebene Pfad bleibt auf seinem eigenen, langsameren Zeitplan (Lektion 3).
5. Gold. Prognose je Anlage und Horizont, mit model_version und produced_at, als Vertrag nach unten (Lektion 8).

Baue das Ganze als Serverless Lakeflow-Pipeline. Databricks empfiehlt für neue Pipelines ausdrücklich Lakeflow-Pipelines statt selbst gebautem Structured Streaming, weil dir damit das Management der Produktionsinfrastruktur abgenommen wird. [Production considerations for Structured Streaming]

Entscheide selbst

Arbeite den Baum unten für deinen eigenen Workload durch. Probiere ihn zweimal: einmal für die Prognose-Pipeline und einmal für etwas, das du versucht sein könntest anzuflanschen — etwa einen Abregelungsalarm.

Verständnis prüfen

Primärquelle

Wie es weitergeht

Zwei naheliegende Anschlussthemen, beide direkt auf der Mission:

• Nowcasting-Design — was ein 5-Minuten-Telemetrie-Update in einer Wind- oder Solarprognose verbessern kann und was nicht, und wie du eine Persistenz-Korrektur mit der NWP-getriebenen Basisprognose kombinierst.
• Freshness-SLAs und Observability — wie du Bronze-Veraltung, Laufzeit und produced_at instrumentierst, damit eine veraltete Prognose abgelehnt statt gehandelt wird.

Siehe auch: Architektur-Spickzettel · Lektion 10 — Kosten & Betrieb

Rechtliches: Impressum