云栖实录 | 理想汽车基于 Hologres + Flink 构建万亿级车联网信号实时分析平台
作者：海博 理想汽车高级大数据工程师、贾天福 理想汽车高级大数据工程师
引言：智能汽车时代的数据挑战
随着电动车和智能汽车的快速普及，车联网信号数据呈现爆发式增长。理想汽车作为国内领先的智能电动汽车企业，已拥有超过 100 万辆在网车辆，每辆车每秒上报多达上万个信号（如车速、胎压、温度、电池状态等），整体数据规模达到万亿级别。这些数据不仅体量巨大，而且对实时性要求极高——端到端延迟需控制在 2 秒以内，至少不超过 5 秒，以支撑数字孪生、智能诊断、车辆预警等关键业务场景。
理想汽车大数据团队面临的核心挑战是如何在保障高实时性的同时，实现系统的高稳定性、高弹性与低成本。为此，团队决定重构数据底座，引入阿里云 Hologres + Flink 技术栈，打造新一代车联网实时分析平台。本文将系统介绍这一实践过程。
一、海量车联网信号的挑战
理想汽车当前拥有 100 万辆以上存量汽车，每辆车约有 1 万个信号进行实时的秒级甚至毫秒级上报。这些信号涵盖制动系统、自动驾驶系统、动力系统、车身系统、座椅系统等多个维度，数据灌入实时数据库后，存量数据达万亿行、PB 级别，日增数据达数百亿行。
业务对数据链路的实时性要求极高，端到端延迟需控制在 2 秒以内，至少不超过 5 秒。为满足这一需求，理想汽车曾构建了一套离线与实时双链路的整体保障方案。然而，随着数据爆炸式增长，进入 2025 年后，旧有技术栈问题频发，暴露出两大核心挑战：稳定性不足、弹性能力弱/成本高。
挑战一：稳定性不足
数据的持续增长不断触发系统瓶颈，导致故障频发。具体表现为：
写入延迟：节假日等流量高峰期间，写入 RPS 超过 150 万，系统出现明显延迟，无法满足业务时效性要求；
冷查询打满资源：大量 30 天以上的冷数据查询 QPS 峰值超 1 万，占用大量计算资源，影响热数据服务；
容错能力弱：系统故障时高度依赖人工处理，恢复效率低，最慢需 12 小时才能完全恢复；
流程不完善：业务接入缺乏准入评估，上线前测试不充分，导致资源错配与线上 Bug 频出；
缺乏兜底机制：升级需停服、难回滚，故障时无法快速止损。
这些问题叠加，使得系统 SLA 难以保障，严重影响用户体验与业务发展。
挑战二：弹性能力弱、成本高
理想汽车原有架构采用存算一体的非云原生设计，部署在云主机或裸金属服务器上，存在显著缺陷：
资源无法弹性扩缩：为应对节假日峰值，需长期按最高负载配置资源，造成大量闲置浪费；
存算耦合：存储与计算绑定，无法独立扩展，计算资源利用率低；
双集群双链路冗余：为保障稳定性，采用主备双集群 + 实时/离线双链路方案，导致资源成本翻倍；
技术栈割裂：实时链路（明细表→物化视图）与离线链路（ODS→DWD→DWS→APP）使用两套技术栈、两套存储，开发运维成本高；
集群拆分复杂：单集群无法支撑未来 200 万辆车规模，拆分带来数据路由、一致性等新问题。
该架构不仅成本高昂，且难以适应立项汽车未来几百万车辆业务的高速增长。
二、基于阿里云 Hologres+Flink 架构方案
为应对上述挑战，理想汽车于 2024 年底启动技术架构升级，全面引入阿里云 Hologres+ Flink，构建“弹性、高可用、低成本”的新一代车联网数据平台。
新架构自下而上分为四层：
写入层：通过阿里云实时计算 Flink 版的 Serverless 实现高性能数据写入，Hologres 具备极强的写入能力，写入即可查。
存储层：利用 Hologres 的冷热分层能力，部分数据放在 OSS，将冷热数据比例从 2:1 提升至 5:1，显著降低存储成本；
计算层：通过 Hologres 计算组实现读写分离 + 负载隔离，写入、加工、查询等分别属于不同计算组，互相不受影像。存在 OSS 的历史数据，对性能不敏感，搭配 Hologres Serverless Computing 弹性资源可以直接进行冷查询或者 ETL 加工大宽表，成本低，又不会影响其他计算组的稳定性。整体架构可以保障高优业务（如热查询、实时预警）的稳定性；
业务层：统一实时与离线链路，实现流批一体，ODS 层数据统一存储，存储成本减半。
关键创新在于：不再需要双集群、双链路兜底，Hologres 自身的高可用与弹性能力即可保障 SLA。
性能压测验证
理想汽车对新架构进行了全链路压测，验证其支撑能力：
写入压测：
真实 100 万+辆车场景下，700CU 资源支撑 150 万+ RPS，写入无延迟；
Mock 200 万辆车，写入峰值达 300 万+ RPS，依然稳定。
查询压测：
500CU 下，单 Query 与混合 Query 均满足 1 万+ QPS 需求；
冷热查询性能差异可控，热查 P99 约 10 秒，冷查约 27 秒。
压测结果证明，新架构具备支撑未来 200 万辆车规模的能力，且冷热查询性能均衡，满足业务需求。
车辆数字孪生 View 场景测试
“车辆数字孪生 View”是理想汽车的核心业务场景：在云端实时还原每一辆车在同一时刻的所有信号状态，用于故障诊断、自动驾驶监控、售后维修支持及工况回放仿真。
该场景极具挑战性：
信号数量多达 1 万个以上；
100 万+辆车按秒/毫秒同时上报；
需要高并发（QPS 超 1 万）、高实时（秒级延迟）、高一致性。
初期方案采用 Hologres Binlog 实时同步，虽能实现高实时性，但由于我们数据量较大，Binlog 体量是原始数据的数倍，需长期占用热存储，成本高昂。
车辆数字孪生 View 场景升级
经与 Hologres 团队联合优化，从左侧的 Binlog 方案，升级到 10 秒增量 ETL 框架，分为四步：
根据 Offset 获取明细：拉取过去 10 秒的增量数据；
预聚合：对增量信号进行初步聚合；
与 View 聚合：将预聚合结果与现有车辆 View 合并；
记录 Offset：持久化最新处理位点，支持断点续传。
该方案优势显著：
时间换空间：复用已有数据，避免额外存储成本；
高性能：基于底层文件行号过滤，性能极高；
强容错：Offset 机制保障系统异常时可快速恢复数据。
理想汽车通过这个方案实现了成本和效率的一个完美的平衡。既能满足业务的需求，也可以复用现有的数据，避免了额外的成本。而且我们增量的数据获取采用底层文件行号过滤性能非常高，并且有 offset 的记录。当系统发生错误的时候，可以根据 offset 实时的追回我们的数据。，有非常好的容错能力。
稳定性保障体系
稳定性不仅是产品的能力，更是流程机制的建立。理想汽车基于 Hologres 存算分离、云原生架构，系统容错能力强，上线至今 0 故障，同时在内部构建了“事前预防、事中止损、事后保障”的全链路稳定性体系：
事前预防：
制定《业务准入 SOP》《变更管控 SOP》《供应商准入 SOP》；
完善 Hologres 监控告警：查询监控、资源监控、存储 IO 监控全覆盖；
使用影子实例验证变更，无误后再上线。
事中止损：
弹性扩缩：高峰期自动扩容，低峰期缩容；
快速回滚：升级异常可秒级回退；
服务降级：非核心查询可临时降级，保障核心链路。
事后保障：
SLA 承诺 99.9%，7×24 小时专属支持；
审计日志完善，支持自助分析瓶颈。
Hologres+Flink 架构总结
使用了阿里云 Hologres+Flink 这套技术栈以后，我觉得我们既有现在又有未来。如刚才所说，现在能支持理想汽车一百多万辆车的一个场景，也可以通过扩容去支持未来 200 万辆车甚至更多的一个场景，不需要做多种集群的拆分。第二方面是效率高，成本低。Hologres 具有极致的弹性能力，还有一些这种 Serverless Computing 这样的弹性资源，大幅提高我们的资源利用率，避免资源浪费。而且 Hologres 是一个多模态的分析场景，未来还可以扩展到 OLAP 分析、点查服务、全文检索、向量搜索以及 AI 推理等多种场景。
最后方面稳定应用。如刚才所说，理想汽车构建了非常完善的稳定性保障的机制，拥有完善的审计日志，让我们可以灵活的自助分析我们系统的瓶颈和风险。
三、理想汽车基于 Hologres+Flink 构建万亿级车联网信号实时分析平台
以上是架构设计的思考，后续给大家介绍理想汽车基于 Hologres+Flink 这套架构在业务上线应用过程中一些情况。包括我们刚才提到了的工况还原、智能诊断、车辆预警等场景。
整体接入及上线时间线
理想汽车与 Hologres 的合作按以下时间线推进，我们通过大约 6-9 个月即完成从最初 POC 测试到正式上线，整个过程平稳有序，验证了新架构的可靠性。
从最开始 24 年的 12 月份跟 Hologres 做初步对接，Hologres 团队其实很快的就完成了 POC 的这个测试，符合我们性能的诉求。过完年后我们开始在 2-4 月份去进行全面的压测跟优化，又做了灰度的查询的验证，验证了扩缩容对业务没有影响。因为这次架构的升级要求对业务无感的，5 越分开始我们进行了新老链路的双跑，并在五一和端午两个高峰的假期去验证整体的能力，发现 Hologres 是完全满足假期高峰出行的流量保障要求。端午之后，我们就把老的这个链路给下线了，整个五月期间，也没有发生任何故障，于是我们在实时的链路上又接入了一些复杂的一些计算的场景。
整体业务实践和收益
接入 Hologres 后，理想汽车资源利用率提升，实现性能与成本的完美平衡；响应时间满足 SLA：历史工况回溯等场景响应时间达标，SLA 达标率 99.9%。
写入性能提升 200%：在成本持平前提下，写入能力翻倍，达 150 万 RPS，零延迟；比方说网络抖动，或者是消费的服务有所异常的情况，导致的信号积压的场景下，我们能快速的恢复跟止损。
QPS 提升 32%：热查询使用独立 Hologres Warehouse，专注热数据处理，资源利用率比共享池高 20%；
计算成本降低 40%：冷查询虽然频率比较低，但是又有一定的实时要求，采用 Hologres Serverless Comuting 模式，按量付费，降低成本，也能保证 SLA；
应用一："自动列化+动态扩列"破解海量车机存储难题
面对 100 万辆车 10000+动态信号，理想汽车设计了“A-Z 固定列 + JSONB 列式动态存储”方案，Hologres 开启 JSONB 列式存储优化后，底层自动将 JSONB 转换为强 Schema 列式存储，查询时可直接命中指定列，提升性能；同时存储压缩效率高，有效降本增效。
灵活性：支持信号动态增减，无需频繁变更表结构，适配业务快速迭代；
高效性：JSONB 格式具备高效存储与解析性能，结合 A-Z 列分类，大幅减少数据扫描范围；
可维护性：信号按首字母分类存储，数据归属清晰，便于后续分区管理与优化。
应用二：读写优化，万亿数据秒级写入和查询
为满足万亿级数据秒级写入，理想汽车基于 Hologres 采用多项优化：
Copy 模式写入：使用二进制协议，高效写入，写入即可查；
连接池 + Table Schema 缓存：防止每次 Copy 创建新连接，减少服务端 CPU 消耗；
攒批 Flush：减少 close 频率，进一步提高性能；Flush 与 Checkpoint 同步，保证消息不丢失；
零延迟快照：基于增量视图 Union 明细表，实现信号最新快照的零延迟查询。
这些优化确保了高吞吐、低延迟、高可靠的数据写入能力。
在查询层面，我们是做到了 1 万+QPS 的秒级返回。主要是基于 Hologres 的 cache 优化能力，保证热点数据能覆盖到 95%以上。基于条件下推减少了 scan 的扫描，jsonb 列存化减少 scan 时的 io 大小和 cpu 消耗。然后针对这一些大量的点查，vin 作为 distribution key 保证数据均匀分布, ts 作为 clustering key 帮助高效裁剪文件。
应用三：高峰期稳定性保障
在五一和端午假期期间，理想汽车通过节前扩容 20%、节后缩容 20%，成功应对流量高峰，保证 SLA，假期无故障，写入无延迟，实现 10000+ QPS 的高性能响应。
应用四：离线场景降本提效
理想汽车还有一些离线场景，我们也将他迁移到 Hologres 上，有几个典型的场景：
数据探查：数据分析师或者是数据产品在提数据需求时，他可能对数据本身的质量和数据的分布情况其实没有一个感知。需要数仓的同学先做探查，再反复地去沟通，这个时间其实比较耗时，可能会占用我们一半的研发的时间。我们希望把这个数据探查做成一个自助化的，通过 Hologres 用户可以去自己探查数据后再来提数据的诉求。
数据加工：针对一些简单的数据加工 ETL，例如一些信号循环的加工，让业务分析师能够自主的去使用。
交叉分析：加工完循环数据表，包括一些简单的信号的加工之后，业务可以做一些交叉分析。
这些场景以前都比较慢，我们通过 Hologres 的 JsonB 全量表+Dynamic Table 增量加工+Serverless Computing 弹性计算资源，实现了在降低成本的同时，提升了加工效率，并满足了业务对性能的要求。
整体资源的利用率比原先离线的能提高 60%，成本是离线场景能下降到 35%，下降了 35%，整体的这个交付的时间基本上从原来的 3 到 5 天能减少到 4 个小时之内，覆盖了 90%离线信号分析场景。
四、未来展望
理想汽车与 Hologres 团队将持续深化合作，探索更多创新方向：
Serverless Flink 统一写入：进一步简化架构，提升写入弹性与性能；
Hologres 能力增强：基于新发布能力，探索 Time Travel 等特性，实现更细粒度的数字孪生与冷存管理；
接入更多场景：扩展至充电场站信号、台架测试数据等新信号源，支持自动驾驶、AI 训练等复杂 OLAP 与 AI 场景。
通过 Hologres + Flink 的深度整合，理想汽车成功构建了稳定、弹性、高效、低成本的万亿级车联网实时分析平台。该平台不仅解决了当前业务痛点，更具备面向未来的扩展能力——可平滑支撑 200 万辆车甚至更大的业务规模，无需架构重构。理想汽车将与阿里云合作不断深耕大数据+AI 场景，为用户提供卓越、稳定、安全的汽车智能驾驶体验。
还未添加个人签名 2020-10-15 加入
分享阿里云计算平台的大数据和AI方向的技术创新和趋势、实战案例、经验总结。
评论