車両計測データの保存と分析に革命を: Databricks上で実現するメルセデス・ベンツのペタバイト規模ソリューション

サマリー：

コネクテッドカーの台頭により、自動車業界では時系列データが爆発的に増加しています。数百もの電子制御ユニット (ECU) が、車載ネットワークを通じて高頻度 (1Hz～100Hz) でデータを継続的にストリーミングします。このデータは予測分析とイノベーションにおいて大きな可能性を秘めていますが、ペタバイト規模で知識を抽出することは、技術、財務、持続可能性の面で大きな課題をもたらします。

このブログ記事では、大規模な時系列データに特化した、新しい階層的セマンティックデータモデルを紹介します。最新の機能 (例:Databricks Intelligence Platformによって導入されたliquid clustering)は、スケーラブルでコスト効率の高い分析を可能にし、生の自動車計測データを、車両開発、パフォーマンスチューニング、予測メンテナンスを推進する実用的なインサイトに変換します。

さらに、Mercedes-Benz の実世界のデータに基づいたベンチマークを共有し、主要な業界のユースケースにおけるパフォーマンスを評価するために、最新のデータ最適化戦略を比較します。

はじめに

自動車業界における時系列分析は、単なる数値計算ではありません。それは、道路を走るすべての車両の脈拍を読み取るようなものです。エンジンの微妙な振動から、自動運転システムの瞬時の判断、さらにはドライバーと車両のインタラクションに至るまで、各データポイントがストーリーを物語っています。これらのデータポイントがトレンドやパターンにまとまることで、車両開発に革命をもたらし、安全機能を強化し、ダッシュボードに警告灯が点灯する前にメンテナンスの必要性を予測することさえ可能にするインサイトが明らかになります。

しかし、この膨大なデータ量は大きな課題となっています。何百ものECUを搭載した現代の車両は、大量の時系列データを生成します。この豊富な情報を収集・保存することは極めて重要ですが、真の課題、そして好機は、その力を活用して単純なレポーティングから、ML & AIを用いた先進的な予測分析へと移行することにあります。

この課題の中心にあるのは、時系列データを表現するための、明確に定義されたユースケースと新たなユースケースの両方をサポートする、普遍的に適用可能で、効率的かつスケーラブルなモデルの必要性です。このニーズに応えるため、自動車の時系列分析の複雑さに対応し、生の測定データを戦略的資産へと変換する、新たな階層的セマンティックデータモデルを導入します。

このデータモデルを開発するにあたり、3つの重要な側面に焦点を当てました。

1. コスト効率と拡張性に優れたデータアクセス: データモデルは、時系列データ分析における一般的なクエリパターンをサポートし、大規模データセットの迅速かつリソース効率の高い処理を可能にするように設計されるべきです。
2. ユーザビリティ: データ実務者だけでなくドメイン専門家にとっても使いやすいことが重要です。これにより、規模にかかわらず、クエリの作成に何時間も費やすことなく、データを簡単かつ直感的に扱って、すばやくインサイトを得ることができます。
3. データの発見可能性&データ ガバナンス: 数千から数百万に及ぶさまざまなシグナルとコンテキスト メタデータを含む時系列データについて、データモデルを最小化することがガバナンスと保守性のために不可欠です。任意の数のカーフリートのデータを Unity Catalog のいくつかのテーブルに簡単に登録でき、ユーザーは信頼できるデータを安全に見つけ、アクセスし、共同で利用できます。

ドイツのシュトゥットガルトに本拠を置く最大級の高級車メーカーの1社である Mercedes-Benz AG との協力のもと、ASAM 標準に基づいてデータモデルを強化し、Mercedes-Benz が Mercedes-Benz Operating System (MB.OS) の能力を活用して最も魅力的な車を開発できるよう支援します。電気自動車の航続距離と効率性で新たな基準を打ち立てたメルセデス・ベンツのコンセプトカー「Vision EQXX」のように、私たちも最先端技術を用いて、分析のパフォーマンスと効率をまったく新しいレベルに引き上げています。

