分布式执行引擎演进：从算子下推到两阶段聚合的优化实践

KaiwuDB 分布式执行引擎这几年的演进，是我在时序数据库领域见过的最能反映“从能用走向好用”这一过程的系统之一。很多团队一开始做分布式数据库，重点往往放在存储和一致性上，执行引擎很容易做成“能跑就行”的附属品，但随着 IoT、工业互联网这类场景把海量时序数据的聚合分析需求摆到台面上，执行引擎很快就成了瓶颈，逼着你不得不回头重构。这篇文章把 KaiwuDB 分布式执行引擎从早期“集中式套壳”到“分布式分片执行”，再到“算子下推 + 两阶段聚合 + 自适应调度”的演进过程完整捋一遍，重点讲每轮重构背后的原因、方案取舍、核心实现细节，以及我在排查问题过程中积累的一组踩坑记录。

如果你是做数据库内核、中间件或者大数据平台开发的人，这篇文章应该能在分布式 SQL 引擎设计上给你一些可落地的参考；如果你只是日常使用 KaiwuDB 或者类似时序数据库，那看第 5 和第 6 部分就够了——里面有怎么读执行计划、怎么排查慢查询的方法。

1. 演进背景：分布式执行引擎到底要解决什么

1.1 KaiwuDB 的场景特征决定了技术路线的走向

KaiwuDB 是面向海量时序数据场景的分布式数据库。它承接的负载和传统 OLTP 有明显差异：写入是高频、小批量、按时间持续追加的；查询则大多是“某个设备、某一时间段、若干指标”的聚合分析，比如“过去 24 小时每个车间每台设备的平均温度峰值”。

这样一组特征直接影响执行引擎的设计目标。时间范围裁剪比什么都重要，一段查询能不能通过元数据索引或者分区剪枝，把要扫描的数据量从几十亿条压到几十万条，是执行引擎优化器的核心职责之一。聚合计算占比非常高，AVG、SUM、MAX、MIN、COUNT 这类操作，绝大多数可以先在数据所在节点上做一轮局部计算，再在协调节点合并，而不是把原始数据全拉上来。数据分布天然是有偏的，不同设备、不同时间段的写入热度差别很大，查询如果不考虑数据分布，很容易出现“一个节点累死、其他节点空闲”的局面。

所以 KaiwuDB 分布式执行引擎的演进核心，其实就是围绕这三个特征，不断把计算往数据侧推，把调度做得更智能。脱离场景谈执行引擎设计没有任何意义，这个前提先立住，后面的每一轮重构才说得清楚。

1.2 一条演进主线：先能用，再好用，再稳着用

我把 KaiwuDB 分布式执行引擎的演进分成三个阶段。第一阶段解决的是“能不能分布式执行”，典型问题是早期版本的执行引擎沿用单机数据库的模型，SQL 优化器只能生成单节点的物理计划，集群模式下所有数据都要拉到一起，在单个节点上做计算，导致节点越多性能反而越差。第二阶段解决的是“怎么更快”，核心工作是算子下推、两阶段聚合、并行扫描与并行排序，这一阶段的改造让分布式执行真正跑出了线性扩展的收益。第三阶段解决的是“在复杂负载下怎么保持稳定”，包括自适应执行策略、内存与并发隔离、慢节点和超时控制。

这三个阶段不是拍脑袋定的。从我的实际经验来看，绝大多数分布式数据库的执行引擎都会经历类似的过程——一开始只要把功能做对就行，等数据量和查询复杂度上来，性能问题会逼着你去改造；等你把性能优化到一定程度，稳定性问题又会出现。所以这篇的叙述逻辑就是按这条主线走，每一轮重构都有自己的动机和取舍，后面逐个展开。

2. 第一阶段：从单机执行到分布式分片执行

2.1 初版执行引擎的局限

