KaiwuDB分布式执行引擎：架构演进、核心设计与性能调优

KaiwuDB 的分布式执行引擎我关注了挺长时间，也实际在一些物联网场景里折腾过它的 SQL 查询。这玩意儿说白了就是把一条原本在单机上执行的 SQL，拆成能在多台机器上并行干活的任务。听起来不复杂，但真正做起来，里面的坑一个接一个——数据怎么分片、任务怎么调度、中间结果怎么传、节点挂了怎么办，每一步都是权衡。这篇文章我就从执行引擎的演进逻辑出发，把分布式查询的拆解思路、核心算子设计、调度策略，以及我在实际使用中踩过的坑，一次性讲清楚。不管是刚接触分布式数据库的开发者，还是已经在用 KaiwuDB 做时序数据分析的同学，这篇应该都能给你一些参考。

1. 为什么单机执行引擎到了分布式场景就不够用了

1.1 单机执行引擎的天花板

先看单机执行引擎是怎么工作的。传统关系型数据库里，一条 SQL 从客户端进来之后，经过解析器变成语法树，再经过绑定和优化器生成执行计划，最后由执行器逐行或者逐批地扫描表、做过滤、做聚合、做连接。整个过程都在一台机器上完成，所有数据都在本地磁盘或者本地内存里。

这套模型在数据量不大、并发不高的时候没什么问题。但一旦落到物联网场景，比如几千台设备每秒上报一条点位数据，一天就能产生几亿条记录。这时候单机执行引擎要面对的就不只是计算压力，还有 IO 瓶颈和内存瓶颈。一张表一两个 TB 算正常，单机扫描一遍就要很久，更别提还需要跟其他表做 join 或者跨时间范围做聚合。

而且单机的扩展方式是垂直扩展，也就是加 CPU、加内存、换更强的磁盘。这种方式的成本曲线非常陡峭，而且物理上限清晰可见。一台机器撑死几十核、几百 GB 内存，再往上就是小型机、大型机的价格区间了，大多数业务根本承受不了。

1.2 分布式执行引擎解决的问题

分布式执行引擎的核心思路，是把数据水平切到多台机器上，每台机器只处理自己那一份，然后再把各自的计算结果合并起来。这样计算能力会跟着节点数量近似线性扩展，存储能力也会跟着磁盘总量走。

但这不只是在执行器外面套一层壳。它带来了一整套新问题。数据怎么切，决定了计算能不能本地化；任务怎么调度，决定了节点之间能不能均衡干活；中间结果怎么传输，决定了网络会不会成为瓶颈；某个节点执行失败，整个查询要不要重来。这些问题的解决方案合在一起，就是分布式执行引擎的全部内容。

在 KaiwuDB 里，它的执行引擎延续了分布式数据库的典型分层思路，但在时序数据场景上做了针对性的调整。比如时序数据天然带时间戳和标签维度，数据分布策略、分区裁剪、聚合下推这些环节，都会跟传统 OLTP 数据库不太一样。这也是为什么不能直接把单机执行引擎的思路硬套到分布式场景上的根本原因——它不只是把算子换个地方跑，而是从数据布局到调度模型都要重新设计。

2. 分布式执行引擎的核心组件拆解

2.1 逻辑计划与物理计划的分离

执行引擎的第一步，是把 SQL 转成逻辑计划。逻辑计划描述的是“要做什么”，比如扫描某张表、按某个条件过滤、按某几个字段分组聚合、跟另一张表做连接。它不关心数据到底存在哪台机器上，也不关心用哪种算法去执行。

物理计划则是逻辑计划的具体落地。分布式场景下，物理计划会在逻辑计划的基础上额外标注数据分布信息、分区裁剪范围、执行节点的选择、算子间的数据交换方式。同一个逻辑计划，可能对应多种物理计划，优化器要从中选择代价最小的那一个。

KaiwuDB 在这层做的事情跟大多数分布式数据库类似，但因为要兼容时序和关系两种模型，它在表达式和数据类型上会更复杂一些。比如时间窗口聚合、插值、降采样这类操作，会被优化器识别并下推到存储层执行，而不是把原始数据拉到计算层再做。这属于“算子下推”的范畴，后面我会细说。

2.2 并行调度器与执行节点管理

