为什么 Parquet 不适合直接用文本工具打开？

2025-12-21

很多同学第一次接触 Parquet 时，会下意识地用记事本、VS Code、Sublime 等“文本工具”直接打开 .parquet 文件，结果看到一堆“乱码”。这并不是文件坏了，而是因为：Parquet 从设计上就不是给人类直接阅读的文本格式。

本文解释：为什么 Parquet 不适合直接用文本工具打开，以及更正确、更高效的查看方式。

1. Parquet 是二进制格式，不是“可读文本”

CSV/JSON/YAML 这类格式，本质是“字符序列”，文本工具能按编码（UTF-8/GBK）把字节映射成字符，所以能读。

而 Parquet 是一个二进制容器格式：

  • 里面存的是结构化的二进制数据块
  • 通过 offset（偏移量）+ 元数据来定位每一段内容
  • 很多字节序列根本不是字符编码后的文本

所以文本编辑器看到的“乱码”是正常现象。

2. 列式存储导致它不是“按行换行”的结构

文本工具擅长的模型是：

  • 一行 = 一条记录
  • 用换行符分隔
  • 用逗号/制表符等分隔字段

Parquet 采用列式存储：

  • 同一列的数据在物理上更靠近
  • 同一行的数据并不一定连续存放

因此你无法指望像在 CSV 里那样“滚动几屏就看到某一行数据”。即使把二进制当成字符强行展示，也很难对应到行/列。

3. Parquet 会对数据进行压缩与编码（读起来更不像文本）

Parquet 的核心优势是高压缩比 + 高读取性能，所以它通常会对列数据做：

  • 压缩（如 Snappy、Gzip、ZSTD 等）
  • 编码（如字典编码、RLE、位打包等）

这意味着：

  • 你看到的很可能是压缩后的字节流
  • 即使原始数据是字符串，存储时也可能被编码/压缩

文本工具对这些内容没有“解压/解码”的能力，自然无法还原成原始值。

4. Parquet 依赖元数据与索引结构，不能靠“肉眼扫字节”理解

Parquet 文件通常包含：

  • schema（字段名、类型、是否可空、嵌套结构）
  • row group（行组）
  • column chunk（列块）
  • page（页）
  • statistics / min-max / null count（统计信息，视写入器而定）

这些结构靠元数据描述，必须用解析器才能正确读取。

没有解析器，你很难知道哪一段字节对应哪个字段、哪个行组、哪一页。

5. Parquet 常见嵌套结构与二进制列，更不适合文本查看

在真实业务数据中，Parquet 经常包含：

  • struct / list / map 等嵌套类型
  • 二进制列（图片、音频、向量、embedding、序列化对象）

这些内容就算用工具解析，也需要以更合适的方式展示（例如 JSON 展开、媒体预览、或只展示占位符），文本工具更无从下手。

6. 大文件场景：文本打开不仅没用，还可能卡死

Parquet 往往用于分析型数据，文件可能很大。

文本编辑器对超大文件的体验通常是：

  • 打开慢、渲染慢
  • 搜索慢
  • 容易占用大量内存

而 Parquet 的正确打开方式通常是“按需读取”：

  • 只读 schema
  • 抽样读取前 N 行
  • 只读某几列
  • 用条件过滤减少扫描

7. 那应该怎么“正确打开” Parquet？

以下是更推荐的方式：

  • 用在线 Parquet Viewer：直接看 schema、预览行、搜索、SQL 过滤
  • 用 DuckDB：本地或浏览器环境都能用 SQL 直接查询 Parquet
  • 用 Spark / Trino / Presto：用于生产级大数据分析
  • 用 Python pandas + pyarrow：适合开发调试与小规模处理

8. 实用建议：什么时候用 CSV，什么时候用 Parquet？

  • 如果目标是“人类阅读/手工编辑/简单传输”：
    • 优先 CSV / JSON
  • 如果目标是“分析计算/压缩存储/按列读取/大规模数据”：
    • 优先 Parquet

二者不是替代关系：很多团队会采用“Parquet 做存储 + CSV 做临时导出/共享”的组合。

小结

Parquet 不适合用文本工具直接打开，原因不是“它太高级”，而是它本来就不是文本格式：

  • 二进制容器
  • 列式存储
  • 压缩与编码
  • 元数据驱动的结构化布局

当你需要排查或浏览 Parquet 内容时，推荐使用 Parquet Viewer 或 SQL 引擎（如 DuckDB）去做“按需读取”。