大数据如何在实时中挽救生命:物联网数据分析有助于预防事故

时刻拯救生命的大数据力量:物联网数据分析在事故预防中的关键作用

 

互联网汽车(IoV)是汽车行业与物联网的结合产物。预计IoV数据将变得越来越多,特别是在电动汽车成为汽车市场新的增长引擎的情况下。问题是:您的数据平台是否为此做好准备?本文向您展示了IoV的OLAP解决方案。

 

IoV数据的特点是什么?

 

IoV的概念很直观:创建一个网络,使车辆能够相互或与城市基础设施共享信息。通常被忽略的是每辆车内部的网络。每辆车上都有一个被称为控制器局域网(CAN)的东西,它作为电控系统的通信中心。对于行驶在路上的汽车来说,CAN是其安全和功能的保证,因为它负责以下事项:

  • 车辆系统监控:CAN是车辆系统的脉搏。例如,传感器将它们检测到的温度、压力或位置发送到CAN;控制器通过CAN向执行器发出命令(如调节阀门或驱动电机)。 
  • 实时反馈:通过CAN,传感器将速度、转向角度和刹车状态发送给控制器,控制器及时对汽车进行调整,确保安全。 
  • 数据共享和协调:CAN允许各种设备之间进行数据交换(如状态和命令),从而使整个系统更加高效。
  • 网络管理和故障排除:CAN监视系统中的设备和组件。它用于维护和故障排除时识别、配置和监控设备。

可以想象,每天CAN传输的数据量是如此之大。在本文的案例中,我们谈论的是一家连接了400万辆汽车并每天处理1000亿条CAN数据的汽车制造商。

 

IoV数据处理

 

将庞大的数据量转化为有价值的信息,以指导产品开发、生产和销售,是非常重要的。与大多数数据分析工作负载一样,这归结为数据写入和计算,在这两个方面都存在挑战:

  • 规模化数据写入:汽车上到处都是传感器:门、座位、刹车灯等等…并且许多传感器收集多个信号。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的分析解决方案提供高查询延迟,这是一个多因素问题。首先,在处理具有10亿行的大表时,Hive比预期要慢。其次,Hive内部通过执行Spark SQL从一个层次提取数据到另一个层次,这可能需要一段时间。第三,在Hive需要与MySQL一起满足应用程序需求时,Hive与MySQL之间的数据传输也会增加查询延迟。

 

实时数据分析平台

 

当他们在图中添加实时分析引擎时,就会发生以下情况:

  与旧的基于Hive的平台相比,这个新平台在以下三个方面更加高效:

  • 数据写入:数据将快速且轻松地摄取到Apache Doris中,无需复杂的配置和额外的组件介入。它支持多种数据摄取方法。例如,在这种情况下,数据是通过流式加载从Kafka写入Doris,通过Broker加载从Hive写入Doris。
  • 数据分析:为了展示Apache Doris的查询速度,它可以在交叉表连接查询中在几秒钟内返回包含1000万行结果集。此外,它可以作为统一查询网关,快速访问外部数据(Hive、MySQL、Iceberg等),使分析人员无需在多个组件之间来回切换。
  • 计算和存储成本:Apache Doris使用Z-Standard算法,可以带来3~5倍的数据压缩比。这是它在数据计算和存储成本方面帮助降低成本的方式。此外,压缩可以仅在Doris中完成,因此不会消耗Flink的资源。

一个好的实时分析解决方案不仅强调数据处理速度,还考虑了数据管道的每个步骤并优化了其各个环节。以下是两个例子:

 

1. CAN数据的安排

 

在Kafka中,CAN数据是按照CAN ID的维度进行排列的。然而,为了进行数据分析,分析人员需要比较来自不同车辆的信号,这意味着需要将不同CAN ID的数据连接到一个平面表中,并按照时间戳对齐。从该平面表中,他们可以为不同的分析目的派生不同的表。在旧的基于Hive的架构中,这种转换耗时且SQL语句的维护成本高。此外,数据每天批量更新一次,这意味着他们只能获取到一天前的数据。

在Apache Doris中,他们只需使用聚合键模型构建表,将VIN(车辆识别号码)和时间戳指定为聚合键,并通过REPLACE_IF_NOT_NULL定义其他数据字段。使用Doris,他们无需关心SQL语句或平面表,而能够从实时数据中提取实时洞察力。

 

 

3. 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内部连接这两个表,并获得实时查询响应。

 

 

结论

 

这是一个真正的IoV实时分析解决方案。它是设计用于处理大规模数据的,并且现在正在支持一个每天接收到100亿行新数据的汽车制造商,以提高驾驶安全性和体验。

构建适合您用例的数据平台并不容易,希望这篇文章对您构建自己的分析解决方案有所帮助。

[Zaki Lu](https://www.linkedin.com/in/zaki-lu-99a06b148/)是百度的前产品经理,现为Apache Doris开源社区的DevRel。