Siemens に学ぶ：データレイテンシを“数時間→数秒”へ、インフラコスト半減の実践

データインフラの未来は、その構成要素の複雑さではなく、いかに効率的に柔軟でリアルタイムかつインテリジェントなシステムを、より少ないリソースとオーバーヘッドで構築できるかによって評価されるだろう。

工場内のIoTデバイスや都市インフラのセンサーから、ユーザーの操作ログ、エネルギー消費データまで、情報は通常収集された後、個別のシステムにサイロ化されてしまいます。多くの企業がデータフローを統合しようと、「メダリオンアーキテクチャ」と呼ばれる構成を導入しています。これは、生データのためのブロンズ層、整形・強化済みデータのためのシルバー層、分析出力のためのゴールド層という構造です。しかし、このようなアーキテクチャは多くの場合、オフラインバッチ処理に依存しており、パフォーマンスが遅く、構造が複雑で、保守も困難です。そのため、リアルタイム性が求められるビジネスには適さないことが多いのです。

この課題は、ドイツを拠点とするテック企業 Hivemind にとって明確なチャンスとなりました。Hivemind は、エネルギー、製造、インフラ業界におけるインテリジェントでデータ駆動型の変革を支援することを専門としています。彼らは、従来の「スケジューリング + ETL + データ着地」という枠組みから脱却し、新たなストリーミング・リアルタイム・統合型のデータインフラを構築することを決断しました。このアプローチは、シーメンスをはじめとする複数の大手クライアントで既に成功裏に導入されています。

アーキテクチャ設計

Hivemind は、このデザインパターンの実用性を複数のプロジェクトで実証してきました。ここでは、このアーキテクチャがどのように機能するかを説明するため、都市のEV充電ネットワークを例に取り上げます。

ブロンズ層：生のストリーミングデータの取り込み

複数メーカーの充電ステーションが Kafka を通じてリアルタイムに生のメッセージを送信します。データフォーマットは統一されておらず、フィールドも異なれば、単位（例えば温度が華氏か摂氏か）も異なる場合があります。この生データはディスクに保存されたり、事前処理されることなく、直接 RisingWave に取り込まれ、ストリーミング型のブロンズ層を構成します。

すべてのデータポイントは忠実性を保持したまま下流で処理可能となり、トレーサビリティ、監査性、リプレイの観点で有利です。

シルバー層：SQL によるリアルタイムな統合・クリーニング・データ強化

シルバー層の目的は、しばしば未加工でバラバラなデータを標準化・構造化し、実用的な情報へと変換することです。従来の手法では、Spark バッチジョブを定期的に起動してデータを整形していました。Hivemind の手法では、これを RisingWave がリアルタイムで処理します。

複雑なコードを書く代わりに、エンジニアは SQL クエリを記述します：

• フィールド名の統一（例：temp_c, temperature_f → temperature_c）
• 単位の変換による標準化
• 欠損フィールドの補完（例：緯度・経度から住所へ変換、天気情報の付加）
• 無効なデータのリアルタイムフィルタリング

これにより、エンジニアは「スケジューリングロジック」ではなく「ビジネスロジック」に集中できます。クリーニングルールは読みやすく、保守性が高く、ホットアップデート可能なため、システムの複雑性を大幅に軽減します。

ゴールド層：リアルタイム集計・洞察・配信 — 単一ロジックで多用途対応

ゴールド層では、主に集計処理とインサイトの生成を担います。EV充電ネットワークのシナリオにおいては、以下のような分析が可能です：

• 各充電ステーションごとの1時間あたりの充電量
• ピーク使用時間帯
• 異常にエラー率が高いデバイスの検出
• 都市内で最も電力網に負荷がかかっている地域の特定

RisingWave のマテリアライズドビューによって、これらのメトリクスはすべてリアルタイムで生成されます。バッチによる集計や中間キャッシュレイヤーは不要です。生成されたマテリアライズドビューの結果は以下のように利用できます：

