干货|流批一体Hudi近实时数仓实践

前言

传统意义上的数据集市主要处理T+1的数据。随着互联网的发展，当前越来越多的业务场景对于数据时效性提出了更高的要求，以便及时快速地进行数据分析和业务决策，比如依托实时数据情况开展实时推荐、实时风控、实时营销等。特别是各种新技术的出现、发展和日趋成熟，实时数据分析和处理也成为可能。实时的大规模数据处理成为企业数字化转型过程中需要破解的难题，也是企业当前面临的一个普遍需求。

数据湖可以汇集不同数据源（结构化、非结构化，离线批数据、实时流数据）和不同计算引擎（流计算引擎、批处理引擎，交互式分析引擎、机器学习引擎），是未来大数据的发展趋势，目前Hudi、Iceberg和DeltaLake等开源湖组件开始吸引越来越多的互联网企业对其研究和探索。笔者基于对开源数据湖组件Hudi的研究和理解，思考在Iceberg、DeltaLake和Hudi等开源数据湖组件之上构建批流一体近实时数仓的可能性和思路。

Hudi是什么

Apache Hudi（Hadoop Upserts Deletes and Incrementals）由Uber开源，它可以以极低的延迟将数据快速摄取到HDFS或云存储（S3）的工具，是构建数据湖的开源产品之一。

当前大数据平台及集市与业务系统数据同步主要为批处理：业务系统导出数据全量文件，通过GTP等文件交换工具传输，批量导入大数据平台，大数据平台及集市才看到数据的更新从而进行OLAP。而Hudi将流处理引入到大数据处理中，实时地向Hadoop等大数据环境提供业务系统的增量数据，比传统批处理效率高几个数量级。Hudi可以支持Spark、Flink、Hive 、Presto等计算引擎，基于Hudi数据的近实时分析，时效性可以从T+1缩短到T+0。

针对当前行内大数据建设广泛应用Hadoop的现状，可以以HDFS作为Hudi的存储介质，通过Hudi构建近实时数据仓库。

Hudi为什么能支持近实时场景

Hudi提供了新的数据集，使流式处理大数据成为可能，相比批处理效率极大提升。Hudi作为湖组件有一些特性对基础环境的稳定性、加快数据检索及实时数据摄取及近实时分析而言较为关键。

1. 自动合并：Hudi自动异步合并小文件，对于流式摄取到HDFS的数据统一合并至相应分区，减少文件系统中小文件数目，减轻Namenode压力，保证Hadoop集群稳态运行。

2. 索引：Hudi实现了分区和索引，实现对HDFS文件内记录的快速定位。

3. 迁移：Hudi缩短了数据迁移的传输时间以及改变数据必须批量传输的模式，改变业务库以日终、月终批量导出，数据仓库再批量导入的方式，使数据同步从T+1缩短至T+0。

4. Timeline：在Hudi表的提交操作时点会记录在Timeline中,通过该Timeline选取时点或时间区间进行数据检索实现数据历史回溯。

5. 查询：Spark、Flink、Hive等可以对Hudi数据集进行查询操作。

6. 视图：Hudi提供增量、读优化、实时三类数据视图，三类视图基于提交合并数据集的历史版本信息可以回溯某个时点、某时间区间的数据集，保证了历史数据的可回溯性。

Hudi摄取（实时获取数据）

建设近实时数仓、近实时的OLAP，高时效的满足业务对数据的需求，依赖于数据的实时摄取。数据从业务库实时同步到仓内是必须要解决的问题。Hudi提供了DeltaStreamer工具，使得数据从Kafka等消息队列中入仓成为可能。

HoodieDeltaStreamer为Spark版实时摄取工具，提供了将HDFS或Kafka等不同来源数据摄取入仓的方式，以Spark作为摄取运行环境。为兼容Flink，Hudi0.7版本开始支持以Flink作为摄取运行环境，提供了HoodieFlinkStreamer工具。

该两个工具的入参类似，主要需要设置作为数据来源的消息队列Kafka的topic、仓的HDFS目的地址、Hudi表名、表Schema、Hudi表类型（MOR、COR）、MOR类型表是否需要压缩、Hudi表RecordKkey、Hudi表分区策略等配置项。

