列式存储原理与实战：从数据布局到性能优化

前两天一个做数据平台的朋友跟我吐槽，说他们集群上跑一个多维分析报表，两张几亿行的表关联聚合，在原来的行式存储引擎上要跑四十多分钟，业务方等得没脾气，天天催。后来换成了列式存储引擎，同样的SQL，六分钟出结果。他没有改任何业务逻辑，只是把存储底座换了，查询性能就翻了好几倍。

这个案例很有代表性。很多人听过"列式存储"这四个字，知道大数据领域离不开它，但真要问起来：它和行式存储到底差在哪、为什么快那么多、什么样的场景适合用、建表的时候该怎么设计排序键和分区字段，能讲清楚的人并不多。这篇文章就把这些事情掰开揉碎讲一遍，从底层原理到工程选型再到避坑经验，尽量做到看完就能用。

文章里提到的原理和方案，基本覆盖了市面上主流列式存储引擎（Parquet、ORC、ClickHouse、Doris等）的共通设计思路。掌握了这套底层逻辑，你再看任何一个具体的列式存储产品，都会轻松很多——因为它们的核心思想其实是同源的。

1. 为什么大家都要用列式存储：从数据布局说起的IO革命

1.1 行式和列式的本质差异：数据在磁盘上怎么摆

先说最基础的问题：行式存储和列式存储到底有什么区别。

想象一张员工表，里面有工号、姓名、部门、薪资、入职日期等20个字段，一共1亿行数据。用Excel打开长这样：

code复制工号  姓名   部门    薪资    入职日期
001   张三   技术部   20000   2020-03-15
002   李四   市场部   18000   2019-07-01
003   王五   技术部   25000   2021-11-20
...

在磁盘上，行式存储（比如MySQL的InnoDB、PostgreSQL、Oracle）是这样摆数据的：把每一行的所有字段连续写在一起，一行写完再写下一行。逻辑上可以理解为：

code复制[001|张三|技术部|20000|2020-03-15][002|李四|市场部|18000|2019-07-01][003|王五|技术部|25000|2021-11-20]...

列式存储（比如Parquet、ORC、ClickHouse的MergeTree）则是反过来：把每一列的数据连续写在一起。磁盘上的物理布局类似于：

code复制[001|002|003|...] [张三|李四|王五|...] [技术部|市场部|技术部|...] [20000|18000|25000|...] [2020-03-15|2019-07-01|2021-11-20|...]

这个布局差异，就是列式存储一切性能优势的源头。

1.2 一条聚合查询背后的IO账本

现在来算一笔IO账。假设业务方要查：每个部门的平均薪资。SQL长这样：

sql复制SELECT 部门, AVG(薪资) FROM 员工表 GROUP BY 部门;

这个查询最终只需要两列数据：部门、薪资。其余18个字段完全用不上。

在行式存储里，数据按行连续存放，数据库要把每一行的完整数据都读进内存，才能拿到部门和薪资两个字段。1亿行 × 每行20个字段，假设一行平均2KB，总共要读大约200GB的数据——即使实际只需要那两个字段，磁盘IO也得把整行都搬回来。

在列式存储里，每一列在磁盘上是独立连续存储的。查询引擎只需要读取"部门"和"薪资"两个列文件，假设每行这两个字段加起来平均100字节，总共只需要读1GB左右。同样的查询，IO量直接变成原来的二十分之一。

磁盘IO在大数据场景下是最昂贵的资源之一。动不动几十GB、几百GB的IO差距，直接决定了查询是秒级还是分钟级。

1.3 列式存储不只是"读得少"：为什么压缩率也差这么多

除了IO量减少，列式存储在数据压缩上的优势同样巨大。

同一列的数据类型是一致的，而且相邻数据之间往往有很强的相关性。比如"部门"这一列，排在一起的可能大量都是"技术部"、"市场部"，重复值非常多；"入职日期"这一列，按时间顺序写入的话，数值变化幅度很小。这种结构对压缩算法极其友好。

