Beusa Energy est une force de disruption depuis 30 ans, avec un groupe d'entreprises couvrant la fracturation hydraulique électrique, la génération d'énergie mobile, la distribution électrique, le traitement du gaz de champ et la fabrication industrielle. Opérant dans des environnements nord-américains exigeants avec une télémétrie à haute fréquence provenant de milliers d'actifs distants, Beusa utilisait initialement une solution MQTT et SQL personnalisée pour envoyer des données au lakehouse Databricks. Cependant, le coût par Go ne pouvait pas monter en charge de manière rentable avec l'explosion de leurs volumes de données. Pour éviter cet obstacle de manière proactive, Beusa a cherché un nouveau modèle d'ingestion pour Monter en charge de manière fluide, éliminer les frais généraux IT et réduire les coûts des données sans ralentir son élan opérationnel.
L'explosion des volumes de données révèle les limites d'un pipeline SQL personnalisé.
Lorsque l'équipe Data & AI de Beusa a construit sa passerelle MQTT-vers-lakehouse, Zerobus Ingest n'existait pas encore. Un service worker .NET 9 s'est abonné aux brokers MQTT sur l'ensemble de la flotte, a analysé les charges utiles JSON et Sparkplug B, et a écrit dans des tables Delta via l'API SQL Statement. Déployée rapidement, elle a fonctionné de manière fiable et a fourni à l'entreprise sa première vue des opérations en quasi-temps réel dans le lakehouse. Le problème n'était pas d'ordre opérationnel, mais économique. À mesure que le nombre d'appareils et les volumes de données augmentaient, le coût par Go sur le chemin de l'API SQL Statement était manifestement insoutenable, et l'équipe pouvait le voir sur le graphique avant que cela ne devienne une crise.
"L'API SQL Statement est un excellent outil, mais elle n'a pas été conçue pour la télémétrie opérationnelle à haute fréquence", a déclaré Nick Fornicola, directeur des plateformes de données & d'IA chez Beusa Energy. "Cela nous a permis de passer en production, et nous a donné des mois de marge pour valider le cas d'utilisation. Mais une fois que nous avons connu la charge de travail, nous avions besoin d'un chemin d'ingestion spécialement conçu pour elle."
L'équipe a évalué deux catégories d'alternatives : les brokers MQTT gérés avec des interfaces compatibles avec Kafka (HiveMQ étant le plus important) et les brokers de streaming traditionnels tels que Kafka et Azure Event Hub alimentant Databricks via Structured Streaming. Les Tarifs de HiveMQ n'étaient pas adaptés à leur capacité à monter en charge et à leur trajectoire. L'approche Kafka et Event Hubs introduirait une couche de broker avec état à exploiter, sécuriser et payer, en plus de la facture Databricks existante. Zerobus Ingest était la seule option qui permettait des écritures directes dans les tables Delta à partir du worker existant sans ajouter de couche de broker. Une fois qu'ils ont fait les calculs, le choix était évident. Beusa a vu le mur se dresser, a fait ses calculs et a changé de cap avant de s'y heurter.
Un accès direct au lakehouse, sans ajouter de couche de broker
Zerobus Ingest est une API d'écriture directe spécialement conçue pour les sources de données opérationnelles telles que l'IoT, la télémétrie et les flux de clics, où les données doivent arriver en continu et à grande échelle dans des tables Delta, avec une latence de quelques secondes. La migration n'a nécessité qu'un seul changement : remplacer l'appel d'API SQL Statement par le Endpoint gRPC Zerobus. Même worker .NET 9. Mêmes abonnements MQTT. Même traitement des payloads Sparkplug B et JSON. Aucune configuration d'appareil modifiée.
« Nous n'avons pas eu à réécrire le worker, nous n'avons pas changé les brokers en amont et nous n'avons touché à aucune configuration d'appareil », a expliqué Fornicola. « Nous avons remplacé le chemin d'écriture, redéployé et vu la courbe des coûts chuter. »
Le coût de l'ingestion, qui était d'environ 689 DBU par Go en utilisant l'API SQL Statement, a chuté à environ 0,29 DBU par Go avec Zerobus, soit une réduction de trois ordres de grandeur pour la même charge de travail, les mêmes charges utiles et les mêmes tables Delta en aval. Beusa a également évité de mettre en place une couche de broker de streaming distincte, éliminant ainsi toute une catégorie d'infrastructures avec état.
Aujourd'hui, plus de 6 000 appareils Stream des données de télémétrie à 1 Hz sur environ 250 assets distants dans un lakehouse central, avec une latence de bout en bout d'environ trois secondes entre le capteur et la table Delta interrogeable, régie par Unity Catalog et prête à l'emploi dès son écriture.
Des économies à la maintenance prédictive pour monter en charge
La réduction des coûts a justifié la migration, mais le principal avantage a été la possibilité de monter en charge sans casse-tête opérationnel. Aujourd'hui, Zerobus Ingest traite sans effort environ 22 millions de lignes de télémétrie par jour sans aucune maintenance, offrant à l'équipe une pile simplifiée et une solution d'avenir rentable. La télémétrie à haute fréquence alimente désormais de l’analytique interfonctionnelle pour la direction des Opérations, la gestion de flotte, le Data Engineering, ainsi que les contrôles et l'automatisation. Les décisions qui reposaient auparavant sur l'intuition ou des rapports obsolètes sont désormais pilotées par des données unifiées presque en temps réel.
"Notre historien est un excellent système d'enregistrement de ce qui s'est passé sur un équipement", a déclaré Fornicola. "Mais pour répondre aux questions que l'entreprise se pose réellement — sur l'ensemble des flottes, des bassins et des événements de maintenance — nous avons besoin de ces données dans le lakehouse, jointes à tout le reste. Zerobus est ce qui rend cela économiquement viable à notre Monter en charge."
La nouvelle architecture offre également à Beusa une voie claire pour faire progresser sa stratégie de maintenance grâce à une progression de maturité définie :
Aujourd'hui — Maintenance conditionnelle : la maintenance est déclenchée par les conditions de fonctionnement actuelles et l'état observé de l'équipement — c'est mieux que des intervalles fixes, mais cela reste réactif à ce qui se passe sur le moment.
En cours — Maintenance prédictive : Avec la télémétrie à haute fréquence désormais dans le lakehouse, ainsi que l'historique de maintenance, Beusa entraîne des modèles pour prévoir la durée de vie utile restante de chaque asset. Dans la fracturation hydraulique, la défaillance des composants à forte usure suit une courbe influencée par des dizaines de variables opérationnelles — pression, débit, propriétés des fluides, cycles, etc. La modélisation de ces relations permet à l'entreprise d'allouer le temps de maintenance en fonction de la trajectoire de l’état réel de chaque asset plutôt que d'un calendrier fixe.
Prochaine étape — La maintenance prescriptive : une fois que la couche prédictive arrive à maturité, l'objectif est de passer de la prévision des pannes à la recommandation d'actions, en conciliant automatiquement les pannes prévues avec les plannings de la flotte, l'inventaire des pièces, la disponibilité des équipes, la météo et d'autres contraintes opérationnelles.
À mesure que la flotte se développe, l'économie unitaire de l'ingestion ne constitue plus un frein aux données pouvant être capturées ni à ce que l'entreprise peut en attendre.
"L'enseignement que nous en avons tirée, c'est que toutes les migrations ne doivent pas forcément permettre d'économiser de l'argent pour être rentables ; parfois, l'objectif est de réduire la charge opérationnelle ou d'améliorer la latence, et parfois les deux", a noté Fornicola. “Zerobus Ingest nous a fait économiser beaucoup d'argent, a simplifié notre stack et nous a engagés sur une voie d'avenir gérée. C'est rare."
Pour Beusa, Zerobus Ingest a transformé un compromis architectural difficile en une évidence. Les données transitent du site du puits vers le lakehouse en quelques secondes, les ingénieurs n'ont plus à se soucier du coût de chaque enregistrement écrit et l'entreprise peut passer plus rapidement du signal opérationnel à l'action opérationnelle.
