之前文章先后聊了两款重要的数据库，Clickhouse以及Doris，今天这篇文章呢，咱再来聊聊一款当下比较火热的数据湖组件——Hudi。

之前写过一篇关于调侃“数据湖”这个概念的文章，说现在很多关于这个概念的营销文之所以层出不穷，什么只有数据入湖，湖仓一体才能解决你的业务问题之类，其核心目的是在推广他们的软件。

更重要的是，这些不断涌现的“虚头巴脑”的新概念，会让一些新手程序员在学习的道路上，又给铺上一层厚厚的迷雾，让本就学习方向不明确的他们，更加迷茫和无助。

作为程序员老鸟们都应该知道，这个世界就不存在哪个用了就一劳永逸的软件，也没有哪个放之四海而皆准的技术架构，更不存在某个虚空的，可以解决任何业务问题的空泛概念。

能不能行，是否能解决你的业务痛点，关键在用技术的人。

牛逼的人，你就是只给他个MySQL，他一样能成事。

水平不行的人，你就是把当下最新潮，最高级的技术都给他用，也一样搞不定。

那hudi这个技术，到底是一个什么样的存在呢？从这篇文章开始，决定带你一起聊聊。

0. 如何理解数据湖

从维基百科的解释来看呢，定义数据湖是一个能够容纳各种不同数据格式和类型的，能提供对数据进行存储，管理，分析以及使用的这么个数据平台。

很明显，这里只是定义了一个非常模糊和宽泛的数据需求，没有绑定任何技术，以及任何使用标准。

但是当下却有很多文章在一本正经的告诉你，什么才是数据湖，什么才叫数据平台，以及什么才算数据仓库，跟你掰扯各种雨里雾里的概念，玩文字游戏，越说越玄乎。

看完这些，说实话，我是真的没有看出来这些概念背后，明显的技术或者业务边界在哪，也不清楚把这些本就界定模糊的概念，非得装模作样给你一通解释的目的是什么(显得有学问？)。

咱务实一点，根据实际场景需要，去设计一个个合理的技术架构，踏踏实实去解决一个个真实存在的业务问题，不好吗？

1. 如何理解当下的数据湖技术

从网上能查到的公开资料可以知道，当下被直接称作数据湖(官网定义)的技术中，主流的有：hudi、iceberg、delta这3种。

从我对这几个技术的定义和理解来看呢，这3个所谓的数据湖解决方案的共同点是：

定义了一个，介于分布式文件系统与普通数据库之间的，同时继承了文件系统中数据对使用者直接可见的优点，以及数据库对数据的schema，metadata和事务管理能力的优点。

但同时，又摒弃了文件系统存储松散，数据库技术又过于厚重缺点的，这么一个数据管理中间件。

所以，现有的所谓数据湖技术，只不过就是提供了一种，介于文件系统，和数据库之间的，吸取了这两者的优点，但同时又摒弃了这两者一些缺点的，依附于分布式文件系统之上的，数据存储方案。

说到这里，让我想起了ORC和parquet这两种Hadoop生态常见的，同样依附于HDFS之上的数据存储方案，人家同样也是自带schema的，且ORC格式还支持ACID功能，是不是也算某种意义上的数据湖解决方案呢？

不得不说，这几个存储组件很聪明，把自己绑上数据湖的定义后，然后自然就能引起大量的关注。

那到底这玩意有没有吹的那么神，咱们先通过hudi这个组件，来一探究竟。

2. 初识hudi

不是有3个主流数据湖的技术吗，为啥偏偏选hudi呢？

这个主要跟它的名字有关系，hudi的全称叫：Hadoop Upserts Deletes and Incrementals。

意思是，它的初衷就是基于Hadoop文件系统之上，来设计的这样一种对数据提供CRUD的管理方案。

这就让人很容易想起hive，hive就是这么个借助HDFS作为存储，以及利用MR/Tez/Spark作为计算工具的中间商。

只不过，hudi的玩法跟hive有些区别，hive是一个需要额外部署的服务，用起来很重。

而hudi则更像是一个轻量级的数据管理插件，通过一个额外的jar包，就可以跟其他组件(计算引擎)一起配合使用，完成hudi的数据管理功能。

而且从官网中也可以看出来，它推荐你直接通过计算引擎来使用它：

槽点：

这里必须要吐槽的是，官方文档虽然提供了中/英两种语言的选择，但是当我切换到中文显示时，很多页面的内容丝毫没有反应，依然还是显示的英文(比如上面截图的页面)，主打一个逗你玩(当然，优点是不用梯子，官网也可以顺利打开)。

3. 对计算引擎的兼容

从官方文档描述来看，它是同时兼容Spark和Flink的。

先来看跟spark的兼容性：

截止到我写这篇文章为止，hudi最新的版本为0.13.1，虽然从这个跟spark的兼容列表里看不到。

但是，从下面给的spark-shell启动案例却能看到：

也就是当前最新的hudi 0.13.1版本是兼容spark3.2的，正好我的spark版本就是3.2，咱就用这个了。

篇幅关系，今天先写到这，咱下一篇接着唠...