用字典编码举例：把"技术部"编码为0、"市场部"编码为1、"财务部"编码为2，存储的时候只存编码数字，再加一个字典映射表。这种方式的压缩比通常能达到10:1甚至更高。

相比之下，行式存储里一行数据包含各种类型的字段混在一起，字符串、数字、日期交错排列，压缩算法很难找到重复模式，压缩比自然就低。

我见过一个真实案例：同样一份100GB的原始数据，行式存储压缩后还剩60GB左右，转成Parquet列式格式后直接压到15GB。磁盘占用少了四分之三，查询时的IO开销也同步缩小，一箭双雕。

2. 列式存储核心机制拆解：为什么它天生适合分析型查询

2.1 谓词下推：先把没用的数据过滤掉再干活

列式存储之所以能在万亿级数据上做秒级查询，除了列裁剪（只读需要的列），还有一个关键机制叫谓词下推（Predicate Pushdown）。

先看行式存储的处理逻辑。假设要查：技术部薪资大于20000的员工有多少。SQL如下：

sql复制SELECT COUNT(*) FROM 员工表 WHERE 部门 = '技术部' AND 薪资 > 20000;

行式存储的常规做法是把每一行数据都加载出来，逐行判断部门字段和薪资字段是否满足条件——全表扫描，一行不落。

列式存储的做法完全不同。每个列在物理存储上被切分成一个个数据块（Row Group或Data Page），每个数据块在写入时会记录一些统计信息，比如这个块内薪资的最大值、最小值、平均值，部门列的枚举值等。查询引擎可以先看"薪资"列的数据块统计信息：如果某个块的最大值都小于20000，整个块直接跳过，一个字节都不用读。

这就好比你在一堆书里找一本红色封面的书——列式存储的统计信息就像每本书封面上的颜色标签，扫一眼就知道哪些不用翻。数据量越大、过滤条件越严格，这种跳过机制带来的性能提升越明显。

这个机制在Parquet里叫Row Group统计信息，在ClickHouse里叫数据part的minmax索引，在Doris里叫Zone Map，名字各不相同，底层思路是同一套：利用元数据减少不必要的物理IO。

2.2 延迟物化：把"拼接成行"这一步拖到最后

列式存储还有一个精妙设计叫延迟物化（Late Materialization）。

行式存储的工作方式里有一个隐含前提：数据在内存中始终以"行"的形式存在。因为数据从磁盘读出来就是完整的行，所以后续所有计算都基于行结构展开。

列式存储则相反。数据从磁盘读出来是"列"的形式，每一列独立存放在内存里。如果查询引擎拿到每个列就立刻拼成完整的行，那前面省下的IO优势就浪费了。所以列式引擎普遍采用延迟物化的策略：

1. 先在单独的列上执行过滤、聚合等操作，比如先算"部门='技术部'"的位置列表，再算"薪资>20000"的位置列表；
2. 对多个列的结果做位图运算（AND、OR），得到满足条件的所有行号；
3. 最后才根据最终行号去提取需要的字段、拼接行结构，返回给上层计算。

这样做的好处是：整个查询过程中，内存里流动的都是列数据和行号列表，而不是完整的行对象。分析查询往往只访问少数几列，延迟物化可以把中间结果的数据量压到极致。

2.3 向量化执行：别一行行算了，一次处理一整批

有了列式存储的底层数据布局，CPU层面的优化也随之而来——向量化执行（Vectorized Execution）。

传统数据库的执行引擎是逐行处理的：读一行，算一行，返回一行。这个模式在OLTP场景下没毛病，因为事务处理天然就是逐条的。但在分析场景下，一次要处理几亿行数据，逐行处理带来的CPU指令开销、函数调用开销、缓存失效开销会被无限放大。

向量化执行的核心思路是：一次从列数据中取出一批（比如1024行）连续的数值，放到CPU的寄存器里，用SIMD（单指令多数据）指令一次性完成批量的加减乘除、比较、逻辑运算。

