长安汽车：基于云器 Lakehouse 的车联网大数据平台建设

近年来随着智能汽车行业的迅速发展，数据也在呈爆炸式增长。长安大数据平台承接了长安在生产上大部分流量应用及日常生产业务应用。本文将分享长安汽车在车联网场景下大数据平台建设面临的一些挑战和具体落地的实践。

主要内容如下：

1. 背景介绍

2. 长安汽车面对的挑战

3. 改造前的架构和挑战

4. 改造后的架构介绍

5. 改造后的价值与效果

6. 总结及后续计划

01背景介绍“以前人们称汽车为配备电子功能的机械产品，到今天演变为具有机械功能的智能电子产品，这是一个非常大的转变。”—— 长安云器联合项目组石静猛

转变，源自产业的数字化转型。新能源汽车厂商正在用数字化技术打造差异性的竞争优势，关注点由发动机的制造逐渐趋向于基于数字化技术打造丰富的用户体验。

中国的汽车产业正在高速发展的过程中完成数字化升级，我国汽车产销总量连续15年稳居全局全球第一。在产销快速增长的同时，车企正在通过数字化提升乘用车产品的竞争力。

（图1：汽车产销总量及增长率）

数字化关系到车辆如何更好地应用，如何更好地跟人互动，与人们的生活打通，包括更广为人知的智能化自动驾驶、智能座舱等应用场景，以及不为人所知的汽车设计、生产制造过程，数字化正在重构汽车工业。

长安汽车面对的挑战

面对超大规模数据量和业务的飞速发展，长安大数据平台面临的挑战可以总结为三大方面，即成本高、用数难、运维烦。

1.成本高每天有 20+TB 的新增数据，一年就会接近 9PB 的规模。随着新能源车的比例越来越高，并且新能源车的数据要求全生命周期存储，可能要存储十年，整体下来，存储成本是累加的。业务依然在快速增长，第二年数字可能就会翻倍。在这样的数据量下，计算是超大规模的，即使是一个非常简单的场景如一个简单的 query，都可能会因为数据量庞大而计算困难。

2. 用数难

首先，查询分析慢，因为数据量大，查一天的数据都很难，更何况在很多场景中需要查多天的数据，比如取一辆车在几个月里的明细数据进行分析，将会是一个非常大的挑战。另外，实时数据加工比例非常低，因为数据量大，如果以传统方式对全量数据进行实时加工，成本会非常高。因此只能采用Lambda架构，其中除了一套 t+1 的离线链路，还要有一套实时链路处理一些重要数据。这带来的问题是，当业务新增需求时，或者做一个新的数据产品、处理一些新的信号时，需要从头开发整个链路，在实时链路上重新加入这些数据，开发链路会非常复杂，要跨多个组件、多个平台，除了Java，还需要 SQL 等等，开发门槛高，效率低。

3. 运维烦

Lambda 架构下，不同场景用不同的产品，这种多组件的架构非常复杂，运维困难。同时，性能瓶颈难以突破。另外，每年需要对平台链路进行一次优化升级，运维成本持续高涨。还存在存储空间报警，计算资源浪费的情况。03

改造前的架构和挑战

1. 改造前的架构

长安汽车大数据平台改造前的整体架构是典型的 Lambda 架构，分为实时和离线两部分。

实时链路

使用 Flink 对数据进行一些简单的加工，加工后的数据写到 Doris、ClickHouse或StarRocks 等分析型平台上。中间也包括一些HBase的应用。

离线链路

车上的数据实时接入 Kafka，再通过 Flink 实时消费写到 HDFS 的某个文件，写完之后，天级别的定时任务将这个文本文件加载成 Parquet 文件，再建成表，后面做 t+1 的分析处理，这就是整个离线的链路。

2. 挑战

首先，长安汽车面临着高 TPS+大吞吐的挑战，除了每天会有 22TB 以上的增长，实时吞吐的峰值也超过了每秒 500 万条，这一数字非常可观，并且数据量仍在快速增长。其次，很多 JSON 这种半结构化数据，信号列非常多，随着新能源车数据产品应用的场景越来越多，信号列增长非常快。另一方面，Lambda 架构下的实时化比例非常小，不到 10%，主要是离线加工。

改造后的架构介绍

针对上述挑战，我们对大数据平台进行了改造，将数据平台升级到一个更简洁高效的架构。如下图所示，整体上从之前的 Lambda 架构升级为了一体化的Kappa架构，并且从 t+1 加工变成了百分百全域数据实时加工。

平台的各种组件变成了一个组件，最终是一份资源、一个引擎，一种开发语言 SQL，支持不同的 workload，包括实时的加工、离线的加工、实时分析、ad-hoc 查询等等。05

改造后的价值与效果

1. 解决成本高问题

（1）存储成本

以某张表一天的数据量为例，将同一份数据（数据条数和内容完全一致）导到两个平台上来进行对比。在旧的平台上，HDFS存储，单副本大约为2.8T，而新平台，COS存储只有831G。等价换算后，每百亿条在旧平台上为373G，而新平台是130G。存储节省了65%。这还只是单副本的对比，如果是两副本，降低的比例就更高了。

