从零实现列式分析引擎：向量化执行、SIMD 聚合与延迟物化深度实战

引言：为什么分析的永远比写的慢？

在OLTP系统中，你永远不会觉得"读一行很慢"——因为它天然就是按行组织的。但在OLAP场景中，当你要在一个十亿行表的某几个聚合列上计算 SUM(revenue) GROUP BY region 时，行式存储需要把整行数据（包括你不需要的 description 文本、user_avatar 二进制）全部读入内存。这意味着 I/O 带宽的 95% 被无用数据占据，CPU 缓存命中率趋近于零。

列式存储就是为这一问题量身打造的架构决策。它不是一种银弹，但在分析场景下，它能带来 10-100x 的查询加速。从 ClickHouse 到 DuckDB，从 Apache Arrow 到 Parquet，列式思想正在重塑数据处理的基础设施。

本文将从一个简化的引擎出发，完整实现列式存储的核心机制：列布局内存模型、向量化执行引擎、SIMD 友好的算子、压缩编码、延迟物化策略，并最终与 Apache Arrow 生态对接。目标不是复现 DuckDB，而是让你真正理解"为什么快"的工程根源。

一、列式内存模型：Arc