このブログ投稿では、効果的なデータ分析のユースケースと実世界のデータを使って、さまざまなセットアップにおける拡張データモデルの機能をご紹介します。さらに、さまざまな最適化戦略に関する科学的な研究を行い、Z-Ordering と Liquid Clustering のデータレイアウトについて体系的なベンチマークを実施しました。

3つの重要な側面に対処するための階層的セマンティック データ モデル

このデータモデルは、数万の信号からなる時系列データを単一のテーブルで表現でき、コンテキストメタデータの階層的表現を含んでいます。したがって、このモデルには次のような利点があります。

1. 効率的なフィルタリング: 階層構造により、複数の次元にわたる迅速なフィルタリングが可能になり、アナリストは検索範囲を素早く絞り込むことができます。
2. セマンティックな関係: サンプルとコンテキスト メタデータ間のセマンティックな関係を組み込むことで、このモデルはより直感的で強力なクエリ機能を容易にします。
3. スケーラビリティ: モデルの階層的な性質により、データ量がペタバイト規模に増大しても効率的なデータ編成がサポートされます。
4. コンテキストの統合: セマンティック レイヤーにより、コンテキスト メタデータのシームレスな統合が可能になり、分析の深さが向上します。

コアデータモデル

コアモデルは、時系列データとコンテキストメタデータを効率的に表現する5つのテーブルで構成されています（ER図については図1を参照）。モデルの中心となるのはsamplesテーブルです。このテーブルには、container_idとchannel_idという2つの識別子列を持つ、ナローフォーマットの時系列データが含まれています。container_id は時系列オブジェクトのコレクションに対する一意の識別子として機能し、一方 channel_id はそのコンテナ内の各時系列 (またはチャネル) を一意に識別します。この構造により、基になる時系列データの分散分析が可能になります。

自動車の分野では、コンテナには、テスト走行中に車両のデータロガーによって記録され、単一のファイルに保存された、事前に定義されたチャネルが含まれます。しかし、サイズの制約によって1回の走行の計測が分割された場合、複数の計測ファイルを1つのコンテナにグループ化できます。このコンセプトは、連続的な時系列データ ストリーム（IoT デバイスなどからの）にも適用されます。この場合、コンテナの境界は、時間（1 時間ごと、1 日ごとなど）や、製造工程やバッチに基づいてストリームを分割するといったプロセスの知識によって定義できます。

すべてのサンプルデータはランレングス符号化（RLE）を使用して保存され、同じ値を持つ連続するサンプルは、開始時刻（「tstart」）、終了時刻（「tend」）、記録値で定義される単一の行にマージされます。終了時刻は、その値を含まず、次の値への移行を示します。RLEは、値をバケット化してヒストグラムを計算したり、期間 (tend - tstart) を合計したりするなど、効率的な分析を容易にする単純な圧縮方式です。各行は container_id、channel_id、およびアクティブなタイムフレームによってインデックス付けされます。このコアサンプルテーブルは、ストレージサイズを最小化してクエリのパフォーマンスを向上させるために、シンプルな構成になっています。

サンプルテーブルに加えて、コンテキストメタデータを表す 4 つのテーブルがあります。

• 「container_metrics」と「container_tags」は、指定された「container_id」によってインデックスが作成されます。
• 「channel_metrics」と「channel_tags」のメタデータは、対応する「channel_id」によってさらに識別可能です。
• 両方のメトリクステーブルには静的スキーマがあり、クエリのプルーニングに役立つ貴重な情報が含まれています。
• 両方のタグテーブルは、あらゆる種類のメタデータを保持できる単純なキーと値のペアのストアとして使用されます。

一部のメタデータは測定ファイルから直接抽出できます。また、リンクされたコンテナやシグナルにコンテキストを付与するために、外部のメタデータソースからタグをエンリッチすることも可能です。

メルセデス・ベンツでの実装

