基于flink&hudi批流一体技术

一、业务背景及hudi

1.1业务背景

广告主和代理商通过广告投放平台来进行广告投放，由多个媒介进行广告展示 ，从而触达到潜在用户。整个过程中会产生各种各样的数据，比如展现数据、点击数据。其中非常重要的数据是计费数据，以计费日志为依据向上可统计如行业维度、客户维度的消耗数据，分析不同维度的计费数据有助于业务及时进行商业决策，但目前部门内消耗统计以离线为主，这种T+1延迟的结果已经无法满足商业分析同学的日常分析需求，所以我们的目标为：建设口径统一的实时消耗数据，结合BI工具的自动化配置和展现能力，满足业务实时多维消耗分析，提高数据运营的效率和数据准确性

1.2为什么需要HUDI

1.2.1传统技术选型存在哪些问题？

【离线方面】：
这种T+1延迟的结果已经无法满足商业分析同学的日常分析需求。

【实时方面】：
有些场景需要基于具有相同主键的多个数据源实时构建一个大宽表，数据源一般包括 Kafka 中的指标数据，以及 KV 数据库中的维度数据。

业务侧通常会基于实时计算引擎在流上做多个数据源的 JOIN 产出这个宽表，但这种解决方案在实践中面临较多挑战，主要可分为以下两种情况：

01 - 维表 JOIN
场景挑战：指标数据与维度数据进行关联，其中维度数据量比较大，指标数据 QPS 比较高，导致数据可能会产出延迟。
当前方案：将部分维度数据缓存起起来，缓解高 QPS 下访问维度数据存储引擎产生的任务背压问题。
存在问题：由于业务方的维度数据和指标数据时间差比较大，所以指标数据流无法设置合理的 TTL；而且存在 Cache 中维度数据没有及时更新，导致下游数据不准确的问题。

02 - 多流 JOIN
场景挑战：多个指标数据进行关联，不同指标数据可能会出现时间差比较大的异常情况。
当前方案：使用基于窗口的 JOIN，并且维持一个比较大的状态。
存在问题：维持大的状态不仅会给内存带来的一定的压力，同时 Checkpoint 和 Restore 的时间会变 得更长，可能会导致任务背压。

总结上述场景遇到的挑战，主要可归结为以下两点：
由于多流之间时间差比较大，需要维持大状态，同时 TTL 不好设置。
由于对维度数据做了 Cache，维度数据数据更新不及时，导致下游数据不准确。

1.1.2Hudi有什么优点？

基于 Hudi Payload 机制的多流拼接方案：
（Payload是一个条数据的内容的抽象，决定了同一个主键的数据的增删改查逻辑也决定了其序列化的方式。通过对payload的自定义，可以实现数据的灵活合并，数据的自定义编码序列化等，丰富Hudi现有的语义，提升性能。）

1.多流数据完全在存储层进行拼接，与计算引擎无关，因此不需要保留状态及其 TTL 的设置。
2.维度数据和指标数据作为不同的流独立更新，更新过程中不需要做多流数据合并，下游读取时再 Merge 多流数据，因此不需要缓存维度数据，同时可以在执行 Compact 时进行 Merge，加速下游查询。
3.支持离线场景和流批混合场景。
4.内置通用模板，支持数据去重等通用接口，同时可满足用户定制化数据处理需求。

1.3HUDI的应用场景

1.3.1什么场景适合使用hudi？

0. 具有相同主键的多个数据源构建一个大宽表；
1. 近实时DB数据入仓/湖：把原来T + 1的数据新鲜度提升到分钟级别；
2. 近实时OLAP：分钟级别的端到端数据新鲜度，同时又非常开放的OLAP查询引擎可以适配；
3. 近实时ETL；

1.3.2什么场景不适合使用hudi？

下游对时效性要求较高，对数据延迟容忍度较低；

1.4什么是HUDI？HUDI能做什么？

1.4.1什么是HUDI？

Hudi是Hadoop Updates and Incrementals的简写，它是由Uber开发并开源的Data Lakes解决方案。Hudi 用于管理的数据库层上构建具有增量数据管道的流式数据湖，同时针对湖引擎和常规批处理进行了优化。简言之，Hudi是一种针对分析型业务的、扫描优化的数据存储抽象，它能够使DFS数据集在分钟级的时延内支持变更，也支持下游系统对这个数据集的增量处理。

1.4.2Huid 功能和特性

功能：
1、Hudi是在大数据存储上的一个数据集，可以将Change Logs通过upsert的方式合并进Hudi；
2、Hudi 对上可以暴露成一个普通Hive或Spark表，通过API或命令行可以获取到增量修改的信息，继续供下游消费；
3、Hudi 保管修改历史，可以做时间旅行或回退；
4、Hudi 内部有主键到文件级的索引，默认是记录到文件的布隆过滤器；
特性：
1、Update/Delete记录：Hudi使用细粒度的文件/记录级别索引来支持Update/Delete记录，同时还提供写操作的事务保证。查询会处理最后一个提交的快照，并基于此输出结果。
2、变更流：Hudi对获取数据变更提供了一流的支持：可以从给定的时间点获取给定表中已updated/inserted/deleted的所有记录的增量流，并解锁新的查询姿势（类别）。
注意：

