3.概说hudi
通过比较理解hudi的特点
hudi的更新是记录级别的。hive是表或分区级别的，但凡有一条数据要更新，就需要重写整个表分区甚至整张表，而hudi是细化到单条记录的，为这些操作提供了数量级的优化。
hbase是有排序的功能，这本身也可以理解为一种索引功能。hudi也有索引的数据结构，所以在应用的场景上来说，都可以用作实时数据处理。但是hudi可以利于hive的metastore，做到基于sql的实时处理。我们之前的做法是把批的sql逻辑拆解为java逻辑，利用hbase的实时更新的特性，做到数据的实时处理，而这些无疑大大增加的业务开发的难度。
hudi定位准实时处理，一方面我们需要用来实时查询一张表的最新数据，例如快照表的查询，另一方面，hudi也可以针对一段时间的增量数据进行处理，仅仅处理增量的更改，然后upsert或delete接下来的表。
通过架构定位hudi
正式来讲，hudi充分利用了开源的列格式(Parquet)和行格式(Avro)的文件来存储数据，并在写入数据的同时生成特定的索引，进而提供更快的查询性能。这里的存储和索引，下面都会有介绍，这也是hudi的重点部分。
hdfs存储层由于上面的hudi存在，从而具备了实时存储的功能，不需要像以前那样，为了处理实时数据需要引入额外的存储组件，做到了流批在存储层面的一体化。
表设计
Index
索引机制会讲RecodeKey+PartitionPath组合的形式作为唯一的标示映射到一个文件ID，而且这个唯一标示和文件/文件组之间的映射自写入文件组后就不会再改变。
hudi的索引有4种类型6个实现类，均继承自抽象类HoodieIndex
⚠️注意
全局索引：会强制在所有分区的范围内保证键的唯一性，这样会使得更新和删除的操作随着表越来越大而消耗也越来越多，所以适合于在小表设置
非全局索引：仅在表的某一分区内保证键的唯一性，可以很好适应写入量的扩展。
DataFile
时间轴
表类型
COW表
更新：hudi在更新数据的时候，会找到包含最新数据的文件，然后再使用最新值来重写该文件，含有其他记录的文件保持不变，当有突然大量的写入的时候会有大量的重写操作，从而有很大的IO开销。
读取：通过读取含有最新数据的文件，此存储方式舍写少读多的场景。
MOR表
更新：在更新记录时，仅更新到avro文件中，然后进行异步（或同步）的compaction，最后创建列式文件parquet的新版本。此存储方式适合大量的写入操作。
读取：在读取的时候需要将增量文件和旧文件进行合并，然后生成列式文件后再进行查询。一般会消耗几分钟的时间。
修改于 2025-03-20 05:45:24