1、概述
Hudi（Hadoop Update Delete Incremental）官网介绍是为数据湖之上提供事务反对、行级别更新 / 删除（Row Level Update/deletes）和变更流（Change Stream）的一个数据湖框架，最早是由 Uber 开发于 2016 年，2017 进入开源社区，并在 2020 年成为 Apache 顶级我的项目。本文会从 Hudi 诞生背景条件登程，搞清楚 Hudi 最后是为了解决什么问题而呈现的。
2、近实时场景需要
随着大数据技术的倒退，逐步倒退出了两种比拟成熟的计算模型：
一种是批处理模型，技术栈以 Hadoop 为代表，其特点是规模大，容错高，提早高，次要利用在离线的大规模剖析场景下；另一种是流解决模型，技术栈以 Strom/Flink 此类流解决框架为代表，其特点是提早非常低，次要利用在要求提早很低的实时场景下。这两种模型笼罩了绝大多数大数据的利用场景。
然而在流解决与批处理之间却存在一个含糊的边缘地带，即提早在 5 分钟~1 小时的范畴，在这个范畴内，既能够用批处理技术也能够用流解决技术，称为近实时（Near Real-time）需要。比方过来若干分钟某些维度指标的变动统计。
此类场景有有以下 3 个特点：
1、对提早度要求在亚小时级别。
2、数据来源于业务数据的统计分析（可能存在多表 join）。
3、数据在业务窗口期内会变动。
3、传统模型的解决形式
3.1、利用批处理解决近实时问题
批处理模型面向离线计算场景，须要将数据从业务数据库导入数仓中。这个阶段采纳 Select * From Where Condition 查问数据的形式。Condition 通常是工夫维度，并且抉择也会综合思考业务数据库的受影响水平来确定启动周期，个别抉择隔天的凌晨业务量小的时间段拉取前一天的数据。数据导入实现后，再进行计算作业。
当应用批处理模型来解决解决近实时场景需要时，须要将调度周期设置为 5 分钟~1 小时，这会带来一些问题。
3.1.1 业务数据库负载
Select * from Condition 是一个代价很大的操作，失常批处理都会抉择业务量小的时候进行，防止影响业务。若为了反对近实时业务而将工作距离设为每分钟或每小时，会对业务数据库产生十分大的压力，有可能对业务产生影响。
3.1.2 无奈疏忽的数据更新
同样是 Select 的问题，通过 SQL 查问数据的形式，获取变更数据须要额定的条件，并不是所有状况都能通过 select 取得变更数据。这在传统的离线解决场景下，产生的影响绝对较小。因为工夫范畴和启动周期都根本都在 24H 以上，绝大部分数据都不会再发生变化，且此时的数据量级为天级，数据量较大，即便有个别数据没有更新，对最终后果的影响水平也能够忽略不计。
然而在近实时场景下：因为启动周期的缩短，在这期间数据变动的概率大幅回升，同时数据总量在大幅缩小。此消彼长，最终后果的正确性就无奈失去保障。因而，在近实时场景下，批处理不反对数据更新的问题带来的影响，很有可能无奈被忽视。
3.2、利用流解决解决近实时问题
流解决次要用来应答提早要求低的实时计算场景，个别解决事件驱动的场景。因而，近实时场景天生能够间接应用流解决模型进行解决。但因为近实时场景的面向的事件工夫在 5 分钟 1 小时之间，相比拟于秒级工夫窗口的事件，利用流解决技术解决工夫窗口为 5 分钟 1 小时的数据时，会带来更大的老本。
3.2.1、更大的内存耗费
在解决业务数据库的 Changelog 中的 update/delete 语句时，须要基于对应的历史数据进行操作，这就须要将大量的数据载入内存中。而相比拟于解决秒级别的实时工作，近实时的工夫窗口因为在 5 分钟~1 小时之间，这会导致近实时工作须要数倍甚至数十倍于秒级实时工作的内存资源。
3.2.2、峰谷资源错配
因为须要实时处理，解决工作须要始终运行，占用的资源大于批处理所需的资源。当业务顶峰来长期须要更多的资源用于撑持业务，这部分资源在业务低谷期来长期，就可能无奈失去高效利用，如果是云上零碎还好，能够将资源开释，如果是自建机房，那么多进去的资源就有可能造成节约。
3.3、小结
应用批处理和流解决两种解决模型解决近实时问题时，都有着各自不同的问题。批处理有无奈漠视的数据更新解决问题；流解决付出的老本较高，能够说是用牛刀杀鸡。这就难免会让人陷入抉择。那是否有一种解决模型，可能刚好满足需要呢？带着这样的谋求，一种新的解决模型被提了进去。
4、增量解决模型
4.1、根本构造
增量解决模型面向近实时场景提出，它的根本构造能够认为是全量数据存储 + 增量数据处理。数据导入阶段采纳变更流捕捉将数据导入存储引擎中，在剖析计算阶段，查问增量数据进行后果计算
4.2、与传统解决模型的区别
4.2.1、与批处理的区别
与批处理相比，增量解决模型中的存储局部能够反对 Update/Delete。这就能够在将批处理中数据摄取的形式从本来的查问数据这一种，拓展为既能够查问数据也能够解决 Changelog。
4.2.2、与流解决的区别
与流解决相比，数据模型实质还是批，数据的解决须要周期性的导入和抽取计算，数据须要通过经验内存到磁盘再到内存的过程。
4.3、增量解决模型解决近实时场景的长处
既然增量解决模型面向近实时场景问题提出，那么增量解决在解决近实时场景时相比传统的两种解决模型具备哪些长处
4.3.1、可能应答数据变更
增量解决模型通过引入反对 Update/Delete 的存储引擎，具备了解决 changelog 的能力。在面对近实时场景中的变更数据流时，不会呈现数据无奈解决数据变更的问题
4.3.2、通过解决 Changelog 升高对业务库的影响
通过捕捉 changelog 来防止 Select 查问的形式来升高对数据库的影响。通常生产级别的业务数据库 (OLTP) 的日志在数据库自身就须要通过生成，解决，落盘归档，主从同步等一系列动作来保障生产级别的 HA。只须要额定的线程获取到 changelog 即可。此外，通常 changelog 只须要一条 EL 作业将其先导入 Kafka 中作为缓冲，增量模型的 EL 作业只须要生产 Kafka 中的 changelog 即可。相比拟于不定时的从业务数据库查问历史数据来说，负载大大降低。
4.3.3、通过批处理升高内存资源占用
增量解决模型将 changelog 写入存储引擎中，并从存储引擎查问须要剖析的数据，相比于流解决须要将数据加载至内存中，增量解决模型的数据不须要将数据加载至内存中。
4.3.4、通过微批计算取得更灵便的调度空间
微批的形式意味着数据导入和计算作业都不须要像流解决作业一样的继续运行，这也就留出了更多的可调度空间。在同样的计算资源下，借助正当的调度零碎能够同时包容更多的计算作业同时运行，为企业节省成本。
4.4、小结
增量模型能够说是一种非凡的批，也能够说是一种非凡的流。相比于流来说，它其实是周期性运行的批处理。相比拟于批来说，它具备了解决变更事件的能力。它在解决近实时场景需要时所体现出的长处，其实都是在谋求收益和老本之间的均衡。
5、总结
本文介绍了 Hudi 须要解决的问题—近实时场景的需要，并比拟了在大数据畛域中两种成熟的解决模型：流解决和批处理在解决此类场景中各自的不足之处。最初介绍了一种新的增量解决模型的解决形式。
增量解决模型以 CDC 的形式数据摄取，以微批的形式进行计算剖析，均衡了提早和老本。为了应答数据变更，须要引入数据更新 / 删除操作的反对。不难发现，其中的关键点就是在传统的大数据存储引擎之上提供数据更新 / 删除的能力，那么 Hudi 又是做了哪些具体的工作来反对增量解决的实现？请关注下期专题文章。
6、参考援用
- Uber’s case for incremental processing on Hadoop – O’Reilly (oreilly.com)
- Uber’s Big Data Platform: 100+ Petabytes with Minute Latency – Uber Engineering Blog
- Apache Hudi – The Data Lake Platform | Apache Hudi
- 《大数据流解决架构 | 滴普科技 FastData 系列解读》