关于flink:中原银行对金融行业实时数仓的现状与发展趋势思考

近期举办的 2022 第四届实时计算 Flink 挑战赛中，在各位大佬的领导下，实现了本课题的设计和实际，当初把本计划的设计思路分享给大家，心愿通过本次教训分享能够为其它企业带来一点实时数据应用的新思路。

家喻户晓，实时数仓落地是一个难点，尤其是金融行业，还没有呈现真正所谓的实时报表。金融行业个别案例的实时数仓是在较窄场景、较多限度下的尝试，还不可能称之为实时数仓，如银行广泛的实时报表业务都无奈满足。以后亟需设计实现一套可能落地的金融行业的实时报表计划，来满足业务场景对数据时效性越来越高的需要。

本文内容首先介绍了银行业常见的实时场景和解决方案，而后针对银行业报表依赖维度表计算的特点，提出了基于 Flink Table Store 作为数据存储，进而构建流式数仓的解决方案。

在正式开始之前呢，简略介绍一下中原银行的根本状况。中原银行是河南全省惟一的省属法人银行，总资产冲破 1.2 万亿，在国内城市商业银行排名第 8 位。本团队是负责中原银行的实时计算业务，包含实时的采集、加工和剖析全链路。

一、金融行业实时数仓现状剖析

1.1 动账场景介绍

数仓建模有范式建模和维度建模，银行业采纳的是维度建模，其中分为事实表和维度表。

事实表：刻画行为的，个别用来统计交易笔数，交易金额，业务量等。

维度表：形容后果和状态的，常见的用户手机号、身份证号、所属的机构等不常常更新的数据，但其中银行业比拟重要的有“账户余额”，客户余额会随着动账交易而频繁更新。

本文以银行典型的动账场景为例，一次动账操作其实是一个事务，至多操作两张表，第一张比拟好了解，就是交易流水表，记录转账的一次行为；第二张则是用户的属性表，其中有一个字段是用户的余额，须要随着动账的交易流水表同步更新，下面的两个表是两次转账的示例。

在这个转账场景下进行剖析

流水表的特点：次要是 Insert 操作，记录行为信息，适宜增量计算，如统开户、取款、贷款、购买理财等事件行为。

利用的场景有实时营销，如大额动账揭示，工资代发，理财产品购买等；实时反欺诈的申请反欺诈、交易反欺诈；在贷后治理也有利用，如监控用户入账行为，提供给零贷贷后临期催收、扣款等。

客户属性表的特点：次要是 Update 操作，记属性信息，客户的贷款、贷款、理财、基金、保险等产品的余额是在维度表中，所以常应用维度表全量计算资产信息，如资产余额类的计算，计算某分支行的总贷款余额等。

利用的场景次要是实时报表、实时大屏：如对公 CRM、批发 CRM；经营治理；资产负债治理等。

针对于银行业这两种典型的动账场景，有三种解决方案。上面一一介绍不同计划实用的场景和有哪些局限。

1.2 基于 Kafka 的 ETL

该架构可能解决的问题，大多是基于事实表的增量计算，曾经在行内有大量的落地案例，但无奈解决银行业的基于维度表的全量计算。另外该计划很难造成规模化的数据分层复用，Kafka 存在数据无奈查问和长期长久化等问题。这种烟囱式的 case by case 开发阶段，本行曾经经验过了，生产上也有大量的落地场景，实时工作达到了 300+个。

1.3 基于微批的 ELT

为了解决银行业大量基于维度表的统计分析场景，来看一下进行了哪些形式的摸索。总结来说，是一种先载入后剖析，也就是 ELT 的形式。过程是这样的，先实时采集-> 而后间接实时载入->最初在实时 OLAP 查问阶段进行逻辑的加工。

在ELT摸索的的初期，咱们采纳过微批全量计算的形式，在数据实时地写入到数据库后，定时执行全量加工逻辑，相似于离线数仓有跑批的概念，只不过每天跑批缩短到了小时级别或分钟级别跑一次批，来达到准实时加工的成果。不言而喻，这种形式是不可取的，存在时效性差、跑批不稳固等问题。

1.4 基于视图的 ELT