ASAM（オートメーションおよび計測システムの標準化団体）コミュニティのメンバーとして（2025年8月時点）、メルセデス・ベンツは長年にわたり、収集した計測データを分析するためにさまざまな技術を活用してきました。Databricksとの協業を通じて、私たちは前述の時系列データモデルがMercedes-Benzの車両開発をサポートする上で、計り知れない可能性を秘めていることを認識しました。その結果、車両開発の専門知識を活用し、ASAM MDF 標準に基づいてデータモデルを強化しました (図 2 参照)。私たちは、開発車両から得られた本番測定データを提供し、実データ分析のユースケースを適合させました。これにより、私たちはデータモデルのコンセプトを検証し、車両開発プロセスと品質の向上におけるその実現可能性を実証することができました。

ここからは、この強化されたデータモデルがメルセデス・ベンツの開発車両の計測データでどのように機能するかを実証することに焦点を当てます。

• 「t_test_object_metric」と「t_test_object_tag」によるレベル1のフィルタリング: これら2つのテーブルには、テストオブジェクトレベルのビジネス情報と統計が格納されます（例:テスト車両）。例として、車両タイプ、車両シリーズ、モデル年式、車両構成などがあります。この情報によって、データ分析ユースケースの最初のステップで、何百ものテストオブジェクトの中から特定のオブジェクトに焦点を絞ることができます。
• レベル2フィルタリング: 「t_measurement_session_metric」&「t_measurement_session_tag」: これら2つのテーブルには、計測セッションレベルのビジネス情報と統計が格納されます。例として、テストイベント、タイムゾーン情報、測定の開始/終了タイムスタンプなどがあります。計測の開始/終了タイムスタンプは、2番目のステップのデータ分析スクリプトが、数百万の計測セッションの中から対象となる数百の計測セッションを絞り込むのに役立ちます。
• 「t_signal_metric」と「t_signal_tag」によるレベル3フィルタリング: これら2つのテーブルには、シグナルキーレベルでのビジネス情報と統計が格納されています。例には、車速、道路の種類、気象条件、ドライブパイロット信号などが含まれます。データ分析スクリプトは、最終ステップでこの情報を活用し、利用可能な何千ものシグナルの中から、基になるクエリに関連するシグナルを特定します。
• 測定信号データテーブルに対する分析スクリプト: 実際の分析ロジックは、テスト車両から収集された時系列データを格納する測定信号データテーブルで実行されます。しかし、上記の 3 つのレベルのデータフィルタリングを適用すると、通常、処理と分析が必要になるのは元の生時系列データのほんの一部だけです。

メタデータテーブルを操作するためのメルセデス・ベンツのユースケースの例

コアメタデータとして異なるレベルのメトリックテーブルとタグテーブルを導入することで、Mercedes-Benz の既存のソリューションと比較してデータ分析のパフォーマンスが大幅に向上しました。コアメタデータが分析パフォーマンスをどのように向上させるかを説明するために、自動レーンチェンジ (ALC) システムの準備状況検出を例として使用します。

Mercedes-Benz innovation で強調されているように、ALC 機能は、アクティブステアリングアシストを備えたアクティブディスタンスアシスト・ディストロニックの不可欠な要素です。前方をより低速の車両が走行している場合、車線が検出され十分なスペースがあれば、時速 80～140 km の速度域で車両が自ら車線変更を開始し、完全に自動で追い越しを行うことができます。前提条件は、制限速度のある道路であること、そして車両に MBUX ナビゲーションが搭載されていることです。この高度なシステムでは、自動レーンチェンジを実行する際に、ドライバーによる追加の操作は必要ありません。これら 3 つの事前条件は、分析スクリプトが何千ものセッションから関連するセッションをフィルタリングするのに役立ちます。明確にするため、私たちの手法を論理的かつ順を追って説明します (図 3 を参照)。ただし、実際の実装は並行して実行できる点に注意することが重要です。

