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、参考引用
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。