Interview Prep · Data Infra

大数据文件格式：
从 CSV 到 Lance

这门课按时间线讲每一种格式：它要解决上一种的什么问题，字节怎么放，读和写各走哪几步，优缺点，现在还在哪里用。后面有对比表、Staff 级的面试题、一个能跑的练习和一页速查表。

时间线

从文本文件到 Lance，每一步在解决上一步的什么问题

1. 一直都在CSV / JSON文本人能直接看懂，但没有类型，又大又慢。▼
2. 2006 前后SequenceFile行存二进制的键值对文件，可以切分，是 MapReduce 的原生格式。▼
3. 2007 / 2008Thrift / Protocol Buffers序列化它们是序列化框架，不是文件格式，但定下了 schema 演进的基本做法。▼
4. 2009Avro行存带 schema 的行存格式，擅长一条条写入和改字段。▼
5. 2010Dremel 论文列存不是开源格式，但它说明了嵌套数据怎么按列存。▼
6. 2011RCFile列存RC 是 Record Columnar：先按行切成组，组内再按列存。▼
7. 2013 年 2 月ORC列存RCFile 的继任者：知道类型，带索引。▼
8. 2013 年 3 月Parquet列存现在数据湖的事实标准。▼

   出处

   Twitter 和 Cloudera

   它要解决的问题

   Twitter 想要一个不绑定任何查询引擎的列存格式，并且能存 Thrift 那样的嵌套数据。Cloudera 的 Impala 也需要一个列存格式。

   • 魔数 PAR1
   • row group
     • 第 1 列的 column chunk
       • 字典 page可选
       • 数据 page默认上限 1 MB，独立编码和压缩
       • 数据 page …
     • 第 2 列的 column chunk
     • 第 3 列 …
   • row group …
   • 文件尾（footer）schema，每个 row group 和 column chunk 的位置，每列的统计信息
   • 文件尾的长度 + 魔数 PAR1

   怎么存

   • 文件切成 row group，每个 row group 里每列是一个 column chunk，column chunk 再切成 page。page 的默认上限是未压缩 1 MB，实际常常更小。
   • page 是编码和压缩的最小单位。常见编码有字典编码、游程编码、增量编码，编码之后再套一层通用压缩。
   • 文件尾（footer）用 Thrift 编码，记录 schema、每个 row group 的位置，以及每列的最小值、最大值、空值数量。
   • 嵌套数据用 Dremel 的 repetition level 和 definition level。

   写入的过程

   1. 攒够一个 row group 的数据，每列编码压缩成若干 page 依次写出。
   2. 所有 row group 写完后，把文件尾写在最后。
   3. 文件尾在末尾，所以文件写完之前不能读。

   读取的过程

   1. 先读文件最后 8 个字节，得到文件尾的长度。
   2. 再读文件尾，拿到 schema 和统计信息。
   3. 根据查询条件挑出需要的 row group 和列，只读这些 column chunk，逐个 page 解压解码。

   优点

   • 只读需要的列。
   • 压缩率高。
   • 靠统计信息跳过整个 row group。
   • 支持嵌套数据。
   • 几乎所有引擎和语言都能读。

   缺点

   • 随机读一行很贵：要读并解码整个 page。文件尾通常有缓存，但定位到 page 靠的 offset index 是可选的，没有它就得顺着 column chunk 一个个 page 头找过去。
   • 图片、向量这类很大的值不好放：row group 按行数切，行数少了整数列太碎，行数多了图片列一组就有几个 GB。
   • 列非常多（几千列）时，文件尾必须整个解析，光读元数据就很慢。
   • 给已有的行补一列的值，需要重写文件。

   用在哪里，现在还在哪里用

   数据湖里的分析查询，以及 Iceberg、Delta、Hudi 的数据文件。是现在的默认选择。

   被什么取代，为什么

   没有被取代。新格式是在它不擅长的地方挑战它：随机读、很宽的值、几千列的表。

   面试时，一句话

   列存的事实标准：行组、列块、页三层结构，文件尾存元数据。

   面试时，两分钟

   Parquet 的结构是三层：文件切成 row group，每个 row group 里每列是一个 column chunk，再切成 page。page 是编码和压缩的单位。文件尾存 schema 和每列的最小值最大值，所以读的时候可以只读需要的列，并跳过整个 row group。嵌套数据用 Dremel 的两个 level。它的短板是随机取一行很贵，很宽的值不好处理，给已有的行补一列要重写。它能成为标准主要靠生态：不绑定引擎，Spark 选它做默认，后来 Arrow、云数仓和表格式都围着它。

   值得补一句的

   它胜出主要靠生态，不是靠技术碾压。下面「Parquet 为什么几乎一统江湖」一节专门讲。

