数据湖的技术-数智化转型网szhzxw.cn

数字化转型网数据专题将关注数据治理、数据质量管理、数据架构、主数据管理、数据仓库、元数据管理、数据备份、数据挖掘、数据分析、数据安全、大数据、数据合规、等数据相关全产业链相关环节。

数据湖要解决的核心问题是高效的存储各类数据并支撑上层应用，传统的数据湖一般采用HDFS为存储引擎，但在实际应用中面临着难以克服的问题，这直接催生了delta、iceberg和hudi[11]三大开源数据湖方案，虽然它们开始的时候是为了解决特定的应用问题的，但最终促成了数据湖特征的统一。

1、Delta

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

在没有delta数据湖之前，Databricks的客户一般会采用经典的lambda架构来构建他们的流批处理场景。以用户点击行为分析为例，点击事件经Kafka被下游的Spark Streaming作业消费，分析处理（业务层面聚合等）后得到一个实时的分析结果，这个实时结果只是当前时间所看到的一个状态，无法反应时间轴上的所有点击事件。所以为了保存全量点击行为，Kafka还会被另外一个Spark Batch作业分析处理，导入到文件系统上（一般就是parquet格式写HDFS或者S3，可以认为这个文件系统是一个简配版的数据湖），供下游的Batch作业做全量的数据分析以及AI处理等。数字化转型网www.szhzxw.cn

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

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

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

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

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

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

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

2、Hudi

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

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

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

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

3、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 Memstore没有文件级别的统计信息，这使得filter只能下推到partition级别，而无法下推到文件级别，对上层分析性能损耗无可避免。最后，Hive对底层文件系统的复杂语义依赖，使得数据湖难以构建在成本更低的S3上。

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

总体来说，Netflix设计Iceberg的核心诉求可以归纳为如下：数字化转型网www.szhzxw.cn

因此，数据湖并不是炒作的新概念，而是来源于应用的驱动，delta、iceberg和hudi这类新技术实际是介于上层计算引擎和底层存储格式之间的一个中间层，我们可以把它定义成一种“数据组织格式”，Iceberg 将其称之为“表格式”也是表达类似的含义。它与底层的存储格式（比如 ORC、Parquet 之类的列式存储格式）最大的区别是，它并不定义数据存储方式，而是定义了数据、元数据的组织方式，向上提供统一的“表”的语义。它构建在数据存储格式之上，其底层的数据存储仍然使用 Parquet、ORC 等进行存储。

delta、iceberg和hudi诞生于不同公司，需要解决的问题存在差异，Iceberg 在其格式定义和核心能力上最为完善，但是上游引擎的适配上稍显不足；Hudi 基于 Spark 打造了完整的流式数据落地方案，但是其核心抽象较弱，与 Spark 耦合较紧；Delta Lake 同样高度依赖于 Spark 生态圈，与其他引擎的适配尚需时日，虽然这三个方案在设计初衷上稍有不同，但实现的思路和提供的能力却非常相似，我们可以总结出数据湖技术需要具备的能力：数字化转型网www.szhzxw.cn

（1）同时支持流批处理

（2）支持数据更新

（3）支持事务（ACID）

（4）可扩展的元数据

（5）支持多种存储引擎

（6）支持多种计算引擎数字化转型网www.szhzxw.cn

不同公司根据不同需求选择了不同的数据湖产品，比如阿里云的 DLA 团队选择 hudi 作为其底层数据湖存储引擎；腾讯选择了 iceberg 作为他们的数据湖存储引擎,比如文章《基于 Flink+Iceberg 构建企业级实时数据湖》[12]就介绍了腾讯的企业实时数据湖方案。

声明：本文来自网络，版权归作者所有。文章内容仅代表作者独立观点，不代表数字化转型网立场，转载目的在于传递更多信息。如有侵权，请联系我们。数字化转型网www.szhzxw.cn

数字化转型网数据专题包含哪些内容

数字化转型网数据专题包含：数字化转型网（www.szhzxw.cn）

1、数据相关外脑支持：100+数据相关专家、100+数据实践者、1000+相关资料

2、数据研习社：与全球数据相关专家、实践者共同探讨相关问题，推动产业发展！