1. Apache Hudi 本身不存储数据，仅仅管理数据，借助外部存储引擎存储数据，比如HDFS、S3；
2. 此外，Apache Hudi 也不分析数据，需要使用计算分析引擎，查询和保存数据，比如Spark或Flink

1.4.3Hudi 基础架构

1.4.3.1概念

COW表（Copy On Write）：
在数据写入的时候，通过复制旧文件数据并且与新写入的数据进行合并，对 Hudi 的每一个新批次写入都将创建相应数据文件的新版本。

MOR表（Merge On Read）：
对于具有要更新记录的现有数据文件，Hudi 创建增量日志文件记录更新数据。此在写入期间不会合并或创建较新的数据文件版本；在进行数据读取的时候，将本批次读取到的数据进行Merge。Hudi 使用压缩机制来将数据文件和日志文件合并在一起并创建更新版本的数据文件。
总结：COW适用于读多写少的场景；MOR适用于写多读少的场景。

1.4.3.2原理

Hudi存储分为两个部分：
元数据：
.hoodie目录对应着表的元数据信息，包括表的版本管理(Timeline)、归档目录(存放过时的instant也就是版本)，一个instant记录了一次提交（commit）的行为、时间戳和状态，Hudi以时间轴的形式维护了在数据集上执行的所有操作的元数据；

数据：
和hive一样，以分区方式存放数据；分区里面存放着Base File(.parquet)和Log File(.log.*)；

MOR表数据组织架构：
数据构成关系：table -> partition -> FileGroup -> FileSlice -> parquet + log ；

1、通过DeltaStreammer、Flink、Spark等工具，将数据摄取到数据湖存储。
2、支持 HDFS、S3、Azure、云等等作为数据湖的数据存储。
3、支持不同查询引擎，如：Spark、Flink、Presto、Hive、Impala、Aliyun DLA。
4、支持 spark、flink、map-reduce 等计算引擎对 hudi 的数据进行读写操作。

二、架构选型

2.1Lambda架构

由于部门内在过去一段时间主要以离线数据分析为主，所以经过持续对数据仓库治理，现有离线数据平台能力为：

PB级数据计算能力：基于主流大数据技术栈构建数据基础设施，数据规模10PB+，日增数据量20T+，服务节点300+，日均提供2.5W+批次计算任务。

数据开发实现一站式: 自研数据研发平台集成数据同步/数据计算/数据存储/任务调度/数据发布等数据研发全链路，一站式完成数据开发。

数据治理初步实施：完成对数据的定义、开发、部署和调度进行全链路管控，强制保障数据仓库规范和元数据完整性，数据规范和数据治理初步实施。

基于此，初步规范的方案为：不改变原有离线数据架构，在现有离线数据架构链路上再增加实时计算链路，该方案所形成的架构为Lambda架构，是目前业界比较主流的整体数仓架构方案。

Lambda架构分为三层：离线处理层，实时处理层，对外服务层，对应图中的左下、左上和中间部分：

离线处理层 : 主要存储数据集，在数据集上进行离线批计算，构建查询所对应的数据。离线处理层可以很好的处理离线数据，并将数据输出至服务层中。当前离线消耗计算的过程为：当天所产生的实时计费数据会输出至HDFS文件中，在第二天作为离线处理的ODS数据源，参与后续数据清洗和维度数据ETL计算，并同步最细维度数据至数据服务层；

实时处理层: 实时处理层处理的是当天最近的增量数据流，具有较好的时效性。对应到实时消耗统计项目中，其过程为：kafka生产的实时计费日志作为数据源，由Flink计算引擎进行数据清洗，并将中间结果回写到kafka,最终将计算结果同步至数据服务层中；

对外服务层 : 见图中数据服务层，其用于合并离线处理层和实时处理层中的结果数据集到最终数据集，并提供对BI等对外服务接口。如基于对外服务层的数据，业务分析同学可以通过BI工具自助配置，快速分析多维数据，从而提高分析效率。

Lambda架构存在如计算稳定、数据易于订正等优点，但也存在很明显的缺点：
(1) 架构维护成本很高：存储框架不统一，计算框架不统一；
(2) 业务维护成本高：数据存在两份、schema不统一、 数据处理逻辑不统一(两份)
(3) Kafka不支持数据更新，只支持append，对延迟的数据无法更新之前的结果
(4) Kafka无法支持DWD等层表高效的OLAP查询

基于以上缺点，进一步探索其他可行性方案。

2.2批流一体架构

对Lambda架构缺陷进一步分析：
存储框架不统一：离线和实时计算采用的存储不统一，基于kafka的实时存储，无法满足即席的Olap查询，且存储能力有限，不支持海量存储。通过调研，可引入数据湖技术，实现离线数据和实时数据在存储层面的统一，数据湖的存储统一体现在用户不用关心底层真实存储，数据湖在真实存储上抽象TableFormat层，可将结构化或非结构化数据映射成数据表，实现存储上的统一；
计算框架不统一：离线计算框架所采用的spark\hive计算和实时计算框架flink导致计算框架多样，维护成本高，且需要开发不同计算框架对应的ETL，导致研发成本高；可统一采用flink计算框架，其支持流式和批处理API，解决高成本问题；

基于