理想汽车基于StarRocks构建海量数据分析平台，应对车辆数据激增的挑战。文章介绍了从存算一体到存算分离的架构演进，解决了稳定性、性能和效率问题。通过Multi-Warehouse实现隔离，并基于K8s探索弹性伸缩。最终目标是构建稳定、高效、易用的查询分析服务，以数据驱动汽车智能化。

🚗 理想汽车面临海量车辆数据分析挑战，数据类型包括车机埋点、车辆信号和视频图像等。为应对数据量激增，理想汽车希望构建稳定、高效、易用的查询分析服务。

🛠️ 在存算一体架构下，理想汽车通过规范使用、多级隔离、限流降级等手段提升稳定性。同时，通过DQS和SQL优化，提升查询性能。然而，存算一体架构仍存在扩容不灵活、资源利用率低等问题。

💡 为了解决存算一体架构的局限性，理想汽车采用存算分离架构。利用Multi-Warehouse实现内外表隔离，并通过BOS存储冷数据。通过在K8s上部署StarRocks，实现弹性伸缩，提高资源利用率。

海博 2025-04-24 21:22 四川

分享嘉宾

INTRODUCTION

海博

理想汽车

大数据工程师

专注于大数据计算领域，曾参与过多个数据平台的建设。目前负责理想汽车 OLAP 引擎 StarRocks 和时序引擎 MatrixDB 的应用和周边生态的建设。

---

01

海量数据分析的挑战

首先来介绍一下理想汽车海量数据分析场景。

1. 背景：海量数据分析驱动汽车数字化、智能化

与互联网数据分析不同，汽车制造业的数据分析场景主要围绕车辆数据进行分析，除了企业经营数据，大部分数据是从车端采集而来。车辆数据主要包括三类：

车机埋点数据：来自于车辆上类似 pad 的车机，其中会有一些行为埋点数据，采集分析后用于驱动智能座舱的迭代。

车辆信号数据：即车辆元器件产生的信号，比如刹车、速度、里程等各种 IoT 数据，后续会应用于车辆制造和车辆状态的监测等场景。

视频图像：来自于智能驾驶传感器，比如摄像头采集的数据，后续将应用于智能驾驶模型的迭代。

这些来自车端的数据每天都会达到万亿级别，通过采集、分析这些海量数据，再应用回车辆，从而打造更智能的车，以数据去驱动汽车的数字化、智能化。

2. 海量数据分析面临的问题

在海量数据分析过程中会面临诸多问题，主要包括三个方面：

稳定性问题：

使用缺乏规范，告警覆盖不完全，导致问题发现难；

问题 SQL 难拦截，业务混用难隔离，单个业务异常可能导致整个集群受影响；导致故障时止损困难。

问题定位比较难，组件自身 BUG 可能潜藏很深，难以定位，人肉查日志费时费力。

性能问题：由于 Cache 或慢节点等原因，Hive 查询时快时慢；另外，我们采用 Spark 加 StarRocks 结合 Linkis 的技术栈支持 ad-hoc 查询，由于一些技术限制，这部分查询也比较慢。

效率问题：资源使用周期明显，高峰和低谷差异大，资源利用率低，且使用成本高。

3. 目标:基于 StarRocks 构建稳定、高效、易用的查询分析服务

针对上述问题，我们希望基于 StarRocks 构建一套稳定、高效、易用的查询分析服务。

稳定性：通过规范使用、多级隔离、限流降级等能力提升稳定性。

高效性：通过优化查询性能和资源利用率提高效率。

易用性：通过统一查询服务、产品化和服务化能力降低使用门槛。

我们在查询分析层，基于 StarRocks 集群封装了一层 DQS 统一查询服务。产品化方面，构建了 OLAP 云产品，全面覆盖集群的管理，包括新建、扩缩容、元数据管理等操作，以降低用户使用门槛。此外，我们还希望基于 K8s、Serverless 探索弹性伸缩、按量使用的方式，以进一步提升资源利用率。

4. 发展历程

