Loading......

文章背景图

📚 大数据存储格式详解:TextFile / ORC / Parquet

2025-11-24
5
-
- 分钟

在传统数据仓库或早期 Hadoop 体系中,TextFile 是最常用的文件格式,但随着数据规模增大,其局限性非常明显,因此 ORC / Parquet 逐渐成为主流。本笔记深入分析三者的结构、差异及最佳实践。


📝 1. TextFile 的行式结构问题

传统 TextFile(如 CSV、TSV、日志)属于 行式存储(Row-based Storage)

1.1 TextFile 在大数据中的典型问题

📉(1)压缩率低

行结构松散、冗余多,不利于压缩。

🐢(2)全行扫描,列裁剪无效

查询少数列也必须读取整行 → I/O 浪费巨大。

🧩(3)行是原子粒度,无法利用列优化

不能跳过不相关字段,不支持向量化。

👉 总结:TextFile 不适合 PB 级大规模数据仓库与分析。


🧊 2. ORC 文件格式(Optimized Row Columnar)

ORC 是 Hive 体系最主流的列式存储格式,以高压缩率、高扫描性能著名。


2.1 ORC 的主要特点

  • ✔ 列式存储(按行组 → 列块组织)

  • ✔ PB 序列化元数据,压缩率高

  • ✔ 列裁剪、谓词下推

  • ✔ 支持索引(min/max/bloom filter)

  • ✔ Hive/Spark 原生支持


2.2 ORC 文件整体结构

| —————— Data Stripes —————— |
| Stripe 1 | Stripe 2 | Stripe 3 | … |
|———— File Footer ————|
|———— PostScript ————|

2.3 PostScript(文件末尾元信息)

记录:

  • 压缩算法

  • footer 长度

  • 版本信息

👉 ORC Reader 读取文件从这里开始。


2.4 File Footer(文件级元信息)

包含:

  • Stripe 索引

  • 列的统计信息

  • 每个 stripe 偏移量

用于快速过滤无关 stripe。


2.5 Stripe(默认 250MB 数据块)

Stripe 包含三部分:

(1)Index

记录列的:

  • min/max

  • null 数量

  • bloom filter(可选)

用于跳过不满足条件的数据块。

(2)Data

真正存储数据,按列组织,支持编码压缩。

记录各列的编码方式、偏移量等。


2.6 ORC 三层过滤(查询加速核心)

  1. 文件级过滤

  2. Stripe 级过滤

  3. Row Data 内的列裁剪

👉 使得 ORC 查询性能远高于 TextFile。


2.7 ORC 读取流程

  1. 读取 PostScript

  2. 读取 File Footer

  3. 判断是否跳过特定 stripe

  4. 加载 Stripe 的 index/footer

  5. 最终按列读取 Row Data


🟦 3. Parquet 文件格式(Spark、Flink 主流)

Parquet 是另一种列式存储格式,结构更细粒度,尤其适合嵌套数据类型(JSON/Struct)。


3.1 Parquet 文件结构

File
 ├── RowGroup 1
 │     ├── Column Chunk A
 │     │       ├── Data Page 1
 │     │       ├── Data Page 2
 │     └── Column Chunk B
 │             └── …
 ├── RowGroup 2
 └── Footer

3.2 组件说明

(1)Row Group

一组行数据
通常对应 HDFS 一个 block(128MB)

(2)Column Chunk

一个 row group 中某一列的数据块

支持:

  • 单独压缩

  • 列裁剪

(3)Data Page(最小数据页)

包含:

  • 编码(RLE、bit-pack)

  • 压缩块

  • 嵌套结构的定义层 / 重复层

👉 Parquet 对嵌套数据比 ORC 更友好。


🔥 4. 数据重排(排序 + 分发)提升压缩率

重排(reorder)是存储治理的重要手段。


4.1 为什么排序能提升压缩?

排序后相似字段连续出现 → 压缩算法更容易找到重复模式 → 压缩率大幅提高

典型示例:

  • user_id 排序

  • event_type 排序

  • 时间戳排序


4.2 适用场景

  • 日志大宽表

  • 支付 / 交易流水

  • 行为数据

  • 大量重复维度字段的表


4.3 Hive 重排示例(重要!)

分布 + 排序:

DISTRIBUTE BY partition_key
SORT BY sort_key

典型 SQL:

INSERT OVERWRITE TABLE t_orc
SELECT *
FROM source
DISTRIBUTE BY biz_date
SORT BY biz_date, user_id;

4.4 重排的优点

  • 📦 显著提高压缩率(ORC + zlib 最佳)

  • ⚡ 提升查询速度

  • 📉 扫描数据更少


4.5 重排缺点与调优点

  • 排序会增加执行时间

  • reducer 数量、并发需要合理规划

  • 分区过多会造成小文件问题


🎯 5. ORC 与 Parquet 对比总结

特性

ORC

Parquet

生态适配

Hive 最佳

Spark/Flink 最佳

压缩率

⭐⭐⭐⭐⭐

⭐⭐⭐⭐

写性能

较好

更好

读取性能

⭐⭐⭐⭐

⭐⭐⭐⭐

嵌套结构

一般

更强

典型场景

DW、宽表

大规模计算、嵌套结构

👉 Hive → ORC
👉 Spark → Parquet

仍然是最常见的技术组合。


📘 6. 全文总结

本笔记完整整理了:

✔ TextFile 缺陷
✔ ORC 文件结构
✔ ORC 三层过滤机制
✔ Parquet 文件结构
✔ 数据重排(排序 + 分发)最佳实践
✔ ORC/Parquet 对比与使用场景

评论交流