|
#Hudi学习笔记
1.Copy On Write&Merge On Read解析
一、Copy On Write&Merge On Read
Hudi 核心概念之表类型
Hudi有两种表类型Copy On Write（写复制）和Merge On Read（合并读）。这两种表类型决定数据在DFS(data files system)如何写入、存储，索引和查询，所以正确理解这两种表类型，对理解hudi起到至关重要的作用，下面来一起解析他们。
一、Copy On Write？
先上图
Copy-On-Write文件使用列式存储（如parquet）。数据在写入期间执行同步合并原有数据来更新并重写文件，数据每次提交都会进行隐式压缩，并附带时间戳，。
从这个图中，10：10提交了一份最新数据（粉色），那么在这个提交之前（比如10:07），进行数据查询的时候，只能查到10:05分（绿色）的数据，而正在进行的update/insert的数据相当于吧10：05的数据copy一份，进行合并和更新，等到10;10commit之后，查询就是最新的粉色数据。Copy On Write换个Write On Copy获取更好理解。
二、Merge On Read
Merge On Read可以看到和Copy-On-Write明显区别。10:05之后新增的数据用基于行式存储（如avro）,历史数据还采用列式存储。增量数据放到append log里，并没有和历史数据进行合并，只有在compact（压缩）操作之后，才会与历史文件的合并和更新。那么10：10在查询数据的时候，实际上是历史数据（10：05）+增量数据（06，07，08，09，10）的合并，所以叫Merge On Read，实际就是Read On Merge
三、二种表的特点
Copy On Write：
1 run on committed data：查询数据时候会查询最新commit的数据，而不是最新的文件切片；比如10：07查询上了select count（*），只会有10:05（做了一次commit）的数据，而不会受到后一阶段数据是否成功、失败的影响。
2.数据文件级更新：一个逻辑分区下会存在大量的文件。Copy On Write可以自动更新文件的数据，而不用去更新整个表或者分区。
3.严格控制文件大小以保持出色的查询性能（小文件严重损害查询性能）
4.可以感知增量变化，而不用浪费资源做扫描或者试探。
Merge On Read：
1.提供近乎实时的数据：10:05之后，每一分钟的增量数据，都可以被计算在内而不用等10:10的commit操作
2.历史版本数据和增量日志区分开。
3.可以自主的对历史数据和增量日志进行周期性的compact(压缩)
4.可以进行根据实际需要（是想查的快还是想查的最新的数据）来觉得使用优化查询（ Read Optimized query） 或快照查询（Snapshot query）。
四、两类表对比
1.数据延迟：Copy On Write高，Merge On Read低。从上面例子可以看到Copy On Write有五分钟的延迟，而Merge On Read可以做到一分钟.
2.查询延迟：Copy On Write低，Merge On Read高。Copy On Write查的是一份copy,而Merge On Read是一份Merge数据
3. 更新成本(I/O):Copy On Write高,需要重写整个parquet文件，Merge On Read低，只需要增加到增量日志中。
4. parquet文件大小:Copy On Write小，Merge On Read大
5. 写放大：Copy On Write高，Merge On Read低（依赖压缩策略）
|
