导读
数据团队的很多麻烦，卡的不是技术，是架构。明明只是想多跑几个分析任务，却要先看存储扩不扩得动；明明只是想把车辆轨迹和原始报文放在一起看，却得在两套系统之间来回倒数据、人工拼接。
长城汽车也走到过这一步。原有架构搭建在腾讯云上，用 HBase 存原始报文、InfluxDB 存轨迹数据，两条腿各自支撑着每日新增的百亿行级车联网数据，但存算强绑定、两套系统各自为政的问题一直埋在那里，直到业务规模大到忽视不了。
引入云器 Lakehouse 之后，这次升级解决了三件事：计算资源不再因为存储扩容被迫跟涨；HBase 和 InfluxDB 里的数据，可以在同一个平台里联合查询；长城汽车整体 TCO 下降超过 40%，运维复杂度也大幅简化。
现状与痛点
1. 架构背景
长城汽车是中国自主品牌头部车企之一，旗下涵盖哈弗、坦克、魏牌、欧拉、长城皮卡五大品牌，产品覆盖 SUV、新能源、皮卡等多个细分市场。2025 年全年销售新车 132.37 万辆，同比增长 7.33%，创历史新高；新能源销量 40.37 万辆，同比增长 25.44%；海外销量 50.61 万辆，同比增长 11.68%，再创历史纪录；全球用户突破 1500 万。长城皮卡连续 28 年蝉联中国皮卡销量冠军，国内终端市占率近 50%。
随着新能源业务快速发展，长城汽车每日新增的车辆原始报文、轨迹及驾驶行为等数据已经达到百亿行级别，需要实时采集与分析。原有数据平台搭建在腾讯云上，采用 HBase 存原始报文、InfluxDB 存轨迹数据，双数据库并行的架构模式。
（原数据平台架构图）
接入层由 Kafka 统一承接数据写入，经 Java/Flink 完成数据消费后，分别流入 HBase 和 InfluxDB；应用层的各类分析任务直接对接这两套存储，取数、查询都在各自系统内完成。
2. 核心问题
架构跑起来没问题，但随着业务规模扩大，三个问题逐渐浮出水面。
问题一：存算一体架构僵化，计算资源浪费严重。 HBase 采用存算一体设计，计算与存储资源强绑定，没法把这两者分开扩缩容。随着智能网联汽车销量增长，数据存储量水涨船高，为了存下更多车辆数据，只能持续扩展 HBase 节点——但节点一扩，计算资源也跟着扩，哪怕业务并不需要这么多计算能力，也只能被动多花这份钱。
问题二：多套系统割裂，无法统一融合分析。 关键业务数据分散在 HBase 和 InfluxDB 两个异构系统里，彼此互不相通。一旦需要对两边的数据做跨系统的多维关联分析，就得另外引入新平台来做整合，开发效率低，也很难做到实时洞察。
问题三：运维成本高，SLA 保障风险高。 两套异构数据库集群需要同时维护，各自有独立的监控告警体系，上下游的数据生产和消费应用也是各自一套——任何一个环节出问题，排查链路都要在两套系统里来回切换，运维复杂度居高不下。
拆开看是三件事，但顺着往根上找，其实是同一个架构选择带来的三重代价：
- HBase 把计算和存储焊在一起，资源没法精打细算；
- HBase 和 InfluxDB 各管一摊、彼此不通，分析做不到一处去看；
- 而两套相互耦合的系统各自一摊运维，复杂度自然也跟着叠加。
三个问题不是三块可以分开打的补丁，真要解决，得从"存算耦合 + 多引擎并行"这个架构本身下手。
升级选型逻辑
为解决上述痛点，长城车联网大数据团队启动了新一代数据底座的选型工作，目标是构建一个高性能、低成本、易运维且面向未来的统一数据平台 。
2.1 需求清单
经过内部深入讨论，团队明确了以下关键需求：
| 关键能力分类 | 关键项 | 说明 |
|---|---|---|
| 架构优化 | 支持存算分离 | 必须能将计算与存储解耦，实现资源的独立弹性伸缩，以应对业务波峰波谷。 |
| 架构优化 | 统一数据湖仓 | 需要一个单一平台，能够同时承载原始报文、时序轨迹、驾驶行为等多种数据类型，并支持统一的SQL查询。 |
| 成本控制 | 显著降低成本 | 新架构的总体拥有成本（TCO）需要大幅度，目标是降低30%以上。 |
| 运维简化 | 极简运维 | 希望将工程师从繁杂的集群管理、参数调优中解放出来，专注于业务价值创造。 |
| 性能指标 | Lookup查询 | 单车明细查询100ms级Response Time |
| 能力演进 | 支持超大规模数据实时同步（百TB级别） | 平台需具备高效的数据采集能力，支持百TB级别数据的实时或准实时同步，保障跨系统间数据一致性；同时提供灵活的弹性扩缩容方案，可根据业务负载动态调整资源，满足高吞吐、低延迟的数据同步需求。 |
| 能力演进 | 支持近实时分析 | 平台需具备强大的流批一体处理能力，支撑分钟级的近实时数据接入与分析场景。 |
2.2 方案选择：云器 Lakehouse
长城汽车车联网大数据团队评估了多种开源与商业方案，并用真实生产数据完成了两个月的 POC 论证，最终选择了云器 Lakehouse。
能打动团队的，不是产品功能表上有多少条目，而是云器的几项核心能力，和长城的三个痛点几乎逐条对上了。
针对存算耦合 → 云原生存算分离架构
HBase 存算一体的设计，导致为了撑住写入峰值就得常驻千核计算资源，但日均用量只有峰值的 30%，大量计算资源只是在空转。云器 Lakehouse 的存算分离架构 彻底解开了这个绑定——存储和计算独立扩缩，高峰期快速拉起计算集群，峰值过去后缩回来，不再被迫为用不到的资源买单。
针对系统割裂 → 统一的湖仓引擎
HBase 存报文、InfluxDB 存轨迹，两套系统各管各的，想做跨系统的多维分析就必须另引平台整合，链路冗长、口径难对齐。云器 Lakehouse 以统一的湖仓引擎 同时承载原始报文、时序轨迹、驾驶行为等多种数据类型，支持统一的 SQL 查询。原来需要多个系统接力才能完成的分析，在一个平台内就能端到端做完，实时洞察不再是奢望。
针对运维重担 → 全托管服务 + 高 SLA 兜底
同时维护 HBase 和 InfluxDB 两套集群，意味着两套监控体系、两套告警链路、两套故障排查流程，任何一端出了问题，工程师都得两边来回切换。云器 Lakehouse 团队直接兜底平台运维，长城的工程师无需介入平台层，从根本上卸掉了这个包袱。99.9% 的 SLA 保障与连续 4 个月零故障的实际交付，也给一直悬在头上的可靠性风险打上了实证的底。
从 POC 到落地：被验证出来的结论
这次选型没有止步于供应商演示——长城汽车用自己的真实生产数据跑了两个月的 POC 论证。过程中跑通了三个痛点的解法，还碰到了一些需求清单之外的能力，比如对已有 COS、HDFS 数据湖的免迁移查询加速。这也解释了为什么最终落地后，实际降本 40% 能超过当初定的 30% 目标线。
云器 Lakehouse 方案介绍
长城汽车基于云器 Lakehouse 搭了一套新的数据平台，替换掉了原来 HBase + InfluxDB 的双系统结构。存算分离解决了资源浪费，统一引擎解决了跨系统查询，运维也跟着轻了一截。
（采用云器Lakehouse后架构图）
具体来看，有三个能力点值得展开：
1. 存算分离（统一存储，弹性计算） ： 业务数据统一写入腾讯云 COS 对象存储，采用 Parquet 列式存储，压缩率达 3.5 倍，存储成本下降 75%。
原架构的痛点在于，HBase 采用存算一体设计，为应对写入峰值，需要常驻千核级计算资源，但日均写入量仅为峰值的 30%，计算资源闲置率高达 70%，加上 HBase 三副本机制，存储成本一直降不下来。升级后，原始报文、轨迹、驾驶行为等数据统一写入云器 Lakehouse 管理的 COS 对象存储，不仅实现 3.5 倍压缩率，还支持数据生命周期管理，到期数据自动清理；数据入湖加工与分析查询两类负载分别配置独立虚拟集群，按工作负载和并发情况弹性扩缩容。
2.高效数据入湖 ： 通过云器 Pipe & Copy 能力，实现百亿行数据、百万级 TPS 的近实时数据接入，确保数据分钟级可见。
此前数据入库依赖 K8s 调度 Java/Flink 程序，每次业务逻辑变更都需要重新开发、测试和部署，改动成本高、周期长。
云器 Pipe 直接替换了这条链路：用 SQL 定义从 Kafka 到 Lakehouse 的端到端数据导入逻辑，批次间隔 60 秒，数据写入后即可查询；业务逻辑需要调整时，改 SQL 重新提交即可运行，不需要重走整套工程保障流程。需要从某个历史时间点重新消费数据时，调整 RESET_KAFKA_GROUP_OFFSETS 参数即可，无需单独搭建批处理流程。以下是实际使用的 Pipe SQL：
CREATE PIPE pipe_ods_commit_log VIRTUAL_CLUSTER = 'pipe_ods_commit_log' BATCH_INTERVAL_IN_SECONDS = '60' RESET_KAFKA_GROUP_OFFSETS = '1740931200000' -- epoch in millis of 2025-03-03 00:00 AS COPY INTO ods_commit_log FROM ( SELECT parse_json(j['event']::string) as event, parse_json(parse_json(j['event']::string)['statements']::string) as statements, j['op_type']::string as op_type, j['datasource_id']::string as datasource_id, j['database_name']::string as database_name, j['schema_name']::string as schema_name, j['table_name']::string as table_name, timestamp_millis(j['event_ts']::bigint) as event_ts, j['event_seq']::string as event_seq, timestamp_millis(j['server_ts']::bigint) as server_ts, j['server_seq']::bigint as server_seq, `timestamp` as __kafka_timestamp__ FROM ( SELECT `timestamp`, parse_json(value::string) as j FROM read_kafka( 'kafka-bootstrap-1:9092,kafka-bootstrap-2:9092,kafka-bootstrap-3:9092', -- bootstrap servers 'topic_name', -- topic '', -- reserved 'sub2cz', -- kafka group id, for keeping read position '', '', '', '', -- reserved 'raw', -- key format, can only be raw 'raw', -- value format, can only be raw 0, MAP( 'kafka.security.protocol', 'PLAINTEXT' ) ) )
3. 丰富分析 ： 在保障单车 Lookup 点查秒级返回的同时，开放了跨主题的多维实时分析能力，比如历史车况和行程信息查询，为业务创新提供支撑。
这里的关键是 Lookup 表能力。在旧架构下，HBase 和 InfluxD
B 各存一摊，把车况和行程信息放在一起分析，必须先从两个系统分别取数，再人工合并——这正是前面痛点二的具体体现。换到云器 Lakehouse 之后，Lookup 表支持在查询时直接关联不同类型的数据，时序轨迹、原始报文、行程信息可以在同一次查询里跨主题联合，不需要提前做数据整合，也不依赖额外的中间层。
性能上，单车明细查询的响应时间做到了 100ms 级别，跨主题的联合查询同样能秒级返回，两种场景兼顾。对于长城汽车的业务团队来说，"车况+位置+行程"的多维融合实时分析，从需要多系统接力、人工拼接，变成了在同一个平台内直接完成——精细化运营和产品迭代所需的数据支撑，分析链路大幅缩短。
实际收益
方案上线后，在生产环境中稳定运行，取得了几方面比较明显的成效。
4.1 成本下降：整体 TCO 降低 40%+ 引入云器 Lakehouse 存算分离架构后，计算和存储资源都得到优化，综合下来总拥有成本下降超过 40%——比需求清单里定的 30% 目标线，又往前走了一截。
4.2 运维提升：复杂度下降 100% 告别了多套系统的维护复杂度，不再需要管理 HBase/InfluxDB 集群及配套的入湖数据采集应用，也无需参与 Lakehouse 平台自身的运维。
4.3 业务提升：分析场景极大丰富 在满足原有高性能查询 SLA 的前提下，成功解锁了"车况+位置+行程"的多维融合实时分析新场景，为精细化运营和产品迭代提供了数据支撑。
4.4 场景扩展：已有数据湖免迁移查询加速 云器 Lakehouse 还在探索对已有数据湖的免迁移查询加速能力，可直接对接已有的 COS 数据湖、HDFS 数据湖与 HMS，数据不用搬家也能跑起来。
前三项收益的根源都在同一处：存算解耦、数据归仓，多套系统间反复腾挪的成本被一并压缩。4.4 则是在此基础上的进一步延展——已有数据湖不用搬家，新平台的查询能力可以直接向前覆盖。
总结与展望
长城汽车这次架构升级具体解决了三件事：计算资源不再因为存储扩容而被迫跟着涨；HBase 和 InfluxDB 之间的数据可以在同一个平台里联合查询了；运维不用在两套系统之间来回切换了。TCO 降低 40%，是这几件事加在一起的结果。
往后，长城汽车面对的数据挑战只会更复杂。随着新能源车型加速普及和全球市场持续扩张，车端传感器的种类和密度在增加，每日新增数据量还会继续攀升。与此同时，数据的用途也在从"存得下、查得到"向"用得好"演进——驾驶行为分析、预测性维保、精细化运营，这些场景对数据平台的实时性、灵活性和多维联合分析能力的要求只会越来越高。现在打下的存算分离底座，正是为了承接这些还没到来的需求。
已有数据湖的免迁移查询加速，是长城汽车目前正在探索的下一步。这个方向意味着存量数据不需要搬家就能纳入新平台的分析体系，历史积累不会因为架构升级而打折——这也是 Lakehouse 统一湖仓的价值边界还在向外延伸的信号。
有同样处境的企业，可以从长城这个案例里找到一条路径参考：不用等数据规模大到撑不住才动手，也不用一次性推倒重来——先把底座换掉，在现有数据资产的基础上把增长空间留出来，其余的事情可以慢慢来。
欢迎了解云器科技车联网解决方案，扫描下方二维码获取云器汽车数据平台白皮书 。 云器 Lakehouse 已上线腾讯云精品云市场 ， 欢迎搜索订购！
🎁 新用户专享福利
✅ 1 TB 存储 · 1 CRU时/天计算 · 1 年全托管体验
➤ 即刻访问云器官网领取：https://www.yunqi.tech/product/one-year-package