打个比方：逐行处理就像你一个一个地往墙上钉钉子，向量化执行则是拿起电动射钉枪，咔嚓一下打一排。同样是"打钉子"这个动作，后者的吞吐量完全不是一个量级。

这也是为什么ClickHouse在单表聚合查询上能比传统数据库快几个数量级——列式存储提供数据基础，向量化执行把现代CPU的算力榨干，两者配合才能达到极致的查询性能。

3. 主流列式存储引擎对比：从Parquet文件格式到分布式数据库

3.1 文件格式层：Parquet与ORC怎么选

先说文件格式层的两个主流选手。Parquet和ORC都是大数据生态中最常见的列式存储文件格式，但设计理念和适合场景不完全一样。

Parquet由Twitter和Cloudera主导开发，后来捐给了Apache基金会。它的核心特点是跨平台、跨语言支持好，几乎所有主流大数据组件——Spark、Hive、Flink、Presto、Impala、Doris——都能无缝读写Parquet文件。如果你需要把数据在不同系统之间流转，Parquet基本是无脑选择。

ORC由Hortonworks主导开发，最开始是Hive的专用格式。它的压缩效率比特化更高一点，尤其是嵌套数据结构的处理上有一些优化。但在其他计算引擎上的支持度不如Parquet广泛。如果你的技术栈完全围绕Hive/Spark展开，ORC也是个不错的选择；如果涉及多引擎混合使用，Parquet更稳妥。

我个人的倾向是：没有特别强的理由，优先选Parquet。生态兼容性是最重要的指标，格式上的微小压缩率差异在生产环境中影响远不如兼容性大。

3.2 数据库层：ClickHouse、Doris、Apache Druid怎么选

如果说Parquet和ORC解决了"文件怎么存"的问题，那ClickHouse、Doris、Apache Druid这些列式数据库解决了"怎么查得更爽"的问题。

ClickHouse是俄罗斯Yandex开源的列式数据库，极致追求单表查询性能。它的MergeTree表引擎家族非常强大，支持分区、排序键、TTL、物化视图等一系列功能。适用场景是海量数据的OLAP分析，特别是那种"一张大表，各种维度组合查询"的场景。缺点是分布式能力相对简单，复杂关联查询（多表JOIN）性能一般，不适合需要频繁更新的场景。

Apache Doris（以及它的商业分支StarRocks）是国人主导的MPP架构列式数据库，思路是"既能跑大查询，也能支持高并发实时查询"。它有Unique Key模型、Aggregate Key模型、Duplicate Key模型三种数据模型，兼顾了数据更新和查询性能。如果你需要做实时报表、用户画像这类需要写入更新的分析场景，Doris/StarRocks是很好的选择。

Apache Druid主打的是时间序列数据的实时摄入和查询，在时序监控、OLAP分析的结合点上做得不错。它最擅长的是"大量数据持续写入 + 按时间范围快速聚合"这种模式。如果你的数据天然带强时间属性，查询也基本围绕时间窗口展开，Druid值得关注。

3.3 选型决策参考表

直接给一张选型参考表，方便对照决策：

选型没有绝对的对错，核心是匹配业务场景。你能接受数据多长时间延迟，就决定用离线批处理还是实时写入；你最重要的查询模式是什么，就决定表模型和存储格式。

4. 列式存储的边界：哪些场景千万别硬上

4.1 OLTP事务场景：列式存储的天然短板

列式存储不是银弹，它有明确的能力边界。

最典型的不适用场景是高频单行点查和事务处理。比如一个订单系统，用户提交订单时需要按订单号读取一行数据、修改字段、再写回去。这个操作涉及一整行的所有字段，而且需要强一致性和行级锁。列式存储的"按列读取"特性在这种场景下不但没有优势，反而因为需要组装多列数据而变慢。

