Kudu、Hudi和Delta Lake的比较

kudu、hudi和delta lake是目前比较热门的支持行级别数据增删改查的存储方案，本文对三者之间进行了比较。

存储机制

kudu
最新的数据保存在内存，称为MemRowSet（行式存储，基于primary key有序），
当MemRowSet写满（默认1G或者120s）后flush到磁盘，形成DiskRowSet（列式存储）。
tablet定期对DiskRowSet执行compaction操作，进行重排序，
清除DeltMemStore中的update和delete的数据，并减少DiskRowSet的数量。

hudi
hudi维护了一个时间轴，记录了在不同时刻对数据集进行的所有操作。
hudi拥有2种存储优化。
读优化（Copy On Write）：在每次commit后都将最新的数据compaction成列式存储（parquet）；
写优化（Merge On Read）：对增量数据使用行式存储（avro），后台定期将它compaction成列式存储。

delta lake
delta lake的数据不会保存在内存中，而是直接写到新的数据文件中，同时在commit log中添加AddFile这种FileAction，快照新建/更新时读取事务日志，会加载新的数据文件信息。

读数据

kudu
client向master发出请求，master校验表、schema和主键是否存在，并通过查询catalog Table，将tablet对应的tserver地址、tserver状态等元数据信息返回，client与tserver建立连接，通过metaData找到primary key对应的RowSet，返回数据；

hudi
hudi维护着一个索引，以支持在记录key存在情况下，将新记录的key快速映射到对应的fileId。索引的实现是插件式的，默认是bloomFilter，也可以使用HBase。
hudi提供3种查询视图。
读优化视图：仅提供compaction后的列式存储的数据；
增量视图：仅提供一次compaction/commit前的增量数据；
实时视图：包括读优化的列式存储数据和写优化的行式存储数据。

delta lake
通过读取事务日志的checkpoint文件（parquet格式）和之后版本的commit文件（json格式），建立当前最新的快照，该快照包含了当前版本所有数据文件的地址。
delta lake是基于spark实现的，拥有spark同样的读取优化。

更新数据

kudu
client向master请求预写表的元数据信息，然后根据元数据连接tablet对应的tserver，若数据在内存（MemRowSet）中，则将信息写入所在行的mutation链表中，若在磁盘（DiskRowSet）上，则将更新信息写入DeltMemStore中；

hudi
hudi写数据的时候需要指定PRECOMBINE_FIELD_OPT_KEY、RECORDKEY_FIELD_OPT_KEY和PARTITIONPATH_FIELD_OPT_KEY。
RECORDKEY_FIELD_OPT_KEY：每条记录的唯一id，支持多个字段；
PRECOMBINE_FIELD_OPT_KEY：在数据合并的时候使用到，当 RECORDKEY_FIELD_OPT_KEY 相同时，默认取 PRECOMBINE_FIELD_OPT_KEY 属性配置的字段最大值所对应的行；
PARTITIONPATH_FIELD_OPT_KEY：用于存放数据的分区字段。
hudi更新数据和插入数据很相似（写法几乎一样），更新数据时，会根据 RECORDKEY_FIELD_OPT_KEY、PRECOMBINE_FIELD_OPT_KEY 以及 PARTITIONPATH_FIELD_OPT_KEY三个字段对数据进行Merge。

delta lake
delta lake更新数据时会先定位待更新数据所在的文件，然后将更新后的数据和文件中其他不需要更新的数据一起写入到新的文件里，同时在commit log中记录AddFile（新文件）和RemoveFile（旧文件）两种action。

其他

--	Kudu	Hudi	Delta Lake
使用索引	是	是	否
元数据位置	master	根目录文件夹	根目录文件夹
版本回滚	不支持	hudi有时间轴，支持版本回滚	delta lake有事务日志系统，支持版本回滚
实时性	kudu使用内存存储新增数据，实时性高	hudi有写优化存储方式，实时性高	delta lake必须完成commit提交才能查询到新增数据，实时性相对较低
支持hadoop文件系统	不支持，kudu通过raft管理自己的存储服务器	支持	支持