写时复制（COW）原理：写入流程、文件版本管理、数据文件与日志文件

核心原理：不可变文件与版本切换

写时复制（Copy on Write，COW）是 Hudi 最基础的表存储模式，其核心思想是“数据文件一旦写入即不可修改”。每次对已有数据的更新操作，都不会直接修改磁盘上的旧数据文件，而是生成一个包含最新数据的新文件版本，并更新表的元数据指针，使其指向新文件。旧文件在完成查询服务后，由异步压缩或清理机制回收。

这种设计带来了三个关键收益：

  • 快照隔离：读取操作始终基于某个时间点的文件版本集合，不会看到写入一半的数据。
  • 故障恢复简单：写入过程若中途失败，只需丢弃未提交的新文件，旧文件不受影响。
  • 并发控制友好：写入与读取互不阻塞，多个写入任务可通过乐观锁机制协调。

COW 表在文件布局上只存在基础文件（Base File），没有独立的日志文件。每次提交（Commit）都会将变更合并进新的列式存储文件（如 Parquet），因此 COW 表的文件版本管理本质上就是“同一 FileGroup 下不断追加新 FileSlice”的过程。

关键术语速记：FileGroup 是分区内同一主键范围的数据文件集合；FileSlice 是 FileGroup 内某个提交版本对应的具体文件；COW 表每个 FileSlice 只包含一个基础文件，不存在日志文件。

写入流程：从记录到文件版本

一次典型的 COW 写入（以 Spark 批量写入为例）包含以下阶段：

  1. 记录定位：根据主键（Record Key）计算每条记录所属的 FileGroup。Hudi 通过索引（如布隆过滤器或 HBase 索引）快速定位记录所在的文件 ID。
  2. 读取旧版本：对于需要更新的 FileGroup，读取其最新 FileSlice 中的基础文件，将旧记录加载到内存。
  3. 合并新旧数据：将本次写入的新记录与旧记录按主键合并，相同主键以新记录覆盖旧记录，并保留必要的预合并字段（Pre-combine Field）用于冲突解决。
  4. 写入新文件：将合并后的完整数据集写入一个新的 Parquet 文件，该文件属于同一 FileGroup，但拥有新的 FileSlice 版本。
  5. 提交元数据：将新文件路径、提交时间、涉及的 FileGroup 列表写入 Hudi 元数据（如 .hoodie 目录下的 commit 文件），并更新索引。
  6. 清理旧文件：根据保留策略（默认保留最近 10 个提交版本），异步删除不再被查询引用的旧基础文件。
// 伪代码示意：COW 写入核心逻辑
for each record in input_batch:
    file_group_id = index.lookup(record.record_key)
    if file_group_id is None:
        // 新记录，分配新 FileGroup
        file_group_id = create_new_file_group(partition_path)
    old_file = get_latest_file_slice(file_group_id).base_file
    merged_data = merge(old_file.records, record)  // 按主键合并
    new_file = write_parquet(merged_data, file_group_id, commit_time)
    update_metadata(file_group_id, new_file, commit_time)

整个写入过程是“读-合并-写”的循环，因此 COW 表的写入放大系数较高——即使只更新 1 条记录，也需要重写整个 Parquet 文件。这也是 COW 表适合读多写少场景的根本原因。

文件版本管理：FileGroup 与 FileSlice 的演进

Hudi 将文件版本管理抽象为三层结构，COW 表尤其依赖这种层级关系来保证数据一致性：

层级名称说明COW 表特点
分区Partition按分区路径隔离数据分区内独立管理文件
文件组FileGroup同一主键范围的数据集合文件 ID 唯一，跨提交稳定
文件切片FileSlice某次提交产生的文件版本每个 FileSlice 仅含 1 个基础文件

以下示意图展示了 COW 表同一 FileGroup 在三次提交中的版本演进：