• 生成されたすべての計測セッションから、2025年7月7日から2025年7月11日までのテスト走行期間中のセッションをフィルタリングして、セッション グループ1を作成します。このステップでは、「t_measurement_session_metric」テーブルのmeasurement_first_data_point_timestamp列とmeasurement_end_data_point_timestamp列を使用して、車両の記録されたすべてのセッションの中から関連するセッションを特定します。
• セッション グループ1内でアクティブステアリングアシストが有効化されたセッションをフィルタリングして、セッション グループ2を作成します。このステップでは、「t_signal_metric」テーブルでmax_int_raw_value > 0（有効化されたアクティブステアリングアシストのシグナル整数raw値が1であると仮定）のセッションをチェックして、セッション グループ1から関連するセッションを特定します。
• セッション グループ2内で、車両が車線表示のある道路を走行しているセッションをフィルタリングして、セッション グループ3を作成します。このステップでは、「t_signal_metric」テーブルでmax_int_raw_value > 2（車線表示のある道路タイプのシグナル整数raw値が3であると仮定）のセッションをチェックして、セッション グループ2から関連するセッションを特定します。
• セッション グループ3内で、車速が80～140 km/hの範囲にあるセッションをフィルタリングしてセッション グループ4を作成します。このステップでは、「t_signal_metric」テーブルでmax_float_value >= 80またはmin_float_value <= 140のセッションをチェックして、セッション グループ3から関連するセッションを特定します。
• セッション グループ 4 内で必要なシグナル ID をフィルタリングします。このステップでは、pdu_name、link_name、vlan_id、および signal_name の組み合わせを使用して、関連するシグナルのシグナル ID を見つけます。
• セッショングループ4からフィルタリングされたシグナルIDと計測セッションIDを使用して、計測シグナルデータポイントテーブルを結合し、ALCシステムの準備状況を特定します。

実世界のデータとユースケースのベンチマークを通じた最適なデータレイアウトの選択

前述のデータモデルのパフォーマンスとスケーラビリティを実証するために、実世界の計測データとユースケースを体系的にベンチマークしました。ベンチマーク調査では、データレイアウトと最適化手法のさまざまな組み合わせを評価しました。このベンチマークは、次を最適化するように設計されました。

1. データレイアウトと最適化戦略: クエリのパフォーマンスを最適化するために、パーティショニングスキーム、RLE、非RLE、Z-Ordering、Liquid Clusteringなど、さまざまなデータレイアウトアプローチをテストしました。
2. スケーラビリティ: 私たちは、効率を維持しながら、増え続ける計測データの量に対応できるソリューションに焦点を当てました。
3. コスト効率: ストレージコストとクエリパフォーマンスの両方を考慮し、長期的なデータ保持と分析のための最もコスト効率の高いアプローチを特定しました。

ベンチマーク結果は、Mercedes-Benzにおける将来の計測データスキーマとフォーマットの選定に不可欠であるため、本番データと分析スクリプトを使用してさまざまなオプションを評価しました。

実際には、ごくわずかな最適化でさえも大規模な環境で大幅なコスト削減を実現でき、何千人ものエンジニアが安全かつコスト効率よくインサイトを抽出できるようになります。提案されたソリューションの効率性を検証するにはベンチマークが重要であり、システムに大きな変更が加えられた場合は、着実に繰り返す必要があります。

ベンチマークセットアップ

ベンチマークデータセットには、21台の異なるテスト車両からの計測データが含まれており、各車両には計測データを収集するための最新のカーロガーが搭載されています。このコレクションには車両1台あたり30,000から60,000の記録された信号が含まれており、分析のための幅広いデータポイントを提供します。データセットは合計40,000時間分の記録で、そのうち12,500時間は車両が稼働中（イグニッションオン）の状態でデータを取得したものです。このデータセットにより、さまざまな車両や動作条件下における自動車の挙動とパフォーマンスのさまざまな側面を研究することが可能になります。

ベンチマークの一環として、以下の4つの分析クエリカテゴリが実行されました。

1. シグナル分布分析 - 主要なシグナル（e.g. の1次元ヒストグラムを生成しました。車両速度）を使用してデータ分布と頻度パターンを評価します。
2. 信号の算術演算 - 基本的な計算を実行しました（例:減算、比率）を数個から数千の信号に対して。
3. テストケースの特定 – クエリは、データセット内の事前定義された運用シナリオ（特定の順序で発生する一連のイベントによって定義される）を特定し、検証します。
4. 自動レーンチェンジアシスタントシステムの準備完了検知 - このクエリは、基盤となる実際の時系列データにクエリを実行する前に、メタデータテーブルを広く利用します。