KaiwuDB 早期版本执行引擎的定位比较尴尬：优化器能识别到集群环境，但物理计划生成的粒度是“整棵树在一个节点上执行”。也就是说，一条 SQL 如果涉及多个节点的数据，协调节点会把相关数据通过存储层接口批量拉回本地，再在本地执行完整的扫描、过滤、聚合流程。

这种模式在数据量小、集群规模不大的时候还能接受，但集群一旦扩展到三五个节点以上，问题就暴露得很明显。网络 IO 成为第一瓶颈，因为所有原始行都要跨节点传输；协调节点的内存成为第二瓶颈，因为结果集和中间状态都堆积在同一个进程里；CPU 利用率则非常不均衡，协调节点忙死，数据节点闲死。

我自己在做压测的时候遇到过一个特别典型的例子：一个 5 节点的集群，跑一条按天分组的 AVG 聚合查询，集群总吞吐不但没有比单节点高，反而因为网络开销比单机还慢。这时候团队才真正意识到，执行引擎的分布式改造必须提上日程，否则存储和分片做得再漂亮，查询出口还是堵死的，整个数据库在用户那里的体感就是“慢”。

2.2 分片执行框架的引入：从单计划到多计划

第一阶段改造的核心，是引入“计划分片”（plan fragment）的概念。简单说，就是把原本一棵完整的物理计划树，从数据交换算子处切成多段：协调节点负责生成全局计划，然后把可以下推到数据节点执行的子树片段，连同数据扫描、过滤、投影这些操作，下发给持有对应分片数据的节点执行；每个数据节点执行完自己的片段后，通过数据交换算子把结果向上传递，协调节点拿到各节点的结果后，再做最终的汇总、排序、Limit 等操作。

这个模型在业界叫 shared-nothing 架构下的分布式执行，KaiwuDB 在第一阶段采用了和多数分布式数据库类似的实现方式。每个 fragment 是一个独立的执行单元，包含一组物理算子；节点间通过 Exchange 算子交换数据，Exchange 底层一般是远程过程调用加流式数据传输；协调节点负责 fragment 的调度、状态跟踪和结果汇总；数据节点把 fragment 执行结果按批返回，避免一次性把全量结果载入内存。

这里最关键的设计点是数据不重复读取。因为 KaiwuDB 的数据是分片存储的，每个 fragment 必须知道自己要扫哪个分片、哪些时间范围、哪些 tag 组合。如果 fragment 的裁剪条件没有下推，就还会出现“明明只要一个设备的数据，却把整张表扫一遍”的情况。所以第一阶段虽然以框架搭建为主，但也同步做了分区裁剪条件和 filter 条件的下推，这个是分布式执行引擎的基础功，做不到位后面一切都白搭。

2.3 第一阶段踩过的坑：网络往返与结果序列化

框架跑通之后，最大的问题变成“框架有了，但性能依然不够理想”。这时候排查出来的问题集中在两个地方。

第一个是结果集序列化的开销。早期阶段节点间传输结果时，用的是通用序列化格式，字段类型转换和对象拷贝开销非常大，一条聚合结果只有几十个字节，序列化加网络头的开销反而是它的几十倍。这其实是一个很常见的问题：分布式框架刚搭起来的时候，大家往往先追求功能正确，性能问题随后才会暴露出来，等到真出了性能问题，又要花不少功夫去优化这些看起来不起眼的基础环节。

第二个是数据节点之间的重复连接。第一版实现里，协调节点每执行一个 fragment 就对数据节点建一次远程连接，连接没有复用，导致查询稍微多几个分片，光建连的时间就占了执行时长的三分之一。后来改成了连接池复用，配合批量流式回传，同样的查询在集群规模不变的情况下，端到端时延下降了大约 60%。这种优化看起来没有“算子下推”“并行执行”那么有技术含量，但对真实用户体感的提升非常明显。

3. 第二阶段：算子下推与并行化改造

3.1 为什么算子下推是时序场景的生命线

