车联网数据分析：大数据实时拯救生命，预防事故的关键

车联网数据分析需要注意什么？近实时分析数据平台和实际实时分析数据平台有什么区别？

车联网（IoV）是汽车行业与物联网结合的产物。车联网数据预计会越来越大，尤其是电动汽车成为汽车市场新的增长引擎。问题是：您的数据平台准备好了吗？本文向您展示了 IoV 的 OLAP 解决方案是什么样的。

车联网数据有何特别之处？

车联网的想法很直观：创建一个网络，以便车辆可以彼此或与城市基础设施共享信息。经常没有得到充分解释的是每辆车本身内部的网络。每辆汽车上都有一个称为控制器局域网 (CAN) 的网络，充当电子控制系统的通信中心。对于在道路上行驶的汽车来说，CAN 是其安全性和功能性的保证，因为它负责：

• 车辆系统监控：CAN 是车辆系统的脉搏。例如，传感器将其检测到的温度、压力或位置发送至 CAN；控制器通过 CAN 向执行器发出命令（例如调节阀门或驱动电机）。

• 实时反馈：传感器通过 CAN 将速度、转向角度、制动状态发送给控制器，控制器及时调整汽车以确保安全。

• 数据共享和协调：CAN 允许各种设备之间进行数据交换（例如状态和命令），因此整个系统可以更加高性能和高效。

• 网络管理和故障排除：CAN 密切关注系统中的设备和组件。它可以识别、配置和监控设备以进行维护和故障排除。

由于 CAN 如此繁忙，您可以想象每天通过 CAN 传输的数据量。在本文中，我们讨论的是一家汽车制造商，该汽车制造商将 400 万辆汽车连接在一起，每天必须处理 1000 亿条 CAN 数据。

车联网数据处理

将如此庞大的数据量转化为指导产品开发、生产和销售的有价值的信息是最有趣的部分。与大多数数据分析工作负载一样，这归结为数据写入和计算，这也是存在挑战的地方：

• 大规模数据写入：汽车中到处都有传感器：车门、座椅、刹车灯……此外，许多传感器收集多个信号。400 万辆汽车加起来的数据吞吐量达到数百万 TPS，这意味着每天有数十 TB。随着汽车销量的增加，这个数字仍在增长。

• 实时分析：这或许是“时间就是生命”的最好体现。汽车制造商从车辆中收集实时数据，以识别潜在的故障，并在发生任何损坏之前修复它们。

• 低成本的计算和存储：谈论巨大的数据量就很难不提及其成本。低成本使大数据处理可持续。

从 Apache Hive 到 Apache Doris：向实时分析的过渡

罗马一样，实时数据处理平台不是一天建成的。该汽车制造商过去依靠批量分析引擎（Apache Hive）和一些流式框架和引擎（Apache Flink、Apache Kafka）的组合来获得近乎实时的数据分析性能。直到实时成为一个问题时，他们才意识到自己如此需要实时。

近实时数据分析平台

这曾经对他们有用：

来自 CAN 和车辆传感器的数据通过 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 既快速又简单，无需复杂的配置和引入额外的组件。它支持多种数据摄取方法。例如，在本例中，数据通过 Stream Load 从 Kafka 写入 Doris，通过 Broker Load 从 Hive 写入 Doris。

• 数据分析：以 Apache Doris 为例展示其查询速度，跨表连接查询秒级返回千万行结果集。此外，它还可以作为统一的查询网关，快速访问外部数据（Hive、MySQL、Iceberg 等），因此分析师不必在多个组件之间切换。

• 计算和存储成本：Apache Doris 提供了 Z -Standard 算法，可以带来 3~5 倍的数据压缩比。这就是它如何帮助降低数据计算和存储成本。此外，压缩可以单独在 Doris 中完成，因此不会消耗 Flink 的资源。

一个好的实时分析解决方案不仅强调数据处理速度，还考虑整个数据管道并平滑其每一步。下面是两个例子：

1. CAN 数据的整理

在 Kafka 中，CAN 数据按照 CAN ID 的维度排列。然而，为了进行数据分析，分析人员必须比较来自不同车辆的信号，这意味着将不同 CAN ID 的数据连接到一个平面表中，并按时间戳对齐。从该平面表格中，他们可以得出用于不同分析目的的不同表格。这种转换是使用 Spark SQL 实现的，在基于 Hive 的旧架构中，这种转换非常耗时，而且 SQL 语句维护性高。而且，数据是每天批量更新的，也就是说只能获取到一天前的数据。

在 Apache Doris 中，他们只需要使用 Aggregate Key 模型构建表，指定 VIN（车辆识别号）和时间戳作为 Aggregate Key，并通过 定义其他数据字段 REPLACE_IF_NOT_NULL。有了 Doris，他们不必关心 SQL 语句或平面表，而是能够从实时数据中提取实时见解。

2、DTC 数据查询

在所有 CAN 数据中，DTC（诊断故障代码）值得高度关注并单独存储，因为它可以告诉您汽车出了什么问题。制造商每天都会收到大约 10 亿个 DTC。为了从 DTC 中捕获救生信息，数据工程师需要将 DTC 数据与 MySQL 中的 DTC 配置表关联起来。

他们以前的做法是每天将 DTC 数据写入 Kafka，在 Flink 中处理，然后将结果存储在 Hive 中。这样，DTC 数据和 DTC 配置表被存储在两个不同的组件中。这就造成了一个困境：10 亿行的 DTC 表很难写入 MySQL，而从 Hive 查询又很慢。由于 DTC 配置表也在不断更新，工程师只能定期将一个版本导入到 Hive 中。这意味着他们并不总是能够将 DTC 数据与最新的 DTC 配置相关联。

如前所述，Apache Doris 可以作为统一的查询网关。这是由其多目录功能支持的。他们将 DTC 数据从 Hive 导入 Doris，然后在 Doris 中创建 MySQL 目录以映射到 MySQL 中的 DTC 配置表。当这一切完成后，他们可以简单地连接 Doris 中的两个表并获得实时查询响应。

结论

这是一个实际的车联网实时分析解决方案。它专为超大规模数据而设计，目前正在支持一家每天接收 100 亿行新数据的汽车制造商，以提高驾驶安全性和体验。

构建适合您的用例的数据平台并不容易。我希望本文能帮助您构建自己的分析解决方案。 文章来源地址 https://www.toymoban.com/diary/system/571.html

到此这篇关于车联网数据分析：大数据实时拯救生命，预防事故的关键的文章就介绍到这了, 更多相关内容可以在右上角搜索或继续浏览下面的相关文章，希望大家以后多多支持 TOY 模板网！

原文地址:https://www.toymoban.com/diary/system/571.html

如若转载，请注明出处：如若内容造成侵权 / 违法违规 / 事实不符，请联系站长进行投诉反馈，一经查实，立即删除！