一篇文章读懂Doris认识Doris Doris是一个MPP架构的数据库，可以大规模并行处理。Doris 采用 MySQ

Doris是一个MPP架构的数据库，可以大规模并行处理。Doris 采用 MySQL 协议，高度兼容 MySQL 语法，支持标准 SQL。

Doris整体物理架构

截屏2026-01-20 12.19.35.png

图中的部分：最上方的蓝色框，显示支持 MySQL 协议。
通俗理解：这是餐厅的前台窗口。顾客（开发人员或 BI 工具）不需要学新的点菜语言，直接用通俗的 MySQL 命令就能下单。Doris 对外伪装成一个普通的 MySQL，让你用起来非常顺手。

图中的 FE 分成了三种角色（Leader, Follower, Observer），它们是餐厅的管理层。

Frontend (Leader/Follower) ：这是值班经理。
- 它们负责接单（SQL 解析）、制定做菜计划（查询规划）、盯着库存（元数据管理）。
- Leader 是大经理，说了算；Follower 是副经理，随时准备在大经理累倒时接班。它们之间通过日志同步信息，确保办公室里的账本（元数据）是一致的。
Frontend (Observer) ：这是实习助理。
- 它们只看账本，不参与决策，专门负责回答那些简单的“查账”问题，帮经理分担压力，提高餐厅的接待速度。

图中最下方的 Backend 框，标注着 C++ 编写。

通俗理解：这是后厨的厨师们。
- C++ 编写：意味着它们干活极其麻利，动作极快（高性能）。
- 分工协作：一个查询请求会被拆成很多小任务，分给多个 BE 同时开火。
- 存储数据：食材（数据）就存在每个 BE 自己的冰箱（磁盘）里。
- 横向通信：你看 BE 之间有箭头，这代表厨师们会互相传菜（Exchange 数据交换）。比如我这边的肉切好了，传给你去下锅炒。

一个query查询周期

截屏2026-01-20 12.18.51.png

用户发送一条 SQL 给 Frontend。简单理解为：顾客进店，跟店长说：“我要一份全店所有厨师做的红烧肉总和报告。”

这是图中最核心的部分， Exchange/Shuffle 发生的时刻。

各个 BE 完成了自己的任务，把局部的小结果传回给 Frontend。简单理解为：厨师 A、B、C 各自把做好的部分端到店长面前。

FE 把所有局部结果做最后的合并（比如最后的求和），吐给用户。简单理解为：店长把所有的菜装进一个大盘子，递给顾客。

结合架构图和query生命周期图来整体分析一下

建立连接：用户通过 MySQL 协议发送查询请求给 FE 的 MySQL Server。
SQL 解析与分析 (Parser & Analyzer) ：FE 检查语法对不对，表 users 是否存在，用户有没有权限查看 score 列
生成逻辑计划 (Logical Plan) ：FE 将 SQL 翻译成一棵由 Scan、Filter、Aggregation 等算子组成的树。
生成物理计划与分布式拆解 (Optimizer & Planner) ：
- FE 查看元数据 (Catalog) ，确定数据分布在哪些 Tablet 上，这些 Tablet 又在哪些 BE 上。
- FE 将计划拆分成多个 Fragments（查询片段）。
任务派发 (Coordinator) ：FE 将这些 Fragments 发送给相关的 BE 节点。

此时，压力来到了各个 BE 节点。每个 BE 内部会发生以下动作：

Pipeline 调度：BE 接收到 Fragment，Pipeline 执行引擎将其拆成流水线任务，分配给不同的 CPU 线程去跑。
定位数据（利用“眼睛”） ：
- 列过滤：只打开 name、score、age 这几列的文件。
- 索引过滤：利用 Zone Map (Max/Min) 跳过不符合 age > 18 的数据块。
- 布隆过滤器：如果是精确匹配，则进一步“点杀”掉不需要的块。
数据读取 (Scan & Vectorized) ：ScanOperator 从磁盘（存算一体）或缓存/S3（存算分离）读取数据。数据以 Vector（向量化批次） 的形式推向后续算子，一次处理 1024 行，提升效率。
过滤与预计算 (Filter & Local Agg) ：
- FilterOperator 剔除 age <= 18 的记录。
- 本地聚合：BE 会先在自己本地算出“每个名字的分数总和”的中间结果。
数据交换 (Exchange/Shuffle) ：如果需要全局聚合，BE 之间会通过网络互相传输中间结果。