在理想汽车，StarRocks 引擎的迭代经历了三个阶段。

第一阶段：当时面对的主要问题是多种引擎共存，资源成本高，运维成本高,使用成本高。因此我们将 OLAP 引擎统一为 StarRocks，当时基本上是裸机的使用，产品化、服务能力还比较弱，因此存在稳定性不足问题。

第二阶段：解决稳定性问题，提升产品化能力。构建完善的监控，告警，巡检体系；做好集群规划流程建设，规范用户使用；利用资源组隔离的能力将大业务隔离，并跟进社区最新版本；完善元数据，数据导入等产品能力。

第三阶段：在解决稳定性问题之后，存算一体架构的弊端逐渐暴露，因此我们开始探索云原生能力和存算分离的架构。

5. 集群规模现状

当前存在 10+ 集群，1w+ CPU cores，每天有超过 1000w 的 query，100 亿级别的写入。

02

存算一体的实践

接下来介绍我们基于存算一体架构的一些实践经验，及其存在的一些问题。

1. 稳定性保障

首先是解决稳定性问题。针对用户使用不规范的问题，我们制定了一套完善的用户使用 SOP，并将其产品化，通过系统的手段对用户进行约束。

接入前：实现了集群管理的产品化。在申请资源时，系统可预估资源使用量，从而避免申请的资源量过多或过少。

接入中：实现了监控的产品化，包括对慢查询和趋势等的监控。

接入后：实现了治理的产品化。

基于 SOP 建设了一整套完整的稳定性保障体系。

事前：识别并避免风险

完善的监控、巡检能力。

拦截大 Query：如扫全表、查询超大 Hive 表、结果集过多等异常 SQL。

限制元数据风险操作：建十年空分区、单次刷全年物化视图。

发布、升级等线上操作后进行 query 回归测试。

事中：快速止损、缩小影响范围

按业务、场景隔离多个集群。

单集群内隔离大查询、高优业务。

熔断大查询。

事后：持续治理阻断风险

持续治理问题 SQL、问题表。

复盘、压测。

虽然我们建设了完整的稳定性保障体系，但是受限于 StarRocks 存算一体架构，其本身还是存在一些问题。

首先，多业务混用、资源隔离不足。单个业务的异常会影响其他业务、无法有效隔离不同业务之间的资源使用。单业务打满集群 CPU 或磁盘，会导致其他业务无法查询或写入。

除了共享集群中多个业务混用的情况之外，还存在内外表两种场景混用的情况，外表依赖多种外部组件如 hdfs、s3、metastore，天然不稳定，外部依赖异常时可能致使集群不可用。

2. 性能问题解决

另一方面是性能的问题。最初使用 Linkis 加 Spark EC 来实现 ad-hoc 查询，速度慢。

我们使用自研的 DQS 的服务，再加上底层的 StarRocks 引擎的方案替代了原有组合，取得了十倍的性能提升。

StarRocks 替代 Spark：

HiveMetastore 元数据实时同步，减少元数据延迟；

资源常驻，且 SR 具有强劲的计算能力，可大幅提升查询速度；

Hedged Read 解决读 HDFS 遇到慢节点的问题。

DQS 替代 Linkis：

免去 EC 启动时间；

拦截超大 Query；

路由至 Spark 兜底。

提升性能的另一方面是 SQL 优化。基于以往积累的 SQL 优化规则沉淀成文档后，我们尝试将能力内化为服务化功能，辅助用户自助分析并推送解决方案。常见的慢 SQL 主要包括 Scan 节点慢、Join 慢、涉及 shuffle 的操作慢、建表不合理导致并发不上去、本机执行慢等五类场景。详细原因和优化措施如上图中所示。

3. 存算一体架构存在的问题

存算一体架构存在固有局限性。

