【Hudi】Copy-on-Write(COW)和Merge-on-Read(MOR)

https://cloud.tencent.com/developer/article/1827930

https://www.sev7e0.site/%E7%94%B1hudi%E4%BA%86%E8%A7%A3-copy-on-write-cow-%E5%92%8C-merge-on-read-mor

数据湖—hudi核心概念

COW

“写入时复制”表中的文件切片仅包含基本/列文件，每次提交都会生成新版本的基本文件。换句话说，我们在每次提交时都隐式压缩，这样只存在列数据。因此，写入放大率（为1字节的输入数据写入的字节数）高得多，其中读取放大率为零。这是分析工作负载非常需要的属性，因为分析工作负载主要是重读取的。

下面从概念上说明了当数据写入到写时拷贝表中并在其上运行两个查询时，这是如何工作的。

当数据被写入时，对现有文件组的更新会为该文件组生成一个新的切片，该切片标记有提交instant time，而插入会分配一个新文件组并为该文件群写入其第一个切片。这些文件切片及其提交时间在上面用颜色编码。针对这样一个表运行的SQL查询（例如：select count（*）统计该分区中的总记录），首先检查最新提交的时间线，并过滤每个文件组中除最新文件片段之外的所有文件片段。正如您所看到的，一个旧的查询不会看到当前飞行中提交的文件以粉色编码，而是在提交后开始的一个新的查询会拾取新的数据。因此，查询不受任何写入失败/部分写入的影响，仅在提交的数据上运行。

COW表的目的，是通过一下几个方面功能上提高表的组织能力：

• 文件级自动更新数据，而不是重写整个表/分区
• 能够增量更改，而不是浪费扫描或试探摸索
• 严格控制文件大小以保持出色的查询性能（小文件会严重影响查询性能）。

Merge on Read(MOR)

读时合并表是写时复制的超集，从某种意义上说，通过只在最新的文件切片中显示基/列文件来支持表的读优化查询。此外，它将每个文件组的传入的 upserts 存储到基于行的增量日志中，以便通过在查询期间将增量日志应用到每个文件id的最新版本来支持快照查询。因此，这种表类型试图智能地平衡读和写放大，以提供接近实时的数据。这里最重要的变化将是压缩程序，它现在仔细选择需要将哪些增量日志文件压缩到其列状基础文件上，以保持查询性能的检查（较大的增量日志文件将导致较长的合并时间，而合并数据位于查询端）

我们现在每1分钟左右就会提交一次，这是其他表类型无法做到的。

在每个文件id组中，现在有一个增量日志文件，它保存对基本列文件中记录的传入更新。在示例中，增量日志文件保存10:05到10:10之间的所有数据。与之前一样，基本列式文件仍然使用提交进行版本控制。因此，如果只查看基本文件，那么表布局看起来就像一个写时复制表。

定期压缩过程从增量日志中协调这些更改，并生成新版本的基础文件，就像示例中10:05发生的情况一样。

查询同一基础表有两种方法：读取优化查询和快照查询，这取决于我们选择的是查询性能还是数据的新鲜度。

当来自提交的数据可用于查询时，对于读优化查询，语义会以微妙的方式发生变化。注意，这样一个在10:10运行的查询在10:05之后不会看到数据，而快照查询总是看到最新的数据。

当我们触发压缩时，它决定压缩什么，这是解决这些难题的关键。通过实施压缩策略（与旧分区相比，我们积极压缩最新分区），我们可以确保读取优化的查询在X分钟内以一致的方式查看发布的数据。

合并读表的目的是直接在DFS上实现近乎实时的处理，而不是将数据复制到可能无法处理数据量的专用系统。该表还有一些次要的好处，例如通过避免数据的同步合并来减少写入放大，即一批中每1字节数据写入的数据量

对比

Table Types
Hudi支持以下表类型。
Copy on write：使用列式文件格式（例如 parquet）存储数据。通过在写入期间执行同步合并，更新简单地对文件进行版本和重写。
Merge on read：使用列式（例如 parquet）+基于行的（例如avro）文件格式的组合存储数据。更新被记录到增量文件中，然后被压缩以同步或异步地生成新版本的列式文件。

Hudi COW 两个用户同时写一张表会出现的问题

https://blog.csdn.net/hjl18309163914/article/details/113522379?spm=1001.2101.3001.6650.4&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-4-113522379-blog-129016744.235%5Ev43%5Epc_blog_bottom_relevance_base2&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-4-113522379-blog-129016744.235%5Ev43%5Epc_blog_bottom_relevance_base2&utm_relevant_index=9