5分钟了解实时车联网，车联网（IoV)OLAP 解决方案是怎样的？

编者按，本文基于国外技术文档翻译和国内某top汽车大厂车联网大数据项目整合，脱敏编辑而成，如有同事发现有熟悉之处，请你闭嘴

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

01

车联网数据的特别之处

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

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

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

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

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

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

02

车联网数据处理

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

• 大规模数据写入：汽车中到处都有传感器：车门、座椅、刹车灯……此外，许多传感器收集多个信号。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 的资源。

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

2.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.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 亿行新数据的汽车制造商，以提高驾驶安全性和体验。

涤生大数据往期精彩推荐