9. 2016Arrow内存内存里的列式格式，让不同系统之间传数据不用来回转换。▼
10. 2016–2017Hudi / Delta Lake / Iceberg表格式不是新的文件格式，而是在数据文件之上加的一层元数据。▼
11. 2022Lance新一代为 AI 数据设计：随机读快，能存图片和向量，自带索引和版本。▼
12. 2024–2025Nimble / Vortex / F3新一代都在回答同一个问题：Parquet 之后的列存格式应该是什么样。▼

先懂这五个概念

所有格式都在这五件事上做取舍

行存和列存

一条记录的字段挨着放，还是同一列的值挨着放。

写入和整行读取用行存；只读几列的分析查询用列存。这是所有格式的第一个分岔口。

可切分（splittable）

一个大文件能不能从中间切开，让多个任务同时读。

不能切分的文件只能由一个任务读完。sync marker、row group、stripe 都是为了让文件能切开。

编码和压缩

编码利用数据本身的规律（重复、递增），压缩是在字节层面再压一次。

列存压缩率高，是因为同一列的值类型相同、经常重复，先做字典编码或游程编码，再压缩，效果远好于直接压缩一整行。

数据跳过

引擎把查询条件交给读取方（这一步叫谓词下推），读取方靠每块数据的最小值、最大值，跳过不可能命中的块。

查询快不快，很大程度取决于能少读多少数据。统计信息记得越细，能跳过的越多，但元数据也越大。

schema 演进

加字段、删字段、改类型之后，旧数据还能不能读。

数据会存很多年，表结构一定会变。Avro 靠两份 schema 对齐，Protobuf 靠字段编号，Iceberg 给每列一个不变的 ID。

展开讲 · 一

SequenceFile 的一个例子

假设 HDFS 上有一百万张小图片。每个文件都要占 NameNode 的内存，每个文件还会单独起一个读取任务。常见的做法是把它们打包进一个 SequenceFile：key 是文件名，value 是图片的字节。

# PySpark：把很多小文件打包成一个 SequenceFile
# key 是文件名，value 是文件内容
pairs = sc.parallelize([
    ("cat-001.jpg", bytearray(open("cat-001.jpg", "rb").read())),
    ("cat-002.jpg", bytearray(open("cat-002.jpg", "rb").read())),
])
pairs.saveAsSequenceFile("hdfs:///datasets/cats.seq")

# 读回来：得到 (文件名, 内容) 的键值对
sc.sequenceFile("hdfs:///datasets/cats.seq").take(1)

写出来的文件，里面大致是这样：

SEQ\x06                                   魔数和版本
org.apache.hadoop.io.Text                 key 的类
org.apache.hadoop.io.BytesWritable        value 的类
压缩: 否   块压缩: 否                      压缩标志
<16 字节 sync marker>                     文件头结束

[记录长度][key 长度] "cat-001.jpg" <图片字节>
[记录长度][key 长度] "cat-002.jpg" <图片字节>
<16 字节 sync marker>                     每隔一段出现一次
[记录长度][key 长度] "cat-003.jpg" <图片字节>

文件头里写的是 Java 的类名，这就是它难以被其他语言读取的原因。sync marker 让一个任务可以从文件中间开始，找到下一条完整的记录。

展开讲 · 二

Parquet 为什么几乎一统江湖

