列存引擎内核 — 系列规划

本文是写作规划，不是可发布正文。主选 ClickHouse 作为拆解对象，DuckDB 作为嵌入式/OLAP 对照；不写泛泛的「列存概念」科普。

一、为什么写这个系列

1.1 存储引擎三角的缺口

结论：读者理解行存（PG）和写优化（LSM）后，缺 读优化列存 的完整源码级拆解。ClickHouse 是开源列存工程标杆；DuckDB 代表「嵌入式分析」路径——两者对照覆盖 OLAP 主战场。

1.2 为什么选 ClickHouse（主）+ DuckDB（辅）

1.3 系列定位

列存 = 存储布局 + 向量化执行 + 合并策略 + 分布式（可选）

不写 SQL 教程，写： - 为什么列存 scan 1 列比行存读整行快（含 CPU cache / SIMD） - MergeTree part 如何 merge、为什么 merge 是列存的心脏手术 - PRIMARY KEY 在 ClickHouse 里不是唯一约束——排序键语义 - 向量化 volcano vs 向量批处理（morsel-driven）

二、核心问题与目标读者

2.1 六个关键问题

1. 列存文件在磁盘上长什么样？ → 第 1、2 章：Part、Column、Mark、Granule、压缩块。

2. 一次 SELECT 如何从 part 读到向量批？ → 第 3、4 章：Read path、Mark Range、PREWHERE、向量化执行。

3. MergeTree 的 merge 到底在合并什么？ → 第 5、6 章：Merge 算法、TTL、Mutation vs Merge。

4. ClickHouse 的「索引」是什么？ → 第 7 章：稀疏主键索引、跳数索引（minmax/set/bloom）、与 B-Tree 的本质差异。

5. 分布式表如何工作？ → 第 8、9 章：Local table、Distributed、ReplicatedMergeTree、ZooKeeper/ Keeper 协调。

6. 列存生产环境会出什么事故？ → 第 14–16 章：Parts 过多、merge 跟不上、mutation 阻塞、副本延迟、内存 OOM。

2.2 目标读者

• 数据平台工程师、OLAP 开发者、从 PG/MySQL 转 ClickHouse 的 DBA
• 先修：SQL、postgresql-kernel 或 storage 索引章节、基本 C++ 阅读能力
• 不假设：已有 ClickHouse 运维经验

三、篇目结构（主系列 16 篇 + DuckDB 专题 3 篇）

第一部分：存储格式（第 1–3 章）

第 1 章：列存基础与 ClickHouse 架构

• 行存 vs 列存：带宽、压缩、向量化三角
• ClickHouse 进程模型：Server、MergeTreeBackgroundExecutor
• 表引擎概览：MergeTree 家族地图
• 源码入口：src/Storages/、src/Databases/

第 2 章：MergeTree Part 文件格式

• Part 目录结构：columns.txt、checksums.txt、.bin、.mrk、.idx
• Column 文件：压缩块、Granule、Mark 文件语义
• 实验：clickhouse-local 建表 + 查看 data/ 目录
• 源码：src/Storages/MergeTree/MergeTreeDataPart*

第 3 章：压缩与编码

• LZ4、ZSTD、Delta、DoubleDelta、Gorilla（时序）
• 编码选择与列类型
• 实验：同列不同编码的压缩比 benchmark（本机，≥3 轮）
• PG 对照：TOAST 压缩 — 不同优化目标

第二部分：读取路径（第 4–7 章）

第 4 章：向量化执行引擎

• Block 结构：列向量 batch
• 算子 pipeline：filter、project、aggregate 的向量实现
• 与 volcano 模型对比（引用 PG 执行器 #12-executor）
• 源码：src/Processors/、src/Columns/

第 5 章：查询读取路径

• Mark Range 定位 Granule
• PREWHERE vs WHERE
• 并行读：max_threads、parts 级并行
• 实验：EXPLAIN indexes=1 输出解读

第 6 章：Merge 与 Mutation

• Merge 触发条件、merge selector
• ReplacingMergeTree、CollapsingMergeTree 语义
• Mutation（ALTER UPDATE/DELETE）的异步路径与危害
• 源码：MergeTreeDataMergerMutator

第 7 章：索引与跳数索引

• PRIMARY KEY = 排序键 ≠ 唯一
• Data Skipping Index：minmax、set、bloom_filter
• 与 PG B-Tree（postgresql-kernel/14-btree）对照表

第三部分：分布式与高可用（第 8–10 章）

第 8 章：ReplicatedMergeTree

• Log entry、ZooKeeper/Keeper 路径
• 副本同步、recovery
• 实验：双节点副本 + 断网观察

第 9 章：Distributed 引擎

• 分片键、分布式查询路由
• GLOBAL IN/JOIN 的代价
• 与 PG Citus / 分布式系列边界

第 10 章：物化视图与增量管道

• Materialized View 触发机制
• Kafka 引擎 + MV 典型架构
• 坑：MV 目标表引擎选择错误

第四部分：DuckDB 对照专题（第 11–13 章）

第 11 章：DuckDB 架构与嵌入式 OLAP

• 进程内、无服务器
• Storage：Row Group + Column Segment
• 与 ClickHouse 部署模型差异

第 12 章：DuckDB 向量化与 Pipeline

• Morsel-driven parallelism
• 源码：src/execution/、src/storage/

第 13 章：ClickHouse vs DuckDB 选型

• 规模、并发、嵌入、联邦查询（pg_duckdb）
• 决策树，不排名

第五部分：运维实战（第 14–16 章）

第 14 章：监控与系统表

• system.parts、system.merges、system.replication_queue
• 关键指标：parts 数、merge 延迟、memory tracking

第 15 章：经典故障模式

• Too many parts
• Merge 跟不上 insert
• Mutation 堆积
• 副本延迟 / lost replica
• OOM：max_memory_usage

第 16 章：配置陷阱与容量规划

• parts_to_throw_insert / parts_to_delay_insert
• merge_max_block_size
• max_bytes_to_merge_at_max_space_in_pool
• 磁盘：SSD vs HDD merge 策略

四、依赖关系

1 → 2 → 3 → 4 → 5
        ↓       ↓
        6 ← 7   8 → 9
                ↓
               10
11 → 12 → 13（DuckDB，可与 4–7 并行）
14 → 15 → 16

五、阅读路径

六、来源台账

A 级

• ClickHouse 源码（标注 release，如 24.3）
• ClickHouse 官方文档：MergeTree、Replication
• DuckDB 源码 + https://duckdb.org/docs/internals/
• 论文：MonetDB/X100（向量化）、C-Store（列存）

B 级

• Altinity / ClickHouse 官方博客（版本标注）

七、实验台账

八、系列联动

九、边界

不承诺

• 替代 ClickHouse 官方文档
• Cloud 托管版（ClickHouse Cloud）内部实现
• Spark/Flink 批流框架全文
• 实时数仓业务建模

十、写作顺序

1. index.md
2. 第 1、2、3 章（格式基础）
3. 第 4、5 章（读路径）
4. 第 6、7 章（merge 与索引）
5. 第 14、15、16 章（运维，可与 8–10 交错）
6. 第 8、9、10 章（分布式）
7. DuckDB 11–13

十一、待确认问题

1. ClickHouse 版本锚定：24 LTS？
2. Keeper 替代 ZooKeeper 是否作为默认写法？
3. DuckDB 3 篇是否并入主 index 还是子目录 duckdb/？
4. 是否增加 MergeTree 以外引擎（如 S3Queue）专章？

规划版本：v1，2026-06-18 目录建议：post/db/columnar-engine/