简介
随着数据湖技术越来越流行，大家对数据湖技术框架之间分析对比的关注度越来越高。本文通过对比Apache Hudi、Delta Lake、Apache Iceberg技术框架，深入介绍Apache Hudi作为一个成熟数据湖平台方案的技术优势。
读/写特性对比
表服务特性对比
平台工具对比
生态支持对比
社区数据
对于开源项目来说，社区活跃程度和支持力度同样重要。社区决定项目的发展势头和周边生态支持的完整度。
以下是Hudi、Delta和Iceberg在社区方面的比较：
Github stars数量一定程度上代表着项目受欢迎程度。从这个角度出发，如图中可以看出Delta Lake的知名度和受欢迎程度遥遥领先。
Github Watchers和Forks数量，如图可以看出基本持平：
Github Contributors数(2022.12)，如图可以看出Hudi贡献者数据量是Iceberg的2倍、Delta Lake的三倍：
TPC-DS性能基准
虽然基本测试不能代表现实场景的工作负载情况，最起码是个参考指标。Hudi商业化公司OneHouse性能基准测试结果如下： 
上图可以看出，性能方面来说，Delta和Hudi还具有可比性。而Iceberg性能远远落后于Delta和Hudi。虽然性能指标不是现实场景中技术选型的唯一标准，但确实是最重要的标准之一。
注意：TPC-DS性能基准测试使用开箱即用的默认配置是不合理的。Delta和Iceberg默认对append-only(追加写insert)进行优化，而Hudi默认对upsert(更新)进行优化。Upsert性能开销自然比insert要高。所以，TPC-DS性能基准测试需要将Write Operations默认upsert改为insert。
Hudi特性亮点
构建数据湖平台的技术框架选型不能简单地对比功能列表，而是需要详细对比相同功能的实际区别。
Incremental Pipelines
目前，数据开发工程师可能觉得ETL只能选择一种方式：流或者批。Hudi开创一种称为Incremental Pipelines的新范式。Hudi可以开箱即用地捕获所有变更(appends、updates、deletes)数据作为change streams。基于record级别的索引，用户可以更加有效地增量处理所有变更数据。Databricks开发了类似功能(称为Change Data Feed)计划在Delta Lake 2.0开源(目前社区不可用)。而Iceberg所谓的增量读取仅允许读取增量append，不允许支持读取updates和deletes。
Concurrency Control
ACID事务和并发控制是数据湖的关键特征。Hudi、Delta、Iceberg都支持乐观并发控制(OCC，Optimistic Concurrency Control)。在OCC中，writers需要检查是否存在重复文件，如果存在，则会失败并触发重试。以Delta Lake为例，OCC只是一个保存在Spark Driver进程的 JVM级别的锁，这意味着多个Spark集群之间并不支持OCC。
通常，让writers离线进行表管理来确保表数据可用性和性能是不现实的。Hudi并发控制比其他数据湖框架(文件级别)更细粒度，并且针对多个小数据量级updates和deletes进行优化。所以，在大多数的现实场景中，并发写冲突的可能性大大降低(基本可以忽略不计)。
Merge On Read
所有数据库系统都支持在写性能与读性能之间进行权衡抉择。Hudi社区为整个数据湖行业的概念定义方面做出了开创性贡献。Hudi、Delta、IceBerg都将数据写入存储到parquet文件。发生Updates时，parquet文件进行版本控制和重写，也就是业界所说的写时复制(COW)。
COW可以提供很好的查询性能，但是会限制写入性能和数据时效性。除了COW表，Hudi还支持MOR表。MOR表的数据存储将parquet文件和基于行级的avro文件相结合。Updates数据批量写入到avro文件，稍后以同步或者异步方式合并到parquet文件中。这样，可以平衡最大的查询性能和最低的写入放大开销。
因此，对于近实时的流场景，Hudi可以使用更加高效的行级avro格式；而对于批处理hcangjing，Hudi可以使用向量化的列式parquet格式；两种格式需要合并时可以无缝进行。
总结
在进行数据湖的技术框架选型时，技术框架的功能特性列表和性能基准测试结果不应该是最终决定因素。结合实际场景现网业务进行评估才是最重要的。
