微信公众号微网站开发,wordpress增强型短代码,网站建制作公司,竞价推广教程简介#xff1a; 本文介绍了百信银行实时计算平台的建设情况#xff0c;实时数据湖构建在 Hudi 上的方案和实践方法#xff0c;以及实时计算平台集成 Hudi 和使用 Hudi 的方式。 本文介绍了百信银行实时计算平台的建设情况#xff0c;实时数据湖构建在 Hudi 上的方案和实践…简介 本文介绍了百信银行实时计算平台的建设情况实时数据湖构建在 Hudi 上的方案和实践方法以及实时计算平台集成 Hudi 和使用 Hudi 的方式。 本文介绍了百信银行实时计算平台的建设情况实时数据湖构建在 Hudi 上的方案和实践方法以及实时计算平台集成 Hudi 和使用 Hudi 的方式。内容包括 背景百信银行基于 Flink 的实时计算平台设计与实践百信银行实时计算平台与实时数据湖的集成实践百信银行实时数据湖的未来总结一、背景
百信银行全称为 “中信百信银行股份有限公司”是首家获批独立法人形式的直销银行。作为首家国有控股的互联网银行相比于传统金融行业百信银行对数据敏捷性有更高的要求。
数据敏捷不仅要求数据的准确性还要求数据到达的实时性和数据传输的安全性。为了满足我行数据敏捷性的需求百信银行大数据部承担起了建设实时计算平台的职责保证了数据快速安全且标准得在线送达。
受益于大数据技术的发展和更新迭代目前广为人知的批流一体的两大支柱分别是“统一计算引擎” 与 “统一存储引擎”。
Flink作为大数据实时计算领域的佼佼者1.12 版本的发布让它进一步提升了统一计算引擎的能力同时随着数据湖技术 Hudi 的发展统一存储引擎也迎来了新一代技术变革。
在 Flink 和 Hudi 社区发展的基础上百信银行构建了实时计算平台同时将实时数据湖 Hudi 集成到实时计算平台之上。结合行内数据治理的思路实现了数据实时在线、安全可靠、标准统一且有敏捷数据湖的目标。
二、百信银行基于 Flink 的实时计算平台设计与实践
1. 实时计算平台的定位
实时计算平台作为行级实时计算平台由大数据 IaaS 团队自主研发是一款实现了实时数据 ”端到端“ 的在线数据加工处理的企业级产品。
其核心功能具备了实时采集、实时计算、实时入库、复杂时间处理、规则引擎、可视化管理、一键配置、自主上线和实时监控预警等。目前其支持的场景有实时数仓、断点召回、智能风控、统一资产视图、反欺诈和实时特征变量加工等。并且它服务着行内小微、信贷、反欺诈、消金、财务和风险等众多业务线。
截止目前在线稳定运行的有 320 的实时任务且在线运行的任务 QPS 日均达到 170W 左右。
2. 实时计算平台的架构
按照功能来划分的话实时计算平台的架构主要分为三层
■ 1数据采集层
采集层目前主要分为两个场景
第一个场景是采集 MySQL 备库的 Binlog 日志到 Kafka 中。我行所使用的数据采集方案并没有采用业界普遍用的如 CanalDebezium 等现有的 CDC 方案。 1、因为我们的 MySQL 版本为百信银行内部的版本Binlog 协议有所不同所以现有的技术方案不能很好的支持兼容我们获取 Binlog 日志。 2、同时为了解决我们数据源 MySQL 的备库随时可能因为多机房切换而造成采集数据丢失的情况。我们自研了读取 MySQL Binlog 的 Databus 项目我们也将 Databus 逻辑转化成了 Flink 应用程序并将其部署到了 Yarn 资源框架中使 Databus 数据抽取可以做到高可用且资源可控。 第二个场景是我们对接了第三方的应用这个第三方应用会将数据写入 Kafka而写入 Kafka 有两种方式 1、一种方式是依据我们定义的 Json shcema 协议。
UMF协议{col_name:””,umf_id:,umf_ts:,umf_op_:i/u/d} 协议定义了 ”唯一 id””时间戳“ 和 ”操作类型“。根据此协议用户可以指定对该消息的操作类型分别是 insertupdate 和 delete以便下游对消息进行针对性处理。 2、另外一种方式用户直接把 JSON 类型的数据写到 kafka 中不区分操作类型。■ 2数据计算转换层
消费 Kafka 数据进行一层转换逻辑支持用户自定义函数将数据标准化做敏感数据的脱敏加密等。
■ 3数据存储层
数据存储到 HDFSKuduTiDBKafkaHudiMySQL 等储存介质中。 在上图所示的架构图中我们可以看到整体实时计算平台支持的主要功能有:
开发层面 1、支持标准化的 DataBus 采集功能该功能对于支持 MySQL Binglog 同步到 Kafka 做了同步适配不需要用户干预配置过多。用户只需要指定数据源 MySQL 的实例就可以完成到 Kafka 的标准化同步。 2、支持用户可视化编辑 FlinkSQL。 3、支持用户自定义 Flink UDF 函数。 4、支持复杂事件处理(CEP)。 5、支持用户上传打包编译好 Flink 应用程序。 运维层面 1、支持不同类型任务的状态管理支持savepoint。 2、支持端到端的延迟监控告警。
在实时计算平台升级迭代的过程中社区 Flink 版本之间存在一些向下不兼容的情况。为了平滑的升级 Flink 版本我们对计算引擎的多版本模块进行统一的抽象将多版本之间做了严格的 JVM 级别隔离使版本之间不会产生 Jar 包冲突Flink Api 不兼容的情况。 如上图所示我们将不同的 Flink 版本封装到一个独立的虚拟机中使用 Thrift Server 启动一个独立的 JVM 虚拟机每个版本的 Flink 都会有一个独立的 Thrift Server。在使用的过程中只要用户显示指定的 Flink 版本Flink 应用程序就会被指定的 Thrift Server 启动。同时我们也将实时计算的后端服务嵌入一个常用的 Flink 版本避免因为启动 Thrift Server 而占用过多的启动时间。
同时为了满足金融系统高可用和多备的需求实时计算平台也开发了多 Hadoop 集群的支持支持实时计算任务在失败后可以迁移到备集群上去。整体的方案是支持多集群 checkpointsavepoint支持任务失败后可以在备机房重启实时任务。
三、百信银行实时计算平台与实时数据湖集成实践
在介绍本内容之前我们先来了解一些我行目前在数据湖的现状。目前的实时数据湖我行依然采用主流的 Lambda 架构来构建数据仓库。 1. Lambda
Lambda 架构下数仓的缺点
同样的需求开发和维护两套代码逻辑批和流两套逻辑代码都需要开发和维护并且需要维护合并的逻辑且需同时上线计算和存储资源占用多同样的计算逻辑计算两次整体资源占用会增多数据具有二义性两套计算逻辑实时数据和批量数据经常对不上准确性难以分辨重用 Kafka 消息队列Kafka 保留往往按照天或者月保留不能全量保留数据无法使用现有的 adhoc 查询引擎分析。
2. Hudi
为了解决 Lambda 架构的痛点我行准备了新一代的数据湖技术架构同时我们也花大量的时间调研了现有的数据湖技术最终选择 Hudi 作为我们的存储引擎。
Update / Delete 记录Hudi 使用细粒度的文件/记录级别索引来支持 Update / Delete 记录同时还提供写操作的事务保证支持 ACID 语义。查询会处理最后一个提交的快照并基于此输出结果变更流Hudi 对获取数据变更提供了流的支持可以从给定的时间点获取给定表中已 updated / inserted / deleted 的所有记录的增量流可以查询不同时间的状态数据技术栈统一可以兼容我们现有的 adhoc 查询引擎 prestospark。社区更新迭代速度快已经支持 Flink 两种不同方式的的读写操作如 COW 和 MOR。在新的架构中可以看到我们将实时和批处理贴源层的数据全部写到 Hudi 存储中并重新写入到新的数据湖层 datalakeHive 的数据库。出于历史的原因为了兼容之前的数据仓库的模型我们依然保留之前的 ODS 层历史的数仓模型保持不变只不过 ODS 贴源层的数据需要从 datalake 层获取。 首先我们可以看到对于新的表的入仓逻辑我们通过实时计算平台使用 Flink 写入到 datalake 中新的贴源层Hudi 格式存储数据分析师和数据科学家可以直接使用 datalake 层的数据进行数据分析和机器学习建模。如果数据仓库的模型需要使用 datalake 的数据源需要一层转换 ODS 的逻辑这里的转换逻辑分为两种情况 1、第一种对于增量模型用户只需要将最新 datalake 的分区使用快照查询放到 ODS 中即可。 2、第二种对于全量模型用户需要把 ODS 前一天的快照和 datalake 最新的快照查询的结果进行一次合并形成最新的快照再放到 ODS 当前的分区中以此类推。
我们这么做的原因是对于现有的数仓模型不用改造只是把 ODS 的数据来源换成 datalake时效性强。同时满足了数据分析和数据科学家准实时获取数据的诉求。
另外对于原始的 ODS 存在的数据我们开发了将 ODS 层的数据进行了一次初始化入 datalake 的脚本。 1、如果 ODS 层数据每天是全量的快照我们只将最新的一次快照数据初始化到 datalake 的相同分区然后实时入 datalake 的链路接入 2、如果 ODS 层的数据是增量的我们暂时不做初始化只在 datalake 中重新建一个实时入湖的链路然后每天做一次增量日切到 ODS 中。 最后如果是一次性入湖的数据我们使用批量入湖的工具导入到 datalake 中即可。
整体湖仓转换的逻辑如图 3. 技术挑战
在我们调研的初期Hudi 对 Flink 的支持不是很成熟我们对 Spark - StrunctStreaming 做了大量的开发和测试。从我们 PoC 测试结果上看 1、如果使用无分区的 COW 写入的方式在千万级写入量的时候会发现写入越来越慢 2、后来我们将无分区的改为增量分区的方式写入速度提升了很多。
之所以会产生这个问题是因为 spark 在写入时会读取 basefile 文件索引文件越大越多读取文件索引就会越慢因此会产生写入越来越慢的情况。
同时随着 Flink 对 hudi 支持越来越好我们的目标是打算将 Hudi 入湖的功能集成到实时计算平台。因此我们把实时计算平台对 Hudi 做了集成和测试期间也遇到一些问题典型的问题有 1、类冲突 2、不能找到 class 文件 3、rocksdb 冲突
为了解决这些不兼容的问题我们将对 Hudi 的依赖重新构造了一个独立的模块这个工程只是把 Hudi 的依赖打包成一个 shade package。 4、当有依赖冲突时我们会把 Flink 模块相关或者 Hudi 模块相关的冲突依赖 exclude 掉。5、而如果有其他依赖包找不到的情况我们会把相关的依赖通过 pom 文件引入进来。在使用 Hudi on Flink 的方案中也遇到了相关的问题比如checkpoint 太大导致 checkpoint 时间过长而引起的失败。这个问题我们设置状态的 TTL 时间把全量 checkpoint 改为增量 checkpoint且提高并行度来解决。COW 和 MOR 的选择。目前我们使用的 Hudi 表以 COW 居多之所以选择 COW 1、第一是因为我们目前历史存量 ODS 的数据都是一次性导入到 datalake 数据表中不存在写放大的情况。 2、另外一个原因是COW 的工作流比较简单不会涉及到 compaction 这样的额外操作。
如果是新增的 datalake 数据并且存在大量的 update并且实时性要求较高的情况下我们更多的选择 MOR 格式来写尤其写 QPS 比较大的情况下我们会采用异步 compaction 的操作避免写放大。除了这种情况外我们还是会更倾向以 COW 的格式来写。
四、百信银行实时数据湖的未来
在我行实时数据湖的架构中我们的目标是将实时数仓的整个链路构建在Hudi之上架构体系如图 我们整体的目标规划是替代 kafka把 Hudi 作为中间存储将数仓建设在 Hudi 之上并以 Flink 作为流批一体计算引擎。这样做的好处有
MQ 不再担任实时数据仓库存储的中间存储介质而 Hudi 存储在 HDFS 上可以存储海量数据集实时数据仓库中间层可以使用 OLAP 分析引擎查询中间结果数据真正意义上的批流一体数据 T1 延迟的问题得到解决读时 Schema 不再需要严格定义 Schema 类型支持 schema evolution支持主键索引数据查询效率数倍增加并且支持 ACID 语义保证数据不重复不丢失Hudi 具有 Timeline 的功能可以更多存储数据中间的状态数据数据完备性更强。
五、总结
本文介绍了百信银行实时计算平台的建设情况实时数据湖构建在 Hudi 上的方案和实践方法以及实时计算平台集成 Hudi 和使用 Hudi 的方式。
在使用 Hudi 的过程中也遇到一些问题由衷感谢社区同学的帮助。特别感谢社区 Danny chanleesf 解疑答惑。在实时数据湖架构体系下构建我们实时数仓流批一体方案还是在摸索中。
仅以此篇希望能给其他正在建设实时计算平台和使用 Hudi 构建实时数据湖的同学提供一些参考。
原文链接 本文为阿里云原创内容未经允许不得转载。