随着 MPP 数据库的倒退，查问性能失去了极大的晋升，本行应用 StarRocks 引擎，通过 View 视图嵌套加工逻辑的形式也进行了摸索，也就是把业务数据库的数据以 CDC 形式，载入 MPP 数据库的明细层，查问剖析逻辑应用 View 封装，在查问触发时间接计算，这种形式也能够解决基于维度表的全量计算，但每次查问资源耗费太大，撑持大数据高频率的查问操作比拟艰难，无奈大范畴利用推广。

1.5 动账场景总结

基于事实表的增量计算曾经在生产进行了大量的落地和实际，本文次要是探讨银行业基于维度表的全量计算场景，上述两种解决方案尽管可能解决一部分实时场景，但局限很大，以后阶段来到了优化降级和将来方向抉择的节点。

为了解决银行业基于维度表的实时 OLAP，必须把局部计算向前挪动，在 Flink侧计算。湖存储 Flink Table Store 的呈现，使基于维度表的全量计算成为了可能。也就是底层一部分转化工作在Flink中计算，另一部分聚合计算等工作在 OLAP 数据库中计算，两者摊派一下计算工夫和资源耗费。在将来，还是心愿把全副加工逻辑，全副在Flink端分层实现，向着存算拆散、流批一体的流式数仓方向倒退。

二、基于 Flink Table Store 的金融行业流式数仓

2.1 Flink Table Store 介绍

2022 年公布的 Flink Table Store，可能很好地解决之前遇到的大量数据更新、全量存储等问题，Table Store 是一个对立的存储，用于在 Flink 中构建流式解决和批处理的动静表，反对高速数据摄取和疾速的数据查问。

是一种湖存储格局，存储和计算拆散，导入数据时双写到数据文件和日志零碎。
反对流批写入、流批读取，反对疾速 Update 操作。
还反对丰盛的 OLAP 引擎，Hive、Trino 等，以后 StarRocks 也在反对湖存储查问剖析，置信在不久的未来，StarRocks 也是可能反对查问 Flink Table Store。

理解详情，请移步到官网：https://nightlies.apache.org/flink/flink-table-store-docs-release-0.2/

2.2 导入数据

在银行业，业务数据库依然是以 Oracle 为主，全量数据初始化到 Flink Table Store 中，应用的 Oracle Connector 须要开发能力应用，同时须要反对 Filter、Project 等操作。采纳 JDBC 连贯以流式读取数据库的形式进行全量写入到 Flink Table Store 中，同时在建表配置项中配置 changelog-producer = input，保留残缺的 changelog，为后续流写和流读作筹备。

在实现了全量数据的初始化，后续增量的更新数据须要继续地写入到 Flink Table Store 中，首先从 Oracle 中把数据实时地抽取进去，以 JSON 格局写入到 Kafka，供后续多个场景复用 Topic。在银行业，数据库治理较为严格，可能实时获取业务数据比其它行业要解决更多方面的艰难。上面模仿一下动账过程：

客户表初始状态为客户 1、2、3 的余额别离为 100、200、300。
客户 1 转入 100 元，则客户表执行 Update 操作，使客户 1 的余额从 100 -> 200。
客户 2 转出 100 元，则客户表执行 Update 操作，使客户 2 的余额从 200 -> 100。
数据库的 Update 操作，应用 CDC 工具把 changelog 信息以 json 格局写入到 Kafka 队列。后续启动 Flink SQL 工作生产 Kafka，将 changelog 流写入到 Flink Table Store 中。

在拿到增量的 CDC 数据后，须要把增量更新数据和历史全量数据进行交融，才可能失去残缺最新的全量数据。这里有两个问题须要探讨：

第一：全量数据和增量数据为什么离开写入呢？

防止实时数据抽取多份，对立写入 Kafka，后续多个实时场景能够复用；
离线数据全量初始化可能是一个经常性的操作，比方每周进行一次全量的初始化。

第二：全量数据和增量数据如何保障连接正确呢？

维度表惯例状况下是有主键的表，这样就可能保障有幂等的个性，只须要保障增量数据早于全量数据就行了。比方增量数据5点开始启动写入到 Kafka，全量数据 6 点开始全量同步，增量写入工作在全量同步完结后开始指定早于 6 点的数据开始生产就能够保证数据的完整性了。

另外在写入 Flink Table Store 时须要配置 table.exec.sink.upsert-materialize= none，防止产生 Upsert 流，以保障 Flink Table Store 中可能保留残缺的changelog，为后续的流读操作做筹备。