不是因为它技术上碾压了 ORC。两者同一年出现，结构相似，性能各有胜负。差别在生态：

1. 1

   不绑定任何一个引擎

   ORC 长在 Hive 里。Parquet 由 Twitter 和 Cloudera 一起做，一开始的目标就是让多个引擎都能用，还提供了和 Avro、Thrift、Protocol Buffers 这些数据模型的转换。

2. 2

   Spark 把它当默认格式

   Spark 的默认数据源是 Parquet。Spark 成为主流计算引擎的那几年，大量新数据自然就写成了 Parquet。

3. 3

   嵌套数据处理得好

   它用的是 Dremel 的做法，和 Protocol Buffers、Thrift 这类嵌套的数据模型对得上。

4. 4

   Arrow 和 Python 生态

   pandas、DuckDB、Polars 都能一行代码读写 Parquet。数据科学家不需要搭 Hadoop 也能用它。

5. 5

   云数仓和表格式都围着它

   各家云上的查询服务都能直接读 Parquet。Delta Lake 只用 Parquet，Iceberg 的默认数据文件也是 Parquet。

一个格式一旦成为大家都能读的那个，新工具就会优先支持它，于是更多数据写成它。这是网络效应，和格式本身的细节关系不大。

展开讲 · 三

Lance 到底改了什么

1. Parquet 取一行为什么慢

   要取第 N 行的一个值，得先读文件尾，找到它在哪个 row group、哪个 page，再把整个 page（默认上限 1 MB）读出来解压解码，最后取出那一个值。要几列就重复几次。定位 page 靠的 offset index 还是可选的，没有它就得顺着 page 头一个个找。顺序扫描时这些开销被摊薄了，随机读时每一行都要付一遍。

2. Lance 怎么让随机读变快

   它去掉了 row group，每列自己切 page。2.1 版按值的宽度选存法：整数、短字符串这类窄值切成小块，每块默认最多 4,096 个值，规范要求压缩后不超过 32 KiB，取一个值只需要读一小块；图片、向量这类宽值一个挨一个放，可以直接定位到那个值。分界线在当前规范里是每个值 256 字节。

3. 加列为什么不用重写

   表由 fragment 组成，一个 fragment 可以有多个数据文件，各存不同的列。给表加 embedding 列时，只需要给每个 fragment 写一个只含新列的文件，再提交一个新版本。原来存着图片的文件完全不动。

4. 它同时是表格式

   每次写入产生一个新的 manifest，记录这个版本有哪些 fragment。所以它自带历史版本。删除是写一个 deletion file 做标记。向量索引、标量索引和全文索引也记在表里。

5. 哪些地方要小心

   生态比 Parquet 小得多；格式在一两年内连续出了 2.0、2.1、2.2；版本和小文件多了要定期合并清理。LanceDB 公布过和 Parquet 对比的性能数字，但我没有核对到它们的测试条件，也没有找到独立的验证，所以这里不引用。另外，Lance 的论文自己也提到，Parquet 配置得当时随机读可以比默认设置快很多。

七个追问

面试官顺着问下来，多半是这几句

横向对比

同样的几个维度，放在一起看

业界最新的方向 · 2026 年 10 月核对

现在大家在做什么

• 为 AI 数据设计的格式

  训练和检索需要随机读，数据里有图片和向量。Lance 是这个方向上最受关注的一个，2026 年初 Apache Polaris 这个 catalog 也接入了 Lance 表。

• 把编码从文件结构里拆出来

  Nimble、Vortex 和 F3 都让编码可以替换和嵌套。Vortex 在 2025 年 8 月进入 Linux 基金会旗下的 LF AI & Data。

• Parquet 自己也在更新

  2025 年 3 月的 parquet-format 2.11.0 加入了 GEOMETRY 和 GEOGRAPHY 两种地理类型，也第一次写进了 Variant；2025 年 8 月的 2.12.0 把 Variant 的规范定稿。Variant 用来存结构不固定的半结构化数据。

