Parquet和ORC怎么选？生产环境用哪个？
先说结论
一句话总结：用Spark引擎就选Parquet，用Hive原生引擎就选ORC。 现在大多数公司都用Spark作为执行引擎，所以Parquet是主流选择。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
文件格式的选择直接影响存储成本和查询性能。很多人知道“列式存储比行式快”，但问到Parquet和ORC具体怎么选就答不上来了。今天用我在三家公司的真实经验来讲清楚。
为什么Spark上Parquet更快？
Parquet是Spark的原生数据源，Catalyst优化器对Parquet做了大量专属优化：
① 分区裁剪更彻底： Parquet的元数据里有每个Row Group的统计信息（最小值、最大值），Catalyst可以跳过不符合条件的Row Group。
② 向量化读取（Vectorized Reader）： Spark对Parquet默认开启向量化读取，批量处理数据，CPU缓存命中率更高。
③ Tungsten内存格式兼容： Parquet的内存布局和Tungsten的二进制格式更匹配，转换开销更小。
详细对比
| 维度 | Parquet | ORC |
|---|---|---|
| 起源 | Twitter/Cloudera | Facebook → Apache Hive |
| Spark支持 | 原生数据源，性能最优 | 支持但非原生，性能稍差 |
| Hive支持 | 支持 | 原生，性能最优 |
| 默认压缩 | Snappy（快） | ZLIB（压缩率高） |
| 索引能力 | 列统计信息 | 列统计 + Bloom Filter + 轻量索引 |
| 嵌套类型支持 | 非常好（原生支持） | 支持但稍弱 |
| 多引擎生态 | Spark/Flink/Trino/Presto全部原生 | 主要是Hive生态 |
| ACID事务 | 不支持（需要Delta/Iceberg） | 支持（Hive ACID） |
压缩算法怎么选？
Snappy： 压缩/解压速度快，压缩率一般。适合热数据（经常查询的）。
Zstd： 压缩率高且速度不慢，Spark 3.x开始支持。适合存储成本敏感的场景。
Gzip/ZLIB： 压缩率最高但慢。适合归档数据（很少查询）。
实战经验：统一格式后的效果
我在出海硬件公司迁移到Databricks时，把原来的混合格式（部分ORC、部分Parquet、甚至还有JSON和CSV）统一切换为Parquet + Snappy压缩。
效果：存储空间整体减少40%（主要是JSON/CSV→Parquet的压缩收益），查询性能平均提升30%。后来升级到Delta Lake后，底层仍然是Parquet，只是加了一层事务日志。
总结
记住一句话：Spark选Parquet，Hive原生选ORC。压缩选Snappy（热数据）或Zstd（省空间）。面试的时候能说清楚“为什么Spark上Parquet更快”（原生支持 + 向量化读取 + Tungsten兼容），再加一个格式统一后的实战效果，就很完整了。
下一篇聊数据血统——老板问“这个指标是怎么算的”，你怎么快速追溯？这是数据治理的核心能力。
你们生产环境用的什么文件格式和压缩算法？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长