开源数据湖方案选型: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为例,它要解决的核心问题基本上集中在下图 :

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

图片来源: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看来,以下四个点是数据湖必备的:

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

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

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

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

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

Uber和Apache Hudi

Uber的业务场景主要为:将线上产生的行程订单数据,同步到一个统一的数据中心,然后供上层各个城市运营同事用来做分析和处理。

在2014年的时候,Uber的数据湖架构相对比较简单,业务日志经由Kafka同步到S3上,上层用EMR做数据分析;线上的关系型数据库以及NoSQL则会通过ETL(ETL任务也会拉去一些Kakfa同步到S3的数据)任务同步到闭源的Vertica分析型数据库,城市运营同学主要通过Vertica SQL实现数据聚合。当时也碰到数据格式混乱、系统扩展成本高(依赖收Vertica商业收费软件)、数据回填麻烦等问题。

后续迁移到开源的Hadoop生态,解决了扩展性问题等问题,但依然碰到Databricks上述的一些问题,其中最核心的问题是无法快速upsert存量数据。

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

如上图所示,ETL任务每隔30分钟定期地把增量更新数据同步到分析表中,全部改写已存在的全量旧数据文件,导致数据延迟和资源消耗都很高。

此外,在数据湖的下游,还存在流式作业会增量地消费新写入的数据,数据湖的流式消费对他们来说也是必备的功能。所以,他们就希望设计一种合适的数据湖方案,在解决通用数据湖需求的前提下,还能实现快速的upsert以及流式增量消费。

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

Uber团队在Hudi上同时实现了Copy On Write和Merge On Read的两种数据格式,其中Merge On Read就是为了解决他们的fast upsert而设计的。

简单来说,就是每次把增量更新的数据都写入到一批独立的delta文件集,定期地通过compaction合并delta文件和存量的data文件。同时给上层分析引擎提供三种不同的读取视角:仅读取delta增量文件、仅读取data文件、合并读取delta和data文件。满足各种业务方对数据湖的流批数据分析需求。

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

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

Netflix和Apache Iceberg

Netflix的数据湖原先是借助Hive来构建,但发现Hive在设计上的诸多缺陷之后,开始转为自研Iceberg,并最终演化成Apache下一个高度抽象通用的开源数据湖方案。

Netflix用内部的一个时序数据业务的案例来说明Hive的这些问题,采用Hive时按照时间字段做partition,他们发现仅一个月会产生2688个partition和270万个数据文件。他们执行一个简单的select查询,发现仅在分区裁剪阶段就耗费数十分钟。

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

他们发现Hive的元数据依赖一个外部的MySQL和HDFS文件系统,通过MySQL找到相关的parition之后,需要为每个partition去HDFS文件系统上按照分区做目录的list操作。在文件量大的情况下,这是一个非常耗时的操作。

同时,由于元数据分属MySQL和HDFS管理,写入操作本身的原子性难以保证。即使在开启Hive ACID情况下,仍有很多细小场景无法保证原子性。另外,Hive Metastore没有文件级别的统计信息,这使得filter只能下推到partition级别,而无法下推到文件级别,对上层分析性能损耗无可避免。

最后,Hive对底层文件系统的复杂语义依赖,使得数据湖难以构建在成本更低的S3上。

于是,Netflix为了解决这些痛点,设计了自己的轻量级数据湖Iceberg。在设计之初,作者们将其定位为一个通用的数据湖项目,所以在实现上做了高度的抽象。

虽然目前从功能上看不如前面两者丰富,但由于它牢固坚实的底层设计,一旦功能补齐,将成为一个非常有潜力的开源数据湖方案。

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

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

痛点小结

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

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

七大维度对比

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

第一、ACID和隔离级别支持

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

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

  • Serialization是说所有的reader和writer都必须串行执行;
  • Write Serialization: 是说多个writer必须严格串行,reader和writer之间则可以同时跑;
  • Snapshot Isolation: 是说如果多个writer写的数据无交集,则可以并发执行;否则只能串行。Reader和writer可以同时跑。

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

第二、Schema变更支持和设计

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

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

第三、流批接口支持

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

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

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

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

