一、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 成熟度追赶中 | 不支持数据写入/存储 |
4.OLAP选型指引
- 选 StarRocks：多表 Join + 实时更新 + 高并发，追求"一个引擎解决多种分析需求"
- 选 ClickHouse：超大单表聚合、时序分析、日志分析，不介意 Join 能力弱
- 选 Apache Doris：需求与 StarRocks 类似但更看重国内社区支持、运维简单
- 选 Trino：数据散布多源、不需要存储层、已有成熟数据湖基础设施
 agent和组件)