基于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？

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