StarRocks 集群架构部署选型与优化实践

一、引言

StarRocks 的集群部署不只是"装几个 FE、BE 或 CN"，真正影响生产稳定性的，是架构模式、节点角色、数据分布、导入节奏、Compaction、资源隔离和监控体系之间的组合关系。

StarRocks 的核心架构可以理解为"FE 管元数据和查询调度，BE/CN 执行计算，数据根据架构模式放在本地磁盘或远端存储"。在 Shared-nothing 架构中，BE 同时负责本地数据存储和 SQL 执行；在 Shared-data 架构中，CN 负责计算和缓存，持久数据放在对象存储或 HDFS 中。

FE 内部又分为 Leader、Follower 和 Observer。Leader 负责元数据读写，Follower 参与元数据复制和 Leader 选举，Observer 只同步元数据并服务读请求，不参与选举；建议生产环境至少部署 3 个 Follower FE，以避免单点故障。

二、两种部署模式

StarRocks 当前最重要的部署决策，是选择 Shared-nothing 还是 Shared-data。Shared-nothing 更像传统 MPP OLAP 集群，数据放在 BE 本地磁盘上，查询尽量在数据所在节点本地完成；Shared-data 则更接近云原生湖仓架构，数据放在对象存储或 HDFS，CN 只保存本地缓存，扩缩容时无需迁移持久数据。

维度	Shared-nothing 存算一体	Shared-data 存算分离
节点组成	FE + BE	FE + CN
数据位置	BE 本地磁盘	对象存储或 HDFS
计算节点	BE	CN
高可用方式	Tablet 多副本，默认三副本	依赖远端存储可靠性，CN 无状态
扩容影响	BE 扩容后触发 Tablet 均衡	CN 扩容不需要数据迁移
成本结构	本地多副本，存储成本较高	远端存储更弹性，计算按需扩展
性能特征	本地 I/O，低延迟优势明显	热数据命中缓存时性能接近存算一体
典型场景	实时数仓、低延迟 BI、高 QPS 聚合查询	云上弹性、多租户隔离、冷热分层、低成本大规模存储

Shared-data 集群不支持与 Shared-nothing 混部，也不支持二者相互直接转换；如果已有存算一体集群想迁移到存算分离，不能简单改配置原地切换，而应按迁移项目重新规划部署、数据同步与业务割接。

三、场景化选型

如果业务追求极致低延迟、查询负载稳定、数据热度高、存储成本不是首要矛盾，Shared-nothing 是更稳妥的默认选择。它通过 BE 本地存储与多副本机制降低远端 I/O 影响，适合实时指标看板、明细钻取、交互式分析和高并发 BI 查询 。

如果业务运行在云上，数据规模增长快，计算负载呈明显峰谷，或希望把存储成本和计算弹性拆开治理，Shared-data 更值得优先评估。Shared-data 模式下 CN 是无状态计算节点，数据保存在对象存储或 HDFS 中，CN 本地只保留缓存，因此扩缩容时不需要像 BE 那样做数据重平衡 。

                         +---------------------+
                         |  StarRocks 选型入口 |
                         +----------+----------+
                                    |
                 +------------------+------------------+
                 |                                     |
        查询延迟极敏感                         云上弹性和成本优先
        热数据占比高                           数据规模增长快
        负载相对稳定                           计算峰谷明显
                 |                                     |
                 v                                     v
       Shared-nothing                         Shared-data
       FE + BE                                FE + CN
       本地多副本                             远端存储 + 本地缓存
                 |                                     |
                 v                                     v
       重点优化 Tablet、Compaction、            重点优化 Cache、资源隔离、
       本地磁盘、导入节奏                      CN 弹性和远端存储访问

有三类场景要谨慎选择 Shared-data。第一，强依赖备份恢复能力的场景，存算分离集群不支持数据备份与恢复；第二，强依赖某些尚未支持特性的场景，例如官方 Shared-data 支持范围页列出的部分能力限制；第三，期望在同一集群中混用 BE 和 CN 的场景，因为官方明确不支持混部。

四、生产部署基线

生产环境的最小高可用基线可以概括为：FE 至少 3 个 Follower，Shared-nothing 至少 3 个 BE，Shared-data 根据计算负载规划 CN 数量。建议 FE 节点可按 8 CPU cores、16 GB RAM 起步，BE/CN 可按 16 CPU cores、64 GB RAM 起步，FE 因主要维护元数据，多数场景约 100 GB HDD 可满足需要。

组件	生产建议	主要职责	扩展方向
FE Follower	至少 3 个	元数据复制、Leader 选举、查询调度	保证元数据高可用
FE Observer	按需增加	承担读请求，不参与选举	扩展连接和查询规划能力
BE	至少 3 个	本地存储、查询执行、导入写入	扩展存储、计算和并发
CN	按计算负载规划	查询执行、热数据缓存	弹性扩缩容、资源隔离

Shared-nothing 的容量规划要把副本数和压缩比放进模型。BE 总存储估算公式是：Total BE storage space = Raw data size * Replica count / Compression ratio，默认副本数通常为 3，压缩比一般可按 3:1 到 5:1 估算，但实际值会受字段类型、编码、排序键和数据分布影响。

