一、StarRocks 整体架构总览StarRocks 整体架构极为精简仅由 FE 和 BE或 CN两类进程构成不依赖任何外部组件如 ZooKeeper、HDFS 等极大降低了部署和运维复杂度。StarRocks 支持两种部署架构存算一体Shared-NothingFE BE 组合BE 同时负责存储和计算数据以多副本形式存储在 BE 本地磁盘。存算分离Shared-DataFE 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 节点后数据自动 rebalanceFE 多副本通过 BDB JE 的 Replication 协议保证元数据高可用。二、FE元数据与查询规划中心FEFrontend基于 Java 开发是 StarRocks 的大脑承担以下核心职责元数据管理维护数据库、表、分区、Tablet 分布等全量元数据信息客户端连接兼容 MySQL 协议接受用户 SQL 请求查询规划SQL Parse → Analyze → Rewrite → Optimize(CBO) → 生成分布式物理执行计划查询调度将 Fragment Instance 分发到各 BE/CN 节点执行FE角色划分如下角色元数据操作选举参与适用场景Leader读写由 Follower 选举产生元数据写入的唯一入口Follower只读转发写请求参与选举高可用容灾Observer只读不参与选举扩展读并发、不增加选举压力Leader FE 通过BDB JEBerkeley DB Java Edition的 Replication 机制将元数据变更日志同步到 Follower/Observer 节点所有 FE 在内存中保留完整的元数据副本确保任一 FE 可独立提供查询服务。三、BE存储与计算一体引擎BEBackend基于 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存算分离下的弹性计算节点CNCompute 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 JEStarRocks 的元数据管理机制是理解 FE 高可用的关键。其核心设计采用EditLog Checkpoint模式类似 HDFS NameNode 的思路。全内存存储所有元数据Database、Table、Partition、Job 等由 Catalog 对象在内存中持有保证查询规划时的高效访问仅 Leader 可写非 Leader 节点将写请求转发给 LeaderEditLog 持久化每次元数据变更生成一条自增 JournalId 的日志通过 BDB JE 写入本地文件并自动同步到 FollowerCheckpoint 快照Leader 定期将全量元数据序列化为 image 文件并通知其他 FE 拉取EditLog 将变更日志分散存储到 BDB JE 的多个 database 中默认每 50,000 条日志划分一个 databasedatabase 名即该批次最小的 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 AnalyzeFE 使用 ANTLR 生成的 Parser 将 SQL 文本解析为 ASTAbstract Syntax Tree随后进行语义分析类型推导、函数签名匹配、权限校验、将表名/列名绑定到元数据对象。⑤ 规则改写RBO基于一组确定性规则对逻辑计划进行等价变换常见规则包括谓词下推Predicate Pushdown常量折叠Constant Folding列裁剪Column Pruning子查询解关联Subquery UnnestingLimit 下推、分区裁剪⑥ 代价优化CBOStarRocks 的 CBO 基于 Cascades 框架自研实现是其查询性能的核心竞争力。CBO 的关键能力包括Join Reorder在多表 Join 场景下搜索最优的 Join 顺序分布式 Join 策略选择Broadcast / Shuffle / Colocate / Bucket ShuffleCTE 复用公共子表达式识别与复用低基数优化全局字典编码直接在编码数据上计算代价模型基于 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。