列式数据库普遍不支持完整的事务隔离级别，不支持复杂的外键约束，也不擅长处理UPDATE/DELETE这类操作。很多列式引擎（比如ClickHouse的默认表引擎）把数据设计成不可变或追加式的，每次UPDATE实际是"插入一条新记录 + 标记旧记录作废"，频繁更新会导致存储膨胀和性能下降。

4.2 高频单行查询的尴尬

再举一个例子。我们内部有一个运营后台，需要根据手机号实时查询用户信息，QPS大概上千。这个需求放在列式库里非常别扭：一条用户记录的所有字段都要返回，列式存储反而要多列拼接；而且每次都是单点查询，列式引擎的分区裁剪、小文件合并等优化机制完全发挥不出来。

后来我们把这个需求放在MySQL里，加个手机号索引，单机就扛住了。这说明没有一种存储引擎适用于所有场景。列式存储擅长的是"一次扫一大片数据、只取其中几列、做聚合统计"，而不是"随机翻一条记录、取全部字段"。

4.3 多表JPJOIN的痛点

列式存储还有个需要正视的问题：复杂多表关联查询。

为了极致追求单表查询性能，很多列式数据库把表设计成宽表模式（一张大表包含所有维度和指标字段），通过冗余存储避免JOIN。比如ClickHouse的社区里有个经典说法："在ClickHouse里你不需要JOIN，你需要的是把数据拍平进一张大表。"

但现实业务中往往没法完全避免多表关联。两个十万行级别的表做JOIN可能感觉不明显，但两个十亿行级别的表做JOIN，即使使用列式存储，也需要shuffle、构建哈希表、磁盘溢写，性能依旧会急剧下降。这时候你可能需要考虑Doris/StarRocks这类MPP架构中对JOIN优化做得更好的引擎，或者通过数仓分层、预计算、宽表建模等手段规避JOIN。

5. 实践指南：从建表设计到查询优化的完整步骤

5.1 分区字段选什么：时间字段是首选

在实际使用列式存储引擎（ClickHouse、Doris等）时，第一个要踏实做的决策是分区字段选什么。

绝大多数列式数据库的第一分区选择都是时间字段，这对两个原因：一是分析业务天然有强烈的时间属性，"近30天"、"本季度"、"去年同期"这类过滤条件是标配；二是时间字段天然递增，写入时顺序感强，新数据总是落在最新分区，避免了大量随机IO和分区碎片。

以ClickHouse的MergeTree表为例，常见建表语句长这样：

sql复制CREATE TABLE user_behavior (
    event_date Date,
    user_id UInt64,
    page_url String,
    duration_seconds UInt32,
    ...
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_date)
ORDER BY (page_url, user_id);

这里PARTITION BY按月分区。查询时只要带上时间条件，引擎就能直接跳过不符合月份的分区，只扫描相关分区的数据。

5.2 排序键怎么设计：把高频过滤字段放前面

排序键（ORDER BY）是列式存储中影响查询性能的核心参数。它决定了数据在每个分区内的物理排列顺序，而物理排列顺序直接决定了前面说的Zone Map、minmax索引等统计信息能否生效。

排序键的设计原则是：高频等值过滤字段放前面，次高频字段放后面，最后放排序字段。

举个例子。一个用户行为分析表，最常见的查询条件是"查某个用户在某段时间内的行为"和"查某个页面在某段时间的访问量"。那么排序键可以设计为：

sql复制ORDER BY (user_id, page_url, event_date)

这样设计的好处是：同一用户的记录在物理上被集中存放，压缩效率更好，查询时Scan的范围也最小。如果你把event_date放最前面，而用户ID放在后面，查询"某个用户的行为"时，引擎无法快速定位数据位置，只能扫描大量不相关的分区，性能差距可能好几倍。

有一个常见误区是"分区字段一定要放在排序键第一位"。这个说法不完全对。分区的裁剪不受排序键影响，排序键只影响分区内的数据排列。你完全可以把分区字段设为月份，排序键的第一位设为用户ID，两者互不冲突。

