Parquet 文件格式解析

Fri, 07 Aug 2026 00:00:00 +0800

Parquet 诞生时，Hadoop 生态中的数据处理框架正在快速增多。同一份数据会被不同工具反复读取，却缺少一种独立于计算框架的高效列式格式。分析查询通常只需要少数几列；按完整记录读取，会把大量 I/O 浪费在无关字段上。

Parquet 并非第一个列式存储格式。它的价值在于把列式表示、编码和压缩写进一套公开的文件规范，并借鉴 Google Dremel 的记录拆分与重组算法来表示嵌套数据。项目最初由 Twitter、Cloudera 等贡献者开发，2014 年进入 Apache Incubator，次年毕业成为 Apache 顶级项目。现在，多种语言和分析工具都能直接读写 Parquet。

正文固定读取 parquet-lab/transactions-small.parquet。这是一份未加密的普通 Parquet 文件，由附录 B中的脚本生成。样例有 30,000 行、3 个 Row Group 和 8 个叶子列。精确大小与校验值集中列在附录中。除附录 A 的嵌套示例外，正文中的 parquet 与 DuckDB 命令都读取这份文件。

现在给查询引擎一个具体问题：从这份交易文件中，按用户汇总 2026 年 5 月 8 日 03:00 到 04:00 的交易净额。

SELECT user_id, SUM(amount)
FROM transactions
WHERE created_at >= TIMESTAMP '2026-05-08 03:00:00'
  AND created_at <  TIMESTAMP '2026-05-08 04:00:00'
GROUP BY user_id;

通过 SQL 可得到结果列、过滤条件和聚合方式，却无法告诉读取器这些列数据在文件中的具体位置。执行查询前还要回答三个问题：

Schema 如何定义，user_id、amount 和 created_at 对应哪些叶子列？
哪些 Row Group 和 Page 不可能满足时间条件，可以直接跳过？
候选列采用什么编码和压缩，读取器怎样找到并解码它们？

1. Parquet 文件结构#

先看完整文件，再模拟查询。图中的粗边界表示 File -> Row Group -> Column Chunk -> Page。细线只表示局部放大，不是数据流。

Apache Parquet on Yeqown

Parquet 文件格式解析

1. Parquet 文件结构#