3、COW与MOR原理对比：写入放大、读放大、数据文件与日志文件结构
3.1 核心存储结构：从文件布局看本质差异
COW（Copy-on-Write）与MOR（Merge-on-Read）最根本的区别，不在于“快或慢”的抽象结论，而在于数据文件与日志文件的物理组织方式。理解这一点，才能解释后续所有读写放大、延迟特征与生产选型问题。
在Hudi中，COW表的所有数据都存放在列式文件（Parquet）中。每次对已有记录的更新，都会将包含该记录的文件整体读出，在内存中合并新数据后，重写为一个新的Parquet文件，旧文件在清理策略执行后被标记删除。因此COW表在任何时刻，每个分区下只有“最新版本”的Base文件，没有独立的增量日志。
MOR表则采用Base文件 + Log文件的双层结构。Base文件同样使用Parquet列式存储，保存已经完成合并的“基线数据”；而新到达的更新或插入，首先追加写入Avro格式的Log文件（基于HFile的日志格式），记录的是行级增量。读取时，需要将Base文件与对应的Log文件进行合并，才能得到完整的最新视图。
3.2 写入放大与读放大的量化对比
写入放大（Write Amplification）指实际写入物理存储的数据量与逻辑写入数据量的比值。读放大（Read Amplification）指读取时实际扫描的数据量与返回有效数据量的比值。两者在COW与MOR中呈现截然不同的特征。
| 对比维度 | COW（Copy-on-Write） | MOR（Merge-on-Read） |
|---|---|---|
| 写入放大系数 | 3~5倍（读旧文件+写新文件+写版本元数据） | ≈1.1倍（仅追加Log，元数据开销小） |
| 读放大系数 | ≈1倍（直接读最新Parquet） | 2~10倍（Base+Log合并，取决于Log数量） |
| 更新延迟 | 高（需完成整个文件重写） | 低（追加即可返回） |
| 查询延迟 | 稳定且低 | 随Log积累逐渐升高 |
| 文件数量 | 少（定期清理旧版本） | 多（Base+多个Log文件） |
| Compaction开销 | 每次写入隐含合并 | 异步Compaction，可调度 |
3.3 数据文件与日志文件的生命周期
理解文件生命周期，是掌握Hudi运维与调优的关键。以MOR表为例，一个FileGroup的生命周期如下：
- 创建Base文件：第一批数据写入时，直接生成Parquet格式的Base文件。
- 追加Log文件：后续更新/删除操作，以Avro格式追加写入对应的Log文件。每个FileGroup可包含多个Log文件，按时间顺序编号。
- Compaction触发：当Log文件数量或大小达到阈值（如
hoodie.compaction.inline.max.delta.commits=5），触发Compaction，将Base与所有Log合并为新的Base文件。 - 清理旧文件：Compaction完成后，旧版本文件被标记删除，由Cleaner异步清理。
-- 查看MOR表文件布局（Hudi CLI或文件系统）
hdfs://namenode:8020/warehouse/orders_mor/
├── partition_date=2025-01-15/
│ ├── .orders_mor_12345.base.parquet # Base文件
│ ├── .orders_mor_12345.log.1_0.avro # 第1个Log文件
│ ├── .orders_mor_12345.log.2_0.avro # 第2个Log文件
│ └── .orders_mor_67890.base.parquet # 另一个FileGroup
└── partition_date=2025-01-16/
└── .orders_mor_11111.base.parquetCOW表的文件生命周期则简单得多：每次写入直接生成新版本Parquet文件，旧文件在hoodie.cleaner.commits.retained=10（默认保留最近10次提交）后被清理。没有独立的Log文件，也没有Compaction概念。
3.4 案例复盘：为什么我的MOR表查询越来越慢？
某互联网公司使用MOR表存储用户行为日志，每天写入约2亿条更新。上线初期查询P95延迟约200ms，运行两周后P95飙升至1.2秒。排查发现：
- 根因：Compaction调度配置不当，
hoodie.compaction.inline.enable=false且未配置异步Compaction，导致Log文件无限累积。 - 现象：单个FileGroup下堆积了超过30个Log文件，读取时需逐一合并，读放大系数高达15倍。
- 解决：开启异步Compaction并设置
hoodie.compaction.trigger.strategy=num_commits，阈值设为5；同时将hoodie.parquet.small.file.limit调至128MB，减少小文件数量。
另一个典型误区是“COW一定比MOR慢”。实际上，在批量导入场景（如每天一次全量刷新）中，COW的写放大影响有限，而查询性能优势明显。反之，在秒级延迟的实时更新场景中，MOR几乎是唯一选择。选型应基于写入频率、查询延迟要求、数据新鲜度三个核心参数综合判断。
最后需要强调的是，Hudi 0.14+版本引入了Clustering与Compaction策略优化，使得MOR的读放大问题得到一定缓解。但底层原理不变：COW以写放大换读性能，MOR以读放大换写性能。理解这一本质，才能在架构设计时做出理性决策，而不是盲目追随社区热点。