从 Hudi 到 Iceberg，资本博弈下的降本增效之路

大家好，我是大圣！一个热爱互联网技术并且爱折腾的人！

这篇文章希望大家明白互联网技术的发展是资本和业务推动的结果，技术的终极使命是降本增效。技术重要，但是业务也十分重要！

今天想跟大家聊一下数据湖这个热门的话题，我是国内第一批使用数据湖的人，对数据湖感触很深，今天和大家聊一下数据湖的来世今生。

数据湖开山鼻祖 Hudi

一个新框架或者技术诞生，肯定是它解决了业务场景中的痛点，那么数据湖解决了什么问题呢？ 大家顺着这条主线看下去

其实第一个提出数据湖雏形的 Hudi，它是 2016 年 Uber开发，并于 2017 年开源。Hudi 是数据湖界的开山鼻祖，后面几乎所有的数据湖框架的思想都是从 Hudi 里面借鉴来的。

这个 Uber 说起来大家应该比较熟悉，它就是 2015年左右和滴滴一起竞争国内打车市场的优步！我是体验过那段时间由于滴滴和Uber 竞争的时光，三公里打车0.8 元，五公里打车 2 块钱不到。最后由 滴滴收购了优步中国的品牌、业务、数据等全部资产结束。

扯得有点多，拉回正题。

据 Hudi 的创始人 Vinoth Chandar 在采访说 Uber 的业务增长迅猛，数据量随之激增。作为一家高度实时化的公司，Uber 需要优化数据新鲜度，以降低成本并提高查询效率。

最初使用 Vertica 进行数据存储，但随着数据量增长，转向 Spark 和数据湖来管理海量数据。然而，传统数据湖基于 Hadoop 进行大规模批量处理，导致数据延迟增加，无法满足实时性需求。

数据湖 Hudi 设计思想

为了解决这一问题，Uber 需要一个能够支持数据 更新和删除 的方案，并直接基于数据库变更日志进行高效数据同步，以提升数据新鲜度。Hudi（Hadoop Upserts Deletes and Incrementals） 因此诞生，它支持 增量更新、低延迟查询，弥补了传统数据湖在实时数据处理上的缺陷，成为现代数据湖架构的重要组件。

这就是 Hudi 的诞生背景，从技术思想来看 Hudi 就是想在文件系统上面实现更新操作。比如 HDFS、OSS、S3 等文件系统。后面 Hudi 的所有的功能都是基于这个技术思想来实现的。

Hudi 在文件系统上面实现更新操作的核心实现是 ： 先把数据按照一定的规则存储在多个小文件里面，然后需要更新数据的时候，找到数据所在的小文件，然后把这个文件里面的内容全部重写一遍！

思考

从 Hudi 的核心实现中会提出疑问：

1.Hudi 按照什么规则把数据拆分到多个小文件里面？

2.在大数据场景下许多小文件，怎么找到数据所在的文件？

3.找到数据所在的小文件之后，怎么知道这条数据是更新还是插入？

4.如果每次写入都重写整个文件，那这样频繁写入速度会不会很慢？

如果大家能够把上面四个问题想明白，大概就知道 Hudi 的核心原理是怎么实现的。

见解

1.Hudi 是通过 partitions、file groups、file slices、base file 这几个逻辑概念把数据进行分文件保存

2.找数据所在的文件是通过 Index 来完成

3.这个结合索引和分区+ Record Key 来判断

4.这就是 COW 表和 MOR 表的区别

Hudi 官网写的比较晦涩难懂，它只告诉你了就是这样的，我们强制去接受记忆，从而不知道为什么，所以很多人觉得 Hudi 的入门门槛比较高。

另外这篇文章只是从大的方向去说数据湖的发展，所以很细节的技术只是点到为止，大家如果对哪个技术感兴趣，可以留言，我会详细给大家拆解！

资本博弈的结果 - Flink

说起数据湖 Paimon 的诞生，就不得不提到 Flink 框架的横空出世！

某里错过了在 2010 年左右错过了 Spark 的市场，结果在 Spark 可以说是在大数据领域大火，一骑绝尘，无数大数据开发对 Spark 是的热情水涨船高！

某里可以说错过了大数据批处理方面的一个重要里程碑。

某里在 2014 年花 1.033亿美元 收购了 Flink，在2015 年开始改进Flink，并创建了内部分支Blink，并在 2019 年合并 Flink 和 Blink 进行开源！

之后 Flink 进正式进入大众视野，火遍中国互联网，现在做大数据要是没有听过 Flink 都称不上一个合格的数据开发。

但是以 Flink 为代表的实时开发，真的是现在许多公司所需要的吗？

Paimon 的出生

在 2021 年左右，国内用的数据湖还都是以 Hudi 为主，但是 Hudi从它的技术特性就可以看出，它还是批处理为主。

所以一直在它对 Spark 支持特别友好，一般有什么新特性也是先支持 Spark 框架，对 Flink 的扩展一直都不是很好，很多时候 Hudi 在 Spark 上面已经支持的功能，但是对 Flink 来说是不支持的，这就需要开发者去重复造轮子。

随着 Flink 越来越火，Hudi 对 Flink 的支持变得越来越鸡肋，Flink 开发者先是孵化出来了 Flink Table Store，接着再摇身一变成为了 Paimon。 号称真正流处理的数据湖！

但是在数据湖的思想和设计理念上面和 Hudi 不能说一毛一样，只能说大差不差，只是当初使用 Hudi 需要开发者造的那些轮子，Paimon 给我们造好了！但是 Paimon 的批处理能力现在仍然不行，有兴趣的可以去了解一下！

另外 Paimon 把很多其他需要造的轮子也给写好了，比如数据从 RDMS 到 Paimon 数据湖等等。进一步推动技术的发展，进行降本增效。

Iceberg 的出现

Iceberg 最开始设计开发出来核心希望解决的是Hive数仓遇到的问题
如下图：

简单翻译一下就是在传统基于 Hive Metastore 与文件系统的表管理模式中，存在以下主要问题：

1.元数据存储分散：表的元数据同时存储在 Hive Metastore 和文件系统，管理复杂，容易出现状态不一致。

2.分桶方案依赖性强：Hive 的分桶实现基于 Java 哈希，灵活性和可移植性不足。

3.缺乏完善的 ACID 支持：非 ACID 表仅能依靠“添加分区”这种有限的原子操作，难以满足事务级一致性需求。

4.文件移动的原子性难以保证：在云存储或分布式文件系统中原子移动文件常常成本较高，也不易实现。

Iceberg 刚开始的设计理念是不支持像在 Hadoop 上支持 Upsert 的，是在 2020 年之后才加上这个特性，从此打上了数据湖的标签！

不过 在 Databricks 收购了 Apache Iceberg 之后，Iceberg 在数据湖方面发展迅速，有望成为湖仓一体开放表格式事实上的标准，业界预计2025年，企业对数据湖仓一体的应用将明显提速。