Beusa Energy ist seit 30 Jahren eine Disruption im Energiesektor, mit einer Unternehmensfamilie, die die Bereiche elektrisches hydraulisches Fracking, mobile Stromerzeugung, Stromverteilung, Feldgasverarbeitung und industrielle Fertigung umfasst. Für den Betrieb in anspruchsvollen nordamerikanischen Umgebungen mit Hochfrequenz-Telemetrie von Tausenden von Remote-Assets (Vermögenswerte) nutzte Beusa anfangs eine benutzerdefinierte MQTT- und SQL-Lösung, um Daten an das Databricks lakehouse zu senden. Allerdings ließen sich die Kosten pro GB bei den explosionsartig anwachsenden Datenmengen nicht wirtschaftlich skalieren. Um diese Hürde proaktiv zu vermeiden, suchte Beusa nach einem neuen Ingestionsmodell, das nahtlos Scale, den IT-Overhead eliminiert und die Datenkosten senkt, ohne die operative Dynamik zu verlangsamen.
Explodierende Datenmengen zeigen die Grenzen einer benutzerdefinierten SQL-Pipeline auf.
Als das Daten- & KI-Team von Beusa seine MQTT-zu-Lakehouse-Bridge erstmals baute, gab es Zerobus Ingest noch nicht. Ein .NET 9-Worker-Dienst abonnierte flottenweit MQTT-Broker, parste JSON- und Sparkplug-B-Nutzlasten und schrieb über die SQL Statement API in Delta-Tabellen. Es wurde schnell bereitgestellt, funktionierte zuverlässig und gab dem Unternehmen seinen ersten Überblick über den Betrieb im lakehouse in nahezu Echtzeit. Der Schmerzpunkt war nicht der Betrieb – er war wirtschaftlicher Natur. Mit steigender Geräteanzahl und wachsendem Datenvolumen waren die Kosten pro GB auf dem SQL-Statement-API-Pfad sichtlich nicht nachhaltig, und das Team konnte dies im Diagramm erkennen, bevor es zu einer Krise kam.
"Die SQL Statement API ist ein großartiges Tool, aber sie wurde nicht für hochfrequente operative Telemetrie entwickelt", so Nick Fornicola, Director of Data & KI Platforms bei Beusa Energy. "Sie hat uns in die Produktion gebracht und uns monatelang Zeit verschafft, um den Anwendungsfall zu beweisen. Aber als wir die Workload kannten, brauchten wir einen speziell dafür entwickelten Ingestion-Pfad."
Das Team bewertete zwei Kategorien von Alternativen: verwaltete MQTT-Broker mit Kafka-kompatiblen Schnittstellen (wobei HiveMQ am bekanntesten ist) und herkömmliche Streaming-Broker wie Kafka und Azure Event Hubs, die Daten über Structured Streaming an Databricks weiterleiten. Die Preise von HiveMQ passten nicht zu ihrer Scale und Entwicklung. Die Lösung mit Kafka und Event Hubs hätte eine zustandsbehaftete Broker-Ebene eingeführt, die zusätzlich zur bestehenden Databricks-Rechnung betrieben, gesichert und bezahlt werden müsste. Zerobus Ingest war die einzige Option, die direkte Schreibvorgänge vom bestehenden Worker in Delta-Tabellen ermöglichte, ohne eine Broker-Schicht hinzuzufügen. Nachdem sie die Zahlen durchgerechnet hatten, war die Entscheidung eindeutig. Beusa sah die Wand, rechnete nach und schlug einen anderen Weg ein, bevor sie dagegen stießen.
Ein direkter Weg zum lakehouse, ohne eine Broker-Schicht hinzuzufügen
Zerobus Ingest ist eine Direct-Write-API, die speziell für operative Datenquellen wie IoT, Telemetrie und Clickstreams entwickelt wurde, bei denen Daten kontinuierlich, in Scale und mit einer Latenz von wenigen Sekunden in Delta-Tabellen landen müssen. Die Migration erforderte nur eine einzige Änderung: den API-Aufruf für SQL-Anweisungen durch den Zerobus gRPC-Endpoint zu ersetzen. Derselbe .NET 9 Worker. Dieselben MQTT-Abonnements. Dasselbe Handling von Sparkplug B und JSON-Payloads. Es wurden keine Gerätekonfigurationen geändert.
„Wir mussten den Worker nicht umschreiben, wir haben die Upstream-Broker nicht geändert und keine einzige Gerätekonfiguration angefasst“, erklärte Fornicola. „Wir haben den Schreibpfad ausgetauscht, alles erneut bereitgestellt und zugesehen, wie die Kostenkurve fiel.“
Die Ingestion, die auf dem SQL Statement API-Pfad rund 689 DBU pro GB gekostet hatte, fiel bei Zerobus auf etwa 0,29 DBU pro GB – eine Reduzierung um drei Größenordnungen bei derselben Workload, denselben Payloads und denselben nachgelagerten Delta-Tabellen. Beusa vermied außerdem die vollständige Einrichtung einer separaten Streaming-Broker-Ebene und eliminierte so eine ganze Klasse zustandsbehafteter Infrastruktur.
Heute Stream mehr als 6.000 Geräte Telemetriedaten mit 1 Hz von circa 250 Remote-Assets (Vermögenswerte) in ein zentrales lakehouse, mit einer End-to-End-Latenz vom Sensor bis zur abfragbaren Delta-Tabelle von rund drei Sekunden, die von Unity Catalog gesteuert werden und sofort nach dem Schreiben einsatzbereit sind.
Von Kosteneinsparungen bis zur vorausschauenden Wartung in Scale
Die Kostensenkung rechtfertigte die Migration, aber die weitreichendere Auswirkung war die Erschließung der Scale ohne operativen Aufwand. Heute verarbeitet Zerobus Ingest mühelos täglich ca. 22 Millionen Zeilen Telemetriedaten ohne Wartungsaufwand, was dem Team einen vereinfachten Stack und einen kostengünstigen Weg für die Zukunft bietet. Hochfrequente Telemetriedaten fließen jetzt in funktionsübergreifende Analysen für die Betriebsleitung, das Flottenmanagement, das Engineering sowie die Steuerung und Automatisierung ein. Entscheidungen, die zuvor auf Intuition oder veralteten Berichten basierten, werden nun von einheitlichen nahezu Echtzeitdaten gesteuert.
"Unser Historian ist ein großartiges System of Record für das, was an einem Gerät passiert ist", sagte Fornicola. „Aber um die Fragen zu beantworten, die das Unternehmen tatsächlich stellt – über Flotten, Becken und Wartungsereignisse hinweg –, benötigen wir diese Daten im lakehouse, verknüpft mit allem anderen.“ Zerobus macht das in unserer Scale wirtschaftlich rentabel."
Die neue Architektur gibt Beusa auch einen klaren Weg vor, um seine Wartungsstrategie durch eine definierte Reifegrad-Progression voranzutreiben:
Heute – Zustandsbasierte Instandhaltung: Die Instandhaltung wird durch aktuelle Betriebsbedingungen und den beobachteten Zustand der Anlage ausgelöst – besser als feste Intervalle, aber immer noch reaktiv auf das, was gerade geschieht.
In Bearbeitung – Vorausschauende Wartung: Mit der Hochfrequenztelemetrie, die nun neben dem Wartungsverlauf im lakehouse zur Verfügung steht, führt Beusa ein Training von Modellen durch, um die Restnutzungsdauer jedes Asset (Vermögenswert) zu prognostizieren. Beim hydraulischen Fracking folgt der Ausfall von verschleißanfälligen Komponenten einer Kurve, die von Dutzenden von Betriebsvariablen beeinflusst wird – Druck, Rate, Flüssigkeitseigenschaften, Zyklen und mehr. Die Modellierung dieser Zusammenhänge ermöglicht es dem Unternehmen, Instandhaltungszeiten auf Basis der tatsächlichen Zustandsentwicklung jedes Assets (Vermögenswerts) zuzuweisen, anstatt nach einem festen Schedule vorzugehen.
Nächster Schritt – Präskriptive Wartung: Sobald die prädiktive Schicht ausgereift ist, besteht das Ziel darin, von der Vorhersage von Ausfällen zur Empfehlung von Maßnahmen überzugehen – durch automatischen Abgleich vorhergesagter Ausfälle mit Flottenplänen, Teilebeständen, Personalverfügbarkeit, Wetter und anderen betrieblichen Einschränkungen.
Mit der Erweiterung der Flotte setzen die Stückkosten der Datenerfassung keine Obergrenze mehr dafür, welche Daten erfasst werden können oder was das Unternehmen damit anfangen kann.
„Die Lektion für uns ist, dass sich nicht jede Migration finanziell lohnen muss; manchmal geht es um einen geringeren Betriebsaufwand oder eine bessere Latenz, manchmal um beides“, bemerkte Fornicola. „Zerobus Ingest hat uns viel Geld gespart, unseren Stack vereinfacht und uns auf einen gemanagten Weg für die Zukunft gebracht. Das ist selten.“
Für Beusa machte Zerobus Ingest aus einem schwierigen architektonischen Kompromiss eine Nicht-Entscheidung. Die Daten fließen vom Bohrstandort in Sekundenschnelle in das lakehouse, die Ingenieure müssen sich keine Sorgen mehr über die Kosten für jeden geschriebenen Datensatz machen und das Unternehmen erhält einen schnelleren Weg vom Betriebssignal zur betrieblichen Maßnahme.