5.3 压缩算法的选择：存储空间与查询速度的平衡

列式存储通常支持多种压缩算法，最常见的是LZ4和ZSTD。

LZ4的压缩速度极快，CPU开销小，但压缩比相对低。ZSTD的压缩比更高，能省更多磁盘空间，但压缩和解压时消耗的CPU时间更多。

怎么选，取决于你的业务瓶颈在哪：

• 如果查询响应时间要求高，服务器的CPU资源相对紧张，优先用LZ4。它牺牲一点存储空间，换取更低的CPU消耗和更快的查询速度。
• 如果磁盘空间紧张，或者数据量极大并且以离线任务为主（用户能容忍几分钟的等待），优先用ZSTD，用算力换空间。

ClickHouse建表时可以在压缩设置里指定：

sql复制CREATE TABLE user_behavior (...) ENGINE = MergeTree()
SETTINGS index_granularity = 8192, compression = 'zstd';

另外还有压缩级别可以调。默认ZSTD级别一般是1或3，如果磁盘空间极度紧张，可以试试把级别调高一点，压缩比还能再上一个台阶，但写入性能和查询性能也会相应下降。需要根据实际数据量自己测试，没有统一的"最优配置"。

5.4 写入层面最容易踩的坑：小文件和大写入间隔

列式存储数据库的写入模式非常讲究。不像MySQL那样一条一条INSERT就能跑得很欢，列式数据库强调整批写入。

以ClickHouse为例，每次INSERT都会生成一个数据part（数据分片），后台的Merge线程会把多个小part逐渐合并成大part。如果你每秒都往表里INSERT几十条数据，会产生大量极小文件，Merge线程根本来不及合并，最终会面临一个尴尬局面：

• 查询需要读的文件数暴涨，打开文件、读取元数据的开销远超实际读取数据的开销；
• 磁盘上堆积大量碎片文件，HDFS Namenode或本地文件系统都受不了；
• 后台Merge进程持续高负载，占用大量CPU和IO。

正确的姿势是：数据攒着批量写入。比如每5到10分钟批量写一次，每次写入的数据量足够大。实时性要求特别高的场景（毫秒级延迟），可以部署专门的实时写入模块（Kafka→流式计算→列式数据库），通过攒批和攒大小两个维度控制写入频次。

这张表可以做一个参考：

5.5 查询优化：尽量别用SELECT *，数据分布也能榨出性能

即使用了列式存储，SQL写法仍然能显著影响查询性能。最经典的一条：不要写SELECT *。

列式存储最大的优势是只读需要的列。如果你写了SELECT *，引擎不得不把表里所有列都读进来，列裁剪机制完全失效。一个100列的表，业务可能只需要其中5列，SELECT *会让IO规模放大20倍。

我在实际团队里推过一个硬性规范：分析查询必须显式列出需要的字段，禁止用SELECT *。这个规范带来的性能提升肉眼可见。

另外，合理利用物化视图也是列式存储实践中的常用套路。ClickHouse里可以这样建物化视图：

sql复制CREATE MATERIALIZED VIEW mv_page_daily
ENGINE = SummingMergeTree()
PARTITION BY toYYYYMM(event_date)
ORDER BY (page_url, event_date)
AS SELECT
    page_url,
    event_date,
    count(*) AS pv,
    count(DISTINCT user_id) AS uv
FROM user_behavior
GROUP BY page_url, event_date;

数据写入源表时，物化视图会自动把明细数据聚合到预计算表中。查询的时候直接查聚合结果，不用再实时跑几亿行明细的聚合计算。空间换时间，效果立竿见影。

6. 实际项目中的经验教训：排序键选错之后，查询慢了一百倍

6.1 一次排序键设计事故的复盘

最后分享一个我实际遇到过的案例，这个坑很有代表性。

