当一辆岚图追光行驶在高速上,它不只是交通工具 —— 车机的每一次触控、刹车的每一次触发、摄像头的每帧画面,都在产生数据。作为东风集团旗下高端新能源品牌,岚图汽车如今每日要处理百亿级车联网数据,这些数据支撑着智能座舱迭代、车辆故障预警、智能驾驶模型优化三大核心业务。
但就在一年前,传统数据架构还在拖后腿:Hive 处理 10 亿级表查询较慢,ClickHouse 多表join性能不好,70 台服务器的运维让团队疲于奔命。直到引入 Apache Doris,岚图才彻底解决了 “数据处理慢、运维重、成本高” 的难题,打造出支撑 20 万 + 销量、出口 40 国的实时数仓体系。今天就拆解这份车企级 Doris 落地实践,看新能源汽车如何用 OLAP 引擎打通数据价值链路。
先搞懂一个问题:岚图每天要处理的 “百亿级数据” 到底是什么?这些数据不是凭空产生的,而是每辆车数百个传感器的 “实时心跳”:

这些数据形成了 “采集 - 分析 - 应用” 的闭环,比如:当车辆传感器检测到 “刹车磨损异常”,数据实时上传分析后,会推送保养提醒给车主,这就是 “预防性维护”—— 而要实现这个场景,数据处理必须满足三个硬性要求:
但早期的 “Hive+ClickHouse” 架构,完全扛不住这样的需求。
岚图早期用 Hive 做离线分析、ClickHouse 做实时查询,这套组合在早期销量低时还能凑合用,但随着销量逐渐提升,三个问题彻底暴露:
在处理大规模数据时,hive on tez 计算速度慢,另外占用的资源也大;
对于 10 亿级别以上大规模表查询,Hive on tez 查询性能较慢,且占用资源多;Clickhouse 在 join 场景下,速度也较慢;
Clickhouse 集群运维比较复杂,没有对应的运维管理工具;

岚图没有盲目选型,而是做了一套严谨的 “决策矩阵”,对比了 Apache Doris、ClickHouse、Trino、StarRocks 等 5 种主流 OLAP 引擎,最终 Doris 以 “全场景覆盖 + 低运维 + 高性价比” 胜出,核心原因有 4 个:

Doris 支持 Routine Load 订阅 Kafka,车辆信号数据从产生到写入数仓,延迟能控制在 秒级,完全满足故障预警的实时需求;更关键的是多表 Join 性能 —— 之前 ClickHouse 到现在的Doris 实现质的提升。
这是最打动运维团队的一点。Doris 官方提供的 Doris Manager,支持集群部署、监控告警、扩缩容、日志查看全流程自动化:之前需要手动扩缩容 ClickHouse,现在用 Doris Manager 点几下鼠标就能完成;还能自动巡检集群状态,比如 “某 BE 节点磁盘使用率过高” 会提前告警。
Doris 支持 Stream Load(实时)、Broker Load(离线 HDFS 导入)、Routine Load(Kafka 订阅)多种导入方式,岚图不用再维护 “离线仓(Hive)+ 实时仓(ClickHouse)” 两套体系:车机埋点数据用 Routine Load 实时导入,历史车辆数据用 Broker Load 从 HDFS 补录,全量数据存在 Doris 里,查询时不用跨系统跳转。
作为 Apache 顶级项目,Doris 社区有 5000 + 企业用户。还有丰富的车企案例可以参考,比如其他新能源品牌的车联网数据处理方案,少走了很多弯路。
选对引擎只是第一步,岚图还针对车企场景做了 5 个关键优化,让 Doris 真正适配 “车联网数据” 的特性:
岚图把数据分成 “热、冷” 两级:

这套分层策略下来,存储成本直接降低 60%。
Apache Doris 通过高并发点查短路径优化,让 FE 节点接收请求后直接生成轻量化执行计划,跳过传统 MPP 的复杂查询生成与调度环节,点查性能达 4 万 QPS。该优化精准匹配车联网实时分析场景,为智能座舱、车辆故障预警等业务提供亚秒级响应支撑,有效应对 “多用户同时查车辆数据” 的高并发压力。

针对各业务线的资源隔离需求,岚图汽车采用 “Doris 原生特性 + 架构优化” 组合方案:一方面利用 Doris 的资源组与工作负载分组机制,实现资源配额的精细化管控;另一方面在 FE 节点与 Observer 节点前端架设负载均衡器,构建业务专属的 SQL 处理链路。最终各业务线可通过专属 FE 角色完成解析与执行,确保研发、售后、运营等负载间互不干扰,既满足研发对大内存的需求,也保障售后高并发点查的稳定性。