实现这一改进的关键措施如下：

在Parquet存储上自研了更多编码优化，对半结构化数据自研map格式存储，压缩率比JSON更高，查询效率也更高，在存储上对数据进行了行级+信号级的二级去重。

车联网信号数据常存在信号跳变的情况，而去重的基本原则就是不丢失任何跳变信息。乘用车进行行级去重之后，存储降低 60% 左右。新能源车，采用行级+信号级去重，存储降低 38% 左右。在存储降低之后，下游的计算性能也可以得到极大提升，从而节省计算资源。去重前的原始数据可以归档，进一步降低成本。（2）计算成本

计算成本方面，在同样的数据量、同样的加工逻辑、得到同样的结果，并保证结果正确的前提下，从T+1集中时间计算，分摊成近实时增量计算，比如5分钟加工一次，一天共 288 次，将全天的资源累加起来，与之前天级的计算资源相比较，计算口径为CU时=8core*1hr。可以看到，Spark用了14个CU时，而新平台仅用了3.5个CU时。我们将Spark的资源再增加一倍，把系统负载因子乘以50%，之后与新平台对比，仍然会有50% 左右的计算成本降低。说明同样的数据，得到同样的结果，一样的加工逻辑，将离线计算变成实时计算的基础之上，仍可以获得大幅的计算成本降低。

这里需要说明的是，以上对比都是基于真实生产的 ETL 加工任务，这其中用到的核心技术就是增量计算。

2. 解决用数难问题

（1）提升查询性能

先从查询性能上来说，之前查询数据非常慢。这里提取了 8 个子场景，分别代表了不同的业务价值，比如某些签到信号分析的查询、智慧能耗的分析、云云诊断仪、智能诊断等等。还包括一个创新场景，即跨天查询的场景。

从上图中可以看到，平均性能有三倍的提升。规模越大，表现越好。尤其是跨天场景，以前跑不出来，而现在 5 分钟左右就可以跑出来。查询数据量达到每天 700 亿条，其中跨天查询，三天 2000 亿条数据。实现这一提升，归功于查询 plan 的优化，ShareEverything 架构下更高效的读写性能，以及算子优化、向量执行、shuffle 加速等一系列改进。（2）实现低成本下的 100% 数据实时

用数难中第二个问题是实时的比例低，之前业务想开发一个有实时要求的数据产品，整个过程是非常痛苦的。而现在变成了百分百数据实时，之后要做一个数据产品，只要从这个数仓平台上拿数据、拿结果，直接做开发即可，效率大幅提升。要做到百分百数据实时，低成本是关键，虽然用 Flink 也可以但成本高昂难以接受。上图展示了全链路实时加工的流程。其中有一个 IGS：Ingestion Service，是读写分离的一个独立的服务，能够支持结构化/半结构化的数据实时写入，数据会落到业务库中对应的分区表里，然后对数据做去重，基于去重后的数据做加工，每条链路都是实时加工，并通过增量计算技术来实现，因此成本比较低。同时对延迟数据也能进行加工，因为能够识别出延迟数据落在哪个业务分区，增量计算只算那个分区相关的结果即可。整个数仓建成了一个实时的数仓，支撑车企的各项业务应用。这里以一个典型的业务场景为例，即车联网数据质量分析。以前的平台实现困难，因为要接入一天上千亿条数据，对里面的信号进行分析，一条数据里面可能有几十上百个信号，要把信号 explode 出来，等于要面对上千亿条数据再乘以几十倍的一个数据量来进行分析。传统的方式是根本算不出来的，现在变成了近实时的方案，用增量的方案即可实现。

上图是增量计算的示意图。每次处理 Delta 数据，有两种模式，一个是增量计算 MV，另一个是 table stream 的方式。Table stream 方式也支持多分支，可以在一个表上创建多个，然后做 ETL 加工、监控等等，并且不会增加存储成本，因为底层都是 Meta 支持的，只需要做好应用即可。增量计算 MV，指的是可以用全量的语义写逻辑，系统内部自动地以增量的方式计算，而且会自动刷新，不需要配置调度系统自动触发，所以整个开发过程非常简单。（3）提升数据开发及协同效率

在解决用数难的问题方面，还实现了开发和协同效率的提升。比如以前的开发语言有很多种，包括 Java、Python，以及多种 SQL，开发门槛高，业务方使用难。新的平台统一成了一种语言，同时支持实时和离线分析。另外，在 Lambda 架构下，业务逻辑要维护多套代码，基本上所有的厂商都会有面临这样的问题，还可能带来数据不一致的问题。而新的 Kappa 架构下则只需一套代码。并且，以前一个新的开发，需要打通多组件、多链路、多份数据，效率很低。现在一份数据，一个平台，不再需要导入导出。最后，针对元数据割裂的问题，新的架构下统一了元数据，可以很方便地找到结果表的上游是谁，在数据出问题时也可以进行高效地排查。

3. 解决运维烦问题

（1）架构升级，减轻运维负担