目前市面上流行的三大开源数据湖方案分别为：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隐私保护等等。

第四、频繁地数据导入会在文件系统上产生大量的小文件，导致文件系统不堪重负，尤其是HDFS这种对文件数有限制的文件系统。

所以，在Databricks看来，以下四个点是数据湖必备的。

事实上,  Databricks在设计delta时，希望做到流批作业在数据层面做到进一步的统一(如下图)。业务数据经过Kafka导入到统一的数据湖中（无论批处理，还是流处理），上层业务可以借助各种分析引擎做进一步的商业报表分析、流式计算以及AI分析等等。

所以，总结起来，我认为databricks设计delta时主要考虑实现以下核心功能特性：

Uber和Apache Hudi

Uber的业务场景主要为：将线上产生的行程订单数据，同步到一个统一的数据中心，然后供上层各个城市运营同事用来做分析和处理。在2014年的时候，Uber的数据湖架构相对比较简单，业务日志经由Kafka同步到S3上，上层用EMR做数据分析；线上的关系型数据库以及NoSQL则会通过ETL（ETL任务也会拉去一些Kakfa同步到S3的数据）任务同步到闭源的Vertica分析型数据库，城市运营同学主要通过Vertica SQL实现数据聚合。当时也碰到数据格式混乱、系统扩展成本高（依赖收Vertica商业收费软件）、数据回填麻烦等问题。后续迁移到开源的Hadoop生态，解决了扩展性问题等问题，但依然碰到Databricks上述的一些问题，其中最核心的问题是无法快速upsert存量数据。

如上图所示，ETL任务每隔30分钟定期地把增量更新数据同步到分析表中，全部改写已存在的全量旧数据文件，导致数据延迟和资源消耗都很高。此外，在数据湖的下游，还存在流式作业会增量地消费新写入的数据，数据湖的流式消费对他们来说也是必备的功能。所以，他们就希望设计一种合适的数据湖方案，在解决通用数据湖需求的前提下，还能实现快速的upsert以及流式增量消费。

Uber团队在Hudi上同时实现了Copy On Write和Merge On Read的两种数据格式，其中Merge On Read就是为了解决他们的fast upsert而设计的。简单来说，就是每次把增量更新的数据都写入到一批独立的delta文件集，定期地通过compaction合并delta文件和存量的data文件。同时给上层分析引擎提供三种不同的读取视角：仅读取delta增量文件、仅读取data文件、合并读取delta和data文件。满足各种业务方对数据湖的流批数据分析需求。

最终，我们可以提炼出Uber的数据湖需求为如下图，这也正好是Hudi所侧重的核心特性。

Netflix和Apache Iceberg

Netflix的数据湖原先是借助Hive来构建，但发现Hive在设计上的诸多缺陷之后，开始转为自研Iceberg，并最终演化成Apache下一个高度抽象通用的开源数据湖方案。Netflix用内部的一个时序数据业务的案例来说明Hive的这些问题，采用Hive时按照时间字段做partition，他们发现仅一个月会产生2688个partition和270万个数据文件。他们执行一个简单的select查询，发现仅在分区裁剪阶段就耗费数十分钟。

他们发现Hive的元数据依赖一个外部的MySQL和HDFS文件系统，通过MySQL找到相关的parition之后，需要为每个partition去HDFS文件系统上按照分区做目录的list操作。在文件量大的情况下，这是一个非常耗时的操作。同时，由于元数据分属MySQL和HDFS管理，写入操作本身的原子性难以保证。即使在开启Hive ACID情况下，仍有很多细小场景无法保证原子性。另外，Hive Metastore没有文件级别的统计信息，这使得filter只能下推到partition级别，而无法下推到文件级别，对上层分析性能损耗无可避免。最后，Hive对底层文件系统的复杂语义依赖，使得数据湖难以构建在成本更低的S3上。

于是，Netflix为了解决这些痛点，设计了自己的轻量级数据湖Iceberg。在设计之初，作者们将其定位为一个通用的数据湖项目，所以在实现上做了高度的抽象。虽然目前从功能上看不如前面两者丰富，但由于它牢固坚实的底层设计，一旦功能补齐，将成为一个非常有潜力的开源数据湖方案。

总体来说，Netflix设计Iceberg的核心诉求可以归纳为如下：

痛点小结

我们可以把上述三个项目针对的痛点，放到一张图上来看。可以发现标红的功能点，基本上是一个好的数据湖方案应该去做到的功能点。

7大维度对比

在理解了上述三大方案各自设计的初衷和面向的痛点之后，接下来我们从7个维度来对比评估三大项目的差异。通常人们在考虑数据湖方案选型时，Hive ACID也是一个强有力的候选人，因为它提供了人们需要的较为完善功能集合，所以这里我们把Hive ACID纳入到对比行列中。

第一、ACID和隔离级别支持

这里主要解释下，对数据湖来说三种隔离分别代表的含义。