如需从Kafka中摄取某表数据，配置上述参数后，提交HoodieDeltaStreamer或HudiFlinkStreamer作业至Spark或Flink集群，可实现消息队列实时数据源源不断地实时摄取到Hudi表中。Hudi根据该表配置的分区策略，自动写入到HDFS对应分区目录下。分区下以Parquet文件格式，列式存储数据。根据作业配置的压缩机制等，实现数据压缩。

Hudi OLAP（近实时分析数据）

DeltaStreamer工具将数据源源不断地摄取入仓（HDFS），Hudi基于数据提交的时间将源源不断的摄取过程量化成Hudi数据表内的时间线并形成了三类逻辑视图。基于Hudi表的时间线和三类数据视图，可以对Hudi表进行全量的和增量的数据分析，或者换句话说可以基于Hudi内的同一张表进行批量和近实时的数据分析。Hudi目前支持的OLAP引擎有Spark、Flink、Hive、Presto等，这些引擎只需启动作业或命令行工具时装载Hudi的spark.bundle.jar、flink.bundle.jar、mr.bundle.jar等扩展包便可使用Hudi接口访问数据，从而实现通过上述OLAP引擎以读写Hudi。

近实时的数据分析方式，主要为Hudi表的增量读取，用户可以指定数据分区partition或_hoodie_commit_time查询分区或自该时间以来的全部更新的数据，并与其他表（主档）进行关联拼接聚合，将聚合结果写出到结果Hudi表或者消息队列中，实现近实时的数据分析并对接下游。

近实时数仓设想

构建的准实时数仓简言之为：实时增量摄取、近实时增全量分析、实现数据从T+1到T+0、从OLTP到OLAP。

01

近实时数仓部署架构思路

近实时数仓系统分为3个集群部署：

1. 数据摄取域通过云上或本地Spark或者Flink集群将上游的实时数据或者批量数据通过湖组件摄取接口摄取到HDFS中；

2. 数据存储域的Hadoop集群将数据以HDFS中.parquet文件的形式存储，并使用关系型数据库或者Hive等进行元数据管理和系统其它信息存储；

3. 数据计算域中的云上或本地Spark或者Flink集群通过对应的湖组件数据接口读取数据湖中的数据表并进行计算。

02

近实时数仓数据流转过程

通过Hudi构建近实时数仓，数据流转过程如下：

1. 业务数据库Oracle、Mysql日志等或者埋点等数据进入消息队列Kafka。

2. 通过Flink、Spark运行DeltaStreamer作业将这些Kafka实时数据摄取到HDFS等介质，生成并源源不断地更新Hudi原始表。

3. 按照数仓分层策略，通过Flink/Spark的ODS 作业对Hudi 表中原始增量数据进行加工，经过加工的数据回写到Hudi的ODS表中，实现原始数据生成明细数据（ODS）。此外，如需对明细数据做进一步的汇总，则继续在Hudi ODS表上启动通用数据建模的 Flink/Spark的CMD层和后续的ADS层作业，之后对接下游仓库、AI和BI应用。

03

批流一体

按照上述思路建设的近实时数仓同时还实现了批流一体：批量任务和流任务存储统一（通过Hudi/Iceberg/DeltaLake等湖组件存储在HDFS上）、计算统一（Flink/Spark作业）、开发统一（Flink/Spark）、业务逻辑统一（同一套逻辑分为批和流）。业务需求使用同一套加工逻辑开发代码，按照加工时效的粒度分为批和流两类加工，在统一的数据来源上在同一套计算环境分别进行批量和流式数据加工，四方面的统一保证批任务和流任务的数据结果一致性。

结语

在商业智能日趋重要的当前，及时的数据处理以辅助公司快速做出决策显得尤为重要，因此近实时数据服务是商业智能发展到一定阶段必然要提供的基础服务。将传统数据仓库统一建模和分层设计的思路与实时技术结合，建设近实时数据数仓，降低数据延迟，提升数据传输能力和数据分析能力。目前，Hudi、Iceberg、DeltaLake等技术处于快速迭代发展期，在这些开源数据湖技术基础上构建近实时数仓更多的新功能新特性有待进一步探索和实践，笔者将继续深化对所述技术的学习，并将传统数仓思路与之有机结合，探索符合我行发展需要的近实时数仓建设之路。

资源获取 获取Flink面试题，Spark面试题，程序员必备软件，hive面试题，Hadoop面试题，Docker面试题，简历模板等资源请去 GitHub自行下载 https://github.com/lhh2002/Framework-Of-BigData Gitee 自行下载 https://gitee.com/li_hey_hey/dashboard/projects