Beusa Energyは、電動水圧破砕、移動式発電、配電、フ ィールドガス処理、工業生産にまたがる企業グループを擁し、30年にわたりエネルギー分野に破壊的革新をもたらしてきました。北米の厳しい環境で事業を展開し、数千のリモートアセットから高頻度のテレメトリを扱うBeusaは、当初、カスタムのMQTTおよびSQLソリューションを使用してDatabricksレイクハウスにデータを送信していました。しかし、爆発的に増加するデータ量に対し、GBあたりのコストは経済的にスケールできませんでした。この壁を事前に回避するため、Beusaは運用上の勢いを落とすことなく、シームレスにスケールし、ITのオーバーヘッドをなくし、データコストを削減できる新しいインジェストモデルを模索しました。
爆発的に増加するデータボリュームによって、カスタムSQLパイプラインの限界が明らかになります。
Beusa のデータ & AI チームが MQTT からレイクハウスへのブリッジを最初に構築したとき、Zerobus Ingest はまだ存在していませんでした。ある .NET 9 のワーカーサービスがフリート全体の MQTT ブローカーをサブスクライブし、JSON と Sparkplug B のペイロードを解析して、SQL Statement API 経由で Delta テーブルに書き込んでいました。これは迅速に導入されて安定的に稼働し、レイクハウスでのオペレーションについて、ビジネスで初めてほぼリアルタイムのビューを実現しました。課題は運用面ではなく、経済面にありました。デバイス数とデータ量が増加するにつれて、「SQL Statement API」パスの GB あたりのコストは目に見えて持続不可能になりましたが、チームは危機的状況に陥 る前にグラフでそれを確認できました。
"SQLステートメントAPIは優れたツールですが、高頻度の運用テレメトリ向けには設計されていませんでした" と、Beusa Energyのデータ&AIプラットフォーム担当ディレクターであるNick Fornicola氏は述べています。"これにより本番運用にこぎつけ、ユースケースを実証するための数ヶ月の猶予を得ることができました。しかし、ワークロードを把握したからには、それ専用に構築されたインジェストパスが必要でした。"
チームは2つのカテゴリの代替案を評価しました。1つはKafka互換インターフェースを持つマネージドMQTTブローカー（最も有名なのはHiveMQ）、もう1つはKafkaやAzure Event Hubsなどの従来のストリーミングブローカーから構造化ストリーミング経由でDatabricksにデータを供給する方法です。HiveMQの価格設定は、彼らの規模と成長軌道に合いませんでした。KafkaとEvent Hubsのパスでは、既存のDatabricksの請求に加えて、運用、保護、支払いを行うためのステートフルなブローカー階層を導入することになります。Zerobus Ingestは、ブローカーレイヤーを追加することなく、既存のワーカーからDeltaテーブルへの直接書き込みを可能にする唯一の選択肢でした。数字を計算してみると、迷う余地はありませんでした。Beusaは壁を予見し、計算を行い、ぶつかる前に進路を変更しました。
ブローカ ーレイヤーを追加することなく、レイクハウスへの直接パスを実現
Zerobus Ingestは、IoT、テレメトリー、クリックストリームなどの運用データソース専用に構築された直接書き込みAPIで、データを継続的かつ大規模に、数秒のレイテンシでDeltaテーブルに格納します。移行に必要な変更は、SQL Statement API 呼び出しを Zerobus gRPC Endpoint にスワップするという 1 点のみでした。同じ .NET 9 ワーカー。同じ MQTT サブスクリプション。Sparkplug B と JSON ペイロードの同一の処理。デバイス構成は変更されていません。
「ワーカーを書き換える必要も、上流のブローカーを変更する必要も、デバイス構成に一つも手を加える必要もありませんでした」と、Fornicola 氏は説明しました。"書き込みパスをスワップし、再デプロイし、コストカーブが下降するのを確認しました。"
SQL Statement APIパスではGBあたり約689 DBUかかっていたインジェストが、Zerobusでは約0.29 DBUまで低下しました。これは、同じワークロード、同じペイロード、同じダウンストリームDeltaテーブルでの3桁の削減に相当します。またBeusaは、個別のストリーミングブローカー層を立ち上げることを完全に回避し、ステートフルなインフラストラクチャという種類全体を排除しました。
現在、6,000台を超えるデバイスが、約250のリモートアセットから中央のlakehouseへ1 Hzでテレメトリをストリームしています。センサーからクエリ可能なDeltaテーブルまでのエンドツーエンドのレイテンシは約3秒で、Unity Catalogによって管理され、書き込まれた瞬間に使用できる状態になります。
コスト削減から大規模な予知保全まで
コスト削減によって移行は正当化されましたが、より大きな影響は、運用上の手間をかけずに規模の拡大を可能にしたことでした。現在、Zerobus Ingest はメンテナンスフリーで毎日約 2,200 万行のテレメトリを容易に処理しており、チームにシンプル化されたスタックと費用対効果の高い今後の道筋を提供しています。高頻度テレメトリは現在、運用リーダーシップ、フリート管理、エンジニアリング、制御および自動化といった部門を横断するアナリティクスにデータを提供しており、これまで直感や遅延したレポートに基づいて下されていた意思決定が、統合されたほぼリアルタイムデータに基づいて行われるようになりました。
「当社のヒストリアンは、機器で何が起こったかを記録するための優れた記録システムです」とフォーニコラ氏は述べました。「しかし、フリート、ベイスン、メンテナンス イベント全体にわたってビジネスで実際に発生する疑問に答えるには、そのデータをレイクハウスに取り込み、他のあらゆるものと結合させる必要があります。Zerobus が、当社の規模でそれを経済的に実現可能にしています。」
また、新しいアーキテクチャは、定義された成熟度の段階を経てメンテナンス戦略を推進するための明確な道筋を Beusa に示します：
現在 — 状態基準保全: 保守は現在の運用状況と観測された機器の状態によってTrigger。これは固定間隔よりも優れていますが、現在起こっていることに対しては依然として事後対応です。
進行中 — 予知保全: 高頻度テレメトリが保全履歴とともにレイクハウスに保存されるようになったことで、Beusaは各資産の残存耐用期間を予測するモデルをトレーニングしています。水圧破砕では、摩耗の激しいコンポーネントは、圧力、流量、流体特性、サイクルなど、数十もの操作変数の影響を受ける曲線に従って故障します。これらの関係をモデル化することで、企業は固定スケジュールではなく、各資産の実際の状態の軌跡に合わせて保全時間を割り当てることができます。
次のステップ — 処方的メンテナンス： 予測レイヤーが成熟したら、目標は障害の予測からアクションの推奨へと移行することです。これは、予測された障害と、フリートのスケジュール、部品在庫、乗員の空き状況、天候、その他の運用上の制約を自動的に照合することを意味します。
フリートが拡大しても、インジェストのユニットエコノミクスが、収集できるデータやビジネスがデータに求めることの制約になることはもはやありません。
「私たちにとっての教訓は、すべての移行がコスト削減につながる必要はないということです。運用上の負担軽減やレイテンシーの改善が目的の場合もあれば、その両方が目的の場合もあります」とフォルニコラ氏は述べた。「Zerobus Ingestのおかげで、コストを大幅に削減でき、システム構成も簡素化され、管理された将来への道筋が見えてきました。」珍しいですね。"
Beusa にとって、Zerobus Ingest は困難なアーキテクチャ上のトレードオフを、悩む必要のないものに変えました。データはウェルサイトからレイクハウスまで数秒で流れ、エンジニアは書き込まれるレコードごとのコストを心配する必要がなくなり、ビジネスはオペレーショナル シグナルからオペレーショナル アクションへのパスを高速化できました。