有了物理计划，接下来要解决的是“谁去跑哪些任务”。这里会有一个调度器，负责把物理计划拆成多个可并行执行的子任务，再分发到各个节点上。

调度器的设计有几个关键要素：

• 任务粒度。拆得太粗，并行度不够，浪费节点资源；拆得太细，调度本身的开销反而会盖过计算收益。一般会根据数据分片数量和节点资源情况动态决定。
• 数据本地性。理想情况下，每个子任务处理的数据就在本节点上，不需要跨网络拉数据。这要求数据分片和计算调度是协同设计的。
• 失败处理。某个子任务执行失败后，调度器需要决定是重试、重新调度到其他节点，还是直接让整个查询失败。

在实际使用中，我遇到过调度器把任务全压到少数几个热点节点上的情况，尤其是当某台机器的数据分片特别大时。这个问题不只是调度策略的问题，更多时候是数据倾斜导致的。分布式执行引擎里，这几乎是最难缠的问题之一。

2.3 分布式算子的执行语义

单机执行引擎里的算子大多直接操作本地数据，但在分布式环境下，每个算子都需要考虑跨节点配合。拿连接算子举例，单机执行时的嵌套循环连接或者哈希连接算法本身还在，但数据必须先从多台机器汇集到执行节点上，这里就有几种选择：广播、重分区、或者直接利用已有的数据分布来做本地连接。

聚合算子也一样。单机聚合是一遍扫数据一边累积状态，分布式场景下需要做两阶段聚合：每个节点先做本地部分聚合（partial aggregate），再把部分结果汇总到最终聚合节点做合并。如果不做这层两阶段处理，所有中间结果都会被一股脑地传输到单点，网络很快就会成为瓶颈。

2.4 数据交换层：分布式执行的血脉

数据交换层负责算子和算子之间、节点和节点之间的数据传输，是分布式执行引擎里最容易被低估的组件。它的传输效率、流量控制、序列化协议、反压机制，直接决定了整个查询的性能上限。

KaiwuDB 在数据交换层的设计上，我观察到的核心是两层：一层是节点间的网络传输模块，处理连接复用、数据压缩、流量控制；另一层是算子间的数据流抽象，把网络传输封装成类似迭代器的接口，上层算子不用关心数据是来自本机还是远端。

这个抽象非常重要。如果上层算子能无感地从远端拉数据，那并行执行计划的表达能力会强很多。代价是底层的序列化和网络管理必须做得足够高效，否则一次简单的扫描都要背上巨大的传输开销。

数据交换层还有反压机制。当下游算子来不及消费数据时，上游必须能感知到并放慢生产速度，否则内存会被中间结果撑爆。这个在单机场景下靠内存缓冲就能兜底，但在分布式场景必须靠数据流控制来解决，不然跑一个大查询很容易把集群的内存打满。

3. 执行引擎演进的主线：从中心化执行到分布式并行

3.1 早期阶段的中心化执行模式

KaiwuDB 执行引擎的演进，如果从架构思路来看，早期版本比较务实，很多操作是集中在单个协调节点上完成的。这个阶段的思路很直接：底层存储已经做了多节点分布，但执行层仍然保留传统的单机模型。

这样做的好处是简单。优化器的实现难度低，算子也不需要考虑跨节点数据交换，因为所有数据都在同一个执行引擎里流转。坏处也很明显——协调节点会成为瓶颈。数据量小的时候还能撑得住，数据量一大，协调节点的 CPU 和网络就被来回传输的中间结果吃满了，整个集群的扩展能力被死死锁住。

我记得早期测试的时候，跑一个大范围的时间聚合查询，协调节点的 CPU 会飙到接近 100%，而存储节点的 CPU 反而用不满。这个现象特别典型，就是执行层和存储层能力不匹配的体现：存储能扛住扫描压力，但执行层把所有计算和传输都压在一个点上。

3.2 走向并行：火山模型到向量化执行

这个阶段的核心是：把执行计划拆成可以并行执行的分片，协调节点只负责调度和整合，计算工作下沉到各个存储节点就近执行。

具体到执行模型上，KaiwuDB 也顺应了从经典火山模型向向量化执行的演进。火山模型把每个算子封装成 next() 迭代器，每次调用返回一行数据。优点是简单灵活，缺点是每次函数调用开销太大，CPU 的大量时间消耗在虚函数调用和行级处理上，现代 CPU 的 cache 和流水线优势完全发挥不出来。

