Parquet 和 ORC 怎么选？
面试怎么回答
Parquet 和 ORC 都支持列裁剪、压缩和谓词下推。Parquet 常见于 Spark 与数据湖生态，ORC 与 Hive 体系结合较深，但我不会只按标签选择。我会看主引擎兼容、嵌套类型、Row Group 或 Stripe 统计、写入模式和工具链，再用真实查询比较压缩率、扫描字节、CPU、写入耗时和跨引擎一致性。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
两种格式都是列式存储，都支持压缩、谓词下推和列裁剪。那是不是随便选一个都一样？
真正的差别常常不在格式宣传，而在计算引擎生态、写入方式、统计信息和团队工具链。
Parquet 与 ORC 都是成熟列式格式，选型应优先看引擎兼容、数据类型、更新模式、索引统计和端到端实测。
先看主要计算生态
Parquet 在 Spark、数据湖和跨语言生态中非常普遍；ORC 与 Hive 系工具结合紧密。实际支持会随引擎版本和连接器变化，应以主查询引擎的读写能力为准。
再看文件内部组织
Parquet 由 Row Group、Column Chunk 和 Page 组成；ORC 使用 Stripe，并提供多级统计与行索引。两者都能通过列裁剪和统计信息减少读取，但粒度与实现不同。
写入参数影响很大
Row Group 或 Stripe 大小、压缩算法、字典编码、排序和文件大小，往往比格式名称更影响性能。参数过小会增加元数据，过大又提高内存与随机读取成本。
用真实负载验证
选取宽表、嵌套字段、高基数字符串和典型过滤条件，比较写入吞吐、压缩率、扫描字节、CPU 和兼容性。不要只用一次全表 COUNT 做结论。
为什么不能只回答概念？
“误区：Parquet 开放通用，ORC 压缩更高，所以答案固定”之所以常见，是因为它在理想数据和单次执行里往往说得通。但生产环境会加入数据规模、异常值、并发、版本、失败重试和下游口径，这些条件一变化，只记住术语就很容易给出错误结论。
所以我会把 先看主要计算生态、再看文件内部组织、写入参数影响很大、用真实负载验证 串成一条完整链路。最终判断标准不是某个函数或配置是否出现，而是能否稳定得到可解释、可验证、可恢复的业务结果。
落地时我会检查什么？
- 输入边界：确认数据范围、时间口径、主键和异常值是否符合假设。
- 执行过程：观察分区、并行度、状态、Shuffle 或资源变化，验证方案是否真正生效。
- 输出结果：用行数、唯一性、关键指标和样本明细证明结果正确，而不是只看任务成功。
- 失败恢复：说明重跑、回滚、版本兼容和责任人，避免一次成功后无人维护。
这些检查不一定全部写进一条 SQL 或一个任务，但面试时能主动补充，说明你回答的不是背诵题，而是在描述一套可上线的工程方案。
一个典型场景
一个团队从 ORC 切到 Parquet，只因为新平台默认推荐 Parquet。迁移后某些高频过滤查询反而变慢，原因是 Row Group、排序和统计配置沿用默认值，且旧引擎对新编码支持不完整。重新按实际查询模式调优后，格式切换的收益才体现。
文件格式是基础，读写实现和参数才决定实际体验。