Parquet 和 ORC 到底有啥区别？别再云里雾里了，咱今天把列式存储聊明白！
大家好，我是你们熟悉的 Echo_Wish。最近后台私信问我：“师傅，Parquet 和 ORC 到底该怎么选？看网上资料越看越迷糊，感觉它俩就是双胞胎。”
我说一句大实话：Parquet 和 ORC 是双胞胎没错，但一个偏文科，一个偏理科，理念不同、能力不同、适用场景也不同。
今天，咱就从工程师视角把 列式存储的核心逻辑 + Parquet/ORC 内部机制 + 选型建议 讲得明明白白。保证你看完之后，能在开技术会时拍着桌子说：
“这个任务我们必须选 ORC！” 或 “这个场景不用犹豫，直接 Parquet！”
开整！
🌟 一、为什么要列式存储？别只背概念
咱先别急着上标准答案“为分析优化、压缩率高、IO 少”这种 PPT 话。我用一句人话解释：
行式存储=仓库把货按订单放，列式存储=仓库把货按“属性”分区放。
如果你常干 OLAP 分析，那你 90% 的时间在做：
统计某列
过滤某列
分组某列
求和某列
这种情况下，扫描全行是非常浪费的，特别是字段很多的时候 —— 行式存储就像 Excel 每次都要把整行翻出来，速度自然慢。
列式存储把字段拆开存储，扫描少、压缩高，分析快，天生适合大数据。
这就是为什么 Hive、Presto、Trino、Spark SQL、Iceberg、Hudi 都离不开它。
🌟 二、Parquet 与 ORC：它俩是在“同一个目标，不同的哲学”
你可以这么理解：
Parquet：跨生态、跨引擎的通用格式，偏向 Spark/Presto 等多引擎混用的体系。
ORC：Hadoop 家族亲儿子，为 Hive 做了非常多的专门优化。
下面我拆开它俩的内部机制讲。
🔍 三、Parquet 内部结构：字段式的精致主义者
Parquet 的结构非常“分层、规整、易扩展”。大概长这样：
File
├─ Row Groups
│ ├─ Column Chunk A
│ │ ├─ Pages
│ ├─ Column Chunk B
│ │ ├─ Pages
...
└─ Footer (Schema + Metadata)
💡 关键点：
1）以 Row Group 为单位组织数据
一个 Row Group 通常 128MB ~ 1GB
大数据引擎读取时可以并发处理多个 Row Group
2）每列的数据独立压缩
每列可以不同编码，例如：
字符串：DICT
int：RLE
布尔：bit-packed
非常适合 高基数+稀疏 的列。
3）Parquet 注重跨系统兼容性
Spark、Presto、Impala、ClickHouse、Iceberg 都用它。
📌 代码示例（PySpark 写入 Parquet）
df.write.mode("overwrite").parquet("/tmp/parquet_demo")
🔍 四、ORC 内部结构：为 Hive 而生的“压缩狂魔”
ORC 的结构看起来比 Parquet 更“工程化”：
File
├─ Stripes (大块数据)
│ ├─ Index Data
│ ├─ Row Data
│ └─ Stripe Footer
└─ File Footer
💡 关键点：
1）以 Stripe（Stripe ≈ 64MB 默认） 为核心
一个 Stripe 包含：
Row Data（核心数据）
Index Data（索引）
Stripe Footer（压缩、偏移信息）
内置的 Stripe Index 能让 ORC 的谓词下推更狠。
2）压缩能力更强
ORC 默认对字符串和整数使用更 aggressive 的字典编码 + RLE2，压缩率往往比 Parquet 高 10%-30%。
3）统计信息非常丰富（Hive 优化器最爱）
例如：
min/max
distinct count
bloom filter
null count
column statistics
Hive 的 CBO（成本优化器）依赖这些统计信息做优化。
📌 代码示例（Spark 写 ORC）
df.write.mode("overwrite").orc("/tmp/orc_demo")
⚔️ 五、核心差异总结（最干的部分）
维度
Parquet
ORC
发源地
Twitter + Cloudera
Hortonworks（Hive 原生）
最佳搭档
Spark / Presto / Iceberg
Hive / ETL 批处理
压缩率
高
更高（通常）
统计信息
足够
特别丰富
查询加速
优秀
极优秀
小文件处理
较好
略优
写入速度
稍快
略慢
跨生态兼容性
最佳
一般
写成一句话：
你要生态？选 Parquet。你要极致压缩+极致 Hive 查询？选 ORC。
💼 六、实际工程选型建议（我最让人点赞的部分）
✔ ① Spark 生态+多系统混用
Parquet 是王道。你很可能还有 Presto/Trino、ClickHouse、Iceberg/Hudi/Lakehouse，要兼容就选它。
✔ ② 基于 Hive 的离线数仓 + 大批量 ETL
ORC 更稳。Hive 的优化和 ORC 一家亲，性能差异能达到 20%-50%。
✔ ③ 强压缩率需求（数据湖冷存储）
ORC 是更实惠的选择。
✔ ④ 流式写入 + 下游多引擎消费
Parquet 更均衡。
✔ ⑤ Iceberg/Hudi/Delta Lake
绝大多数推荐默认：Parquet（数据湖标配，不解释。）
🧪 七、一个真实案例：同样 100GB 文本表 Parquet vs ORC
我们当时做了一个测试（Spark + Hive 混合场景）：
数据量：100GB 原始 JSON
字段数：64 列
业务场景：Ad-hoc 分析 + 部分 Hive Join
📊 结果非常典型：
指标
Parquet
ORC
压缩后体积
16.3 GB
11.9 GB
Hive 查询性能
1.0x
1.3~1.5x
Spark 查询性能
1.0x
0.95x
兼容性
⭕ perfect
❌ 稍弱
看结果就一句话：
ORC = Hive 场景“专用武器”
Parquet = 通用型“万能螺丝刀”
🔚 八、写在最后：格式选对，你的数仓就少走一半弯路
很多团队之所以数仓慢、查询卡、资源浪费，其实根本不是 Spark/Hive 的问题，而是——
底层文件格式选错了，天生短板再怎么调参也补不回来。
我自己的经验是：
大数据生态越来越多引擎协作 → Parquet 适应性最强
Hive 仍然是很多公司的离线基础设施 → ORC 在这块依旧无敌
数据湖时代已经到了 → Parquet 是事实标准