第2章 架构解构

第 2 章 · 架构解构：FE、BE 与一条查询的旅程

章节摘要：调优手册讲的是"怎么做"，本章讲的是"为什么会这样"。我们把 Doris 拆成 FE（前端节点）与 BE（后端节点）两个角色，看清元数据如何保持一致、查询计划如何被切分分发、数据以什么形态躺在磁盘上。理解了这台机器的解剖结构，第 4 章导入排错时的每一个报错码、第 5 章执行计划里的每一条算子树，都找到了对应的器官。

学习目标

完成本章后，你应当能够：

1. 画出一张 FE 三角色加 BE 多节点的集群拓扑，标出元数据流与数据流的路径；
2. 说明 Master、Follower、Observer 在写入与查询中各自的职责边界；
3. 解释一条 SQL 从解析到返回要经过哪五个阶段，以及每个阶段发生在哪种节点上；
4. 用 Tablet、Rowset、Segment 三个词组准确描述一张表的物理形态；
5. 面对集群抖动时，判断应当先看 FE 元数据指标还是 BE 执行指标。

核心概念速览

Doris 的架构哲学是"两类角色，各司其职"。FE 是控制平面：管理元数据、调度副本、规划查询；BE 是数据平面：持有数据分片、执行计算、服务本地扫描。没有 ZooKeeper 这样的外部协调件——元数据一致性由 FE 内部的 BDB JE 复制组保证，副本放置由 Master FE 决策，这种"把分布式系统的复杂度收进两类进程"的设计是它宣称易运维的物质基础。

金句：读不懂架构的调优是碰运气，看得懂故障的人先看得懂分工。

部署形态上这组分工也有约定俗成的配比：FE 通常三台起步且必须是奇数（复制组选举要求多数派存活），规格不必豪华，八核十六吉的虚机在多数中型集群里够用；BE 才是资源大户，核与内存直接决定扫描吞吐，磁盘建议多块独立盘而非单张大盘。一个常见误区是把 FE 配得比 BE 还壮——控制平面的负载是元数据级的数据量，堆硬件买不来查询速度，钱应该花在数据平面。

子章节导航

• 2.1 整体架构设计：MPP 执行模型、元数据服务机制、"计算存储服务"三位一体的协同全景。
• 2.2 前端节点 FE：BDB JE 复制组怎么选主，查询计划如何在几十毫秒内成型并被派发。
• 2.3 后端节点 BE：列存布局、向量化算子、Runtime Filter 与 Tablet 管理——性能承诺的兑现现场。

子章节之间的逻辑关系

三节是一条从整体到局部的变焦镜头：先立全景框架，再进控制平面的心脏，最后落到数据平面的车间。前一节的概念在后一节都会复现：

2.1 全景总账 ──zoom──> 2.2 控制平面细节 ──zoom──> 2.3 数据平面细节
      │                    │                     │
  回答谁管谁          回答谁来决策            回答谁来干活
​

前置知识与后续延伸

你需要第 1 章的基本词汇（Tablet、分区、列存），不要求任何源码背景。学完本章即可进入第 3 章建表实战——那里的每个参数都会回指这里的功能归属；做平台化封装的同学则可以带着"哪些能力收进了 FE"这个问题去读 6.3 权限体系。

读法建议按角色分流：做数仓开发的重点吃透 2.3 的存储形态——分桶、Rowset、索引的机理决定了第 3 章每个建表参数的后果；做平台运维的重点在 2.2 的元数据机制——升级、扩缩容、故障转移的规程都从复制组的行为推导。两条线在 2.1 的全景图上汇合，先花十分钟看懂那张图，后面两节的细节就有了挂靠点。