深度对比 Delta、Iceberg 和 Hudi 三大开源数据湖方案

阅读数:2 2020 年 3 月 19 日 11:08

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

目前市面上流行的三大开源数据湖方案分别为:Delta、Apache Iceberg 和 Apache Hudi。其中,由于 Apache Spark 在商业化上取得巨大成功,所以由其背后商业公司 Databricks 推出的 Delta 也显得格外亮眼。Apache Hudi 是由 Uber 的工程师为满足其内部数据分析的需求而设计的数据湖项目,它提供的 fast upsert/delete 以及 compaction 等功能可以说是精准命中广大人民群众的痛点,加上项目各成员积极地社区建设,包括技术细节分享、国内社区推广等等,也在逐步地吸引潜在用户的目光。Apache Iceberg 目前看则会显得相对平庸一些,简单说社区关注度暂时比不上 Delta,功能也不如 Hudi 丰富,但却是一个野心勃勃的项目,因为它具有高度抽象和非常优雅的设计,为成为一个通用的数据湖方案奠定了良好基础。

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

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

Databricks 和 Delta

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

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

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

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

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

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

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

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

Uber 和 Apache Hudi

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

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

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

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

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

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

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

Netflix 和 Apache Iceberg

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

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

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

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

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

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

痛点小结

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

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

7 大维度对比

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

第一、ACID 和隔离级别支持

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

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

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

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

第二、Schema 变更支持和设计

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

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

第三、流批接口支持

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

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

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

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

这里主要从计算引擎的写入和读取路径、底层存储可插拔、文件格式四个方面来做对比。

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

第五、查询性能优化

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

第六、其他功能

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

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

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

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

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

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

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

总结

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

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

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

深度对比Delta、Iceberg和Hudi三大开源数据湖方案

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

评论

发布