1. 存算一体架构 (Shared-nothing)

存算一体架构是 StarRocks 的经典架构，其特点是极简、无外部依赖、服务高可用且易于扩展 。整个系统主要由 FE 和 BE 两类进程组成 。

1.1 FE (Frontend)

FE 是 StarRocks 的前端节点，使用 Java 语言开发 。它负责元数据管理、客户端请求接收与返回、查询规划与调度等 。

FE 角色

一个 StarRocks 集群可以有多个 FE 节点，以保证高可用。FE 节点有三种角色：

• Leader: 通过选举产生，是唯一可以写入元数据的节点 。
• Follower: 负责元数据读取，并参与 Leader 选举 。当半数以上 Follower 存活时，才能进行有效的 Leader 选举 。
• Observer: 也负责元数据读取，用于扩展集群的读取能力，但不参与选举 。

FE 元数据管理

• 元数据内容: 每个 FE 都存有完整的元数据副本 ，主要包含四类信息：
  1. 数据信息（库、表结构、分片等）。
  2. 作业信息（导入、Clone、Schema Change 等）。
  3. 用户及权限信息 。
  4. 集群及节点信息 。
• 持久化: 使用 Oracle Berkeley DB Java Edition (BDBJE) 来持久化元数据操作日志，并通过日志同步实现 FE 节点间的数据一致性和高可用 。元数据会定期生成镜像文件 (image) 以加快启动时加载速度 。

FE 查询规划与调度

FE 负责将接收到的 SQL 查询转换成物理执行计划 。这个过程包括：

1. 解析 (Parser): 将 SQL 文本转换为抽象语法树 (AST) 。
2. 分析 (Analyzer): 结合元数据对 AST 进行分析 。
3. 重写与优化 (Rewriter & Optimizer): 基于规则和成本估算对逻辑计划进行优化，生成最优的分布式物理执行计划 。
4. 调度: 将物理计划下发给 BE 节点执行 。

1.2 BE (Backend)

BE 是 StarRocks 的后端节点，使用 C++ 语言开发 。它负责执行 FE 下发的计划，并管理本地数据的存储 。

存储引擎 (Storage Engine)

• 数据分布: 表中的数据通过两层结构进行分布：
  1. 分区 (Partition): 按范围 (Range) 对数据进行第一层切分 。
  2. 分桶 (Bucket): 在分区内，按哈希 (Hash) 将数据切分为更小的逻辑单元，即 Tablet 。Tablet 是数据分片和副本管理的基本单位 。
• 存储格式:
  • 数据以 Tablet 的形式物理存储 。
  • 采用列式存储，并使用 LZ4 等算法进行压缩 。
  • 为数据创建多种索引（如 Short Key Index, Zone Map Index）以加速查询 。

执行引擎 (Execution Engine)

• BE 的执行引擎采用 MPP (Massively Parallel Processing) 多机并行计算模型 。
• 它接收 FE 下发的执行计划片段 (Fragment)，在多个 BE 节点上并行执行 。
• 通过 Shuffle 算子实现数据在节点间的交换，以完成分布式的 Join 和聚合计算 。

1.3 Broker 组件 (可选)

Broker 是一个独立的、无状态的 Java 进程，用于封装文件系统接口，帮助 StarRocks 读写 HDFS、S3、OSS 等远端存储系统上的文件 。

• 从 2.5 版本开始，BE 节点也可以直接访问外部存储，但在多 HDFS 集群或多 Kerberos 用户的复杂场景下，使用 Broker 仍然更加方便 。

2. 存算分离架构 (Shared-data)

为了实现计算和存储资源的独立弹性伸缩，降低成本并提高资源利用率，StarRocks 推出了存算分离架构 。该架构将存储和计算解耦，系统由 FE、CN 和对象存储三部分组成 。

2.1 FE (Frontend)

• 在存算分离架构中，FE 的功能与存算一体架构类似，仍然负责元数据管理和查询规划 。
• 元数据目前仍存储在 FE 的本地磁盘上 。
• 内部集成了 StarManager 模块，用于计算和存储资源的统一管理与调度，但对用户透明 。

2.2 CN (Compute Node)

• CN 是由 BE 演进而来的无状态计算节点 。
• 它负责执行 FE 下发的查询计划，但不持久化存储数据，所有数据均持久化至后端存储 。
• 为了提升性能，CN 会利用本地磁盘缓存热点数据 。查询时会优先读取本地缓存，若未命中则从远端对象存储拉取数据并存入缓存 。
• 由于 CN 无状态，其扩缩容可以在秒级完成，无需数据搬迁 。

2.3 对象存储 (Object Storage)

• 所有数据都以 StarRocks 自有的文件格式持久化存储在对象存储上，如 AWS S3, HDFS, Aliyun OSS 等 。
• 这种模式可以充分利用 Primary Key 更新、Colocate Group 等高级特性 。
• 在对象存储中，数据通常被组织在 data、meta、log 等目录下 。

3. 架构选择

存算一体和存算分离架构功能一致、性能相近，旨在互补，满足不同业务场景的需求 。

推荐使用存算分离的场景

• 存储成本高，有大量冷数据 。
• 集群资源利用率波动大，有明显的波峰波谷 。
• 多业务共享集群，资源争抢严重 。
• 对服务高可用和故障转移有强烈需求 。
• 基于公有云或 K8s 部署，希望实现资源的按需弹性伸缩 。
• 运维多套集群压力大，希望统一存储，简化运维 。

存算分离目前尚不适用的场景

• 环境中不具备对象存储或 HDFS 。
• 写入频率非常高（如间隔小于 10s）且并发量大 。
• 对查询性能有极其严格的要求，无法接受任何冷查询场景下的性能下降 。