Starrocks架构特性与OLAP选型

2026/7/31 1:50:19

一、StarRocks 架构原理

StarRocks 采用 FE（Frontend）+ BE（Backend）的经典二层架构，从 3.0 版本开始引入 CN（Compute Node）支持存算分离部署模式。

用户 SQL 先进入 FE，被解析成逻辑计划，再被优化成物理执行计划；FE 会把一个查询拆成多个执行片段，下发到多个 BE 并行运行，这是典型MPP模式；查询过程中会涉及Join、聚合、过滤、排序、Shuffle/Broadcast 分发等分布式算子选择，所以 StarRocks 的性能上限，不只取决于单机 CPU，而取决于计划是否合理 + 数据是否能被局部化处理 + 集群并行度。

FE 负责SQL 解析、元数据管理、权限、查询优化、调度协调；BE 节点同时承担计算和存储，数据以列式格式存储在本地磁盘，这是经典的 Shared-Nothing 架构，适合对延迟敏感的实时分析场景；CN 节点为无状态计算节点，数据持久化到对象存储（S3、HDFS、OSS），这一模式支持弹性伸缩、降低存储成本，适合数据量大但查询负载波动明显的场景。这本质上是“控制面/数据面分离”：FE 负责决定怎么跑，BE/CN 负责高吞吐地真正执行。

FE 通常以多副本方式部署以支持高可用，BE/CN 节点可以横向扩展，数据通常有副本机制以提高可用性和容错性，实际上，StarRocks 的扩展方式更像“加机器扩并行度”，而不是“升级单机吃更大查询”。

二、StarRocks 核心特性

1.MPP 并行执行

StarRocks 是 MPP 分析型数据库，一个查询会被切成多个子任务，在多个 BE 上同时执行，它擅长大扫描、大聚合、多维分析；不擅长高频点写、强事务更新那类 OLTP 工作负载。

2.向量化执行引擎

StarRocks 采用全面向量化（Fully Vectorized）执行引擎，从存储层读取到计算层输出，所有算子均以列式批量（Column Batch）方式处理数据，充分利用 CPU SIMD 指令集（SSE4.2 / AVX2），显著减少虚函数调用和分支预测失败的开销。与传统逐行模型相比，向量化引擎在典型聚合查询上可获得3-10 倍性能提升。

3.列式存储

StarRocks 使用列式存储，分析查询只读需要的列，这比行存更适合 BI、报表、宽表聚合，因为能显著减少 I/O。

4.数据跳过与索引能力

StarRocks 具备分区、分桶、列统计等机制，用于减少扫描范围；它支持多种加速过滤/命中的能力，例如 Bitmap 类思路与数据块级跳过能力。它的关键思想不是“把所有数据都扫一遍再算”，而是尽量提前排除不可能命中的数据块。

5.CBO 优化器

StarRocks 具有基于代价的优化器，会综合统计信息选择 Join 顺序、分发策略和物理算子。真正难的不是“支持 SQL”，而是在复杂多表场景下选对执行计划；这一点直接决定查询尾延迟。

6.物化视图

StarRocks 支持物化视图，用于预计算高频聚合或复杂查询结果，可基于调度策略自动刷新；在合适条件下，优化器可以自动把原查询改写为命中物化视图，无需应用层改造；这对固定口径报表、公共指标层、热点查询非常有杀伤力，因为它把“实时重算”变成了“预先算好”。

7.实时导入能力

StarRocks 支持多种导入方式，包括批量导入、流式导入、订阅式导入等，常被用于对接 Kafka/Flink 一类实时数据链路，这决定了它不像传统离线数仓那样只能 T+1，更适合分钟级甚至更低延迟的分析服务。

8.表模型

StarRocks 提供多种表模型，如 Duplicate Key、Aggregate、Unique/Primary Key 等，这些模型的本质不是“语法区别”，而是你在去重、聚合、更新语义、查询性能之间做取舍，实践里最容易犯错的是：没想清楚业务更新语义，就先选表模型，后面会很痛。

9.湖仓/外表能力

StarRocks 近年强化了对外部数据源与湖仓查询能力的支持，可直接查询部分外部存储数据，相比 Trino/Presto 的纯联邦查询模式，StarRocks 可将热数据导入本地获得更高性能，同时保留对冷数据的湖上直查能力，这使它不只是一套封闭存储，也能作为“统一查询层”接湖里的数据。

10.存算分离

3.0 版本引入的存算分离是 StarRocks 架构演进的重要里程碑：

弹性扩缩：CN 节点无状态，可按需快速扩容/缩容
成本优化：热数据本地缓存 + 冷数据对象存储，存储成本下降显著
多租户隔离：不同 Warehouse 可独立使用 CN 资源池

三、常用OLAP对比与选型

1.典型查询延迟对比

2.多维能力对比

3.综合对比表

维度	StarRocks	ClickHouse	Apache Doris	Trino
架构模型	MPP，Shared-Nothing / Shared-Data	MPP，Shared-Nothing	MPP，Shared-Nothing	MPP，Shared-Nothing（纯计算）
存算分离	3.0+ 原生支持	ClickHouse Cloud（商业版）	3.0+ 在推进（Multi-Compute Cluster）	天然无状态计算
执行引擎	全面向量化 + Pipeline	向量化 + Pipeline	向量化 + Pipeline	向量化（部分算子）
优化器	CBO（Cascades 框架，成熟）	RBO 为主 + 部分 CBO	Nereids CBO（2.0+ 引入）	CBO（成熟）
多表 Join	优秀（CBO + Runtime Filter）	较弱（设计偏宽表）	良好（逐步追赶）	优秀（天生联邦设计）
实时写入	Primary Key 模型，毫秒级	批量写入为主，MergeTree	Unique Key 模型，秒级	不支持（只读查询引擎）
并发能力	高（千级 QPS）	中等（百级 QPS）	高（千级 QPS）	中高（依赖资源隔离）
数据湖集成	External Catalog 直查	有限（需外挂或 ClickHouse Cloud）	Multi-Catalog 直查	原生强项（Connector 生态丰富）
物化视图	异步 MV + 自动路由	有限（Projection 为主）	异步 MV + 自动路由	不支持
协议兼容	MySQL 协议	自有协议 + HTTP	MySQL 协议	自有协议（JDBC/ODBC）
开源许可	Apache 2.0	Apache 2.0	Apache 2.0	Apache 2.0
社区活跃度	高（GitHub 9k+ stars）	极高（GitHub 38k+ stars）	高（GitHub 12k+ stars，国内活跃）	高（GitHub 10k+ stars）
典型短板	生态工具链待完善	多表 Join、高并发弱	CBO 成熟度追赶中	不支持数据写入/存储