课程导入：学习目标、课程结构、Hudi在数据湖生态中的定位

1.1 为什么需要一门专门讨论 MOR 与 COW 的课程

Apache Hudi 作为数据湖三大核心组件（Hudi、Iceberg、Delta Lake）之一，已经在众多企业的实时数仓与湖仓一体架构中承担关键角色。然而，许多团队在引入 Hudi 后，面对的第一道选择题就是：同一张业务表，到底应该建为 Copy-on-Write（COW）还是 Merge-on-Read（MOR）？这个选择并非简单的“写入快选 MOR、查询快选 COW”就能概括，它牵涉到文件大小、更新频率、查询延迟、Compaction 策略、下游消费方式、云存储成本等多个维度的权衡。

在生产环境中，选错表类型往往带来两类典型后果：一类是 COW 表在频繁小批量更新场景下产生大量小文件，导致 NameNode 或对象存储请求数激增，查询计划变慢；另一类是 MOR 表未配置合理的 Compaction 调度，造成 base 文件与 log 文件堆积，读取时合并开销失控，查询 P99 延迟飙升。这些问题的根源并非 Hudi 本身缺陷，而是缺乏对表类型内部机制与生产负载特征的匹配分析。

本课程不打算停留在“COW 适合读多写少、MOR 适合写多读少”的粗浅结论上，而是从文件布局、索引机制、Compaction 策略、实际调优参数、故障排查等角度，结合真实生产案例，帮助你建立一套可复用的选型决策框架。

1.2 学习目标：学完本课程你将能够

• 原理层面：准确描述 COW 与 MOR 在数据写入、文件版本切换、读取合并、索引去重方面的核心差异，并能画出两者的文件组织时序图。
• 决策层面：根据业务表的更新频率、查询模式（点查/全表扫描/增量消费）、数据新鲜度要求、下游计算引擎（Spark/Flink/Presto）等输入条件，给出明确的表类型选型建议。
• 调优层面：针对 MOR 表设置合理的 compaction.async.enabled、compaction.delta_commits、hoodie.parquet.small.file.limit 等参数，避免小文件与合并风暴。
• 排障层面：当出现 MOR 表查询越来越慢、COW 表写入延迟抖动、文件版本冲突等问题时，能够通过 Timeline、FileSystem View 和 Metrics 快速定位根因。
• 架构层面：理解 Hudi 在数据湖生态中与 Spark、Flink、Hive Metastore、Presto/Trino 的集成位置，以及 MOR/COW 选择如何影响下游数据服务。

1.3 课程结构：从原理到实战的六阶段路径

本课程共 30 个章节，分为六个阶段，每个阶段解决一组关键问题。下面用一张结构图展示课程的整体逻辑，这张图也是后续所有案例讨论的“地图”。

从上图可以看到，本课程不是零散的知识点罗列，而是围绕“选型决策”这一核心任务，逐步构建从原理到实战的完整能力闭环。每一章都会提供可操作的参数配置、代码示例或排查步骤，而不是空泛的理论描述。

1.4 Hudi 在数据湖生态中的定位

在深入 MOR 与 COW 之前，有必要先明确 Hudi 在整个数据湖技术栈中的位置。下图展示了 Hudi 与周边组件的典型集成关系：

Hudi 的核心价值在于它在文件系统之上增加了一层“表服务”抽象，包括 Timeline（记录所有操作历史）、索引（加速 upsert 定位）、Compaction（合并 base 与 log）、Clustering（优化文件布局）等。这些服务使得数据湖上的数据不再是“一堆静态文件”，而是具备数据库般的事务性、更新能力和增量消费能力。

理解这一层抽象对 MOR/COW 选型至关重要：COW 表在写入时即完成文件重写，因此文件布局始终是“干净”的 Parquet 文件；而 MOR 表则利用 Timeline 上的 delta commit 记录增量更新，将合并动作推迟到读取或 Compaction 时。这意味着，Hudi 的“表服务”设计直接决定了两种表类型在写入路径、读取路径和运维复杂度上的根本差异。

1.5 常见误区与学习建议