近期举行的 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。
了解详情，请移步到官网：nightlies.apache.org/flink/flink…
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 实时存借款场景为例，该功用显示全行、分支行的实时存借款情况。旨在为事务人员及客户经理供给一个可以随时查看行内总/分/支行及客户的存借款等重要事务目标改变情况的功用，然后时间把握行内财物最新情况。
扫码进入赛事官网了解更多信息：
