リアルタイムで命を救うビッグデータ：IoVデータ分析が事故を予防するのを助ける

「命を救うビッグデータのリアルタイム活用：IoVデータ分析が事故予防をサポートする」

車載通信データ (Internet of Vehicles、IoV) は、自動車産業とIoTの融合から生まれたものです。特に電気自動車が自動車市場の新たな成長エンジンとなることで、IoVのデータはますます大きくなることが予想されます。そのため、あなたのデータプラットフォームはその準備が整っているのでしょうか？本記事では、IoVのためのOLAPソリューションについてご紹介します。

IoVデータの特徴は何ですか？

• パーセプトロンからアダラインまで – From the Perceptron to Adaline
• このAI論文は『プライバシー保護MAE-Alignと呼ばれる新しい事前トレーニング戦略を提案し、合成データと人間除去された実データを効果的に組み合わせる』というものです
• ‘製品およびエンジニアリングリーダーのための実践的なGenAI’

IoVのアイデアは直感的です。自動車同士や都市のインフラストラクチャと情報を共有するためのネットワークを作るというものです。しかし、しばしば説明が足りないのは、実際の車両内部のネットワークです。各車両には、電子制御システムの通信センターとして機能するコントローラエリアネットワーク（CAN）と呼ばれるものがあります。道路を走行する車にとって、CANは安全性と機能性の保証です。なぜなら、CANは以下の役割を果たしているからです。

• 車両システムの監視: CANは車両システムのパルスです。例えば、センサーは検出した温度、圧力、位置などをCANに送信し、制御装置はCANを介して実行エンティティにコマンド（バルブの調整や駆動モーターの調整など）を発行します。
• リアルタイムフィードバック: CANを介して、センサーは速度、ハンドルの角度、ブレーキの状態などを制御装置に送信し、安全性を確保するために車両をタイムリーに調整します。
• データの共有と調整: CANにより、各種デバイス間で状態やコマンドなどのデータ交換が可能になり、システム全体のパフォーマンスと効率が向上します。
• ネットワーク管理とトラブルシューティング: CANはシステム内のデバイスやコンポーネントを監視し、メンテナンスやトラブルシューティングのためにデバイスを識別、設定、監視します。

CANがこれほど忙しいと、毎日CANを通じて送信されるデータの量を想像することができます。この記事のケースでは、4百万台の車両を接続し、毎日1000億件のCANデータを処理する自動車メーカーについて言及しています。

IoVデータの処理

この巨大なデータサイズを、製品開発、生産、販売に役立つ価値ある情報に変換することこそが鍵です。ほとんどのデータ解析作業と同様に、これはデータの書き込みと計算に関わり、課題も存在します。

• 大規模データの書き込み: 自動車にはセンサーがあります。ドア、シート、ブレーキライトなどにセンサーが配置されています。さらに、多くのセンサーが複数の信号を収集します。4百万台の車両は、毎日数百万のトランザクションを生み出し、数十テラバイトのデータを生成します。自動車の販売が増えるにつれて、その数も増え続けます。
• リアルタイム解析: これは「時間こそが命」という言葉の具現化です。自動車メーカーは自社の車両からリアルタイムデータを収集し、潜在的な故障を特定し、損害が発生する前に修理します。
• 低コストの計算とストレージ: 巨大なデータサイズについての話をする際、コストも必要です。低コストならば、ビッグデータ処理を持続可能にします。

Apache HiveからApache Dorisへ：リアルタイム解析への移行

ローマのように、リアルタイムデータ処理プラットフォームは一日で構築されるものではありません。かつてこの自動車メーカーは、バッチ解析エンジン（Apache Hive）とストリーミングフレームワークおよびエンジン（Apache Flink、Apache Kafka）の組み合わせを利用して、ほぼリアルタイムのデータ解析性能を得ていました。彼らはリアルタイムが本当に必要だということに気づいたのは、リアルタイムが問題になった後でした。

ほぼリアルタイムデータ解析プラットフォーム

彼らが以前使っていた解析プラットフォームは以下のとおりです：　車載通信データと車両センサーからのデータは、4Gネットワークを介してクラウドゲートウェイにアップロードされ、データはKafkaに書き込まれます。その後、Flinkがこのデータを処理し、Hiveに転送します。Hiveのさまざまなデータウェアハウジングレイヤを通過した後、集約されたデータはMySQLにエクスポートされます。最終的に、HiveとMySQLがデータ分析やダッシュボード表示などのアプリケーションレイヤにデータを提供します。

バッチ処理に最適化されたHiveは、リアルタイムアナリティクスよりもバッチ処理に向いているため、このユースケースではその不一致が明らかになります。