去年我们有一个广告投放分析需求，数据量大概每天1亿行，需要按广告位、媒体渠道、投放时间的组合维度做报表。第一版排序键是这么设计的：

sql复制ORDER BY (media_channel, ad_slot, event_date)

看起来没什么问题：字段之间的层级关系合理，过滤条件基本都能命中。但上线后真实查询性能令人发指——按"广告位+时间"查询的数据，响应时间稳定在4分钟以上。

排查时发现，排序键的第一位media_channel把数据物理上按媒体渠道分开了。而业务方真正的查询模式是"先确定广告位，再看时间范围"，媒体渠道反而不常用来过滤。排序键和查询模式不匹配，导致每次查询都要扫描几乎全表的数据，Zone Map完全失效。

后来我们调整了排序键：

sql复制ORDER BY (ad_slot, event_date, media_channel)

同样的查询，响应时间从4分钟降到20秒左右。只改了一个字段顺序，性能提升了十几倍。

6.2 为什么排序键要贴近"大多数真实查询"

事后复盘，这个问题的本质是：排序键决定了数据在物理文件上的簇聚程度（clustering）。查询用的过滤字段如果恰好是排序键的前置字段，引擎可以借助统计信息快速定位数据范围；如果过滤字段不在排序键前面，引擎只能把整个分区翻一遍。

所以设计排序键前，先做一件事：拉出过去三个月最核心的20条查询SQL，统计WHERE子句里出现频率最高的字段。然后按出现频率从高到低排列，作为排序键的候选顺序。这个土办法虽然不「高大上」，但极其有效。

6.3 列式存储性能优化的排查思路

当列式数据库查询性能不达标时，我一般按这个顺序排查：

1. 看是否命中分区裁剪：EXPLAIN输出里，确认查询扫描的分区数是否符合预期。如果本应只扫1个分区，实际却扫了12个分区，说明WHERE条件写得不规范，或者分区字段没传进来。
2. 看是否命中可用的索引/统计信息：过滤字段是否在排序键上？是否能用上minmax索引、布隆过滤器等。
3. 看数据倾斜情况：如果某个分区的数据量远大于其他分区，查询时间会被这个热点分区拉长。需要检查数据写入是否均匀分布。
4. 看小文件数量：如果查询需要扫描的分区里有大量小文件，IO开销会严重拖垮性能。调整写入频率或者执行合并操作。
5. 看内存是否溢出：大聚合查询如果内存不足，会触发磁盘溢写，性能断崖式下滑。适当增加内存配额，或者优化SQL减少中间结果大小。

按照这个顺序排查，大部分列式存储性能问题都能定位到根因。

6.4 一套可复制的起步实践路径

最后给准备上手列式存储的团队一条推荐路径：

• 第一步，如果你的数据还在HDFS上且主要跑离线任务，先把核心数据转成Parquet格式，用Spark/Hive/Presto查询，通常能直接感到查询速度的提升。
• 第二步，对查询延迟有更高要求的在线报表场景，引入ClickHouse或Doris，把Parquet数据导入列式数据库，同时注意分区和排序键设计。
• 第三步，根据业务查询模式持续调优：优化排序键、合理使用物化视图、控制写入频率和批次大小。
• 第四步，沉淀一套表结构设计和SQL规范，告诉团队哪些做法是正确的，哪些写法要避免，避免同样的问题在多人协作中反复出现。

整个过程中，最值得投入精力的是第二步里的表结构设计。很多人一开始不重视，随手建表，等数据量大了再回头改排序键、改分区，迁移成本非常痛苦。前期多花半天认真设计表结构，后面能省下几周的调优时间。

我自己在多个项目里反复验证过一个结论：列式存储的选型和表设计，决定了系统性能的天花板，SQL优化和调参只是在地板之上做一些微调。方向选对了，性能不会差到哪里去；方向错了，再厉害的优化手段也只能事倍功半。希望这篇整理能帮你少走一些弯路。