第一阶段搭好了分布式执行的架子，但要让性能真正上一个台阶，必须解决“计算在哪里做”的问题。拿时序场景里最常用的“按时间窗口聚合”来说，假设一张表存了 10 亿条设备采样数据，分布在 10 个节点上，要查“每个设备每 5 分钟的平均值”。

如果不做算子下推，协调节点要把 10 亿条原始记录全部拉回来，在协调节点本地做时间窗口分组、求平均值。先不说网络要传多少数据，单是协调节点的内存就扛不住。做了算子下推之后，每个数据节点先在本地完成“按 5 分钟窗口分组 + 对窗口内的温度求平均”，然后只把每个窗口的“分组键 + 平均值”传给协调节点。10 亿条原始数据传到协调节点的量就降到了几十万分之一。

这就是时序场景里算子下推最核心的价值：数据量下降几个数量级，查询性能自然也跟着上几个台阶。这也是为什么我一直跟团队强调，分布式执行引擎的优化要优先盯着网络传输量，而不是 CPU 利用率。CPU 高不一定好，可能是系统在做无用的重复计算；网络传输量降下来了，其他问题大多会跟着缓解。

3.2 两阶段聚合：从全局聚合到局部聚合

KaiwuDB 第二阶段最重要的改造之一，是引入了两阶段聚合（Partial + Final Aggregation）。原理可以这么理解：全局聚合这件事不需要在所有原始数据上进行，只要每个数据节点先把局部结果算出来，协调节点再基于局部结果做一轮合并就行。

但这里有个容易忽略的细节，不是所有聚合函数都能拆成“局部 + 合并”两步，它要求聚合函数具备可加性或者说可结合性。SUM、COUNT、MIN、MAX 这些都可以直接合并，但要小心 AVG：它需要把局部的 SUM 和 COUNT 都传上去，最后用总 SUM 除以总 COUNT 才算得准确。PERCENTILE 这类算分位数的函数更麻烦，KaiwuDB 的早期实现里直接把它退化成了“拉原始数据到协调节点计算”，后来才逐步替换为近似分位数算法，用很小的精度损失换来了数据传输量的指数级下降。

所以，两阶段聚合的关键代码往往不是“按模板套上 Partial 和 Final 两个算子”这么简单，而是要逐个函数确认它的合并语义。我在实际开发中踩过的一个坑就是，某个自定义的滑动窗口聚合函数只实现了局部聚合逻辑，没实现最终合并逻辑，结果窗口边界出现重复计数，排查了很久才发现是聚合函数的上推语义不完整，少了一个合并分支。后来我们专门建了一张“聚合函数语义描述表”，明确每个函数是否支持分割执行、是否允许重复消除，才从根上避免了这类问题。

3.3 并行扫描与并行排序

两阶段聚合解决的是聚合场景，但用户查询不全是聚合，还有大量的明细查询，比如“查某台设备最近 100 条原始数据”“按时间倒序拉某个时间段的记录”。这类查询涉及排序和拉取，如果只用一个线程顺序扫分片，速度会很慢。第二阶段随后做了并行扫描：一个 fragment 对应的多个分片，或者一个分片内的多个数据块，可以并发读取。

这里要把控好并行度，不是越大越好。并行度太小，节点 CPU 空闲；并行度太大，磁盘 IO 和内存先被击穿。KaiwuDB 在这块的典型做法是：按分片数估算初始并行度，默认值等于节点 CPU 核数的一半左右；每个扫描线程维护独立的游标和批次缓冲区，互不干扰；所有扫描线程的结果通过 Exchange 汇总，再做一次归并排序。

对于跨节点排序，比如“从 10 个节点各取时间最近的前 100 条，最后合并成全局最近 100 条”，最省数据量的方式是在每个节点先做 Top-N（local top-N），协调节点再对收到的 10 组 Top-N 做归并，得到全局 Top-N。这一步如果没做 local top-N 的下推，协调节点就要收到 10 个节点的全量数据再排序，性能差距是数量级的。很多刚接触分布式执行引擎的人容易忽略这点，总想着排序必须全局做，实际上时序场景里大部分有序查询都能拆成“局部有序 + 全局归并”两步。