Shared-nothing 容量估算：

原始数据：100 TB
副本数量：3
压缩比：  4:1

BE 总存储 ≈ 100 TB * 3 / 4 = 75 TB

建议再预留：
- Compaction 临时空间
- 副本修复空间
- 导入峰值空间
- 未来增长空间

五、参数治理

StarRocks 参数治理的第一原则，是区分"配置项"和"系统变量"。FE/BE 配置项分为动态和静态，动态配置可以在线调整，但如果需要重启后仍然生效，应同步修改fe.conf或be.conf；静态配置必须修改配置文件并重启组件。

系统变量则主要作用于查询、导入和会话行为，支持 Global、Session 和单语句SET_VARHint 三种层级。优先级可以理解为：全局变量提供默认值，会话变量覆盖全局值，单条 SQL 的SET_VAR覆盖当前会话值，这可以针对少数大查询临时放宽query_mem_limit或query_timeout，而不是把全局参数调得过于宽松。

参数生效层级：

配置文件 fe.conf / be.conf / cn.conf
        |
        |  静态参数：重启生效
        |  动态参数：可在线调整，建议同步写配置文件
        v

系统变量 GLOBAL
        |
        v
系统变量 SESSION
        |
        v
单 SQL SET_VAR Hint

调参对象	推荐方式	适用场景
FE 元数据、调度、管理类配置	fe.conf + 必要时在线调整	集群级行为、持久化配置
BE/CN 执行、导入、Compaction 配置	be.conf / cn.conf + 动态参数	节点执行能力和后台任务
查询内存、超时、并行度	Session 或 SET_VAR	单业务、单查询、临时放宽
查询队列	Global 变量	集群过载保护
资源组	Resource Group DDL	多租户隔离、业务优先级控制

六、查询与并发控制

查询稳定性不应只依赖"加机器"。在高并发 OLAP 场景中，更合理的控制链路是：先用单查询参数约束异常大查询，再用 Query Queue 做全局削峰，最后用 Resource Group 做业务隔离。StarRocks 自 v2.5 起支持查询队列，当并发数、BE 内存或 CPU 使用率达到阈值后，新查询会进入排队状态，以避免系统过载继续放大。

目标	参数或机制	建议思路
控制单查询内存	query_mem_limit	大查询用 SET_VAR 单独放宽，避免全局放大
控制长查询	query_timeout	面向即席查询设置合理超时
控制查询并发	query_queue_concurrency_limit	防止 BE 被过多并发打满
按资源触发排队	query_queue_mem_used_pct_limit、query_queue_cpu_used_permille_limit	用资源水位保护稳定性
业务隔离	Resource Group	按用户、角色、库、IP、查询类型路由

Resource Group 适合多租户、混合负载和核心业务保障场景。资源组可以配置 CPU 权重或硬隔离、mem_limit、concurrency_limit、大查询限制等；从 v3.3.5 起支持 CPU 硬隔离，v4.1 起又支持百分比形式的 CPU 权重和硬隔离配置，但 CPU 相关参数之间存在互斥关系，不能同时配置多个正值。

查询治理分层：

用户 / BI / 应用
      |
      v
Classifier 匹配资源组
      |
      +--> short_query   ：保障短查询低延迟
      |
      +--> normal_group  ：普通分析查询
      |
      +--> etl_group     ：INSERT / 统计 / 后台任务
      |
      v
Query Queue 判断是否排队
      |
      v
BE / CN 执行

七、导入链路优化

实时 OLAP 集群最常见的问题之一，是导入端把系统拖垮。StarRocks 的导入内存参数通常限制的是"单个导入作业在单个 BE/CN 上的内存使用"，不是整个集群级总内存；高并发导入还需要关注 load_process_max_memory_limit_bytes 和 load_process_max_memory_limit_percent 这类总量保护参数 。

Stream Load 适合少量文件和同步导入场景，建议单文件不超过 10 GB；大量文件、单文件超过 10 GB 或文件位于 NAS 时，建议考虑 Broker Load。Stream Load 默认 streaming_load_max_mb 为 10 GB，调大虽然可放宽单次导入大小，但可能降低性能并增加失败重试成本 。

Routine Load 适合持续消费 Kafka Topic 并导入 StarRocks，底层导入任务通过 Stream Load 机制执行。它的实际并行度由存活 BE 数、Kafka 分区数、作业期望并发和 FE 全局并发上限共同决定，因此"只调大并发参数"不一定能提升吞吐，Kafka 分区数和 BE/CN 资源也必须匹配 。

Kafka -> Routine Load -> Stream Load Task -> BE/CN Writer -> Tablet Version
          |                    |                 |
          |                    |                 +-- write_buffer_size
          |                    +-- 并发任务数
          +-- Kafka 分区数

吞吐瓶颈可能来自：
1. Kafka 分区不足
2. BE/CN 存活节点不足
3. Routine Load 并发上限不足
4. 导入内存限制过小
5. Compaction 跟不上