向量化执行的思路则是每次处理一批数据（比如 1024 行），算子的处理对象从“一行”变成“一列”。这样有几个好处：

• 每批次只触发少量函数调用，降低解释开销。
• 数据连续存放，更容易命中 CPU cache。
• 中间数据可以批量处理，更容易利用 SIMD 指令做批量计算。

这一演进对时序数据分析的查询效果尤其明显，因为时序查询里有大量聚合、过滤、窗口计算，这些操作对逐行的解释式执行非常不友好，向量化之后性能提升往往是数量级的。

3.3 执行计划分片与并行度控制

物理计划分片是分布式执行引擎的另一个核心演进点。在没有分片能力的时候，并行只能体现在不同节点跑不同的独立查询。有了分片能力，单条查询才能被切到多节点并行执行。

分片不是简单地按行数均分就行，需要考虑数据分布和分区信息。在 KaiwuDB 里，数据通常按时间范围加标签维度组织成多个分区，分片逻辑会尽量跟这些分区对齐，这样每个分片的数据物理上都在同一个节点上，避免了跨节点拉数据。

并行度的控制同样关键。并行度开得太猛，节点间通信量会指数上涨，调度开销也会吃掉收益；开得不够，节点资源又被闲置。这个参数没有绝对的最优值，一般会根据集群规模、查询复杂度和当前负载动态调整。我建议从每个节点 4 到 8 个并行任务起步，实测效果比较稳，再根据具体查询调优。

3.4 从批量调度到动态调度

早期的分布式执行引擎通常用静态调度：执行计划生成后，任务分配就固定了，跑完就结束。这种方式实现简单，但如果某一个节点的数据明显比其他节点多，或者某台机器性能抖动，整体执行时间就会被拖长。

后续演进方向是动态调度。任务不再是执行前一次性分配完毕，而是维护一个待执行任务队列，节点空闲时主动领取任务。粒度更小，均衡性更好。比如一个大的扫描操作被拆成 1000 个小任务，4 个节点动态领取，做完一个领一个，这样天然能应对数据倾斜和节点性能差异。

动态调度的代价是调度器本身会变成潜在热点，任务队列的并发访问、任务状态的跟踪、节点心跳的维护，都需要额外的系统开销。但从实际场景看，这点开销换来的均衡性提升非常值得，尤其是在节点规格不一致或者数据分布不均匀的集群里。

4. 查询优化器在分布式场景下的特殊考量

4.1 优化器的作用范围被放大

单机场景下，优化器的核心任务是选择表连接顺序、选择合适的连接算法、决定是否使用索引。分布式场景下，优化器还要额外决定数据重分布的策略、选择哪些算子可以下推、决定聚合和连接应该在哪个阶段完成。

这意味着优化器的一个决策，影响的不只是几倍性能差异，而是可能带来数量级的差距。拿连接举例，两张表做连接，如果一张是小表一张是大表，优化器通常会选择广播连接——把小表的全量数据广播到所有相关节点，每台节点只跟本地的大表分片做连接。但如果优化器误判了表的大小，把小表当成大表，就会选择重分区连接，那所有表的全量数据都要跨节点重分区传输一次，网络开销瞬间爆炸。

所以，分布式场景下统计信息的准确性极其重要。表有多少行、每个分区有多少数据、字段的基数是多少，这些信息直接决定了优化器的选择。如果统计信息过期或者缺失，优化器就像蒙着眼开车，执行计划的质量完全靠运气。

4.2 谓词下推与分区裁剪

谓词下推是最基础也最有效的优化手段。逻辑是把过滤条件下推到数据源端执行，尽早减少参与计算的数据量。在分布式场景里，这个下推可以一直推到存储层。

KaiwuDB 的时序模型让这类优化更容易做，因为数据天然带时间戳和标签字段。查询条件里包含时间范围，存储层可以直接裁剪掉不相关的数据分片。比如查询最近一个小时的数据，如果表按小时分分区，那实际扫描的范围只有一两个分区，其他分区根本不会打开。

这里有个实际经验：建表的时候分区键的选择要仔细想清楚。在 KaiwuDB 里如果用时间做分区主键，那所有查询最好都能带上时间范围条件，否则分区裁剪就失效了，查询会全表扫描，性能差距非常明显。标签字段可以建二级索引或者作为组合分区条件，进一步缩小扫描范围。

