首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >岚图汽车用 Apache Doris 破局:每日百亿级车联网数据,实现 4W QPS + 存储降本 60% 的实时数仓实践

岚图汽车用 Apache Doris 破局:每日百亿级车联网数据,实现 4W QPS + 存储降本 60% 的实时数仓实践

作者头像
数据极客圈
发布2025-11-12 13:11:37
发布2025-11-12 13:11:37
130
举报

当一辆岚图追光行驶在高速上,它不只是交通工具 —— 车机的每一次触控、刹车的每一次触发、摄像头的每帧画面,都在产生数据。作为东风集团旗下高端新能源品牌,岚图汽车如今每日要处理百亿级车联网数据,这些数据支撑着智能座舱迭代、车辆故障预警、智能驾驶模型优化三大核心业务。

但就在一年前,传统数据架构还在拖后腿:Hive 处理 10 亿级表查询较慢,ClickHouse 多表join性能不好,70 台服务器的运维让团队疲于奔命。直到引入 Apache Doris,岚图才彻底解决了 “数据处理慢、运维重、成本高” 的难题,打造出支撑 20 万 + 销量、出口 40 国的实时数仓体系。今天就拆解这份车企级 Doris 落地实践,看新能源汽车如何用 OLAP 引擎打通数据价值链路。

一、新能源汽车的 “数据焦虑”:每日 10TB,要快还要省

先搞懂一个问题:岚图每天要处理的 “百亿级数据” 到底是什么?这些数据不是凭空产生的,而是每辆车数百个传感器的 “实时心跳”:

  • 车机埋点数据:车机屏幕的点击、导航使用、音乐播放记录,用来优化智能座舱体验(比如用户常点的功能放首页);
  • 车辆信号数据:刹车力度、电池温度、电机转速等 IoT 信号,实时监测车辆状态,比如电池温度过高时触发预警;
  • 智能驾驶图像数据:摄像头、雷达采集的道路画面,用于训练自动驾驶模型(比如识别行人、障碍物)。

这些数据形成了 “采集 - 分析 - 应用” 的闭环,比如:当车辆传感器检测到 “刹车磨损异常”,数据实时上传分析后,会推送保养提醒给车主,这就是 “预防性维护”—— 而要实现这个场景,数据处理必须满足三个硬性要求:

  1. :传感器数据产生后,要在秒级完成分析,否则故障预警就失去意义;
  2. :每秒数十万条数据写入,不能丢数据、不卡顿,毕竟数据中断可能导致故障漏判;
  3. :快速增长的全量写入需求与复杂计算任务,导致存储与计算成本攀升,车企需要平衡性能与成本。

但早期的 “Hive+ClickHouse” 架构,完全扛不住这样的需求。

二、传统架构的 3 个 “卡脖子” 痛点,销量越涨越明显

岚图早期用 Hive 做离线分析、ClickHouse 做实时查询,这套组合在早期销量低时还能凑合用,但随着销量逐渐提升,三个问题彻底暴露:

1. 数据导入时效性低

在处理大规模数据时,hive on tez 计算速度慢,另外占用的资源也大;

2. 数据查询分析延迟高

对于 10 亿级别以上大规模表查询,Hive on tez 查询性能较慢,且占用资源多;Clickhouse 在 join 场景下,速度也较慢;

3. 运维难度高:

Clickhouse 集群运维比较复杂,没有对应的运维管理工具;

三、为什么选 Apache Doris?车企的 “决策矩阵”

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

1. 实时性能 “对症”:秒级写入 + 亚秒级查询

Doris 支持 Routine Load 订阅 Kafka,车辆信号数据从产生到写入数仓,延迟能控制在 秒级,完全满足故障预警的实时需求;更关键的是多表 Join 性能 —— 之前 ClickHouse 到现在的Doris 实现质的提升。

2. 运维 “减负”:Doris Manager 一键搞定

这是最打动运维团队的一点。Doris 官方提供的 Doris Manager,支持集群部署、监控告警、扩缩容、日志查看全流程自动化:之前需要手动扩缩容 ClickHouse,现在用 Doris Manager 点几下鼠标就能完成;还能自动巡检集群状态,比如 “某 BE 节点磁盘使用率过高” 会提前告警。

3. 多场景适配:离线 + 实时 “一仓搞定”

Doris 支持 Stream Load(实时)、Broker Load(离线 HDFS 导入)、Routine Load(Kafka 订阅)多种导入方式,岚图不用再维护 “离线仓(Hive)+ 实时仓(ClickHouse)” 两套体系:车机埋点数据用 Routine Load 实时导入,历史车辆数据用 Broker Load 从 HDFS 补录,全量数据存在 Doris 里,查询时不用跨系统跳转。

4. 社区 “靠谱”:问题响应快,文档全

作为 Apache 顶级项目,Doris 社区有 5000 + 企业用户。还有丰富的车企案例可以参考,比如其他新能源品牌的车联网数据处理方案,少走了很多弯路。

四、5 大落地优化:从 “能用” 到 “好用” 的车企级实践

选对引擎只是第一步,岚图还针对车企场景做了 5 个关键优化,让 Doris 真正适配 “车联网数据” 的特性:

1. 冷热数据分层:存储成本直降 60%

岚图把数据分成 “热、冷” 两级:

  • 热数据:存在 SSD 上,保证查询秒级响应,支撑故障预警、实时座舱分析;
  • 冷数据:访问频率较低的数据,则逐步迁移到相对低成本的 HDD 硬盘甚至更为,甚至直接迁移到 S3 等对象存储中,以降低整体存储成本。

这套分层策略下来,存储成本直接降低 60%。

