人人喊你换Parquet，没人讲清为什么

在数据工程圈，"用 Parquet"大概是被重复最多的一条建议，也是被解释得最少的一条。听过的人很多，说得清为什么的很少。这篇文章把这台机器拆开看：它到底省在哪、什么时候不省，以及为什么看不懂原理的团队，总会在迁移这笔账上栽跟头。

🗣️ 被复读一万次的建议，没人讲透

最好的建议，往往配着最敷衍的解释。

一位做数仓的朋友讲过他的入职第一课：团队 Wiki 里躺着一条铁律——所有落地的 CSV 文件，统一转成 Parquet。他照做了，跑完一看，压缩比只有 3 倍，而技术博客里写的明明是 20 倍。他去问老同事，得到的回答只有一句："大家都这么转。"

据多位接近数据平台团队的人说，这种"压不动"的困惑，几乎是每支数据团队新人的必修课。

这条建议本身没错——它确实是数据工程里被重复最多的话。但"重复最多"和"解释最少"往往是一对孪生兄弟。不知道它为什么赢，你就无法判断它什么时候不赢。结局只有两种：要么把本该留在 CSV 的文件白白转了一遍，要么被 3 倍的实际压缩比惊掉下巴——因为你原本有资格期待 20 倍。

产业逻辑其实很直白：文件格式从来不是口号，是一笔账。存储的钱、扫描的算力钱、迁移的人工钱，三者共同决定这个决定值不值。而算清这笔账的前提，是理解 Parquet 赢的几条机械原理——不需要论文，几个常识就够了。

🔍 列裁剪：只读你要的那一列

行式存储的浪费，从你只需要一列的那一刻开始。

假设有一张用户表，字段包括 id、name、email、signup_date、revenue。现在你只想算总收入，写了一句 SELECT SUM(revenue)。

CSV 是按行存的。要读 revenue，读取器得从文件头走到文件尾——每一行的姓名、邮箱、日期都要从磁盘读出来、解析一遍，才能凑出你要的那一列。换句话说，为了不到五分之一的数据，你付了 100% 的 IO 和解析成本。

Parquet 按列存。同样一句 SUM(revenue)，读取器只碰 revenue 那一列，其余列一个字节都不读。

数据很朴素：大多数分析查询只会触碰表中 10% 到 20% 的列。这意味着按列存储只读文件的 10%-20%，而 CSV 永远是 100%。那些头条基准测试里十几倍的差距，背后的核心机关就这么简单。

更关键的是，这个红利会随表变宽而放大。表从 5 列变成 50 列，CSV 的扫描成本线性上涨，Parquet 几乎不动。这就是为什么越是大宽表场景——用户行为、日志、埋点——列式的优势越夸张。所谓头条 benchmark，本质上都是在宽表上拍的照。

🗜️ 压缩的红利：相似的挨在一起

压缩算法吃的是规律，行式存储喂给它的却是噪声。

CSV 的一行，是字符串、日期、浮点数和整数挤在一起的一条长文本。类型混杂、模式混乱，压缩器看过去近乎随机，能压掉的就有限——这就是为什么很多团队的 CSV 加上 gzip 之后，账面依然难看。

Parquet 的一列，是一千万个浮点数挨着放，或者一千万个日期挨着放。相似的东西相邻，规律就浮出来了：重复值、相近数值、固定格式，全是压缩算法最爱的饲料。素材里那句话说得精准：压缩作用于模式，而按列排列让模式自己浮出水面。

存储费用其实只是小头。真正的大头在扫描吞吐——同样的机器，读 15% 的字节和读 100% 的字节，速度差的是倍数级。在按扫描量计费的引擎上（这在云数仓里是常态），少读字节就是直接省钱。这也是为什么"列存"两个字，能撑起整个湖仓时代的底层叙事。

⚠️ 什么时候，Parquet 反而不是答案

知道一个技术什么时候失效，才算真的懂它。

回到开头那两种翻车。第一种：把不该转的文件转了。什么样的数据，✅ 应该留在 CSV？

• 按整行取用的数据。比如配置表、维表 lookup，每次都是捞一整行，列裁剪帮不上任何忙；
• 需要和"只认 CSV"的世界打交道的场景：给业务方出 Excel 友好的导出、和外部伙伴交换文件、喂给只会读文本的下游脚本；
• 一次性、小体量的临时数据。转换本身有成本，数据太小，省下的不够付折腾的。

第二种翻车：压缩比只有 3 倍而不是 20 倍。列存压缩靠的是"相似数据相邻"。如果你的列本身高基数、近似唯一——用户 ID、随机 token 这类——再按列排，也没有多少规律可吃。❌ 比例低不代表你做错了，只代表这份数据没那么多水分可挤。

据圈子里流传的一个说法：判断一个数据工程师是不是真上手过，就看他是只会背"用 Parquet"这三个词，还是能说出"我们哪张表留着 CSV、为什么"。

工程判断力的本质，是把普适建议还原成具体约束。"Just use Parquet" 是对的，但它是一个决策序列的第一句，不是全部。

🏗️ 从一个文件格式，到湖仓的地基

格式看似小事，实际上是一代数据架构的地基选择。

把镜头拉远。今天的湖仓生态，Iceberg、Delta Lake 这类开放表格式，底下的数据文件清一色是 Parquet；Spark、Trino、DuckDB 这些引擎，原生读写它不费吹灰之力。这意味着你可以换引擎、换云、换厂商——只要文件还是 Parquet，数据就还在你手里。开放格式，是数据团队留给自己的退路。

AI 侧同理。训练数据的准备、特征抽取、数据集的反复扫描，本质上都是"读少数几列、扫大量行"的负载——这正是列式存储最舒服的姿势。Data for AI 的管道越重，Parquet 的位置就越稳。这也是近期很多 AI 数据平台的选型讨论里，文件格式问题反而最少被争论的原因：答案已经收敛。

复盘这些机械原理——列裁剪省 IO、相邻相似省压缩、宽表放大红利——你会发现 Parquet 的胜利没有任何魔法，全是朴素工程账的胜利。这也是它区别于很多概念泡沫的地方：它能被拆解、被计算、被验证。数据基础设施这个领域里，凡是讲得清"为什么赢"的技术，往往也活得最久。

小结

"用 Parquet"是一句好建议，但好建议不该以口号的方式传播。看懂列裁剪和压缩这两台引擎，你才知道哪些文件值得转、哪些该原地不动、3 倍的压缩比意味着什么而不是慌什么。往后看，随着 AI 数据管道把"反复扫描、按列取用"变成常态负载，列式开放格式的地基地位只会更稳。真正该记住的不是文件后缀名，而是那套判断方法：算清 IO、算清压缩、算清迁移——格式选型从来都是一笔账，不是一个信仰。