在过去二十年的数据库架构演进中，业界普遍认为列式存储与向量化执行是面向分析型负载（OLAP）的专属技术，而事务型负载（OLTP）仍然依赖传统行式存储与逐行执行模型。然而，随着现代硬件特性的深度挖掘与云原生数据仓库的崛起，这一边界正变得越来越模糊。列式存储不再仅仅是一种物理布局的选择，它正在重新定义我们对数据库规范化的认知 —— 一种技术层面的「规范化回归」正在发生。
列式存储的核心设计原理
传统行式存储将一条记录的所有字段连续存放，这种布局对点查询和写入操作极为友好，因为单次 I/O 即可获取完整记录。但在分析型场景中，查询往往只涉及少量列，却需要扫描海量行 —— 此时行式存储的性能表现堪称灾难。列式存储从根本上解决了这一问题：它将同一列的所有值物理聚合在一起，使得查询可以完全跳过无关列的数据块。
这种按列组织的数据布局带来了三个关键优势。其一是 I/O 优化，假设一个包含一百个字段的表中只查询三个字段，行式存储仍需读取全部数据页，而列式存储只需读取三个列对应的数据块，I/O 量可能降低一个数量级。其二是压缩效率，同一列的数据具有相同的数据类型和相近的值分布，这为字典编码、行程长度编码等压缩算法提供了理想的发挥空间，典型压缩比可达三到十倍。其三是向量处理友好，列式布局天然适合 SIMD（单指令多数据）指令集的批量处理，数据以连续内存块形式存在，能够直接送入 CPU 流水线进行并行计算。
现代云数据仓库如 Snowflake、Google BigQuery、Amazon Redshift 无一例外采用了列式存储作为核心数据布局。一些新兴 OLAP 引擎如 ClickHouse、Druid、Pinot 更是将列式存储推向了极致，它们甚至在同一列内部根据数据特征进一步划分数据块（segment 或 page），每个子块维护独立的统计信息（如最小值、最大值、字典表），以便在查询执行前进行快速剪枝。
向量化执行与批量处理的协同效应
如果说列式存储解决的是数据组织问题，那么向量化执行（Vectorized Execution）解决的就是数据处理效率问题。传统的火山模型（Volcano Model）执行器以行作为迭代单位，每次调用一次 next () 函数只返回一行数据，这种设计虽然灵活但函数调用开销极高，且严重阻碍了 CPU 指令流水线的效率。
向量化执行将处理粒度从单行提升到向量（通常为 1024 或 4096 行），在每个向量化迭代中，操作符一次性处理一个数据块。这种设计带来了多重收益：减少了函数调用次数和分支预测失败率，使 CPU 能够充分利用指令级并行；数据以列式格式驻留在 CPU 缓存中，避免了行式迭代带来的缓存抖动；更重要的是，向量化代码可以自动利用现代 CPU 的 SIMD 指令集，在单条指令内完成多个数据元素的相同操作。
以聚合操作为例，向量化执行引擎可以将一列数据加载到向量寄存器中，使用一条 SIMD 加法指令同时完成数千个元素的求和。根据 MonetDB/X100 项目的经典研究，向量化执行相比传统火山模型可以获得十到百倍的性能提升。这一技术已被 ClickHouse、DuckDB、DataFusion 等现代 OLAP 引擎广泛采用，成为分析型查询加速的标准配置。
规范化设计的范式转移
传统数据库理论将规范化视为消除数据冗余、保证更新一致性的核心手段。OLTP 系统普遍采用第三范式（3NF）或更高的规范化级别，以最小化插入、更新、删除异常。然而，这一原则在 OLAP 领域遭遇了根本性挑战：高度规范化的 schema 意味着复杂的连接操作，而连接恰恰是分析型查询中最耗时的操作之一。
星型模式（Star Schema）和雪花模式（Snowflake Schema）作为反规范化的代表应运而生。在星型模式中，事实表（Fact Table）存储业务度量，维度表（Dimension Table）以扁平化方式存储属性，查询时通过简单的外键连接即可完成多维分析。这种设计以存储冗余为代价，换取了查询性能的显著提升 —— 这在磁盘 I/O 昂贵的时代是完全合理的取舍。
但列式存储与向量化执行的组合正在改变这一计算范式。首先，列式存储的压缩效率大幅降低了存储冗余的成本 —— 同样的数据在列式布局下的存储空间可能只有行式的三分之一甚至更低。其次，向量化执行引擎对连接操作的优化日益成熟，Hash Join、Merge Join 等算法在向量化框架下能够高效处理批量数据。第三，现代物化视图和预计算技术的成熟，使得某些频繁访问的连接结果可以被缓存，进一步弱化了反规范化的必要性。
一个值得关注的现象是，部分现代数据仓库开始支持一定程度的规范化设计。例如，Google BigQuery 采用了混合存储模型，允许在同一张表中同时存在规范化的关系结构与反规范化的嵌套字段；Snowflake 则支持半结构化数据（VARIANT 类型）的原生存储，使得某些维度数据可以直接嵌入事实表中。这种「规范化回归」并非简单的历史倒车，而是建立在强大列式存储与向量化执行能力之上的设计灵活性的体现。
现代 OLAP 引擎的设计取舍
不同 OLAP 引擎在列式存储与规范化策略上展现了各自的设计哲学。ClickHouse 追求极致的列式压缩与向量化性能，默认采用大量冗余的宽表设计，将尽可能多的字段聚合到单张表中，以最大化列式扫描的收益。DuckDB 则采取了更为平衡的策略，它支持完整的 SQL 规范包括外键约束，允许开发者在同一系统中同时定义规范化和反规范化的 schema，由查询优化器根据统计信息自动选择执行策略。
对于实际项目中的架构决策，建议遵循以下原则：优先考虑查询模式的特征，如果分析查询主要涉及少数列的聚合且写入频率不高，列式存储配合适度的反规范化仍是首选；如果系统需要同时支持高并发的写入操作，则应考虑混合存储架构或采用 HTAP（混合事务分析处理）引擎；在存储成本敏感且查询延迟要求极高的场景下，可以探索列式存储配合物化视图的组合策略，将高频查询的连接结果预先物化。
数据架构的演进从未停止。从关系型数据库的规范化理论到数据仓库的反规范化实践，再到今天列式存储与向量化执行赋能下的「智能规范化」，技术的螺旋式发展不断重新定义最佳实践的边界。理解底层技术的特性与取舍逻辑，比记忆某个固定模式更为重要。
参考资料
- 《OLAP Database Architecture: Columnar Storage and Vectorized Execution》, sqlflash.ai
- 《How We Built a Vectorized Execution Engine》, Alfonso Subiotto
- 《Why Analytic Workloads are faster on Columnar Databases?》, Loonytek