なお、このブログ投稿では、カテゴリ 1 と 4 の結果のみをご紹介します。他のカテゴリの結果も同等のパフォーマンスとなり、そこから新たなインサイトは得られないためです。

ソリューションのスケーラビリティをベンチマークするために、4つの異なるクラスターサイズを使用しました。メモリ最適化されたStandard_E8d_v4ノードタイプは、そのdelta cache機能と、コアメタデータを保持するためのより大きなメモリのために選択されました。Databricksランタイムに関しては、15.4 LTSが利用可能な最新の長期サポートランタイムでした。以前の調査で、DBUコストは高いものの、Photon機能の方がコスト効率が高いことが証明されたため、すべてのベンチマークでPhotonを利用しました。表1に、選択したDatabricksクラスタの詳細を示します。

表 1 ベンチマーク クラスタのセットアップ

ベンチマーク結果

ベンチマークは、データモデルの2つの主要バージョンで実行されました。最初のバージョンにはランレングス符号化（RLE）されたサンプルデータがありますが（「コアデータモデル」のセクションを参照）、2番目のバージョンではRLEを使用していません。さらに、データモデルの両方のバージョンに2つの異なるデータレイアウト最適化を適用しました。最初の最適化では、Hive形式のパーティショニングを使用して計測シグナルデータテーブルをmeasurement_session_id列でパーティション分割し、signal_id列にZ-Orderingテクニックを適用しました。2番目の最適化では、Liquid Clusteringを使用して計測シグナルデータテーブルをmeasurement_session_idとsignal_idでクラスタリングしました。

実行時のパフォーマンス

ベンチマーク対象のセットアップ間で絶対実行時間に大きな違いがあったため、結果を可視化するために、非RLE結果を用いたZ-Orderingに基づく相対実行時間を使用することにしました。一般的に、私たちが行ったすべてのテストにおいて、Liquid Clustering（緑色のバー）は、Hiveスタイルのパーティショニング+Z-Ordering（青色のバー）よりも優れたパフォーマンスを示します。頻繁に変化する信号のヒストグラムの場合、RLE 最適化により Z-Ordering のランタイムが約 60% 短縮されますが、Liquid Clustering のランタイム短縮は 10% 未満です。

2 番目のユースケースである自動レーンチェンジシステムの準備状況の検出において、RLE は Z-Ordering で実行時間を約 70%、Liquid Clustering で 50% 以上短縮しました。実証されたユースケースの全体的な結果は、RLE と Liquid Clustering の組み合わせがデータモデルにおいて最高のパフォーマンスを発揮することを示しています。

スケーラビリティ

ソリューションのスケーラビリティを評価するため、さまざまなクラスターサイズを使用して、静的なデータセットに対して4つすべての分析クエリを実行しました。実際、すべてのベンチマーク実行において、前回の実行と比較してクラスターサイズを2倍にしました。理想的には、完全なスケーラビリティを持つソリューションでは、クラスタ サイズが 2 倍になるごとにクエリの実行時間が半分になるはずです。しかし、技術的な制限により、完全なスケーリングが妨げられることがよくあります。

図 5 は、1 つのユースケースにおけるさまざまなベンチマーク設定での絶対実行時間 (秒) の結果を示していますが、他のすべてのユースケースでもまったく同じパターンが観察されました。参照線（黄色と青色の破線）は、2つの異なるベンチマークセットアップにおける実行時間の下限（完全なスケーリング）を表しています。示されたユースケースでは、クラスターサイズがX-SmallからLargeに増加するにつれて、実行時間は概してほぼ完全に減少します。これは、データモデルと最適化戦略がスケーラブルであり、追加のノードと処理能力の恩恵を受けていることを示しています。

それにもかかわらず、RLE Liquid Clusteringソリューション（青線）の実行時間は、Mediumクラスターサイズから完全なスケーリングの参照線から乖離し始めていることがわかります。この差は、Largeクラスタサイズではさらに顕著になります。ただし、RLE Liquid Clustering ソリューションの絶対実行時間は、RLE Z-Ordering のものよりも大幅に短いことに注意することが重要です。したがって、RLEリキッドクラスタリングソリューションは、大規模なクラスタサイズになるとベースラインの実行時間がすでに非常に短くなっているため、スケーラビリティの向上は鈍化すると予想されます。