2. 高并发点查优化:4W QPS 查询

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

3. 资源隔离:业务之间 “不抢资源”

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

4. SQL 熔断:避免 “慢查询搞垮集群”

慢查询是车联网数仓的常见隐患 —— 尤其当 SQL 涉及多表关联或全量数据扫描时,易引发 CPU 资源占满,威胁核心业务稳定性。Apache Doris 的 SQL 熔断机制通过 “分析 - 识别 - 熔断” 的全链路管控,为岚图汽车的数仓提供了可靠保障。

其关键能力体现在两方面:一是借助 Doris Manager 的 SQL Profile,可拆解查询算子(Scan/Exchange/Shuffle)并定位耗时瓶颈,快速识别全表扫描、高并发数据修改等低效操作;二是通过两种熔断策略实现分层防护:

  • 规划时熔断(SQL Block Rule):解析阶段拦截高风险语句,从源头规避资源浪费;
  • 运行时熔断(Workload Policy):执行中实时监控指标,当前已落地 “2 分钟超时熔断”,后续计划新增扫描分区数、扫描分桶数等细粒度规则,精准管控资源。

5. Doris Manager:运维效率大幅提升

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

  • 自动化部署:70 台集群从 “手动装环境” 到 “一键部署”,极大地释放了运维团队的精力;
  • 智能监控:实时监控 FE/BE 节点的 CPU、内存、磁盘使用率,异常时自动发告警到企业微信;
  • 日志聚合:不用再登录每台机器看日志,在 Doris Manager 上就能搜索所有节点的日志,排查问题速度大幅提升。

六、未来规划:车企数仓的下一站 —— 湖仓一体、存算分离

岚图没有止步于当前的成果,而是在规划更贴合车企未来的数仓架构:

1. 湖仓一体:打通数据湖与数仓

未来会把智能驾驶的图像数据(存在 S3 数据湖)和车辆信号数据(存在 Doris 数仓)打通,通过 Doris 直接查询 S3 上的图像数据元信息,不用再做数据迁移 —— 比如研发团队查 “某车型的自动驾驶图像 + 对应的车辆信号”,直接在 Doris 里写一条 SQL 就能关联,不用跨湖仓操作。

2. 存算分离:进一步降本增效

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

3. 智能 BI:让非技术同学也能用数据

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

结语:车企数仓的核心 —— 用对引擎,少走弯路

岚图的实践证明,新能源汽车的 “数据难题”,不是靠堆服务器就能解决的,选对 OLAP 引擎才是关键。从 “Hive+ClickHouse” 的困境,到 “Apache Doris” 的破局,岚图走对了这一步:用 Doris 的实时性能支撑车联网场景,用运维工具减轻负担,用冷热分层控制成本。

对于其他新能源车企来说,这份实践有两个核心启示:

  1. 不要盲目追求 “最先进的架构”,而是选 “最贴合业务需求” 的引擎 —— 车企需要的是 “快、稳、省”,Doris 刚好满足;
  2. 数据架构要 “一步到位”,避免重复建设 —— 岚图用 Doris 替代了 Hive 和 ClickHouse,一套架构支撑所有场景,减少了数据孤岛。

随着新能源汽车越来越 “智能化”,数据会成为比发动机更核心的 “动力源”。而像 Apache Doris 这样的 OLAP 引擎,就是打通 “数据 - 业务” 价值链路的关键 —— 毕竟,能快速把数据变成业务行动的,才是好数据。

往期推荐

Doris BE节点下线卡住?快速排障技巧全攻略!

Apache Doris 索引的全面剖析与使用指南

Apache Doris 湖仓一体:打破数据边界,解锁实时分析的终极答案

Doris vs ClickHouse 企业级实时分析引擎怎么选?

Doris查询报错-230?别慌,教你几招秒解!

Doris Tablet 损坏如何应对?能恢复数据吗?

Doris 导入慢该如何排查和优化

Doris 建表与分区问题全解析

数据极客圈子介绍

圈子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官方社区群

叮咚✨ “数据极客圈” 向你敞开大门,走对圈子跟对人,行业大咖 “唠” 数据,实用锦囊天天有,就缺你咯!快快关注数据极客圈,共同成长!

点击上方公众号关注我们

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2025-10-10,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 数据极客圈 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、新能源汽车的 “数据焦虑”:每日 10TB,要快还要省
  • 二、传统架构的 3 个 “卡脖子” 痛点,销量越涨越明显
    • 1. 数据导入时效性低
    • 2. 数据查询分析延迟高
    • 3. 运维难度高:
  • 三、为什么选 Apache Doris?车企的 “决策矩阵”
    • 1. 实时性能 “对症”:秒级写入 + 亚秒级查询
    • 2. 运维 “减负”:Doris Manager 一键搞定
    • 3. 多场景适配:离线 + 实时 “一仓搞定”
    • 4. 社区 “靠谱”:问题响应快,文档全
  • 四、5 大落地优化:从 “能用” 到 “好用” 的车企级实践
    • 1. 冷热数据分层:存储成本直降 60%
    • 2. 高并发点查优化:4W QPS 查询
    • 3. 资源隔离:业务之间 “不抢资源”
    • 4. SQL 熔断:避免 “慢查询搞垮集群”
    • 5. Doris Manager:运维效率大幅提升
  • 六、未来规划:车企数仓的下一站 —— 湖仓一体、存算分离
    • 1. 湖仓一体:打通数据湖与数仓
    • 2. 存算分离:进一步降本增效
    • 3. 智能 BI:让非技术同学也能用数据
  • 结语:车企数仓的核心 —— 用对引擎,少走弯路
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档