• 表格式在补行级更新的能力

  Iceberg 的 v3 规范引入了 deletion vector：用一个位图标记数据文件里哪些行被删了，位图存在 Puffin 文件里。这让频繁的更新和删除更便宜。

常见误解

这几句话听起来对，其实不对

• 误解：Parquet 胜出是因为技术比 ORC 好。

  两者技术上各有胜负。一篇发表在 VLDB 2024 的论文发现 Parquet 解码更快、文件略小，ORC 跳过数据更有效。Parquet 胜出主要是因为不绑定引擎，以及 Spark 把它当默认格式。

• 误解：Avro 已经没人用了。

  它退出的只是分析存储。Kafka 消息、数据采集，以及 Iceberg 的 manifest 文件都还在用 Avro。

• 误解：Iceberg、Delta、Hudi 是文件格式。

  它们是表格式，是数据文件之上的一层元数据。数据文件绝大多数是 Parquet：Delta 只用 Parquet，Iceberg 还允许 ORC 和 Avro。

• 误解：列存总是比行存好。

  逐条写入、整行读取、按主键取一行，这些场景行存更合适。

• 误解：Arrow 是 Parquet 的替代品。

  一个管内存，一个管硬盘，通常搭配使用。

• 误解：压缩过的文件都不能切分。

  把整个文件用 gzip 压成一个流才不能切分。SequenceFile、Avro、Parquet 都是在文件内部一块一块地压缩，所以仍然可以切分。

• 误解：Lance 会取代 Parquet。

  它们针对的读法不同。全表扫描和聚合仍然是 Parquet 的主场。

Staff 级面试题

先自己答，再点开看

动手练习 · 约 5 分钟

亲手看一眼 Parquet 的文件尾

需要 Python 和 pyarrow（pip install pyarrow）。把下面的代码存成 demo.py 再运行。

import os
import pyarrow as pa
import pyarrow.csv as pacsv
import pyarrow.parquet as pq