• データの書き込み：巨大なデータサイズのため、FlinkからHiveへのデータ取り込み時間が明らかに長くなります。さらに、Hiveはパーティションの単位でしかデータの更新をサポートしていないため、一部のケースでは十分ではありません。
• データの分析：Hiveベースの分析ソリューションは、高いクエリ遅延を持ちます。これは複数の要因によるものです。まず第一に、Hiveは10億行の大きなテーブルを処理する際に、予想よりも遅くなります。第二に、Hive内部でデータはSpark SQLの実行によって一層から別の層へと抽出されるため、時間がかかる場合があります。第三に、HiveはMySQLと連携する必要があり、HiveとMySQL間のデータ転送もクエリ遅延に追加されます。

 

リアルタイムデータ分析プラットフォーム

 

リアルタイムの分析エンジンが組み込まれた場合、以下のようなことが起こります:

  旧Hiveベースのプラットフォームと比較して、新しいプラットフォームは以下の点で効率的です:

• データの書き込み：Apache Dorisへのデータ取り込みは迅速で簡単であり、複雑な設定や余分なコンポーネントの導入は必要ありません。さまざまなデータ取り込み方法をサポートしています。たとえば、この場合、データはKafkaからDorisにStream Loadを使って書き込まれ、HiveからはBroker Loadを使ってDorisに書き込まれます。
• データの分析：Apache Dorisのクエリの速度を例に示すと、テーブル結合クエリでも10万行の結果セットを数秒で返すことができます。また、Hive、MySQL、Icebergなどの外部データにクイックにアクセスできるため、統合されたクエリゲートウェイとしても機能し、分析者は複数のコンポーネント間を行き来する必要がありません。
• 計算とストレージのコスト：Apache DorisはZ-Standardアルゴリズムを使用しており、データの圧縮比を3〜5倍に高めることができます。これにより、データの計算とストレージのコストを削減することができます。さらに、圧縮はDoris内でのみ行われるため、Flinkのリソースを消費することはありません。

優れたリアルタイムの分析ソリューションは、データ処理の速度だけでなく、データパイプラインのすべてのステップを考慮し、スムーズにすることも重要です。以下に2つの例を示します:

 

1. CANデータの整理

 

Kafkaでは、CAN-IDの次元でCANデータが整理されていました。しかし、データ分析のためには、異なる車両の信号を比較する必要があったため、異なるCAN-IDのデータをフラットテーブルに連結し、タイムスタンプで整列する必要がありました。このフラットテーブルから、異なる分析目的に応じたさまざまなテーブルを導き出すことができました。このような変換は、古いHiveベースのアーキテクチャでは時間がかかり、SQL文の保守性も高くなりました。さらに、データは1日分のバッチ更新であり、1日前のデータしか取得できませんでした。

Apache Dorisでは、Aggregate Keyモデルを使用してテーブルを構築し、VIN（車両識別番号）とタイムスタンプをAggregate Keyとして指定し、他のデータフィールドをREPLACE_IF_NOT_NULLで定義するだけで済みます。Dorisを使用すると、SQL文やフラットテーブルの作成に気を使う必要はなく、リアルタイムのデータからリアルタイムのインサイトを抽出することができます。

 

 

3. DTCデータクエリ

 

すべてのCANデータの中で、DTC（診断トラブルコード）は車の問題を教えてくれるため、高い注目と別々のストレージが必要です。製造元は、毎日約10億件のDTCを受け取ります。DTCから重要な情報を抽出するために、データエンジニアはDTCデータをMySQLのDTC設定テーブルに関連付ける必要があります。

以前の方法は、DTCデータを毎日Kafkaに書き込み、Flinkで処理し、結果をHiveに格納することでした。これにより、DTCデータとDTC設定テーブルが2つの異なるコンポーネントに格納されました。これはジレンマを引き起こしました：10億件のDTCテーブルをMySQLに書き込むことは困難でしたが、Hiveからのクエリは遅かったのです。DTC設定テーブルも常に更新されていたため、エンジニアは定期的にそのバージョンをHiveにインポートするしかありませんでした。それはつまり、常に最新のDTC設定とDTCデータを関連付けることができなかったということです。

言及されているように、Apache Dorisは統合クエリゲートウェイとして機能することができます。これはマルチカタログ機能によってサポートされています。彼らはHiveからDorisにDTCデータをインポートし、その後、DorisでMySQLカタログを作成してMySQLのDTC設定テーブルにマップします。これが完了すると、Doris内で2つのテーブルを単純に結合してリアルタイムのクエリ応答を得ることができます。

 

 

結論

 

これはIoVの実際のリアルタイム分析ソリューションです。非常に大規模なデータに対応するために設計され、現在では毎日新たに10億件のデータを受け取る自動車メーカーの運転安全と体験の向上をサポートしています。自分のユースケースに適したデータプラットフォームを構築することは容易ではありませんが、この記事が皆さんの分析ソリューション構築のお手伝いになることを願っています。

[Zaki Lu](https://www.linkedin.com/in/zaki-lu-99a06b148/)は元Baiduの製品マネージャーであり、現在はApache DorisオープンソースコミュニティのDevRelです。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!