2.3 查问数据

第一种形式，Batch模式。

历史存量和实时写入的数据，均可能在线 OLAP 剖析。反对流写批读，Batch 模式读取数据是从 Snapshot 文件中读取，checkpoint interval 周期内可见。反对多种查问引擎 Hive、Trino、Flink SQL 等，全局有序 Sorted File 的 Data Skipping，Sort Aggregation and Sort Merge Join 个性等。

这里能够任意工夫查看各个分支行的贷款余额，或者剖析客户的明细信息等。

第二种形式，Streaming 模式。

以 Streaming 模式启动查问时，工作会继续在线运行，当客户 1 进行转账操作时，如转入 100 元，变成了 200 元。此时在实时数仓产生的过程如下：

这个过程有如下特点：

流批对立。存储对立，Snapshot+Log，存量数据读取 Snapshot，增量数据读取 changelog，hybird 读取全量实时数据。查问对立，离线和实时应用雷同的 SQL 语句。Streaming 模式开启 mini-batch 缩小聚合语句的冗余changelog 输入。
缩小物化。FTS 中有残缺的 changelog，防止 Flink State 中生成物化节点。
时延较低。changelog 应用 File 存储，代价低，时延高；应用 Kafka 存储，代价高，时延低。
数据驱动，而不是工夫调度驱动或者查问时才开始触发计算。

2.4 导出数据

最终的后果数据，如果查问频率不高，能够间接应用 Flink 1.16 提供的 SQL Gateway 性能；如果查问频率较高，能够再以流式写出到内部的数据库中，提供稳固的在线服务能力。

2.5 将来倒退

实现真正端到端的流式数仓，既可能反对实时数据和残缺的 changelog，也反对批量导入离线数据，当数据在源头发生变化时就能捕捉到这一变动，并反对对它做逐层剖析，让所有数据实时流动起来，并且对所有流动中的数据都能够实时查问，是以纯流的形式而不是微批的形式流动。在这个过程中，数据是被动的，而查问是被动的，剖析由数据的变动来驱动。

数仓的分层能够解决实时数据的复用，多指标随着数据的实时流动而实时变动，从另一种角度说也是在用空间换取工夫。离线数据和实时数据独特存储在 Flink Table Store 中，应用便宜的存储和存算拆散更加灵便的进行弹性计算。离线剖析 sql 和实时剖析 sql 式齐全一样的，最终达到流批一体的成果。总结如下：

存算拆散的湖存储，FTS 提供欠缺的湖存储 Table Format，提供准实时 OLAP 剖析。
可能存储全量数据，每层数据可能可查，反对 Batch 和 Streaming 两种模式。
反对大量数据更新，有序的 LSM 构造，反对疾速的 Update 操作。
反对流批写流批读，尤其是可能流式读取，流式数据从 Log System 中读取。
残缺的 changelog，反对全副流程传递残缺的+I、-U、+U、-D 操作，缩小 Flink State 中的物化节点。
真正实现流批一体，流批对立 Flink SQL，流批对立存储。

那为什么不间接采纳这种架构进行构建呢？以后阶段这个架构还无奈齐全落地，比方其中聚合计算有大量的撤销动作、多个层之间的实时数据流动须要大量的资源和调试技能等，不过随着技术的倒退，置信流式数仓肯定会到来。

2.6 流式数仓落地停顿

以后阶段，既然多层的流式数仓落地还有肯定的间隔，那么在退出 Flink Table Store 后，在原有 ELT 架构的根底上，进行优化降级，看看带来了哪些变动。

在整个计算过程中，间接把原始数据写入 Flink Table Store，使之存储历史全量和实时更新的表数据，而后计算逻辑应用 Flink SQL 实现，最初把初步汇总的数据写入到 StarRocks 中。原始明细数据在 Flink 中计算，极大的缩小了 StarRocks 的计算逻辑，Flink 和 OLAP 引擎两者协调配合，独特提供端到端的实时报表业务。这种架构在咱们在生产上也曾经前进了初步的尝试，成果十分显著。

以对公 CRM 实时存贷款场景为例，该性能显示全行、分支行的实时存贷款状况。旨在为业务人员及客户经理提供一个能够随时查看行内总/分/支行及客户的存贷款等重要业务指标变动状况的性能，从而时刻把握行内资产最新情况。

扫码进入赛事官网理解更多信息：