# 1. 造一张 100 万行的表：一列递增的整数，一列只有 4 种取值，一列小数
n = 1_000_000
table = pa.table({
    "user_id": pa.array(range(n), pa.int64()),
    "country": pa.array(["US", "CN", "IN", "BR"] * (n // 4)),
    "amount": pa.array([(i * 7919) % 100_000 / 100 for i in range(n)]),
})

# 2. 分别写成 CSV 和 Parquet，比一比大小
pacsv.write_csv(table, "demo.csv")
pq.write_table(table, "demo.parquet", row_group_size=250_000)
print("CSV    ", os.path.getsize("demo.csv") // 1024, "KB")
print("Parquet", os.path.getsize("demo.parquet") // 1024, "KB")

# 3. 读文件尾（footer）：不读数据，就能知道文件的结构
meta = pq.ParquetFile("demo.parquet").metadata
print("row group 数:", meta.num_row_groups, " 总行数:", meta.num_rows)

# 4. 看每一列在第一个 row group 里占多少字节、用了什么编码
for i in range(meta.num_columns):
    col = meta.row_group(0).column(i)
    print(col.path_in_schema, col.total_compressed_size // 1024, "KB", col.encodings)

# 5. 看每个 row group 里 user_id 的最小值和最大值
for g in range(meta.num_row_groups):
    stats = meta.row_group(g).column(0).statistics
    print("row group", g, "user_id:", stats.min, "到", stats.max)

# 6. 只读一列，并且只要 user_id >= 900000 的行
result = pq.read_table(
    "demo.parquet", columns=["amount"], filters=[("user_id", ">=", 900_000)]
)
print("读到", result.num_rows, "行")

在 pyarrow 19.0 上的实际输出：

CSV     18221 KB
Parquet 8991 KB
row group 数: 4  总行数: 1000000
user_id 1249 KB ('PLAIN', 'RLE', 'RLE_DICTIONARY')
country 2 KB ('PLAIN', 'RLE', 'RLE_DICTIONARY')
amount 994 KB ('PLAIN', 'RLE', 'RLE_DICTIONARY')
row group 0 user_id: 0 到 249999
row group 1 user_id: 250000 到 499999
row group 2 user_id: 500000 到 749999
row group 3 user_id: 750000 到 999999
读到 100000 行

• country 列在第一个 row group 里有 25 万个值，只占 3,049 字节（输出里按 KB 取整，显示成 2 KB）。它只有 4 种取值，字典编码把每个值变成 2 bit 的编号，25 万个值约 62 KB；这些编号按固定顺序循环，Snappy 再把它压到约 3 KB。这里游程编码没起作用，因为相邻的值都不相同。
• 想看游程编码的效果，把 country 这一列排序后再写一次：相同的值连在一起，这一列会小到几十个字节。
• 第 5 步打印的最小值和最大值存在文件尾里。第 6 步的过滤条件是 user_id >= 900000，前三个 row group 的最大值都不到 900000，所以整组被跳过，只读了第四组。
• 自己改一改：把 row_group_size 改成 50000 再跑，看 row group 数和文件大小怎么变；把 country 换成每行都不同的字符串，看那一列变成多大。

速查表

考前十分钟过一遍

CSV / JSON

文本，通用，没有类型，整体压缩后不能切分。

SequenceFile

二进制键值对，sync marker 让它可切分，绑死 Java。

Thrift / Protobuf

不是文件格式。字段编号带来 schema 演进。

Avro

行存，schema 在文件头。写入侧主流：Kafka、Iceberg manifest。

Dremel

repetition level 和 definition level，嵌套数据按列存。

RCFile

Record Columnar：先分行组，组内按列。不认识类型，没有索引。

ORC

stripe 加索引加文件尾，认识类型。Hive 体系。

Parquet

row group、column chunk、page 三层，文件尾存统计。事实标准。

Arrow

内存里的列式布局，零拷贝。和 Parquet 搭配。

Iceberg / Delta / Hudi

表格式：原子提交、历史版本、改表结构。

Lance

没有 row group，随机读快，加列不重写，自带索引。

Nimble / Vortex / F3

宽表、可扩展编码、GPU。都还新。

来源

新格式的部分（Lance、Nimble、Vortex、F3，以及 Parquet 和 Iceberg 的新特性）在 2026 年 10 月核对过，之后可能已经变化。

• Hadoop SequenceFile API 文档（文件头和三种压缩模式）
• RCFile 论文，ICDE 2011
• Dremel made simple with Parquet（Parquet 作者讲嵌套数据）
• An Empirical Evaluation of Columnar Storage Formats，VLDB 2024
• Lance File 2.1 is Now Stable（LanceDB 博客）
• Lance 格式说明（LanceDB 文档）
• Introducing Lance Community Governance（LanceDB 博客）
• LF AI & Data Foundation Hosts Vortex Project（Linux 基金会）
• Nimble（Meta 的 GitHub 仓库）
• Variant Type in Apache Parquet（Parquet 官方博客）
• What's new in Apache Iceberg v3（Google 开源博客）
• Apache Polaris and Lance（Apache Polaris 博客）
• Lance 文件格式规范：编码（mini-block 和 full-zip 的数字出自这里）
• Lance 的论文（arXiv 2504.15247）
• parquet-format 的发布记录（Variant 和地理类型）
• Parquet 配置说明（page 大小）
• Dremel: Interactive Analysis of Web-Scale Datasets（Google，2010）
• Arrow 列式格式规范
• Protocol Buffers 编码说明
• Spark SQL 数据源文档（默认数据源是 Parquet）
• Announcing Vortex Support in DuckDB（DuckDB 博客）
• F3 的 GitHub 仓库
• Iceberg v4 的讨论（二手总结）
• Hadoop SequenceFileRecordReader 源码（怎么处理切分点）
• RFC 1951：DEFLATE 压缩格式
• Introducing Pandas UDF for PySpark（Databricks，2017）
• Apache Avro 规范
• Apache Parquet 文件格式说明
• Apache ORC 规范
• Apache Iceberg 表规范