首先是扩容成本比较高，扩容不灵活。因为存储和计算资源耦合在一起，其中一方资源到达瓶颈，另一方也必须随着一起扩容。以我们的车辆自助分析平台场景为例，最初是基于 APP 层数据和少量明细数据提供自助分析服务，数据规模较小，后续需要接入量级较大的车机埋点和部分车辆信号数据，当时按存储需扩容 20 台。这样为了扩磁盘需扩容大量机器，造成了 CPU 和内存的浪费。同时，冷数据被查到的频率很低，也造成了存储资源的浪费。

存算一体架构的另一个典型问题就是弹性伸缩能力弱，资源利用率低。在我们的智驾场景中，需要将打标数据更新到 StarRocks 的一个主键表中，用于后续模型加工。在这一场景的特点是 query 都很大，因此资源消耗大，并且对查询性能要求高，同时查询峰值高、概率低。为了满足峰值的要求，我们必须按峰值进行资源配置，造成了大量的资源浪费。

03

存算分离的实践

接下来介绍如何通过存算分离架构解决存算一体架构存在的问题。存算分离模式下，存储与计算解耦，各自独立服务，独立扩缩容，解决存算一体模式下资源浪费的问题。计算节点可以实现秒级的动态扩缩容，提升计算资源的利用率。

1. Multi-Warehouse 解决隔离问题

首先是解决隔离问题。

StarRocks 企业版提供了 Multi-Warehouse 的能力，在一个集群中可以根据机器做纵向切分，即一个集群可以分为若干小集群，共享元数据和数据。我们基于 Multi-Warehouse 能力做了三级隔离：

内外表集群隔离：避免外表 ad-hoc 影响内表更高优的业务；外表集群再隔离出 bi warehouse，避免被 ad-hoc 影响。

业务隔离：高低优业务物理隔离；业务内资源组隔离，限制大查询。

读写分离：我们希望将读写分离，避免写操作对查询造成影响。但探索中遇到了一些问题。

我们没有将内外表集群合成一个集群，是因为 StarRocks 有 FE、BE 两个组件，FE 是元数据加执行计划生成和调度的组件，BE 是数据存储和执行组件，目前仅 BE 可以存算分离，FE 是无法实现隔离的，所以我们仍需将内外表分开以避免外表查询导致 FE 异常，进而引发整个集群崩溃。

另外，读写分离尚未实现，是因为 StarRocks 后台有 compaction 操作，会做小文件的合并，目前 compaction 只能在单个 warehouse 中执行，导致 compaction 结果需要从 BOS 上加载到 CN 节点的 local cache，这样就会导致查询变慢。

2. 存算分离解决扩容不灵活、成本高的问题

第二是解决扩容不灵活、成本高的问题。针对前文介绍的车辆数据分析场景中的问题，我们主要采取了两项措施：一是采用存算分离架构，将冷数据存储在百度云对象存储 BOS，这样将存储和计算资源分开；二是采用资源削峰的措施，在夜间进行预计算，通过调参降低 CPU 的使用峰值，白天将预计算结果服务于用户。两项措施共同作用下，实现了保证查询性能不下降的前提下，机器资源节省了 30%。

3. StarRocks on K8s 解决弹性伸缩问题

通过将 StarRocks 部署于 K8s 上来解决弹性伸缩问题。Spark 和 StarRocks 资源波峰波谷互补，夜间 Spark 使用资源生产数据，日间 StarRocks 使用资源分析数据，因此我们将 Spark 和 StarRocks 共同部署在 K8s 集群中，利用 volcano 进行调度，互相削峰填谷，这样资源利用率可提高 50%。

04

总结和规划

基于存算分离架构，我们对未来工作的规划为：

首先，只有一个集群。FE 存算分离后共享元数据，按场景隔离 FE 实例。

第二，按场景切分 warehouse，实现内外分离、读写分离、高优低优业务分离。

第三，实现资源弹性、按量付费。将 ad-hoc、低优场景部署在 K8s 上，实现弹性伸缩；内表场景设置弹性 warehouse；故障时，基于 K8s 快速拉起 backup 集群，实现快速止损和恢复。

加微信，进群深度交流理想长期基本面。不是车友群。

阅读原文

跳转微信打开