编辑|保密
校对|秘密
互联网汽车(IoV)是汽车行业与物联网相结合的产物。预计互联网汽车数据规模将越来越大,尤其是当电动汽车成为汽车市场新的增长引擎。问题是:用户的数据平台准备好了吗?本文展示了互联网汽车的在线分析处理(OLAP)解决方案。
互联网汽车的理念很直观:创建一个网络,让汽车之间或与城市交通基础设施共享信息。通常没有充分解释的是每辆汽车的内部网络。互联网汽车连接的每辆汽车都有一个控制器区域网络(CAN),作为电子控制系统的通信中心。对于每辆行驶在道路上的汽车来说,CAN是其安全性和功能性的保证,因为它负责:
由于CAN如此繁忙,可以想象每天通过CAN传输的数据大小。本文讨论的是一家汽车制造商将400万辆汽车通过CAN连接在一起,每天必须处理1000亿条CAN数据。
将这些庞大的数据转化为指导产品开发、生产和销售的有价值信息是有趣的部分。与大多数数据分析工作负载一样,这归结为数据写入和计算,这也是存在挑战的地方:
就像罗马不是一天建成的那样,实时数据处理平台也不是一天建成的。一家汽车制造商过去依赖于批处理分析引擎(ApacheHive)和一些流框架和引擎(ApacheFlink、ApacheKafka)的组合来获得接近实时的数据分析性能。直到实时性成为一个问题,他们才意识到他们如此迫切地需要实时性。
下图是这家汽车制造商在过去的做法:
来自CAN和汽车传感器的数据通过4G网络上传到云网关,云网关将数据写入Kafka。然后,Flink处理这些数据并将其转发给Hive。通过Hive中的几个数据仓库层,将聚合的数据导出到。最后,Hive和MySQL为应用层提供数据,用于数据分析、Dashboard等。
因为Hive主要是为批处理而不是实时分析而设计的,所以可以在这个用例中看出它的不匹配。
这就是当他们添加实时分析引擎时所发生的事情:
与原有的基于Hive的平台相比,这个新的平台在以下三个方面更高效:
一个优秀的实时分析解决方案不仅强调数据处理速度,它还考虑到数据管道的所有方式,并使其每一步都变得平滑。以下是两个示例:
在Kafka中,CAN数据是按照CANID的维度来排列的。然而,为了进行数据分析,分析人员必须比较来自不同汽车的信号,这意味着将不同CANID的数据连接到一个平面表中,并根据时间戳进行对齐。从这个平面表中,他们可以为不同的分析目的派生出不同的表。这种转换是使用SparkSQL实现的,这在原有的基于Hive的体系结构中非常耗时,而且SQL语句的维护成本很高。此外,数据是每天批量更新的,这意味着他们只能获得一天前的数据。
在ApacheDoris中,他们所需要的只是用聚合密钥模型构建表,指定汽车识别号(VIN)和时间戳作为聚合密钥,并通过REPLACE_IF_NOT_NULL定义其他数据字段。使用Doris,他们不必处理SQL语句或平面表,而是能够从实时数据中提取实时见解。
在所有CAN数据中,故障诊断码(DTC)值得高度关注和单独存储,因为它可以告诉汽车出了什么问题。每天,制造商收到大约
本文地址:https://www.rixiy.com/article/921cb35f5d98d83629fc.html