大数据hudi之核心概念：数据写

写操作

1.upsert:默认行为，数据先通过index 打标（insert/update）,有一些启发式算法决定消息的组织以优化文件的大小 ==>cdc导入
2.insert：跳过index ,写入效率更高 ==>Log Deduplication
3.bulk_insert:写排序，对大数据量的hudi表初始化友好，对文件大小限制 best effort(写HFile)

写流程（upsert）

1)Copy On Write
1.先对records 按照record key去重
2.首先对这批数据创建索引（HoodieKey =>HoodieRecordLocation）,通过索引区分哪些records是update ,哪些records是insert(key 第一次写入)
3.对于update消息，会直接找到对应key所在的最新FileSlice的base文件，并做merge后写新的base file（新的FileSlice）
4.对于insert消息，会扫描当前partition的所有SmallFile（小于一定大小的base file），然后merge写新的FileSlice;如果没有SmallFile，直接写新的FileGroup +FileSlice

2）Merge On Read
1.先对records按照record key去重（可选）
2.首先对这批数据创建索引（HoodieKey =>HoodieRecordLocation）,通过索引区分哪些records是update ,哪些records是insert(key 第一次写入)
3.如果是insert消息，如果logfile不可建索引（默认），会尝试merge分区内最小的base file （不包含logfile 的FileSlice）,生成一个新的FileSlice;如果没有base file就新写一个
FileGroup +FileSlice +base file；如果logfile可建索引，尝试appen小的log file ，如果没有就新写一个 FileGroup +FileSlice +base file；
4.如果是update消息，写对应的filegroup +fileslice,直接append最新的logfile(如果碰巧是当前最小的小文件，会merge base file，生成新的file slice)
5.log file 大小达到阈值会roll over 一个新的；

写流程（insert）

1）Copy On writer
1.先对records 按照record key去重（可选）
2.不会创建index
3.如果有小的base file 文件，merge base file ,生成新的FileSlice +base file , 否则直接写新的FileSlice +base file

2)Merge On Read
1.先对records按照record key 去重（可选）
2.不会创建index
3.如果log file 可索引，并且有小的FileSlice,尝试追加或写新的logfile;如果logfile 不可索引，写一个新的FileSlice + base file；

写流程（insert overwrite）

在同一分区中创建新的文件组集。现有的文件组被标记为"删除"。根据新记录的数量创建新的文件组；


3）优点
1.COW和MOR执行方面非常相似。不干扰MOR的compaction
2.减少parquet文件大小；
3.不需要更新关键路径中的外部索引。索引实现可以检查文件组是否无效（类似于在
HbaseIndex中检查commit是否无效的方式）
4.可以扩展清理策略，在一定的时间窗口后删除旧的文件组；
4）缺点
1.需要转发以前提交的元数据
在t1,比如file1被标记为无效，我们在t1.commit中存储"invalid Files =file1"(或者在MOR中存储deltacommit)
在t2,比如file2也被标记为无效。我们转发之前的文件，并在t2.commit中标记"invalidFiles = file1,file2"( 或MOR的deltacommit)
2.忽略磁盘中存在的parquet文件也是Hudi的一个新行为，可能容易出错，我们必须认识到新的行为，并更新文件系统的所有视图来忽视它们。这一点可能会在实现其他功能时造成问题；

Key生成策略

用来生成HoodieKey(record key + partition path ),目前支持一下策略
1.支持多字段组合record keys
2.支持多个字段组合的 partition path (可定制时间格式，Hive stytle path name)
3.非分区表

删除策略

1）逻辑删：将value 字段全部标记为null
2）物理删：
1.通过 operation_opt_key 删除所有的输入记录
2.配置 payload_class_opt_key = org.apache.hudi.EmptyHoodieRecordPayload 删除所有的输入记录
3.在输入记录添加字段：_hoodie_is_deleted;

总结

通过对写流程的梳理可以了解到apache hudi相对于其他数据湖方案的核心优势；
1.写入过程充分优化了文件存储的小文件问题，Copy On Write写会一直将bucket(FileGroup)的base 文件写到设定的阈值大小才会划分新的bucket;Merge On Read写在同一个bucket中，log file 也是一直append 直到大小超过设定的阈值roll over；
2.对update和delete的支持非常高效，一条record的整个生命周期操作都发生在同一个bucket,不仅减少小文件数量，也提升了数据读取的效率（不必要的join和merge)；