• ダッシュボード用の可視化プラットフォームへ直接供給
• オフライン分析のために Iceberg テーブルへ同期
• Kafka トピックへ配信し、下流システムによるサブスクリプション処理
• PostgreSQL などの OLAP システムに格納し、BI クエリ対応

このように、ゴールド層は「ストリーミングの成果物」であり、「バッチ処理の産物」ではありません。

ソリューション選定

選定フェーズにおいて、Hivemind は複数のリアルタイム処理ソリューションを評価しました。Apache Flink、Kafka Streams、Spark Structured Streaming、その他主流の ETL プラットフォームも対象に含まれていました。しかし、多くのツールは以下の理由で不採用となりました：

• システムが重すぎる
• 導入・運用が複雑
• 学習コストと保守コストが高い

最終的に選ばれたのは RisingWave でした。RisingWave は標準の PostgreSQL 構文をサポートする分散型ストリーミングデータベースであり、ストリーミングデータの SQL 処理に加え、マテリアライズドビュー、ストリーム集約、複数の入力と出力をネイティブにサポートしています。この点が、メダリオンアーキテクチャの3層構造に非常に適していました。

さらに重要なのは、**「リアルタイム計算 + リアルタイム保存 + マルチターゲット配信」**という組み合わせにより、エンタープライズ向けのデータプラットフォーム導入時の複雑性を大幅に簡素化できる点です。これにより、Hivemind は運用可能・クエリ可能・コスト効率に優れたモダンデータシステムを、最小限の時間と労力でクライアントに提供可能となっています。

シーメンスにおける成功事例

Hivemind は、このストリーミング型メダリオンアーキテクチャを複数の大手クライアントに対して展開しており、その中でも代表的な事例がシーメンス社です。

シーメンスのプロジェクトでは、数千の現場デバイスやセンサーからデータが収集されていました。従来のシステムでは、毎晩のバッチ処理によってデータの同期やクレンジングを行っており、これによって：

• 処理パイプラインが長くなる
• レイテンシが高まる
• インフラコストが増大する

という問題を抱えていました。すべてのロジックを RisingWave に移行したことで、次のような即時的な改善が得られました：

• データのレイテンシが「数時間」から「数秒」へ劇的に短縮
• 複雑なスクリプトによるクレンジング処理が、SQL ルールに置き換えられ、保守コストが大幅に低減
• 専用のスケジューリングクラスタや中間データレイヤーが不要になり、インフラリソースが50%以上削減
• マテリアライズドビューを用いた直接可視化により、ビジネス部門がリアルタイムで意思決定可能に

加えて、このアーキテクチャは柔軟性と可搬性も兼ね備えています。クラウド環境でもオンプレミス環境でも稼働できるため、企業が求めるセキュリティ・コンプライアンス・運用制御といった要件にも完全に対応できます。

まとめ

Hivemind の強みは、データベースを開発すること自体ではありません。むしろ、エンジニアリングの観点から、エンタープライズのデータアーキテクチャにおけるボトルネックを的確に把握し、解決策を構築する能力にあります。RisingWave を活用することで、よりシンプルで、リアルタイム性が高く、制御性にも優れたソリューションを生み出したのです。

このアプローチは、単に新しいツールを組み合わせたものではありません。これは、データアーキテクチャにおける根本的なパラダイムシフトを意味します：
「オフラインからリアルタイムへ」「複雑なスクリプトからSQLへ」「固定的なスケジューリングから継続的なストリーミングへ」「分断されたスタックから統合型ソリューションへ」

RisingWave はこのストリーミング型メダリオンアーキテクチャにおける強力なエンジンを提供していますが、Hivemind はそれを実現可能な形で企業に届けるパートナーであり、実際の導入現場において成果を出しています。

最終的に、データインフラの未来は構成の複雑さではなく、より少ないリソースとオーバーヘッドで、いかに柔軟かつリアルタイムでインテリジェントなシステムを構築できるかによって評価されるのです。