大数据系统文件格式ORC与Parquet
一、ORC与Parquet的基本定义
-
ORC（Optimized Row Columnar）
- 设计背景：由Hive社区优化而来，专为Hadoop生态系统设计，尤其针对Hive的查询优化。文件结构包含Stripe（逻辑数据块）、Row Group（最小读取单元）和索引数据，默认使用ZLIB压缩，支持ACID事务和复杂类型（如Struct、Map）。
- 示例：假设一个Hive表包含字段
user_id（整数）、user_info（结构体{name: string, age: int}），ORC会将其拆分为多个子列（如user_info.name和user_info.age），每个子列独立存储并压缩，通过索引快速定位数据。
-
Parquet
- 设计背景：受Google Dremel论文启发，由Cloudera和Twitter联合开发，专注于高效存储嵌套数据（如Protocol Buffers、Thrift）。文件结构包含Row Group（行组）、Column Chunk（列块）和Page（最小编码单元），支持Snappy、Gzip等压缩算法，但不支持ACID事务。
- 示例：若存储嵌套数据
order: {id: int, items: array<{product: string, price: float}>}，Parquet通过definition level和repetition level编码嵌套层级，无需物理拆分字段即可单独读取子列。
二、核心区别对比
| 维度 | ORC | Parquet |
|---|---|---|
| 压缩效率 | 默认ZLIB压缩率更高（测试中ORC压缩后2.8MB vs Parquet的13.1MB） | 支持多种压缩算法（如Snappy），但压缩率略低 |
| 嵌套数据支持 | 通过复杂类型间接实现，深层嵌套时性能下降 | 原生支持嵌套结构，通过def/rep level高效处理多层嵌套 |
| 事务与ACID | 支持ACID事务（Hive场景下） | 不支持事务，写入后不可修改 |
| 生态系统兼容性 | 与Hive深度集成，Presto部分支持 | 广泛支持Spark、Impala、Iceberg等，成为数据湖主流格式 |
| 索引与随机IO | 统计信息分散（文件、Stripe、Row Group三级），易导致随机IO | 元数据集中存储于FileMetadata，减少随机读取 |
三、具体数据场景示例
-
压缩率对比
- 原始文本文件大小：18.1MB
- ORC（默认ZLIB压缩）：2.8MB（压缩比约6.5:1）
- Parquet（默认Snappy压缩）：13.1MB（压缩比约1.4:1）
- 结论：ORC在存储空间占用上显著优于Parquet。
-
嵌套查询性能
- 查询语句：统计用户订单中价格超过100元的商品数量。
- ORC：需逐层解析
order.items的结构体，导致多次IO和CPU解码。 - Parquet：直接通过
rep level定位数组元素，仅读取price列并过滤，效率更高。
-
大文件处理
- ORC：若使用Snappy压缩，因不支持文件分割（Splittable），可能引发数据倾斜（单个Map任务处理超大文件）。
- Parquet：支持LZO等可分割压缩算法，适合分布式处理TB级数据。
四、选型建议
-
优先选择ORC的场景
- Hive数仓，需ACID事务或高压缩率。
- 数据模型扁平（如日志表），无需复杂嵌套。
-
优先选择Parquet的场景
- 嵌套数据频繁查询（如JSON、Protobuf数据）。
- 多引擎兼容需求（如Spark、Iceberg）。
总结
ORC和Parquet各有优劣：ORC在Hive生态中表现卓越，适合事务和高压缩需求；Parquet凭借嵌套数据支持和广泛兼容性，成为数据湖首选。实际选型需结合数据特征、查询模式和生态系统集成度综合考量。