开源数据湖方案选型:开源数据湖方案选型: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为例,它要解决的核心问题基本上集中在下图 :
图片来源:slideshare.net
在没有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这种对文件数有限制的文件
系统。