一、StarRocks 整体架构总览
StarRocks 整体架构极为精简，仅由 FE 和 BE（或 CN）两类进程构成，不依赖任何外部组件（如 ZooKeeper、HDFS 等），极大降低了部署和运维复杂度。
StarRocks 支持两种部署架构：
-
存算一体（Shared-Nothing）：FE + BE 组合，BE 同时负责存储和计算，数据以多副本形式存储在 BE 本地磁盘。
-
存算分离（Shared-Data）：FE + CN 组合，数据统一存储在对象存储（S3/GCS/Azure Blob/HDFS）中，CN 仅负责计算并缓存热数据。
┌─────────────────────── StarRocks 集群 ───────────────────────┐
│ │
│ ┌─────────────────── FE 层 (Java) ───────────────────────┐ │
│ │ │ │
│ │ ┌────────┐ ┌────────┐ ┌────────┐ │ │
│ │ │Leader │◄──►│Follower│◄──►│Observer│ │ │
│ │ │ FE │ │ FE │ │ FE │ │ │
│ │ └────┬───┘ └────────┘ └────────┘ │ │
│ │ │ BDB JE Replication (Raft-like) │ │
│ │ │ │ │
│ │ 职责: 元数据管理 | SQL解析 | 查询优化(CBO) | 调度分发 │ │
│ └───────┼─────────────────────────────────────────────────┘ │
│ │ RPC (Thrift) │
│ ▼ │
│ ┌─────────────── BE/CN 层 (C++) ─────────────────────────┐ │
│ │ │ │
│ │ ┌──────┐ ┌──────┐ ┌──────┐ 存算一体: BE │ │
│ │ │ BE/CN│ │ BE/CN│ │ BE/CN│ 存算分离: CN │ │
│ │ │ #1 │ │ #2 │ │ #3 │ │ │
│ │ └──────┘ └──────┘ └──────┘ │ │
│ │ │ │
│ │ 职责: Pipeline执行 | 向量化计算 | 本地存储/缓存 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└───────────────────────────────────────────────────────────────┘
这种极简架构带来了显著优势：水平扩展无需停服，新增 BE/CN 节点后数据自动 rebalance；FE 多副本通过 BDB JE 的 Replication 协议保证元数据高可用。
二、FE：元数据与查询规划中心
FE（Frontend）基于 Java 开发，是 StarRocks 的"大脑"，承担以下核心职责：
- 元数据管理：维护数据库、表、分区、Tablet 分布等全量元数据信息
- 客户端连接：兼容 MySQL 协议，接受用户 SQL 请求
- 查询规划：SQL Parse → Analyze → Rewrite → Optimize(CBO) → 生成分布式物理执行计划
- 查询调度：将 Fragment Instance 分发到各 BE/CN 节点执行
FE角色划分如下：
|----------|-----------|-----------------|---------------|
| 角色 | 元数据操作 | 选举参与 | 适用场景 |
| Leader | 读写 | 由 Follower 选举产生 | 元数据写入的唯一入口 |
| Follower | 只读（转发写请求） | 参与选举 | 高可用容灾 |
| Observer | 只读 | 不参与选举 | 扩展读并发、不增加选举压力 |
Leader FE 通过BDB JE（Berkeley DB Java Edition）的 Replication 机制将元数据变更日志同步到 Follower/Observer 节点，所有 FE 在内存中保留完整的元数据副本，确保任一 FE 可独立提供查询服务。
三、BE：存储与计算一体引擎
BE（Backend）基于 C++ 开发，在存算一体架构中同时承担数据存储和查询执行两项职责：
数据存储职责
- 数据按分区（Partition）→ 分桶（Bucket）拆分为 Tablet，每个 Tablet 是最小数据管理单元
- 每个 Tablet 以多副本形式分布在不同 BE 上，FE 负责维护副本分布信息
- BE 接收 FE 分发的数据导入任务，完成数据转换、列式编码、索引构建等工作
查询执行职责
-
接收 FE 下发的 Fragment Instance，在 Pipeline 引擎中并行执行
-
全向量化执行引擎：数据按列组织、批量(Chunk)处理、SIMD 指令加速
-
本地数据直接计算，无需网络传输（数据本地性优势）
┌──────────────────── 单个 BE 节点 ────────────────────────┐
│ │
│ ┌─────────────────── Execution Engine ───────────────┐ │
│ │ Pipeline Driver #1 ──► Operator Chain │ │
│ │ Pipeline Driver #2 ──► Operator Chain │ │
│ │ Pipeline Driver #N ──► Operator Chain │ │
│ │ (全向量化 + SIMD) │ │
│ └─────────────────────────────────┬─────────────────┘ │
│ │ pull_chunk() │
│ ┌─────────────────────────────────▼─────────────────┐ │
│ │ Storage Engine (列式存储) │ │
│ │ │ │
│ │ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ │
│ │ │Tablet 1│ │Tablet 2│ │Tablet 3│ │Tablet N│ │ │
│ │ │ (列存) │ │ (列存) │ │ (列存) │ │ (列存) │ │ │
│ │ └────────┘ └────────┘ └────────┘ └────────┘ │ │
│ │ │ │
│ │ 索引: ZoneMap | Bloom Filter | Bitmap | ShortKey │ │
│ └────────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘
四、CN：存算分离下的弹性计算节点
CN（Compute Node）是 StarRocks 3.0 引入的存算分离架构核心组件。CN 本质上是"去掉本地持久化存储的 BE"，具备与 BE 完全相同的计算能力，但不负责数据的持久化存储。
|------|-----------------|----------------------|
| 特性 | BE（存算一体） | CN（存算分离） |
| 数据存储 | 本地磁盘持久化 | 仅本地缓存热数据 |
| 数据来源 | 本地 Tablet | 对象存储 / HDFS |
| 弹性扩缩 | 需要 Rebalance 数据 | 秒级增删节点，无需数据迁移 |
| 执行引擎 | Pipeline + 向量化 | Pipeline + 向量化（完全相同） |
| 适用场景 | 追求极致查询延迟 | 追求弹性 + 成本优化 |
为弥补远程读取延迟，CN 建立了内存 → 本地磁盘 → 远程存储三级数据访问体系。查询时优先命中本地缓存，缓存未命中时从对象存储拉取并缓存到本地磁盘，结合数据预取策略有效消除冷数据查询的性能瓶颈。
┌─── CN 存算分离架构 ───────────────────────────────────────┐
│ │
│ ┌─────┐ ┌─────┐ ┌─────┐ 弹性扩缩 │
│ │ CN1 │ │ CN2 │ │ CN3 │ ◄──── 秒级增减 │
│ └──┬──┘ └──┬──┘ └──┬──┘ │
│ │ │ │ 热数据缓存 (Local SSD) │
│ └────────┼────────┘ │
│ │ 读取 (miss 时拉取) │
│ ▼ │
│ ┌───────────────────────────────────────────┐ │
│ │ 对象存储 / HDFS (持久化层) │ │
│ │ S3 / GCS / Azure Blob / MinIO / HDFS │ │
│ └───────────────────────────────────────────┘ │
│ │
└───────────────────────────────────────────────────────────┘五、元数据管理：EditLog + Checkpoint + BDB JE
StarRocks 的元数据管理机制是理解 FE 高可用的关键。其核心设计采用EditLog + Checkpoint模式，类似 HDFS NameNode 的思路。
- 全内存存储：所有元数据（Database、Table、Partition、Job 等）由 Catalog 对象在内存中持有，保证查询规划时的高效访问
- 仅 Leader 可写：非 Leader 节点将写请求转发给 Leader
- EditLog 持久化：每次元数据变更生成一条自增 JournalId 的日志，通过 BDB JE 写入本地文件并自动同步到 Follower
- Checkpoint 快照：Leader 定期将全量元数据序列化为 image 文件，并通知其他 FE 拉取
EditLog 将变更日志分散存储到 BDB JE 的多个 database 中，默认每 50,000 条日志划分一个 database（database 名即该批次最小的 JournalId）。Checkpoint 完成后会清理已经持久化到 image 中的旧 database，确保 BDB JE 存储量始终可控。
六、存储引擎：Tablet、副本与列存
存储引擎核心特性：
- 列式存储：同列数据连续存放，压缩率高、I/O 少，利于 SIMD 加速
- 多副本：默认 3 副本，FE 基于 Round-Robin 策略将副本分布到不同 BE
- 主键表（Primary Key）：采用 Delete-and-Insert 模式，支持高效 Upsert/Partial Update，通过主键索引快速定位行，无需 Sort-Merge
- 多种表模型：明细表、聚合表、更新表、主键表，适配不同分析场景
七、MPP 查询执行全链路剖析
当一条 SQL 到达 StarRocks，从接收到返回结果，经历以下完整链路：
② ~ ③ Parse & Analyze
FE 使用 ANTLR 生成的 Parser 将 SQL 文本解析为 AST（Abstract Syntax Tree），随后进行语义分析：类型推导、函数签名匹配、权限校验、将表名/列名绑定到元数据对象。
⑤ 规则改写（RBO）
基于一组确定性规则对逻辑计划进行等价变换，常见规则包括：
- 谓词下推（Predicate Pushdown）
- 常量折叠（Constant Folding）
- 列裁剪（Column Pruning）
- 子查询解关联（Subquery Unnesting）
- Limit 下推、分区裁剪
⑥ 代价优化（CBO）
StarRocks 的 CBO 基于 Cascades 框架自研实现，是其查询性能的核心竞争力。CBO 的关键能力包括：
- Join Reorder：在多表 Join 场景下搜索最优的 Join 顺序
- 分布式 Join 策略选择：Broadcast / Shuffle / Colocate / Bucket Shuffle
- CTE 复用：公共子表达式识别与复用
- 低基数优化：全局字典编码，直接在编码数据上计算
- 代价模型：基于 CPU、内存、网络 I/O 综合估算算子代价
CBO 依赖统计信息（行数、NDV、直方图等）来估算代价。StarRocks 支持自动和手动收集统计信息，v3.5+ 还支持多列联合统计。
⑧ Fragment 拆分
物理执行计划按 Exchange 算子边界切分为多个 PlanFragment。每个 Fragment 是可独立并行执行的子树。上游 Fragment 通过 DataStreamSink 向下游 Fragment 的 ExchangeNode 发送数据。
⑨ 调度分发
FE 根据数据分布（Tablet 所在 BE）确定每个 Fragment 的实例数量和执行目标节点，然后一次性（All-at-once）将所有 Fragment Instance 投递到对应 BE/CN。