【列存引擎内核】向量化执行引擎

存储层把 Part 读成 列向量（第 2 篇）；执行层必须在 batch 上算，否则函数调用与 cache miss 吃掉列存带宽优势。ClickHouse 官方 Architecture 明确：operations dispatch on arrays (vectors or chunks of columns)。

本文拆解 Block、IProcessor pipeline，并对照 PG 执行器火山模型。版本：24.x LTS。

一、为什么需要向量化

Volcano：每算子 next() 返回一行 → 虚函数 + 分支多，CPU 流水线难满。

向量：一次处理 \(N\) 行（max_block_size，常见 65536）→ filter 生成位图、aggregate 批量 update。

MonetDB/X100（CIDR 2005）系统论证了 vectorized + cache-conscious 对 OLAP 的必要性；ClickHouse 属同一设计谱系。

flowchart LR
  VOL[Volcano 逐行] --> CH[ClickHouse 逐 Block]
  CH --> SIMD[SIMD 友好]

二、Block 与 Column

Block（src/Core/Block.h）= 列名 + ColumnWithTypeAndName 数组 + 行数。

IColumn 接口：clone、insert、filter、permute 等，算子间传递 ColumnPtr。

三、IProcessor 与 Pipeline

IProcessor（Processors/IProcessor.h）：

• prepare()：声明需要输入端口 / 输出就绪
• work()：消费 Chunk，产生 Chunk
• 端口连接构成 DAG

PipelineExecutor 多线程调度 ready 处理器，减少全局同步（官方 Architecture Processors 节）。

flowchart TB
  SCAN[MergeTreeSelect] --> PRE[Prewhere]
  PRE --> FIL[FilterTransform]
  FIL --> EXP[ExpressionTransform]
  EXP --> AGG[AggregatingTransform]
  AGG --> OUT[Output]

四、读存储：MergeTreeSource

MergeTreeSelectProcessor / read pool 从 Part 读列 → 组装 Block → 下游算子。与 第 5 篇 衔接。

五、Filter 与 Project

FilterTransform：对条件列求值 → UInt8 过滤 mask → IColumn::filter 裁剪各列。

ExpressionTransform：ExpressionActions 将 AST 编译为对列的循环（非常量折叠时）。

六、Aggregate

AggregatingTransform：按 key 列 hash，批量更新 AggregateFunction 状态（非逐行 transition）。GROUP BY + 高基数时内存受 max_bytes_before_external_group_by 等限制。

七、与 PG 执行器对照

PG 向量化改进（如 bulk read）存在，但 OLTP 兼容约束下仍以行为主；ClickHouse 默认即 batch。

八、Settings 与调优

九、实验说明

本环境无 ClickHouse。读者可用：

EXPLAIN PIPELINE SELECT count() FROM table WHERE ...;

观察 processor 链名称。不粘贴未执行输出。

十、学术谱系：Volcano → MonetDB/X100 → Processors

谱系结论：第 1 篇已钉 C-Store 存储侧；本篇钉执行侧——CH 主路径是 X100 式向量解释，不是 HyPer 式全查询 codegen。compile_expressions 是局部加速，不改变 Pipeline 以 Block 为边界的模型。

10.1 争论：Compiled vs Vectorized

工程上：CH 用向量 Block 保可观测与多租户公平；JIT 仅覆盖热点表达式——与「全计划 LLVM」不是同一设计点。

10.2 工程间隙

10.3 开放问题

1. CH 何时值得默认打开更激进的 codegen？ 可检验：同查询开关 compile_expressions 的 CPU 与首次延迟（入口：Kersten VLDB’18；CH settings 文档）。
2. Block 大小是否应随算子自适应？ 固定 max_block_size 对 filter 选择性极端时可能浪费；社区有讨论，无统一论文结论。
3. 与 DuckDB morsel 的并行模型谁更适合多核 skew？ 见第 12 篇。

十一、小结

列存执行核心：Block 列向量 + Processor DAG + 批量算子。学术坐标：Volcano → X100 →（Kersten 争论）→ CH Processors。读路径产出 Block，算子链在 Block 上向量化，直到输出客户端。

上一篇：压缩与编码

下一篇：查询读取路径

参考资料

核心论文

1. Graefe, Volcano—An Extensible and Parallel Query Evaluation System, IEEE TKDE 1994（A 级）。
2. Boncz et al., MonetDB/X100: Hyper-Pipelining Query Execution, CIDR 2005（A 级）。
3. Kersten et al., Everything You Always Wanted to Know About Compiled and Vectorized Queries But Were Afraid to Ask, PVLDB 2018（争论；A 级）。

规范 / 源码 / 文档

4. ClickHouse Documentation, Architecture Overview（Processors / Block；A 级）。
5. ClickHouse Source, v24.3, src/Processors/、src/Columns/、src/Core/Block.h（A 级）。
6. PostgreSQL 系列, 执行器（Volcano 对照）。

Block 与 Chunk

Block（Core/Block.h）含多列；Pipeline 中 Chunk 携带 Block 或列子集 + 行数。max_block_size 控制单行算子输出规模。

IProcessor 状态机

prepare() 返回 NeedData / Ready / Finished；work() 消费输入 Chunk、产出输出 Chunk。PipelineExecutor 多线程调度 ready 节点，避免全局锁（官方 Architecture Processors）。

与 PG 执行器对照

SIMD

Columns/Common/Simd* 与函数实现（如 FunctionsArithmetic）对固定宽度类型使用 intrinsics；具体是否触发取决于类型与编译标志（-march）。