1. Serialization是说所有的reader和writer都必须串行执行；

2. Write Serialization: 是说多个writer必须严格串行，reader和writer之间则可以同时跑；

3. Snapshot Isolation: 是说如果多个writer写的数据无交集，则可以并发执行；否则只能串行。Reader和writer可以同时跑。

综合起来看，Snapshot Isolation隔离级别的并发性是相对比较好的。

第二、Schema变更支持和设计

这里有两个对比项，一个是schema变更的支持情况，我的理解是hudi仅支持添加可选列和删除列这种向后兼容的DDL操作，而其他方案则没有这个限制。另外一个是数据湖是否自定义schema接口，以期跟计算引擎的schema解耦。这里iceberg是做的比较好的，抽象了自己的schema，不绑定任何计算引擎层面的schema。

第三、流批接口支持

目前Iceberg和Hive暂时不支持流式消费，不过Iceberg社区正在issue 179上开发支持。

第四、接口抽象程度和插件化

这里主要从计算引擎的写入和读取路径、底层存储可插拔、文件格式四个方面来做对比。这里Iceberg是抽象程度做得最好的数据湖方案，四个方面都做了非常干净的解耦。delta是databricks背后主推的，必须天然绑定spark；hudi的代码跟delta类似，也是强绑定spark。存储可插拔的意思是说，是否方便迁移到其他分布式文件系统上（例如S3），这需要数据湖对文件系统API接口有最少的语义依赖，例如若数据湖的ACID强依赖文件系统rename接口原子性的话，就难以迁移到S3这样廉价存储上，目前来看只有Hive没有太考虑这方面的设计；文件格式指的是在不依赖数据湖工具的情况下，是否能读取和分析文件数据，这就要求数据湖不额外设计自己的文件格式，统一用开源的parquet和avro等格式。这里，有一个好处就是，迁移的成本很低，不会被某一个数据湖方案给绑死。

第五、查询性能优化

第六、其他功能

这里One line demo指的是，示例demo是否足够简单，体现了方案的易用性，Iceberg稍微复杂一点（我认为主要是Iceberg自己抽象出了schema，所以操作前需要定义好表的schema）。做得最好的其实是delta，因为它深度跟随spark易用性的脚步。

Python支持其实是很多基于数据湖之上做机器学习的开发者会考虑的问题，可以看到Iceberg和Delta是做的很好的两个方案。

出于数据安全的考虑，Iceberg还提供了文件级别的加密解密功能，这是其他方案未曾考虑到的一个比较重要的点。

第七、社区现状（截止到2020-01-08）

这里需要说明的是，Delta和Hudi两个项目在开源社区的建设和推动方面，做的比较好。Delta的开源版和商业版本，提供了详细的内部设计文档，用户非常容易理解这个方案的内部设计和核心功能，同时Databricks还提供了大量对外分享的技术视频和演讲，甚至邀请了他们的企业用户来分享Delta的线上经验。Uber的工程师也分享了大量Hudi的技术细节和内部方案落地，研究官网的近10个PPT已经能较为轻松理解内部细节，此外国内的小伙伴们也在积极地推动社区建设，提供了官方的技术公众号和邮件列表周报。Iceberg相对会平静一些，社区的大部分讨论都在Github的issues和pull request上，邮件列表的讨论会少一点，很多有价值的技术文档要仔细跟踪issues和PR才能看到，这也许跟社区核心开发者的风格有关。

总结

我们把三个产品（其中delta分为databricks的开源版和商业版）总结成如下图：

如果用一个比喻来说明delta、iceberg、hudi、hive-acid四者差异的话，可以把四个项目比做建房子。由于开源的delta是databricks闭源delta的一个简化版本，它主要为用户提供一个table format的技术标准，闭源版本的delta基于这个标准实现了诸多优化，这里我们主要用闭源的delta来做对比。

Delta的房子底座相对结实，功能楼层也建得相对比较高，但这个房子其实可以说是databricks的，本质上是为了更好的壮大Spark生态，在delta上其他的计算引擎难以替换Spark的位置，尤其是写入路径层面；Iceberg的建筑基础非常扎实，扩展到新的计算引擎或者文件系统都非常的方便，但是现在功能楼层相对低一点，目前最缺的功能就是upsert和compaction两个，Iceberg社区正在以最高优先级推动这两个功能的实现；Hudi的情况要相对不一样，它的建筑基础设计不如iceberg结实，举个例子，如果要接入Flink作为Sink的话，需要把整个房子从底向上翻一遍，把接口抽象出来，同时还要考虑不影响其他功能，当然Hudi的功能楼层还是比较完善的，提供的upsert和compaction功能直接命中广大群众的痛点。Hive的房子，看起来是一栋豪宅，绝大部分功能都有，把它做为数据湖有点像靠着豪宅的一堵墙建房子，显得相对重量级一点，另外正如Netflix上述的分析，细看这个豪宅的墙面是其实是有一些问题的。