ストレージサイズ

当社のベンチマークデータは、5 か月間のテスト期間にわたって 21 台の Mercedes-Benz MB.OS テスト車両から収集された、64.55TB の独自の MDF ファイルから生成されました。許容可能なストレージサイズを維持しながらクエリのパフォーマンスを最大化するために、以前の調査結果に基づき、Parquet ファイルに zstd 圧縮を使用し、DELTA ターゲットファイルサイズを 32MB に設定します。このシナリオでは、同じ物理ファイルに多くのシグナルが保存されるのを防ぐために、ファイルサイズが小さいことが望ましいです。これにより、選択性の高いクエリに対して動的ファイルプルーニングがより効率的になります。

すべてのデータレイアウトで、独自のMDFデータと同等のサイズのDeltaテーブルが作成されました（表2を参照）。一般に、rawファイル形式からDeltaテーブルへの圧縮率は、MF4ファイルのさまざまな特性に大きく依存します。基盤となるデータセットには、車両あたり最大 60,000 のシグナルが含まれており、その多くは値が変更されたときにのみ記録されたものです。それらのシグナルに対しては、RLEのような圧縮技術は効果がありません。継続的に記録される数千のシグナルしかない他のデータセットの場合、RAW の MDF ファイルと比較してストレージ サイズが 50% を超えて削減されることがわかりました。

私たちの結果は、Z-Orderedテーブルと比較してLiquid Clusteringテーブルのサイズが大幅に大きいことを示しました（RLEデータレイアウトでは+14%）。しかし、上記の実行時間パフォーマンスのベンチマーク結果を考慮すると、RLE Liquid Clusteringレイアウトで必要となる追加のストレージサイズは、その優れたパフォーマンスによって正当化されます。

表2 rawデータおよびさまざまなRLEデータレイアウトのストレージサイズ

まとめ

私たちはDatabricks Intelligence Platform上で、コネクテッドカーからのペタバイト規模の時系列データを効率的に保存・分析するために、階層的なセマンティックデータモデルを開発しました。コスト効率、拡張性、使いやすさ、強力なガバナンスを考慮して設計されたこのモデルは、生のテレメトリデータを実用的なインサイトに変える新たな可能性を開きます。

実世界のメルセデス・ベンツのデータを用いて、階層メタデータテーブルがマルチレベルのフィルタリングによって分析性能を向上させることを示しました。自動レーンチェンジ準備状況の例では、この構造によって関連するセッションとシグナルを迅速に特定でき、処理時間を大幅に削減しました。

ベンチマークの結果、ランレングスエンコーディング（RLE）とLiquid Clusteringを組み合わせることで、分析クエリのタイプを問わず最高のパフォーマンスが得られ、特に実行時間においてRLEとZ-Orderingの組み合わせを上回ることが明らかになりました。より多くのストレージが必要でしたが、クエリ速度が大幅に向上したことで、そのトレードオフは正当化されました。スケーラビリティ テストでは、データ量が増加しても高いパフォーマンスが維持されることが確認されました。

今後、Databricks チームは以下のソリューションを公開する予定です。1) Databricks Jobs を使用して MDF ファイルを新しく導入されたデータモデルに変換する方法、2) Unity Catalog でプライバシーとセキュリティを維持し、増大する複雑性に対応しながら、大規模なフリートやその他のアセットを含む複雑なデータセットを管理し、簡単に検出できるようにする方法、3) SQL や Python のバックグラウンドが豊富でないエンジニアが、データから効率的にインサイトを自分で得られるようにするためのフレームワーク。

要約すると、RLEとLiquid Clusteringを使用した階層的セマンティックデータモデルは、自動車の時系列分析のための強力で統制のとれたスケーラブルなソリューションを提供し、Mercedes-Benzでの開発を加速させ、より持続可能で効率的な未来に向けたデータ駆動型のコラボレーションを促進します。