4. 第三阶段：自适应执行与资源治理

4.1 静态计划的问题与动态优化

走到第二阶段结束，KaiwuDB 的分布式执行引擎在相对理想的情况下已经能跑出不错的性能，但真实的生产环境从来不是理想的。静态计划的问题在于：优化器在生成计划时依赖统计信息，而统计信息可能是过时的，尤其在时序场景里，数据每时每刻都在写入，表的行数、数据的分布特征变化非常快。

典型情况是，优化器根据旧的统计信息选了哈希分桶聚合方案，但实际某个时间窗口的数据量突然暴涨，哈希表占用内存飙升；或者优化器选了一个需要全量扫描的计划，但实际上某个分片完全可以用索引点查，只是执行时才发现。第三阶段的自适应执行，解决的就是这类“计划选错”的问题。

KaiwuDB 的思路是在每个执行节点上采样运行时的实际数据量、行宽、过滤率，把这些反馈给协调节点；协调节点在严格执行之前，如果发现某个片段的真实代价和预估代价偏差超过阈值，就触发一次计划重优化——重新选择 join 顺序、聚合策略或者并行度。这里要注意，重优化不能无限触发，否则查询本身会被优化开销拖垮。一个相对稳的做法是：每轮执行最多允许一次重优化，且重优化只允许发生在执行刚开始不久、已经处理的数据量还小的时候；一旦执行超过某个进度，就放弃重优化，按原计划走完。

4.2 内存与并发控制：避免 OOM 和“查询风暴”

分布式执行引擎把计算分散到各个节点以后，单个节点的内存压力并没有消失，只是从“协调节点一台机器扛”变成了“多个节点一起扛”。如果并发的重型查询同时打到一个节点上，内存很快会被撑爆。KaiwuDB 在第三阶段给执行引擎加了资源治理层，核心是两类控制。

第一类是算子级内存预算。每个算子在执行前会申请一个内存预算，比如哈希聚合算子的预算默认值可以配置，超过预算之后，不是直接报错，而是将中间结果溢写磁盘，用磁盘空间换内存安全。这个机制对时序场景特别有用，因为用户经常会跑一些时间范围特别大的聚合查询，数据量估算容易失准，有个溢写兜底至少不会把节点打崩。

第二类是查询级并发限制。协调节点在接到新查询时，会先估算整体资源需求，如果当前集群的活跃任务已经很多、剩余内存和 CPU 不足，新的重型查询会被排队，而不是直接放进来和其他查询抢资源。这个队列的深度和等待时间都可以配置，本质上是牺牲一点响应时间，换取集群整体稳定。时序数据库的使用场景里，很多查询是定时跑报表任务，晚几秒执行完完全可以接受，但把在线查询拖垮就不能接受。

4.3 慢节点处理与查询超时控制

分布式系统有个铁律：整个查询的耗时，取决于最慢的那个节点。某个节点磁盘老化、网络抖动、或者刚好在跑一个特别重的后台任务，都会让整条查询被拖住。KaiwuDB 第三阶段对慢节点采用了两层处理策略。

第一层是执行层超时：每个 fragment 在数据节点上都有一个超时时间，超时后会先尝试重派发到副本节点执行，而不是直接让查询失败。第二层是协调层兜底：如果同一个 fragment 在多个副本上都超时，协调节点会把这个查询标记为失败，然后快速清理其他节点上的中间状态，避免悬挂任务占住资源。这种“先重试、再失败、快速清理”的策略，在时序场景里比“一个节点拖死全查询”要实用得多。我自己在运维一个 50 节点规模集群的经验是，加了慢节点重试机制之后，月级的查询失败率从 2% 降到了 0.3% 左右，剩下的大部分失败都是因为网络分区或者节点宕机这些不可恢复的原因，重试意义不大。

