1. 第一章Hudi 框架概述
Apahe Hudi (Hadoop Upserts delete and Incrementals)是Uber主导开发的开源数据湖框架，为了解决大数据生态系统中需要插入更新及增量消费原语的摄取管道和ETL管道的低效问题，该项目在2016年开始开发，并于2017年开源，2019年1月进入 Apache 孵化器，且2020年6月称为Apache 顶级项目。
官网：https://hudi.apache.org/
先了解什么是数据湖DataLake，及Hudi 数据湖框架功能及各个版本特性。
1.1 数据湖Data Lake
数据湖是大数据架构的新范式，以原始格式存储数据，可以满足用户的广泛需求，并能提供更快的洞察力，细致的数据编录和管理是成功实施数据湖的关键。
1.1.1 仓库和湖泊
仓库（WareHouse）是人为提前建造好的，有货架，还有过道，并且还可以进一步为放置到货架的物品指定位置。
而湖泊（Lake）是液态的，是不断变化的、没有固定形态的，基本上是没有结构的，湖泊可以是由河流 、小溪和其他未被任何处理的水源维持。湖泊是不需要预先指定结构的。
1.1.2 什么是数据湖
Data lake这个术语由Pentaho公司的创始人兼首席技术官詹姆斯·狄克逊(James Dixon)提出，他对数据湖的解释是： 把你以前在磁带上拥有的东西倒入到数据湖，然后开始探索该数据。
数据湖（Data Lake）和数据库、数据仓库一样，都是数据存储的设计模式。数据库和数据仓库会以关系型的方式来设计存储、处理数据。但数据湖的设计理念是相反的，数据仓库是为了保障数据的质量、数据的一致性、数据的重用性等对数据进行结构化处理。
数据湖是一个数据存储库，可以使用数据湖来存储大量的原始数据。现在企业的数据仓库都会通过分层的方式将数据存储在文件夹、文件中，而数据湖使用的是平面架构来存储数据。我们需要做的只是给每个数据元素分配一个唯一的标识符，并通过元数据标签来进行标注。当企业中出现业务问题时，可以从数据湖中查询数据，然后分析业务对应的那一小部分数据集来解决业务问题。
了解过Hadoop的同学知道，基于Hadoop可以存储任意形式的数据。所以，很多时候数据湖会和Hadoop关联到一起。例如：把数据加载Hadoop中，然后将数据分析、和数据挖掘的工具基于Hadoop进行处理。
数据湖越来越多的用于描述任何的大型数据池，数据都是以原始数据方式存储，知道需要查询应用数据的时候才会开始分析数据需求和应用架构。
用一个类比来解释Data Lake的概念。游览大湖总是一种非常愉快的感觉。湖中的水以其最纯净的形式存在，不同的人在湖上进行不同的活动。有些人在钓鱼，有些人喜欢乘船游览，这个湖还为生活在安大略省的人们提供饮用水。简而言之，同一个湖有多种用途。
数据湖是专注于原始数据保存以及低成本长期存储的存储设计模式，它相当于是对数据仓库的补充。数据湖是用于长期存储数据容器的集合，通过数据湖可以大规模的捕获、加工、探索任何形式的原始数据。通过使用一些低成本的技术，可以让下游设施可以更好地利用，下游设施包括像数据集市、数据仓库或者是机器学习模型。
数据湖（DataLake）是描述数据存储策略的方式，并不与具体的某个技术框架关联，与数据库、数据仓库也一样，它们都是数据的管理策略，数据湖最核心的能力包括：
1.1.3 数据湖的优点
维基百科上定义，数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统。它按原样存储数据，而无需事先对数据进行结构化处理。一个数据湖可以存储结构化数据（如关系型数据库中的表），半结构化数据（如CSV、日志、XML、JSON），非结构化数据（如电子邮件、文档、PDF）和二进制数据（如图形、音频、视频）。数据湖有如下几个方面优点：
■ 提供不限数据类型的存储；
■ 开发人员和数据科学家可以快速动态建立数据模型、构建应用、查询数据，非常灵活；
■ 因为数据湖没有固定的结构，所以更易于访问;
■ 长期存储数据的成本低廉，数据湖可以安装在低成本的硬件在，例如：在一般的X86机器上部署Hadoop;
■ 因为数据湖是非常灵活的，它允许使用多种不同的处理、分析方式来让数据发挥价值，例如：数据分析、实时分析、机器学习以及SQL查询都可以;
1.1.4 Data Lake vs Data warehouse
数据湖和数据仓库是用于存储大数据的两种不同策略，最大区别是：数据仓库是提前设计好模式（schema）的，因为数据仓库中存储的都是结构化数据。而在数据湖中，不一定是这样的，数据湖中可以存储结构化和非结构化的数据，是无法预先定义好结构的。
从如下7个方面对比认识数据仓库和数据湖不同点：
■ 第一点：数据的存储位置不同
■ 数据仓库因为是要有结构的，在企业中很多都是基于关系型模型；
■ 数据湖通常位于分布式存储，例如Hadoop或者类似的大数据存储中；
■ 第二点：数据源不同
■ 数据仓库的数据来源很多时候来自于OLTP应用的结构化数据库中提取的，用于支持内部的业务部门（例如：销售、市场、运营等部门）进行业务分析；
■ 数据湖的数据来源可以是结构化的、也可以是非结构化的，例如：业务系统数据库、 IOT设备、社交媒体、移动APP等；
■ 第三点：用户不同
■ 数据仓库主要是业务系统的大量业务数据进行统计分析，所以会应用数据分析的部门是数据仓库的主要用户，例如：销售部、市场部、运营部、总裁办等等。而当需要一个大型的存储，而当前没有明确的数据应用用户或者是目标，将来想要使用这些数据的人可以在使用时开始设计架构，此时，数据湖更适合；
■ 数据湖中的数据都是原始数据，是未经整理的，这对于普通的用户几乎是不可用的。数据湖更适合数据科学家，因为数据科学家可以应用模型、技术发觉数据中的价值，去解决企业中的业务问题；
■ 第四点：数据质量不同
■ 数据仓库是非常重数据质量的，大家现在经常听说的数据中台，其中有一大块是数据质量管理、数据资产管理等。数据仓库中的数据都是经过处理的；
■ 数据湖中的数据可靠性是较差的，这些数据可能是任意状态、形态的数据；
■ 第五点、数据模式
■ 数据仓库在数据写入之前就要定义好模式（schema），例如：会先建立模型、建立表结构，然后导入数据，可以把它称之为write-schema；
■ 数据湖中的数据是没有模式的，直到有用户要访问数据、使用数据才会建立schema，可以把它称之为read-schema；
■ 第六点：敏捷扩展性
■ 数据仓库的模式一旦建立，要重新调整模式，往往代价很大，牵一发而动全身，所有相关的ETL程序可能都需要调整；
■ 数据湖是非常灵活的，可以根据需要重新配置结构或者模式；
■ 第七点：应用不同
■ 数据仓库一般用于做批处理报告、BI、可视化；
■ 数据湖主要用于机器学习、预测分析、数据探索和分析；
基于上述内容，可以了解到，数据湖和数据仓库的应用点是不一样的。它们是两种相对独立的数据设计模式。在一些企业中，可能会既有数据湖、又有数据仓库。数据湖并不是要替代数据仓库，而是对企业的数据管理模式进行补充；
1.1.5 数据湖框架
目前市面上流行的三大开源数据湖方案分别为：Delta Lake、Apache Iceberg和Apache Hudi。
1.1.5.1 Delta Lake
Delta Lake：流批一体的Data Lake存储层，支持 update/delete/merge
■ 官网：https://delta.io/
■ 由于出自Databricks，Spark的所有数据写入方式，包括基于dataframe的批式、流式，以及SQL的Insert、Insert Overwrite等都是支持的（开源的SQL写暂不支持，EMR做了支持）。
■ 在数据写入方面，Delta 与 Spark 是强绑定的；在查询方面，开源 Delta 目前支持 Spark 与 Presto，但是，Spark 是不可或缺的，因为 delta log 的处理需要用到 Spark。
1.1.5.2 Apache Iceberg
Apache Iceberg：用于跟踪超大规模表的新格式，是专门为对象存储（如S3）而设计的
■ 官网：http://iceberg.apache.org/
■ Apache Iceberg 是由 Netflix 开发开源的，其于 2018年11月16日进入 Apache 孵化器，是 Netflix 公司数据仓库基础。
■ iceberg 是一种可伸缩的表存储格式，内置了许多最佳实践。允许我们在一个文件里面修改或者过滤数据；当然多个文件也支持这些操作。
■ 在查询方面，Iceberg 支持 Spark、Presto，提供了建表的 API，用户可以使用该 API 指定表明、schema、partition 信息等，然后在 Hive catalog 中完成建表。
1.1.5.3 Apache Hudi
Apache Hudi：提供的fast upsert/delete以及compaction等功能
■ 官网：https://hudi.apache.org/
■ Hudi 设计目标正如其名，Hadoop Upserts Deletes and Incrementals（原为 Hadoop Upserts anD Incrementals），强调其主要支持Upserts、Deletes和Incrementa数据处理，其主要提供的写入工具是 Spark HudiDataSource API 和自身提供的 DeltaStreamer。
■ 支持三种数据写入方式：UPSERT，INSERT 和 BULK_INSERT。其对 Delete 的支持也是通过写入时指定一定的选项支持的，并不支持纯粹的 delete 接口。
1.1.6 湖仓一体（Data Lakehouse）
Data Lakehouse（湖仓一体）是新出现的一种数据架构，它同时吸收了数据仓库和数据湖的优势，数据分析师和数据科学家可以在同一个数据存储中对数据进行操作，同时它也能为公司进行数据治理带来更多的便利性。
1.1.6.1 背景概述
■ 数据仓库曾一直做为决策支持系统的支撑平台。数据仓库使用良好设计的模式规范数据，例如星形模型、雪花模型和正常范式等。数据仓库无法生成数据所需的洞察。
■ Hadoop 生态系统迅速演进，进而出现了称为“数据湖”的非结构化数据存储和处理新范式。数据湖由于缺乏结构和治理，会迅速沦为“数据沼泽”。
LakeHouse是一种结合了数据湖和数据仓库优势的新范式。LakeHouse使用新的系统设计：直接在用于数据湖的低成本存储上实现与数据仓库中类似的数据结构和数据管理功能。如果你现在需要重新设计数据仓库，鉴于现在存储（以对象存储的形式）廉价且高可靠，不妨可以使用LakeHouse。
如下展示，从数据仓库DataWarehouse到数据湖DataLake，再到湖仓一体LakeHouse。
1.1.6.2 概念定义
湖仓一体架构力图结合数据仓库的弹性和数据湖的灵活性。人们创建数据仓库来支持商业智能，主要用例包括编制报表、发布下游数据集市(Data Marts)，以及支持自助式商业智能等。数据湖的概念来自于数据科学对数据的探索，主要用例包括通过快速实验创建和检验假设，以及利用半结构化和非结构化数据等。
湖仓一体具有以下五个关键特性：
■ 支持分析结构化和非结构化数据；
■ 适用于分析师和数据科学家，不仅支持报表，而且支持机器学习和人工智能相关用例；
■ 数据可治理，避免产生沼泽；
■ 架构鲁棒安全，确保利益相关者能正确访问以数据为中心的安全架构；
■ 以合理代价实现有效扩展。
1.1.6.3 架构原则
LakeHouse是一种新的数据管理范式，从根本上简化了企业数据基础架构，并且有望在机器学习已渗透到每个行业的时代加速创新。
湖仓一体概念架构中，各核心组件通过有效的组织，形成了全新的湖仓一体范式。
■ 支持结构化和非结构化数据。无论是类关系数据库那样静态存储，还是以实时数据流方式提供，数据均可转化为洞察。
■ 数据抽取（Data ingestion）服务提供多种抽取方式，将数据抽取到数据湖中，既可以满足批处理需求，也可以满足流式加载需求。一条经验法则是，数据抽取中不做任何数据转换。
■ 抽取的数据存储在数据湖的原始数据区域，该区域也称为“青铜层”（bronze layer）。数据依照源数据结构进行管理，实现源数据和下游分析的解耦。
■ 数据处理（data processing）服务处理原始数据区域中的数据，执行清洗、归并、复杂业务逻辑等操作，并进一步准备好适用于人工智能、商业智能等下游分析的数据格式。
■ 数据同时周期性地临时存放在已清洗数据区域，该区域也称为“白银层”（silver layer）。已清洗数据区域避免对数据重复做多次处理。处理完成的数据最终存储在已处理数据区域，该区域也称为“黄金层”（gold layer）。
■ 数据都存储在数据湖中，可用于即席分析、机器学习和报表等多种用例。但数据湖不利于结构化报表或自助式商业智能，而数据仓库在此类需求上表现出色。这需要数据存储同时提供数据仓库能力。
■ 数据编目（Data cataloging）服务确保所有源数据、数据湖和数据仓库中的数据、数据处理流水线管道以及从湖仓一体中抽取的输出都做了适当的编目，防止湖仓一体变成数据沼泽。
■ 数据分析（Analytics）服务提供多种数据用途。数据科学家可创建分析沙箱，运行实验和假设测试。数据分析人员可创建沙箱，触发快速查询并对数据执行即席分析。人工智能和机器学习人员可运行和维护模型。商业智能为用户提供了具有丰富可视化效果的自助式商业智能。
建立真实有效湖仓一体架构，应遵循如下五个关键原则：
■ 计算和存储的解耦：首要原则是加入解耦和存储。存储便宜且持久，计算昂贵且短暂。计算和存储的解耦，可使系统灵活地按需升级并扩展计算服务。
■ 目标驱动的存储层：数据以多种形态和形式呈现，因此数据的存储方式应具灵活性，以适应数据的不同形态和用途。灵活性包括根据数据的种类及提供方式不同，提供关系层、图数据层、文档层以及 Blob 等多模态存储层。
■ 模块化的体系架构：该原则源自于 SOA，确保数据处于核心地位，以围绕数据开展所需服务为关键。基于数据开展数据抽取、处理、编目和分析等不同类型的服务，而不是借助流水线将数据提供给服务。
■ 聚焦于功能，而非技术：该原则体现了灵活性。功能的变化缓慢，但技术的变革日新月异。因此一定要聚焦于组件所完成的功能，进而可轻易追随技术的发展而替换旧技术。
■ 活动编目（Active cataloging）：该项基本原则是避免数据湖沦为数据沼泽的关键。编目上需具有明确的治理原则，有助于确保数据充分记录到数据湖中。
数据是复杂的，并且在不断地发展。业务也在迅速地变化，需求同样再不断地变化，架构必须具备能适应所有变化的灵活性，上述五个架构原则有助于建立切实有效的湖仓一体架构。
2 Hudi 介绍
Hudi是Hadoop Upserts anD Incrementals的缩写，用于管理HDFS上的大型分析数据集存储。 Hudi的主要目的是高效的减少入库延时，Hudi是Uber开发的一个开源项目。存储于HDFS上的分析数据集一般通过两种类型的表来提供，即Copy-On-Write Table写时拷贝和Merge-On-Read Table读时合并。
Apache Hudi是在大数据存储上的一个数据集，可以将 Change Logs 通过 upsert 的方式合并进 Hudi；Hudi 对上可以暴露成一个普通的 Hive 或 Spark 的表，通过 API 或命令行可以获取到增量修改的信息，继续供下游消费；Hudi 还保管了修改历史，可以做时间旅行或回退；Hudi 内部有主键到文件级的索引，默认是记录到文件的布隆过滤器，高级的有存储到 HBase 索引提供更高的效率。
2.1 官方定义
Apache Hudi通过分布式文件系统（HDFS或者云存储）来摄取（Ingests）、管理（Manages）大型分析型数据集。Hudi是可以借助于DFS之上，提供了一些数据提取、管理功能。
一言以蔽之，Hudi是一种针对分析型业务的、扫描优化的数据存储抽象，它能够使DFS数据集在分钟级的时延内支持变更，也支持下游系统对这个数据集的增量处理。
Hudi 数据湖的基础架构：
■ 1、通过DeltaStreammer、Flink、Spark等工作，将数据摄取到数据湖的数据存储，例如：可以使用HDFS作为数据湖的数据存储；
■ 2、基于HDFS可以构建Hudi的数据湖；
■ 3、Hudi提供统一的访问Spark数据源和Flink数据源；
■ 4、外部通过不同引擎，例如：Spark、Flink、Presto、Hive、Impala、Aliyun DLA、AWS Redshit访问接口；
下载地址：https://hudi.apache.org/download.html
2.2 Hudi 特性
Apache Hudi使得用户能在Hadoop兼容的存储之上存储大量数据，同时它还提供两种原语，使得除了经典的批处理之外，还可以在数据湖上进行流处理。这两种原语分别是：
■ Update/Delete记录：Hudi使用细粒度的文件/记录级别索引来支持Update/Delete记录，同时还提供写操作的事务保证。查询会处理最后一个提交的快照，并基于此输出结果。
■ 变更流：Hudi对获取数据变更提供了一流的支持：可以从给定的时间点获取给定表中已updated/inserted/deleted的所有记录的增量流，并解锁新的查询姿势（类别）。
Hudi提供的功能特性如下：
■ 第一、支持使用索引方式Upsert
Upsert support with fast, pluggable indexing
■ 第二、可以原子性的发布数据并支持回滚
Atomically publish data with rollback support
■ 第三、写入和查询使用快照进行隔离，保证数据的一致性
Snapshot isolatiol between writer & queries
■ 第四、可以用Savepoint进行数据恢复
Savepoints for data recovery
■ 第五、支持基于统计数据管理文件大小和分布
Manages file sizes, layout using statistics
■ 第六、支持对基于行、列的数据进行异步压缩
Async compactiol of row & columnar data
■ 第七、支持时间轴元数据进行数据血统追踪
Timeline metadata to track lineage
■ 利用聚类优化数据湖布局
Optimize data lake layout with clustering
可以说，Hudi支持了数据湖的数据存储以及一定的管理功能。
2.3 应用场景
Apache Hudi作为Uber开源的数据湖框架，抽象了存储层（支持数据集的变更，增量处理）；为Spark的一个Lib（任意水平扩展，支持将数据存储至HDFS）；开源（现已在Apache顶级项目）。
■ 场景一：近实时摄取（Near Real-Time Ingestion）
■ 对于RDBMS摄取，Hudi通过Upserts提供了更快的负载；
■ 对于像Cassandra / Voldemort / HBase这样的NoSQL数据库，采用更有效的方法使得摄取速度与较频繁的更新数据量相匹配；
■ 对于像Kafka这样的不可变数据源，Hudi也会强制在DFS上保持最小文件大小，从而解决Hadoop领域中的古老问题以便改善NameNode的运行状况。
■ 对于所有数据源，Hudi都提供了通过提交将新数据原子化地发布给消费者，从而避免部分提取失败。
■ 场景二：增量处理管道（Incremental Processing Pipelines）
■ 通过记录粒度（而非文件夹或分区）来消费上游Hudi表HU中的新数据，下游的Hudi表HD应用处理逻辑并更新/协调延迟数据，这里HU和HD可以以更频繁的时间（例如15分钟）连续进行调度，并在HD上提供30分钟的端到端延迟。
■ 场景三：统一存储分析（Unified Storage For Analytics）
■ 将流式原始数据带到数据湖存储中，Hudi能够在几分钟内提取数据，并编写比传统批处理速度快几个数量级的增量数据管道，从而开辟了新的可能性。
■ Hudi没有前期服务器基础设施投资，因此可以在不增加运营开销的情况下，对更新鲜的分析进行更快的分析。
■ 场景四：数据删除（Data Deletion）
■ Hudi还提供了删除存储在数据湖中的数据的功能，而且还提供了处理大型写放大的有效方法，该写放大是由于用户通过基于user_id（或任何辅助键）的Merge On Read表类型进行的随机删除而导致的。
■ Hudi优雅的基于日志的并发控制，确保了提取/写入可以继续进行，因为后台压缩作业可分摊重写数据/强制执行删除的成本。
3 Hudi 发展及特性
Apache Hudi代表Hadoop Upserts anD Incrementals，管理大型分析数据集在HDFS上的存储。Hudi的主要目的是高效减少摄取过程中的数据延迟。
由Uber开发并开源，该项目在2016年开始开发，并于2017年开源，2019年1月进入 Apache 孵化器，且2020年6月称为Apache 顶级项目。目前发布5大版本，分别为0.5.x、0.6、0.7、0.8及0.9版本，各个版本功能特性说明如下。
3.1 Hudi 发展历史
从2015年提出增量处理数据模型思想开始，到至今Hudi发展成熟，经历如下几个阶段：
■ 2015 年：发表了增量处理的核心思想/原则（O’reilly 文章）
■ 2016 年：由 Uber 创建并为所有数据库/关键业务提供支持
■ 2017 年：由 Uber 开源，并支撑 100PB 数据湖
■ 2018 年：吸引大量使用者，并因云计算普及
■ 2019 年：成为 ASF 孵化项目，并增加更多平台组件
■ 2020 年：毕业成为 Apache 顶级项目，社区、下载量、采用率增长超过 10 倍
■ 2021 年：支持 Uber 500PB 数据湖，SQL DML、Flink 集成、索引、元服务器、缓存
国内大部分互联网公司都在使用Hudi数据湖框架，进行数据存储，管理数据。
1.3.2 Hudi 版本特性
自从Hudi进入Apache 孵化器项目，发展成为Apache顶级项目，每个版本增加很多新特性。
0.5.x 版本
Hudi 为Apache incubating孵化器项目以后，发布第一个版本从0.5开始，并且经过一年半以后称为Apache 顶级项目，主要就是介绍Hudi功能，修改一些Bug及新的特性，主要看看0.5.3版本，为Apache Hudi毕业后发布的第一个版本。
■ Hudi内置支持 aliyun OSS 对象存储；
■ 默认情况下将为delta-streamer和spark datasource写入启用Embedded Timeline Server；
■ 默认情况下为delta-streamer和Spark datasource写入均启用"增量清理(increment cleaning)"；
■ Hudi Hive Sync现在支持按日期类型列分区的表；
■ Hudi Hive Sync现在支持直接通过Hive MetaStore进行同步；
■ 完成Presto支持查询MoR类型表Hudi侧的改造；
0.6 版本
该版本为2020.08.25发布第一个Hudi 称为Apache 顶级项目大版本，主要为性能改进与提升。
■ 写入端改进
■ 对已有Parquet表进行迁移：支持通过Spark Datasource/DeltaStreamer引导已存在的Parquet表迁移至Hudi，同时可通过Hive，SparkSQL，AWS Athena进行查询（PrestoDB即将支持）；
■ bulk_insert支持原生写入，Hudi bulk_insert对输入进行排序以便优化文件大小并避免在并发写入DFS多分区时的内存溢出问题；
■ 支持一种新的索引类型hoodie.index.type=SIMPLE，对于updates/deletes覆盖表大多数数据的场景，会比BLOOM_INDEX更快。
■ DeltaStreamer工具支持摄取CSV数据源，同时可chain多个transformers来构建更灵活的ETL作业。
■ 支持Azure Data Lake Storage V2， Alluxio 和 Tencent Cloud Object Storage
■ 查询端改进
■ Spark DataSource支持MoR表的SNAPSHOT查询；
■ Hudi现在对MoR表支持使用HoodieCombineInputFormat；
■ 在HoodieROPathFilter中缓存MetaClient来加速Spark查询，这可以减少在S3上对Read-Optimized查询进行文件过滤的额外开销；
■ 易用性提升
■ 对Spark DAG赋名字以便更好的进行调试；
■ 新增Data Snapshot Exporter工具类，通过该工具类可将某一时刻的Hudi表导出为Parquet文件；
■ 支持通过CLI删除Savepoints；
■ 新增命令 export instants来导出instant元数据；
0.7 版本
该版本为2021.01.26发布新版本，增加对Flink/Java客户端支持及写入性能提升。
■ Clustering
■ 支持了对Hudi表数据进行Clustering（对数据按照数据特征进行聚簇，以便优化文件大小和数据布局），Clustering提供了更灵活地方式增加文件大小；
■ 有了Clustering特性，便可更快速地摄取数据，然后聚簇为更大的文件，实验数据表明查询性能可以提升34倍，文件数可以减少1020倍；
■ Metadata表
■ 支持了内部Metadata表，此表可存储索引数据，其他元数据信息等。
■ Metadata表的实现使用了Hudi MOR表，这意味着像其他任何Hudi表一样，可以被压缩（Compaction）、清理（Clean）、增量更新（incrementally updated）。
■ 测试有25W个文件的表，Metadata表相比使用Spark并发Listing要快2~3倍；
■ Flink/Java客户端
■ 完成了写入层的解耦，添加了Flink和Java客户端，现在你可以使用HoodieFlinkStreamer来消费Kafka中的数据，以写入Hudi的COW表中。
■ 写入端优化
■ 支持使用Spark3进行写入和查询，请注意使用scala 2.12版本的hudi-spark-bundle包；
■ Insert Overwrite/Insert Overwrite Table，0.7.0版本中新增了这两种操作类型，主要用于批处理ETL作业，该作业通常会在每次运行时覆盖整个表/分区。
■ 删除分区支持：对于使用WriteClient/RDD级别API的用户，Hudi提供了一个新的API来删除整个分区，而不是采用记录级别删除方式。
■ 新增DefaultHoodieRecordPayload解决乱序问题；
■ Hive同步，支持使用SlashEncodedHourPartitionValueExtractor同步小时分区至Hive中
■ 支持IBM云对象存储、Open Java 9版本。
■ 查询端优化
■ MOR增量查询（Spark Datasource），支持使用Spark datasource增量查询MOR表；
■ Metadata表支持File Listings，用户还可以将元数据表用于以下查询端，对于Hive，设置hoodie.metadata.enable = true会话 属性，对于使用SparkSQL查询注册的Hive表，请使用参数–conf spark.hadoop.hoodie.metadata.enable = true来允许从元数据中获取分区的文件列表，而非使用File Listing。
0.8 版本
该版本2021.04.06发布，称为Apache项目后第四大版本，主要提供与Flink友好支持及并发写。
■ Flink集成
■ 重新设计性能更好、扩展性更好、基于Flink状态索引的写入Pipeline；
■ 支持Flink写入MOR表；
■ Flink批量读取COW和MOR表；流式读取MOR表；
■ 同时支持了Hudi作为Source和Sink的Flink SQL Connector；
■ 在Hudi 0.8.0版本发布后，用户可以使用Flink1.11+体验上述所有新特性。
■ 并发写
■ 使用乐观锁并发控制支持多客户端并发写同一张表，支持文件级别乐观锁并发控制
■ 如两个commit(或写入客户端)同时写入一张表，如果两个commit修改的文件不相同，两个客户端的写入都可以成功，
■ 写入端改进
■ Flink客户端支持InsertOverwrite
■ Java客户端支持COW表
■ 查询端改进
■ 支持Spark Structured Streaming流式读取Hudi表
■ 改进Metadata Table的性能
■ 改进Clustering的性能
0.9 版本
该版本2021.08.25发布，称为Apache项目后第五大版本，主要提供Flink CDC和SparkSQL集成。
■ SparkSQL 支持
■ 添加对使用Spark SQL的DDL/DM 的支持
■ 可以使用 CREATE TABLE…USING HUDI 和 CREATE TABLE … AS SELECT 语句直接在 Hive 等目录中创建和管理表
■ 可以使用 INSERT、UPDATE、MERGE INTO 和 DELETE 语句来操作数据
■ INSERT OVERWRITE 语句可用于覆盖现有表或分区中的数据
■ Flink 集成
■ 写入支持 CDC Format的 MOR 表
■ Flink支持流式读取 COW 表
■ 通过支持不同的 Hive 版本
■ DeltaStreamer改进
■ JDBC Source 可以采用提取 SQL 语句并从支持 JDBC 的源中增量获取数据
■ SQLSource 使用 Spark SQL 语句从现有表中提取数据