三台 BE 跑一条 Join比单机还慢。继续加 BE 后CPU 没有吃满网络却先打满。MPP 没失效它只是忠实地把一个错误的数据搬运方案并行执行了。Doris 的性能来自优化器选对数据位置、Fragment 控制跨机边界、Pipeline 填满单机核心。MPP 只表示可以并行不保证并行有收益。一条 SQL 会经历三次完全不同的拆分SELECTd.region,SUM(f.pay_amount)FROMfact_order fJOINdim_shop dONf.shop_idd.shop_idWHEREf.pay_date2026-08-27GROUPBYd.region;执行链不是 SQL 直接广播到所有 BESQL → Nereids 选择扫描、Join 顺序和数据分布 → FE 在 Shuffle 边界切成 PlanFragment → Coordinator 把 Fragment 实例调度到 BE → BE 把 Fragment 拆成 Pipeline DAG → PipelineTask 在有界线程池中执行 → Exchange 传输中间 Block → Coordinator 汇总结果MPP 官方文档 和 Pipeline 官方文档 分别覆盖跨 BE 和单 BE 两层。把它们混成 MPP 会漏掉性能最关键的边界。MySQL、Spark 与 Doris 的差异不在会不会 Join固定同一条件十亿行事实表关联百万行维表按地区聚合结果用于交互式看板。引擎执行重心优势主要边界MySQL单实例索引、Nested Loop 与行式执行高选择性点查和事务大范围扫描与并行分析受单机限制Spark SQLStage、Task 与 Shuffle大批量容错计算、弹性资源调度和物化开销不适合高频交互Doris常驻 BE、Fragment、向量化 Pipeline低调度开销的并行分析与查询服务错误 Shuffle、倾斜和估算仍会拖垮查询Doris 的优势是常驻执行引擎把分析查询拆成列式 Block在 BE 内继续流水并行代价是需要正确统计信息、数据分布和内存治理。Fragment 决定数据什么时候跨机器物理计划遇到跨节点数据交换时插入DataStreamSink与ExchangeNode并在这里切开 Fragment。小维表可能 Broadcast 到每个事实表节点两张大表通常按 Join Key Shuffle。Broadcast dim_shop 全量 → BE1、BE2、BE3 fact_order 本地扫描 → 本地 Join Shuffle fact_order 按 shop_id 重分布 ↘ 对齐后 Join dim_shop 按 shop_id 重分布 ↗Broadcast 减少事实表搬运却把维表复制到每个实例Shuffle 能处理大表却产生网络、序列化和接收端内存。选错策略时增加节点会增加复制份数或交换连接并不必然更快。Pipeline 解决的是等待不是消灭阻塞Join Build、Aggregation 和 Sort 需要阶段性物化无法组成一条永不停止的流水线。Pipeline 把阻塞算子拆成 Sink 与 Source再用 Dependency 连接Pipeline 0Scan dim → JoinBuildSink ↓ hash table ready Pipeline 1Scan fact → JoinProbe → AggSink ↓ aggregation ready Pipeline 2AggSource → ResultSink等待 Hash Table 时PipelineTask 释放执行线程而不是让一个 OS 线程空等。线程数受 BE 线程池约束所以并发查询增加时不会按 Fragment 数无限膨胀。但 Build 侧过大仍会吃内存热点 Key 仍会造成单实例长尾Sort 仍可能 Spill。Pipeline 改善调度不改变算法复杂度。用 EXPLAIN 和 Profile 分别证明两件事EXPLAIN回答计划准备怎么做分区裁剪、Join 类型、数据分布和 Fragment 边界。Query Profile 回答实际上做了多少扫描行数、Exchange 字节、各实例耗时和峰值内存。最小验证顺序EXPLAINVERBOSESELECTd.region,SUM(f.pay_amount)FROMfact_order fJOINdim_shop dONf.shop_idd.shop_idWHEREf.pay_date2026-08-27GROUPBYd.region;SETenable_profiletrue;-- 执行目标 SQLSHOWQUERY PROFILE;判断只看四个差值证据正常含义异常含义估算行数 vs 实际行数CBO 基数可靠统计信息失真Join 策略可能错误各实例 ScanRows数据分布均匀Tablet 或谓词倾斜ExchangeBytes只搬必要数据Shuffle 放大或裁剪失败最大实例耗时 vs 中位数并行任务接近单个长尾决定总耗时这个实验的淘汰条件很明确增加 BE 后 ExchangeBytes 与长尾实例继续上升却没有减少有效扫描和总耗时说明当前拆分方式没有获得 MPP 收益。源码只追四个入口在 Apache Doris4.0.8中源码阅读的最短路径是FENereidsPlanner逻辑与物理计划入口FECoordinatorFragment 实例调度和结果协调BE Pipeline Fragment Context把 Fragment 建成 Pipeline DAGBE Task Scheduler在有界线程池中推进 PipelineTask。阅读时围绕一条 SQL 对照EXPLAIN定位哪个规则选择了 Join 分布、哪个 Exchange 切开 Fragment、哪个 Dependency 阻塞 Probe。脱离具体计划浏览类文件只会重新变成架构名词。面试里真正有区分度的回答Doris 查询快不是单靠 MPP。Nereids 先决定 Join 顺序和数据分布FE 在 Shuffle 边界形成 FragmentCoordinator 将实例放到持有 Tablet 的 BEBE 再用 PipelineTask 在有界线程池中推进向量化算子。性能最终由扫描裁剪、Exchange 数据量、实例倾斜和阻塞算子内存共同决定。并行只能缩短被正确拆分的工作拆错以后MPP 只是让更多机器一起搬错数据。官方资料MPP ArchitecturePipeline Execution EngineQuery ProfileApache Doris 4.0.8 Source
)