4.3 聚合下推与两阶段聚合

聚合操作的下推是时序数据库的特别优势。常见的时序聚合包括分钟级降采样、按设备分组求均值、按时间窗口做 sum 或 max。这些操作如果先在全量数据上执行再聚合，性能会非常差；正确做法是先在各节点本地做部分聚合，再把部分结果合并。

两阶段聚合的具体流程是：每个存储节点扫描本地数据，先按分组键和时间窗口做本地聚合，把结果集合缩小到很小；然后把这些中间结果传输到协调节点，再做一次合并聚合，输出最终结果。由于中间结果通常已经很小，网络传输量会大幅下降。

这个优化对时序数据的效果特别明显，因为一个设备一天产生的原始数据可能有几万条，但按小时聚合成均值后只有 24 条。如果能在各节点本地先做完这层转化，协调节点拿到的只是非常精简的中间结果，查询速度的提升是肉眼可见的。

4.4 运行时过滤（Runtime Filter）

除了生成期优化，很多分布式执行引擎在运行阶段还会动态优化。比如哈希连接执行时，先扫描驱动表（左表）生成哈希表，这个过程中可以收集到一组过滤值，在下游扫描被驱动表（右表）之前，先把这组值推给存储节点，让存储节点在扫描时直接过滤掉不匹配的数据。

这个叫做运行时过滤，或者动态过滤。它能在执行过程中进一步压缩需要传输和处理的数据量。在时序场景里，一个典型的应用场景是查询“最近活跃的设备”。先用一个简单的查询找到最近有数据上报的设备列表，然后把这个列表作为过滤条件去扫描更大的事实表，大幅减少扫描量。

5. 实操中的性能调优与问题排查

5.1 数据倾斜：分布式执行的首要敌人

数据倾斜这个词儿，做分布式的人应该都不陌生。它指的是数据在节点间分布不均匀，导致部分节点需要处理的数据量远超其他节点。

在 KaiwuDB 的场景里，最常见的倾斜是标签值倾斜。比如海量设备数据里，某几个设备的数据量占了 80%，其他设备只占 20%。如果按设备 ID 做重分区或分组聚合，那几个大设备所在的节点会被压满，其他节点却在空闲等待，整个查询的执行时间被拉长到热点节点的处理时间。

这个问题在执行计划阶段很难完全规避，只能通过运行时的动态调度来缓解。如果倾斜太严重，聚合算子可以在两阶段聚合基础上增加一个“打散”步骤，把每个分组键加上随机后缀分散到多个子任务并行计算，最后再做一次合并。这样每个热点分组也能被拆分到多个节点上去干活。

5.2 查询慢的排查思路

我在实际用 KaiwuDB 的时候，遇到查询变慢，通常按下面的顺序排查：

第一步看执行计划。看优化器选择了什么连接顺序、什么连接算法，有没有做谓词下推和分区裁剪。很多时候问题就出在这里，比如一个大范围查询没有带时间过滤条件，优化器被迫全表扫描，这时候怎么调参数都没用，只能在 SQL 层面优化。

第二步看数据分布。查每个节点上数据分片的大小，查目标数据是否发生倾斜。如果数据倾斜严重，需要从写入侧就考虑调整分区策略，而不是在查询侧硬扛。

第三步看算子耗时。如果是聚合慢，需要确认是否做了两阶段聚合；如果是连接慢，需要确认是否用上了广播连接或者本地连接，有没有多余的重分区和数据传输。

第四步看网络和 CPU。通过监控面板看节点间传输了多少数据，各节点 CPU 是否均衡。如果网络传输量很大，大概率是执行计划里多了不必要的数据交换步骤。

5.3 参数调优的几个关键项

不同的分布式数据库参数名各有不同，但关注点大同小异。我列几个在 KaiwuDB 场景里实际影响比较大的点，供参考：

• 并行度：控制单查询的最大并行任务数。过小会导致资源闲置，过大会导致调度和网络开销失控。
• 内存限制：控制每个执行节点的中间结果内存占用。超出之后会 spill 到磁盘，如果磁盘 IO 性能一般，性能会有明显下降。
• 网络缓冲：控制节点间数据传输的缓冲大小，影响吞吐和延迟的平衡。
• 统计信息刷新频率：优化器依赖统计信息做决策，如果数据变更频繁而统计信息不更新，执行计划质量会快速退化。