COW 表 FileGroup 版本演进（三次提交） 时间 Commit 001 初始写入 1000 条记录 FileSlice-001 file_001.parquet (1000条) Commit 002 更新 200 条记录 FileSlice-002 file_002.parquet (1000条) file_001.parquet（待清理） Commit 003 追加 300 条 + 更新 100 条 FileSlice-003 file_003.parquet (1300条) file_002.parquet（待清理） 当前最新版本 元数据管理（.hoodie 目录） • commit 文件记录每次提交的 FileGroup → FileSlice 映射关系 • 查询时根据 commit 时间戳选择可见的 FileSlice 集合 • 清理服务（Cleaner）根据保留策略删除旧版本文件

从图中可以看出，每次提交都会产生一个新的 FileSlice，并指向新写入的 Parquet 文件。查询时，Hudi 根据快照时间选择对应的 FileSlice，从而保证读取一致性。旧文件不会立即删除，而是等待清理服务在后台异步处理，避免影响正在进行的查询。

数据文件与日志文件：COW 为何没有日志

与读时合并（MOR）表不同，COW 表不维护任何日志文件（Log File）。所有更新都直接写入新的基础文件，因此 COW 表的数据文件只有一种形态：列式存储的 Parquet 文件。

这种设计带来的直接结果是：

  • 查询性能最优：读取时只需扫描单个 Parquet 文件，无需合并日志，适合对查询延迟敏感的分析场景。
  • 写入成本较高：每次更新都要重写整个文件，写入放大系数通常在 5~10 倍之间（取决于文件大小和更新比例）。
  • 文件数量可控：由于没有日志文件，文件数量与提交次数成正比，但清理机制会控制总文件数。

实践建议：如果业务场景以数据追加为主（如日志采集、事件流），且更新频率较低，COW 表是理想选择。若更新频繁且更新比例高，建议评估 MOR 表以降低写入放大。

案例：订单状态更新流程

假设有一个订单表，分区字段为日期，主键为 order_id。某次业务操作需要将一批订单的状态从“待支付”更新为“已支付”：

  1. Hudi 通过索引定位到这些订单所在的 FileGroup（假设分布在 3 个 FileGroup 中）。
  2. 系统读取这 3 个 FileGroup 的最新 FileSlice，加载全部订单记录（包括未更新的订单）。
  3. 在内存中完成状态字段的更新，并将每个 FileGroup 的完整数据写入新的 Parquet 文件。
  4. 提交元数据，记录新文件版本。此时旧文件仍然存在，但元数据已指向新文件。
  5. 查询端立即能看到更新后的数据；旧文件在清理策略触发后被删除。
# 使用 Spark 执行 COW 更新
spark.sql("""
  MERGE INTO orders_cow t
  USING updated_orders s
  ON t.order_id = s.order_id
  WHEN MATCHED THEN UPDATE SET t.status = s.status
  WHEN NOT MATCHED THEN INSERT *
""")

执行上述操作后，Hudi 会自动完成文件版本切换，无需人工干预。

误区与复盘：COW 使用中的常见问题

误区一：认为 COW 表适合频繁小批量更新

这是最常见的误解。COW 表每次更新都会重写整个 Parquet 文件，如果每批次只更新少量记录，会产生严重的写放大。例如，一个 1GB 的文件每次只更新 1 条记录，实际写入量仍为 1GB。正确做法是：将更新操作合并为较大的批次，或改用 MOR 表。

误区二：忽略文件大小对性能的影响

COW 表的文件大小直接影响更新成本。文件越大，单次更新重写的数据越多。建议通过 hoodie.parquet.small.file.limit 参数控制小文件合并，将文件大小维持在合理范围（如 128MB~512MB）。

复盘总结：COW 表的核心优势在于查询性能和简单性，代价是写入放大。在实际应用中，应根据更新频率、查询延迟要求和数据规模综合选型。对于更新比例低于 10% 的场景，COW 表通常表现良好；超过该阈值时，建议对比测试 MOR 表。

理解 COW 表的写入流程和文件版本管理机制，是掌握 Hudi 数据湖表格式的基础。它揭示了“以空间换时间”的存储设计哲学——通过保留多个文件版本换取查询的稳定性和并发控制的安全性。在实际生产环境中，合理配置清理策略和文件大小参数，能够有效平衡存储成本与查询性能。

← 上一章 📖 返回目录 下一章 →