5. 实操拆解：一条典型时序聚合查询的完整旅程

5.1 从 SQL 到物理计划的完整链路

这一节，我带大家走一遍 KaiwuDB 分布式执行引擎处理一条典型查询的全流程。假设场景是工业能耗监控，有表 meter_reading 存储着各种仪表的读数，字段包括 device_id、ts、voltage、current、power 等。用户发的 SQL 是：

sql复制SELECT device_id, COUNT(*), AVG(power)
FROM meter_reading
WHERE ts >= TIMESTAMP '2025-06-01 00:00:00'
  AND ts < TIMESTAMP '2025-06-08 00:00:00'
GROUP BY device_id
ORDER BY device_id;

这条 SQL 的处理链路大致是这样：第一步语法解析，把 SQL 文本解析成抽象语法树；第二步语义分析，绑定表名、字段名，检查类型和权限，生成逻辑计划；第三步逻辑优化，做谓词下推、常量折叠、时间范围裁剪等逻辑优化，重点是把 ts 范围条件转换成对分片和存储文件的裁剪条件；第四步物理优化，把逻辑计划转换成物理计划，决定用哪些扫描方式、聚合策略、并行度；第五步分布式计划切分，在数据交换算子的位置把物理计划切成多个 plan fragment，标记哪些 fragment 在协调节点执行、哪些下推到数据节点执行；第六步调度执行，协调节点把下推的 fragment 发到持有相关分片的数据节点，各节点并行执行局部聚合，然后把中间结果传回协调节点；第七步结果合并，协调节点做最终聚合、排序，返回给客户端。

这条链路看起来简单，实际上每一层都有很多细节。比如第三步的时间范围裁剪，如果执行引擎能把 7 天的时间范围精确映射到某些分块文件，扫描阶段就只需要打开少数几个文件，而不用扫全量数据，这部分优化对查询的影响可能比聚合本身还大。我遇到过一些用户反馈查询慢，看执行计划才发现时间裁剪条件完全没有下推到扫描算子，整张表的数据都被扫了一遍，加了个索引条件之后性能提升了十几倍。

5.2 重点参数配置与执行计划解读

KaiwuDB 的分布式执行引擎提供了若干参数来控制并行度、内存预算、网络传输批次大小等行为。下面是我在实际项目中常用的几组配置，具体命名可能因版本略有差异，但思路一致：

bash复制# 单查询最大并行度，建议结合节点 CPU 核数设置，通常设为核数的一半到一倍
query_parallelism_max = 8

# 哈希聚合内存预算，超过后触发中间结果溢写磁盘
hash_agg_memory_limit = 2GB

# 网络传输批次大小，时序结果行宽一般较小，建议从 64KB 起步，根据网络调整
exchange_batch_size = 256KB

# 是否启用两阶段聚合，时序聚合场景建议开启
enable_partial_agg = true

# 慢节点 fragment 超时时间，超过后重试副本
fragment_timeout_ms = 30000

在排查慢查询时，我一般会先看执行计划，重点确认三件事：聚合是不是两阶段执行的，如果整个聚合都在协调节点，说明算子下推没有生效；数据扫描是不是走了分区裁剪，如果输出里出现全表扫描且数据量很大，大概率裁剪条件没下推；并行度是否合理，如果计划的并行度很小，但节点 CPU 明显空闲，可以调大最大并行度再看。

5.3 实际改造前后的效果

我按上面的思路在一组测试环境上做过对比：4 个数据节点，每节点 16 核 64GB 内存，表里存了 2 亿条模拟的仪表数据。改造前只做了第一阶段分布式分片执行，没有下推聚合，跑上面那条聚合 SQL 时，协调节点需要把每个节点符合条件的数据全部拉回来，约 1.2 亿行原始数据，网络传输量大约 4.8GB，查询耗时 42 秒。