实测下来，这些参数需要按具体查询模式来调整，不存在一套万能配置。我的习惯是先跑一遍查询，记录各节点 CPU、网络和耗时，再做针对性调整，而不是盲目地把并行度调到最大。

5.4 常见问题速查表

6. 演进到现在，还有哪些值得关注的细节

6.1 执行引擎与存储引擎的深度协同

执行引擎的演进并不是孤立的，它跟存储引擎的配合程度决定了最终效果。如果执行引擎只是把任务分发到节点上，然后从存储引擎拉原始数据到计算层处理，那再强的执行引擎也发挥不出来。

在 KaiwuDB 里，存储层做了一些针对时序数据的优化，比如列式存储、编码压缩和索引结构。执行引擎如果能把这些能力用起来，性能会有质的飞跃。比如列式存储允许执行引擎只读取查询涉及到的列，而不是整行数据都加载进来；编码压缩则让节点间传输的数据量大幅下降。

这也是我看到的一个趋势：执行引擎的位置越来越不只是“SQL 执行模块”，而是逐渐成为整个查询路径上融合存储优化能力的枢纽。未来执行引擎的演进，一定会更紧密地与存储层的索引、编码、压缩特性做联动，而不是各行其是。

6.2 自适应执行：反馈驱动优化

统计信息不准、数据分布变化快，是分布式执行引擎长期面临的问题。静态优化做得再好，面对变化的负载也会“失准”。自适应执行就是为了解决这个问题：在执行过程中采集实际数据特征，动态调整后续执行策略。

更具体地说，节点在执行扫描任务时可以统计实际扫描的行数、数据分布、过滤率等信息，反馈给协调节点。协调节点根据这些反馈重新评估后续阶段的执行策略，比如改变连接算法、调整重分区策略、修改聚合方式。这样即使优化器在一开始做了不太好的决策，也能在执行中期被纠正过来。

这个能力在数据分布频繁变化的物联网场景里非常有用。设备上报频次波动、异常流量突发、历史数据过期删除，这些都会导致表的数据分布大幅变化。如果执行引擎没有自适应能力，只能在统计信息更新之前用次优计划硬扛；有了自适应执行，就有机会在执行过程中把偏差拉回来。

我在一些测试里体会过这种差异：同样一条查询，在数据分布发生变化后，自适应执行相比静态执行计划的性能稳定性要好很多，最终执行时间不会因为数据波动而忽快忽慢。

6.3 与资源调度的协同演进

执行引擎在跑查询的时候，它的任务其实跟其他并发查询共享同一批节点资源。如果一个执行引擎不管集群里还有什么别的任务在跑，只顾自己拼命占资源，那资源竞争会让所有查询都变慢。

更成熟的演进方向是执行引擎跟资源调度模块协同。查询进来之前，资源调度先评估当前集群的空闲资源，给查询分配一个可容忍的资源配额；执行引擎在这个配额内运行，资源不足时主动降低并行度或者排队等待。这样不仅能保证单查询的性能，还能提升整个集群的吞吐量和稳定性。

从我的实践来看，多用户共用一套集群的场景里，执行引擎能否跟资源调度配合好，往往比单查询的极致性能更重要。宁可让单个查询慢一点，也不能让它把集群打垮、拖垮所有业务。随着业务规模扩大，这个维度的设计会越来越重要。

写在最后

把执行引擎从单机模型演进到分布式并行模型，本质上是在计算资源、网络带宽、节点均衡之间反复找平衡。没有放之四海而皆准的方案，只有针对自身场景不断调整和优化的过程。

我在操作 KaiwuDB 分布式执行引擎的时候，最深的体会是“执行计划一定要拿在手里看”。很多性能问题，在 SQL 和参数层面很难猜出来，只要看一眼执行计划，数据交换量和算子选择一目了然。分布式执行引擎虽然复杂，但它给了用户足够多的手段去理解和干预执行过程，这也是它能做好性能调优的基础。按这个思路，把执行计划、数据分布、调度策略三个维度理顺，大多数查询性能问题都能找到明确的突破口。