数据湖方案：Hudi、Delta、Iceberg深度对比

目前市面上流行的三大开源数据湖方案分别为：delta、Apache Iceberg和Apache Hudi。

 

其中，由于Apache Spark在商业化上取得巨大成功，所以由其背后商业公司Databricks推出的delta也显得格外亮眼。

 

Apache Hudi是由Uber的工程师为满足其内部数据分析的需求而设计的数据湖项目，它提供的fast upsert/delete以及compaction等功能可以说是精准命中广大人民群众的痛点，加上项目各成员积极地社区建设，包括技术细节分享、国内社区推广等等，也在逐步地吸引潜在用户的目光。

 

Apache Iceberg目前看则会显得相对平庸一些，简单说社区关注度暂时比不上delta，功能也不如Hudi丰富，但却是一个野心勃勃的项目，因为它具有高度抽象和非常优雅的设计，为成为一个通用的数据湖方案奠定了良好基础。

 

很多用户会想，看着三大项目异彩纷呈，到底应该在什么样的场景下，选择合适数据湖方案呢？今天我们就来解构数据湖的核心需求，深度对比三大产品，帮助用户更好地针对自身场景来做数据湖方案选型。

 

首先，我们来逐一分析为何各技术公司要推出他们的开源数据湖解决方案，他们碰到的问题是什么，提出的方案又是如何解决问题的。我们希望客观地分析业务场景，来理性判断到底哪些功能才是客户的痛点和刚需。

 

Databricks和Delta

 

以Databricks推出的delta为例，它要解决的核心问题基本上集中在下图 ：

 

 

图片来源：https://www.slideshare.net/databricks/making-apache-spark-better-with-delta-lake

 

在没有delta数据湖之前，Databricks的客户一般会采用经典的lambda架构来构建他们的流批处理场景。

 

以用户点击行为分析为例，点击事件经Kafka被下游的Spark Streaming作业消费，分析处理（业务层面聚合等）后得到一个实时的分析结果，这个实时结果只是当前时间所看到的一个状态，无法反应时间轴上的所有点击事件。

 

所以为了保存全量点击行为，Kafka还会被另外一个Spark Batch作业分析处理，导入到文件系统上（一般就是parquet格式写HDFS或者S3，可以认为这个文件系统是一个简配版的数据湖），供下游的Batch作业做全量的数据分析以及AI处理等。

 

这套方案其实存在很多问题  : 

 

第一、批量导入到文件系统的数据一般都缺乏全局的严格schema规范，下游的Spark作业做分析时碰到格式混乱的数据会很麻烦，每一个分析作业都要过滤处理错乱缺失的数据，成本较大。

 

第二、数据写入文件系统这个过程没有ACID保证，用户可能读到导入中间状态的数据。所以上层的批处理作业为了躲开这个坑，只能调度避开数据导入时间段，可以想象这对业务方是多么不友好；同时也无法保证多次导入的快照版本，例如业务方想读最近5次导入的数据版本，其实是做不到的。

 

第三、用户无法高效upsert/delete历史数据，parquet文件一旦写入HDFS文件，要想改数据，就只能全量重新写一份的数据，成本很高。事实上，这种需求是广泛存在的，例如由于程序问题，导致错误地写入一些数据到文件系统，现在业务方想要把这些数据纠正过来；线上的MySQL binlog不断地导入update/delete增量更新到下游数据湖中；某些数据审查规范要求做强制数据删除，例如欧洲出台的GDPR隐私保护等等。

 

第四、频繁地数据导入会在