这里主要从计算引擎的写入和读取路径、底层存储可插拔、文件格式四个方面来做对比。这里Iceberg是抽象程度做得最好的数据湖方案,四个方面都做了非常干净的解耦。delta是databricks背后主推的,必须天然绑定spark;hudi的代码跟delta类似,也是强绑定spark。

存储可插拔的意思是说,是否方便迁移到其他分布式文件系统上(例如S3),这需要数据湖对文件系统API接口有最少的语义依赖,例如若数据湖的ACID强依赖文件系统rename接口原子性的话,就难以迁移到S3这样廉价存储上,目前来看只有Hive没有太考虑这方面的设计;文件格式指的是在不依赖数据湖工具的情况下,是否能读取和分析文件数据,这就要求数据湖不额外设计自己的文件格式,统一用开源的parquet和avro等格式。这里,有一个好处就是,迁移的成本很低,不会被某一个数据湖方案给绑死。

第五、查询性能优化

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

第六、其他功能

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

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

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

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

第七、社区现状(截止到2020-01-08)

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

这里需要说明的是,Delta和Hudi两个项目在开源社区的建设和推动方面,做的比较好。Delta的开源版和商业版本,提供了详细的内部设计文档,用户非常容易理解这个方案的内部设计和核心功能,同时Databricks还提供了大量对外分享的技术视频和演讲,甚至邀请了他们的企业用户来分享Delta的线上经验。

Uber的工程师也分享了大量Hudi的技术细节和内部方案落地,研究官网的近10个PPT已经能较为轻松理解内部细节,此外国内的小伙伴们也在积极地推动社区建设,提供了官方的技术公众号和邮件列表周报。

Iceberg相对会平静一些,社区的大部分讨论都在Github的issues和pull request上,邮件列表的讨论会少一点,很多有价值的技术文档要仔细跟踪issues和PR才能看到,这也许跟社区核心开发者的风格有关。

总结

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

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

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

开源数据湖方案选型:Hudi、Delta、Iceberg深度对比

Delta的房子底座相对结实,功能楼层也建得相对比较高,但这个房子其实可以说是databricks的,本质上是为了更好地壮大Spark生态,在delta上其他的计算引擎难以替换Spark的位置,尤其是写入路径层面。

Iceberg的建筑基础非常扎实,扩展到新的计算引擎或者文件系统都非常的方便,但是现在功能楼层相对低一点,目前最缺的功能就是upsert和compaction两个,Iceberg社区正在以最高优先级推动这两个功能的实现。

Hudi的情况要相对不一样,它的建筑基础设计不如iceberg结实,举个例子,如果要接入Flink作为Sink的话,需要把整个房子从底向上翻一遍,把接口抽象出来,同时还要考虑不影响其他功能,当然Hudi的功能楼层还是比较完善的,提供的upsert和compaction功能直接命中广大群众的痛点。

Hive的房子,看起来是一栋豪宅,绝大部分功能都有,把它做为数据湖有点像靠着豪宅的一堵墙建房子,显得相对重量级一点,另外正如Netflix上述的分析,细看这个豪宅的墙面是其实是有一些问题的。

 

责任编辑:张燕妮 来源: Apache Iceberg技术社区
相关推荐

2020-10-30 09:27:25

开源技术 数据

2022-07-06 09:53:04

开源数据湖

2021-07-20 11:52:03

FlinkIceberg 对象存储

2023-06-28 07:47:34

Iceberg数据湖

2023-02-25 10:17:28

2021-08-31 10:07:16

Flink Hud数据湖阿里云

2023-05-05 18:53:23

数据湖数据仓库

2022-10-24 00:26:51

大数据Hadoop存储层

2023-02-26 00:12:10

Hadoop数据湖存储

2023-07-12 08:44:46

湖仓存储系统数据湖

2021-10-19 07:27:07

边缘集群管理

2022-11-10 20:29:21

数据湖

2022-06-08 13:25:51

数据

2022-03-08 13:14:32

数据湖大数据

2021-09-13 13:46:29

Apache HudiB 站数据湖

2022-06-09 14:19:46

顺丰数据集成Flink

2021-02-28 13:45:12

边缘计算云计算Kubernetes

2022-10-17 10:48:50

Hudi大数据Hadoop

2021-09-07 10:41:21

CDC数据湖Apache Hud

2021-12-06 20:39:34

AI
点赞
收藏

51CTO技术栈公众号