改造后启用两阶段聚合、并行扫描和时间裁剪，每个节点本地先聚合，最终只回传约 1000 个分组的 1000 行结果，网络传输量下降到几十 KB 级别，同样查询耗时 3.1 秒。这个例子很直观地说明了一个道理：分布式执行引擎优化的核心收益，往往来自把传输量降下来，而不是单纯堆节点数或 CPU。传输量降了，延迟自然降；资源占用降了，并发能力才有余量给更多的查询。

6. 演进路上的典型问题与排查方法

6.1 高频问题速查表

6.2 三个值得复盘的实战案例

第一个案例是聚合重复计数。某次业务反馈说同一个设备的 5 分钟窗口平均功率数据，在报表系统里查出两组不同结果，一组明显是重复累计的。定位到最后，问题出在自定义窗口聚合函数上，它对窗口滑动场景做了特殊处理，但下推时没有把这个语义传递正确，导致数据节点上重复处理了窗口边界的数据。后来在代码层面加了一张“聚合函数语义描述表”，明确每个函数是否支持分割执行、是否允许重复消除，彻底避免了类似问题。

第二个案例是大查询拖垮协调节点。有一段时间线上会固定出现内存告警，排查发现是某个用户跑了一条不带时间条件的超大范围聚合，把 10 天的数据全部拉起来算。这种查询从业务角度可能不合理，但数据库不能因此崩溃。后来做了两层防线：第一层是在优化器阶段加了一个危险查询拦截规则，对于扫描范围超出阈值的查询，直接拒绝执行并提示用户加时间条件；第二层是给所有查询设置内存预算上限，超出就溢写磁盘。两层防线同时上线后，这类内存告警基本消失了。

第三个案例是节点故障时的查询悬挂。有一次集群里一个节点因为磁盘 IO 故障一直没有返回结果，协调节点等了一个多小时还在等。这是一个典型的“分布式执行引擎缺少故障转移意识”的问题。后来在执行层加了心跳机制，数据节点每几秒上报一次执行状态，协调节点发现某个 fragment 长时间没有心跳，就主动把它标记为失败，并尝试在其他副本上重跑。这个改动对运维来说非常友好，节点失败对查询的影响时间从小时级降到了秒级。

6.3 我的一些实践建议

最后分享几条我基于这段演进经历总结的实践建议，希望对正在做类似系统的团队有用。

先保证执行计划的可观测性。没有执行计划输出、没有执行状态监控，做优化就是盲人摸象。KaiwuDB 后期把执行计划输出的信息做得足够详细，我排查问题的效率提升了不止一倍。不管你是做引擎开发还是做平台运维，第一件事就是把可观测性基础打好，后面所有优化才有依据。

做算子下推时，先把聚合函数的语义清单列清楚。能下推的、不能下推的、要特殊处理的，分门别类写清楚再动手，否则后期就是不停打补丁。分布式执行引擎的性能优化要优先盯着网络传输量和内存峰值这两个指标，不要只盯 CPU。网络传输量降下来，其他问题大多会跟着缓解。

慢节点处理不是可选项。任何分布式系统都会遇到节点性能抖动，提前做好超时、重试、快速失败机制，远比事后救火省心。这三条建议看起来没什么特别高深的，但都是我在真实环境里被问题逼出来的经验，照着做基本能帮你避开大部分坑。

回过头看这段演进历程，我最大的一个感受是：分布式执行引擎这类底层模块，最难的不是某个算法或者某个具体的算子，而是你需要在功能、性能、稳定性、可维护性四条线上同时往前走，而每推进一步，都可能发现之前的设计有需要推翻的地方。KaiwuDB 这几年的演进路径，本质上就是在不停回答同一个问题——在数据规模越来越大、负载越来越复杂的现实下，怎么让一条 SQL 既算得对、又算得快、还算得稳。这个方向后续还有不少值得展开的内容，比如向量化执行、代码生成、更细粒度的资源隔离，以后有时间再单独写一篇。