导入参数中最容易被误调的是write_buffer_size。该参数默认 100 MB，过小会产生大量小文件并影响查询性能，过大则可能导致 RPC 超时；因此它不应被简单理解为"越大越好"，而应结合导入批次大小、网络、BE/CN 内存和 Compaction 能力一起压测。

八、Compaction 治理

Compaction 是 StarRocks 运维中最需要持续观察的后台机制之一。每次导入都会产生新版本，Compaction 负责把多个版本的数据文件合并成更大的文件，减少小文件数量并提升查询效率；如果导入频率高而 Compaction 跟不上，查询延迟、导入延迟甚至写入失败都会出现 。

建议关注 Compaction Score，尤其是 MaxCS。在存算分离 Compaction 文档中，MaxCS < 10 通常表示 Compaction 完成，MaxCS > 100 表示较高，MaxCS > 500 表示需要人工介入；当超过 lake_ingest_slowdown_threshold 默认 100 时系统会减缓导入提交，超过 lake_compaction_score_upper_bound 默认 2000 时会拒绝导入事务 。

Compaction 健康度观察：

MaxCS < 10
  |
  +-- 通常健康

10 <= MaxCS <= 100
  |
  +-- 观察趋势

100 < MaxCS <= 500
  |
  +-- 导入与查询可能受影响，需分析导入频率和小文件

MaxCS > 500
  |
  +-- 需要人工介入

MaxCS > 2000
  |
  +-- 存算分离场景可能拒绝该分区导入事务

生产实践中，Compaction 问题往往不是单点参数问题，而是导入批次、分区粒度、分桶数量、Tablet 数量和后台线程共同作用的结果。如果某张表分区过细、Tablet 过多、高频小批量导入又集中打到少数分区，即使机器 CPU 和内存看起来还有余量，Compaction 仍可能成为系统瓶颈。

九、表设计与数据分布

StarRocks 表设计的核心可以概括为三句话：分区负责粗粒度裁剪和生命周期管理，分桶负责分区内并行度与数据均衡，排序键负责存储层数据裁剪和压缩。

一次查询的裁剪路径：

SQL WHERE 条件
      |
      v
分区裁剪：减少扫描分区
      |
      v
分桶定位：提升并行度与局部性
      |
      v
排序键裁剪：Segment / Page / 前缀索引裁剪
      |
      v
扫描更少数据，减少 CPU、I/O 和内存消耗

分区通常适合事实表和事件流表，典型键是按时间表达式分区；小维表或查找表通常不建议分区，依赖哈希分布即可。复合分区虽然可以提升裁剪效果，但会带来分区数膨胀，例如 tenant_id × days，总分区数过高会增加 FE 内存和 BE Compaction 压力 。

分桶选择要看查询和写入模式。Random Bucketing 适合日志、事件、多租户 SaaS 等写入密集且查询键不稳定的场景，但不支持分桶裁剪、Colocate Join 和本地聚合等能力；Hash Bucketing 更适合过滤键或 Join 键稳定的数仓工作负载，但需要选择稳定、均匀、高基数的分桶键，并持续观察 Tablet 大小 。

排序键对 OLAP 查询的收益通常很高。建议先分析 Top-N 查询模式，排序键顺序可按"高选择性等值列、主要范围列、辅助聚簇列"选择，同时避免排序键过宽，因为过宽会拖慢导入并可能影响前缀索引效果 。

十、物化视图加速

当查询模式相对稳定、聚合或 Join 成本较高时，异步物化视图是 StarRocks 中值得优先考虑的优化手段。异步物化视图支持透明查询改写，部分 SPJG 查询可以在不修改 SQL 的情况下被改写到物化视图上，从而减少计算成本并提升查询速度 。

分区物化视图适合大事实表上的增量刷新和局部物化，能够避免每次刷新都重算全量数据。分区物化视图通常需要基于分区基表创建，并支持通过 date_trunc 做更粗粒度的上卷分区；这类能力特别适合实时明细表上构建小时、天、月级聚合视图 。

明细表 -> 分区物化视图 -> 查询改写

fact_event_daily
      |
      |  refresh by partition
      v
mv_event_agg_daily
      |
      |  transparent rewrite
      v
BI 查询命中 MV

物化视图不是万能索引。它适合稳定、重复、代价高的查询模式，不适合大量随机、低复用、频繁变更口径的临时分析；否则刷新成本和维护复杂度可能抵消查询收益。

十一、监控与告警

推荐使用 Prometheus 和 Grafana 做可视化监控，通过 FE/BE/CN 的 HTTP 端口抓取/metrics，再用 Grafana Dashboard 展示指标与告警。生产环境建议将 Prometheus 和 Grafana 独立部署，避免与 StarRocks 服务混部造成资源竞争。

监控对象	重点指标或现象	运维含义
FE Alive	FE 是否存活	判断元数据服务可用性
BE/CN Alive	执行节点是否存活	判断查询和导入执行能力
Query Error	查询错误数	发现 SQL、资源或稳定性问题
Query Latency	查询延迟百分位	观察用户体验和长尾延迟
Compaction Score	版本合并积压	判断导入与后台合并是否平衡
Clone Failed	副本修复失败	判断数据副本恢复风险
Load Error	导入失败	判断实时链路稳定性