慢查询是车联网数仓的常见隐患 —— 尤其当 SQL 涉及多表关联或全量数据扫描时,易引发 CPU 资源占满,威胁核心业务稳定性。Apache Doris 的 SQL 熔断机制通过 “分析 - 识别 - 熔断” 的全链路管控,为岚图汽车的数仓提供了可靠保障。
其关键能力体现在两方面:一是借助 Doris Manager 的 SQL Profile,可拆解查询算子(Scan/Exchange/Shuffle)并定位耗时瓶颈,快速识别全表扫描、高并发数据修改等低效操作;二是通过两种熔断策略实现分层防护:

岚图用 Doris Manager 做了三件事,彻底解放运维:

岚图没有止步于当前的成果,而是在规划更贴合车企未来的数仓架构:
未来会把智能驾驶的图像数据(存在 S3 数据湖)和车辆信号数据(存在 Doris 数仓)打通,通过 Doris 直接查询 S3 上的图像数据元信息,不用再做数据迁移 —— 比如研发团队查 “某车型的自动驾驶图像 + 对应的车辆信号”,直接在 Doris 里写一条 SQL 就能关联,不用跨湖仓操作。

正在评估 “计算节点与存储节点分离” 的架构:把数据存在 S3 上,计算节点按需扩容 —— 比如新车上市时数据量激增,临时加 10 台计算节点,用完再释放,避免 “计算节点闲置” 的浪费。目前还在测试阶段,核心看 “性能是否达标”(比如查询 S3 数据的延迟)和 “成本是否真的降”。

针对售后、座舱开发团队(不懂 SQL 但懂业务),会基于 Doris MCP Server 构建智能 BI 工具:比如售后同学要查 “某地区的故障类型分布”,不用写 SQL,点几下鼠标就能生成报表,数据团队不用再处理大量临时需求。

岚图的实践证明,新能源汽车的 “数据难题”,不是靠堆服务器就能解决的,选对 OLAP 引擎才是关键。从 “Hive+ClickHouse” 的困境,到 “Apache Doris” 的破局,岚图走对了这一步:用 Doris 的实时性能支撑车联网场景,用运维工具减轻负担,用冷热分层控制成本。
对于其他新能源车企来说,这份实践有两个核心启示:
随着新能源汽车越来越 “智能化”,数据会成为比发动机更核心的 “动力源”。而像 Apache Doris 这样的 OLAP 引擎,就是打通 “数据 - 业务” 价值链路的关键 —— 毕竟,能快速把数据变成业务行动的,才是好数据。
往期推荐
Apache Doris 湖仓一体:打破数据边界,解锁实时分析的终极答案
Doris vs ClickHouse 企业级实时分析引擎怎么选?
完
●
数据极客圈子介绍
●
圈子1
Apache Doris社区是目前国内最活跃的开源社区(之一)。Apache Doris(Apache 顶级项目) 聚集了世界全国各地的用户与开发人员,致力于打造一个内容完整、持续成长的互联网开发者学习生态圈!
如果您对Apache Doris感兴趣,可以通过以下入口访问官方网站、社区论坛、GitHub和dev邮件组:
💡官网文档:https://doris.apache.org
💡社区论坛:https://ask.selectdb.com
💡GitHub:https://github.com/apache/doris
💡dev邮件组:dev@doris.apache.org
可以加作者微信(Faith_xzc)直接进Doris官方社区群
圈子2
PowerData是由一群数据从业人员,因为热爱凝聚在一起,以开源精神为基础,组成的数据开源社区。
社区群内会定期组织模拟面试、线上分享、行业研讨、线下Meetup、城市聚会、求职内推等活动,同时在社区群内你可以进行技术讨论、问题请教,结识更多志同道合的数据朋友。
社区整理了一份每日一题汇总及社区分享PPT,内容涵盖大数据组件、编程语言、数据结构与算法、企业真实面试题等各个领域,帮助您提升自我,成功上岸。
可以加作者微信(Faith_xzc)直接进PowrData官方社区群
叮咚✨ “数据极客圈” 向你敞开大门,走对圈子跟对人,行业大咖 “唠” 数据,实用锦囊天天有,就缺你咯!快快关注数据极客圈,共同成长!
点击上方公众号关注我们