关于后端:中原银行-OLAP-架构实时化演进

5次阅读

共计 7539 个字符，预计需要花费 19 分钟才能阅读完成。

摘要：本文整顿自中原银行数据信息部杜威科，在 Flink Forward Asia 2022 行业案例专场的分享。本篇内容次要分为四个局部：

OLAP 实时化建设背景

OLAP 全链路实时化

OLAP 实时化摸索

将来摸索方向

点击查看原文视频 & 演讲 PPT

中原银行成立于 2014 年，是河南省惟一的省级法人银行，2017 年在香港联交所主板上市，2022 年 5 月经中国银保监会批准正式排汇合并洛阳银行、平顶山银行及焦作中旅银行。合并后总资产冲破 1.2 万亿，在国内城市商业银行排名第八位，下辖 18 家分行、700 余家营业网点及 17 家从属机构，先后荣获“年度十佳城市商业银行”、“铁马十佳银行”、“最佳上市公司”等名称。

近几年实时需要涌现，尤其是银行更加器重开掘实时数据的应用与价值。次要体现在逐年增多的实时报表、实时大屏等面向 BI 的场景。还有实时指标或特色计算等面向 AI 的场景。从技术角度，实时 OLAP 相较于传统 OLAP 倒退起步较晚，多种多样的实时数据需要对实时 OLAP 体系也提出了更高的要求。随着近年来技术迭代，如 StarRocks、ClickHouse 等反对实时 OLAP 场景的数据库也是新陈代谢，对于解决银行业的实时场景也带来了更多可能。

银行业想要获取实时报表数据，这样根本的 OLAP 场景须要解决哪些艰难呢？

首先须要全链路实时化。全链路是指数据实时采集、实时剖析、实时写入数据库以及实时提供查问剖析。整个链路的实时化相较于传统的 OLAP，各个环节均有一些难点须要克服。比方受到银行记账模型无奈变更、数据库治理严格、数据安全要求较低等多方面的限度，以后金融行业数据实时采集也不是一路畅通的。另一方面来说，对于流计算业务，实时计算面临数据源多、整合艰难、技术简单、监控运维老本较低等问题。业务需要也往往波及多个数据部门配合，多种业务类型交错，一旦流计算工作呈现问题，监控剖析排查也会比拟艰难。

其次，从生产实践得悉，实时场景仅有实时数据往往是不够的，须要配合离线数据能力计算出所需的业务数据。尤其是在银行体系下，面向规范化、精准化加工的传统离线数仓体系，可能较好的解决财务剖析等场景，且在很长时间内仍是支流计划。离线数据加工的复杂度往往也较高，以后阶段尚无奈达到全副业务数据的实时化计算。

最初，广泛依赖维度表。家喻户晓，在 kimball 维度建模中，分为事实表和维度表。在我行，基于事实表的场景基本上曾经解决。但银行业的报表大多都基于维度表的统计分析，该场景也是银行业实时报表落地艰难的关键因素之一。

为了解决该场景，我行进行了大量的生产实践，但仍未有较好的解决落地计划。心愿随着实时技术的倒退可能彻底解决该场景。

首先介绍一下实时化的演进历程，对整个倒退过程和将来的方向有一个概括性的理解。

第一阶段：起步。基于 Kafka 的实时 ETL，包含实时采集、实时加工、实时载入、实时 OLAP。该架构可能解决的问题大都是基于事实表的统计分析，曾经在行内有大量的落地案例，但无奈解决银行基于维度表的统计分析。另外，该计划很难造成规模化的数据分层复用，Kafka 数据无奈查问和长期长久化等问题也比较突出。
第二阶段：摸索。为了解决银行业大量基于维度表统计分析场景，先载入后剖析，也就是 ELT 的形式。过程是先实时采集，而后不进行逻辑加工间接实时载入，最初再实时 OLAP 查问阶段进行逻辑加工。
- 在 ELT 摸索初期，咱们采纳过微批全量的形式，在数据实时写入到数据库后，定时执行全量加工逻辑，相似于离线数仓跑批的概念。只不过是从每天跑批缩短到了小时级别，甚至分钟级别，达到准时加工的成果。不言而喻这种形式不可取，存在时效性差、跑批不稳固等问题。
- 随着 MPB 数据库的倒退，查问性能也失去了极大的晋升。应用 View 视图嵌套加工逻辑的形式也进行了摸索，也就是把业务数据以 CDC 的形式载入 MPP 数据库的明细层，剖析查问逻辑应用 View 封装，在查问时触发底层计算。这种形式也能够解决维度表的统计分析，但每次查问资源耗费太大，无奈大范畴推广。这种 ELT 形式尽管可能解决一部分的实时场景，但局限很大。
第三阶段：优化。接下来到了优化降级和将来方向抉择的节点。为了解决银行业基于维度表的实时 OLAP，必须把局部计算向前挪动到 Flink 计算。数据湖 Flink Table Store(Apache Paimon) 的呈现，使基于维度表的全量统计分析成为了可能。也就是后期一部分的加工工作在 Flink 中实现，另一部分聚合等计算工作在 OLAP 数据库中实现，两者摊派了计算的工夫耗费。
第四阶段：将来。在将来还是心愿可能把全副加工逻辑在 Flink 端实现，向着存算拆散流批一体的流式数仓方向倒退。

全链路实时化具体是怎么做的呢？承载哪些业务或者应用了哪些组件呢？上图咱们从下往上看。最上面是数据源，分为了四类实时数据，别离是业务的数据库数据、客户的行为埋点数据、网络流量日志类数据、利用音讯间接产生的数据。所有数据均打入 Kafka，供后续的实时计算平台应用。

两头是实时计算平台，加工逻辑应用 Flink SQL 和自定义函数解决，Flink 工作运行在 Yarn 或 K8s 上，以后次要推广运行在云环境上。应用 Kafka 和 Flink Table Store(Apache Paimon) 作为数据的传输和存储，维表对立应用 ES 提供。在银行业维表应用比拟广泛，同一张维度表可能应用其中的多列进行关联，且维度表往往须要实时的，如在新开户场景。在咱们平台上，应用频率较高的维表，援用次数达 60 屡次。

再往上来到了数据服务层，提供在线服务的同时须要反对实时数据的写入，罕用场景是间接写入业务指标数据库 Oracle 或 MySQL 提供在线服务。大多数场景数据是写入公共的 ES 或者 StarRocks，提供查问或者在线剖析服务，前期也会提供间接对 Flink Table Store(Apache Paimon) 的查问。

最上层是各个业务场景的实时数据需要，如实时反欺诈、实时营销、数据安全行为剖析、实时报表等场景。

右边的数据源有关系型数据库 Oracle、MySQL，还有在起步阶段的国产 OceanBase。银行以后次要应用的还是 Oracle，咱们采纳商业的实时数据采集工具 Attunity Replicate，该工具在部署形式、抽取数据的时延和吞吐体现优良。对多数 MySQL 采纳了开源的 Flink CDC 工具，该工具满足各个场景的需要。明年行内将大范畴推广国产的 OceanBase 数据库，其自带的 OMS 数据迁徙工具是抽取该库的最好抉择。

这几种关系数据库均采纳 JOSN 格局，全副写入 Kafka 中。对于手机银行、微信银行等用户行为埋点数据，应用的是商业神策平台提供的能力。实时计算平台间接从神策的 Kafka 进行数据生产。交换机的流量镜像等日志通过报文解析后也间接写入 Kafka，这部分的实时流量是最大的。另外还有大量产品是把相干的实时数据间接写入 Kafka。

对于 Kafka 中的 topic，也有多种形式适配不同的数据场景。对于关系型数据库，一张表对应一个 topic。对于用户行为，采纳大宽表的模式把所有数据都写入同一个 topic。采纳 Kafka 作为对立对接上游流计算平台，达到复用 topic 的目标，如外围的交易流水表复用了三十屡次。

通过介绍发现不同场景的实时数据最优的采集工具也不同，通过各种采集工具抽取了各个业务部门的数据，但海纳百川，都须要流入 Kafka 对接后续的实时计算。

最初抛出来一个疑难，对于纷繁复杂的数据源，大家是如何对立治理起来的呢？

2018 年首次引入实时计算业务，次要以代码开发为主。2019 年开始零碎的建设实时计算平台，以 Flink SQL 开发实时业务，可能界面配置、启停、监控工作。2020 年反对运行在 K8s 云平台上，可能手机小程序近程监控，承载的工作也达到了 100 多个。2021 年开始反对 CDC 同步场景，摸索实时 OLAP，承载的业务也达到了 200 多个。2022 年反对了最新的 Flink Table Store(Apache Paimon) 湖存储，也引入了高性能的 OLAP 引擎 StarRocks，摸索实时报表场景，承载的业务也达到了 300 多个。

这几年实时工作的运行现状如下：

实时工作个数 380+，以每年 100+ 的速度稳步增长。撑持了二十多个项目组的业务需要。日均解决数据行数 50 亿 +，日均接收数据量 20T+。

这么多的实时工作多种多样，如流量日志计算指标，数据量大但逻辑简略；监控用户账户信息，数据量小但援用维表个数较多；监控用户行为埋点数据，应用了 CEP 进行简单事件处理。

显然数据加工实时化在链路中处于要害地位，平台化也可能升高应用门槛，放慢开发效率。用户可能像应用一般的 SQL 一样，对实时的数据进行解决，不须要关注流计算底层简单的处理过程，极大地升高了实时数据开发的门槛。

其中次要的性能有数据源治理、实时工作开发、工作运维监控、项目管理、集群治理等性能。在实时工作开发模块中，次要有数据源配置、源表 / 维表 / 后果表配置、SQL 开发、自定义函数、SQL 语法检测，包含上线过程中须要的导出和导入性能。

在工作运维中有收发统计、集群资源监控、异样短信告警、近程小程序监控等，同时具备企业级的权限治理、租户治理等性能。该平台涵盖了实时数据开发的全生命周期，平台化能够彻底躲避沉重的底层流计算解决逻辑，繁琐的提交过程等。为用户打造一个只须要关注实时计算逻辑的平台，助力企业向实时化、智能化大数据转型。

后面也曾经提到了，实时计算的场景往往离不开离线数据，不论是在数据加工阶段，还是在查问分析阶段，实时数据次要是写入 Oracle、MySQL、ES、StarRocks 等。

以 StarRocks 为例，写入的既有离线数据，也有实时数据。既有写入 ODS 层明细层数据，也有计算汇总后的 ADS 层汇总数据。StarRocks 作为一款 MPP 架构的高性能数据库，可能撑持 PB 级的数据量，领有灵便的建模形式，能够通过向量化引擎、物化视图、位图索引、稠密索引等伎俩构建对立的数据存储系统。

我行搭建了一站式商业智能 BI 平台，该平台有客户行为剖析零碎——知秋、一站式报表平台——鲁班、一站式大屏——鸿图、自助剖析平台——云间、一站式流动经营平台——智赢等零碎，将来还会加大对 Table Store 的投入，作为实时数据的对立存储。

接下来咱们看一下典型 ELT 链路的工作过程。以后银行业的数据库次要还是 Oracle，采纳商业的 Attunity Replicate 实时采集数据。该工具提供全量和增量的实时同步，秒级时延，数据以 JOSN 格局对立写入 Kafka，以便复用 topic。也能够依照主键哈希程序写入 topic，以保障分区有序性。

而后基于 Flink SQL 构建的实时计算平台进行业务逻辑解决，对立应用 ES 作为维表，关联离线和实时的数据。这里没有抉择 Hbase 和 Redis 作为维表是因为他们只能主建关联，构建二级索引又比拟麻烦。另一方面，维表数据量最大也就是千万级别，应用 ES 可能满足所有场景。

最初数据实时写入 StarRocks 中，StarRocks 反对疾速 update，提供高效 OLAP 的能力，可能应答多种查问场景。这个典型的 ETL 链路对于事实表的行为剖析有很好的成果，比方用来统计交易笔数、交易金额、业务量等指标，但对于维度表的剖析却无能为力，比方计算分支行贷款余额场景。

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

上图中的两个表是演示两次转账动作，该场景在 12:00:01 秒张三转入 100 元，客户表张三的余额也从 100 更新为 200。12:00:02 秒，李四转进去 100 元，客户表李四的余额也从 200 元更新为 100 元，在这个转账场景下进行剖析。

流水表的特点，次要是 insert 操作，记录行为信息，适宜增量计算，如统计开户、取款、贷款、购买理财等行为事件。方才提到的典型的基于 Kafka 的实时计算可能较好的解决该场景，比方实时营销包含大额动账揭示、工资代发、理财产品购买、申请反欺诈、交易反欺诈等。在贷后治理也有利用，如零贷贷后临期催收、扣款等。

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

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

接下来次要探讨的是基于维度表的实时全量计算场景。以在行内落地的对公 CRM 实时存贷款场景为例，来解说一下波及哪些方面的工作。对公 CRM 实时存贷款性能面向总分行领导、支行行长、客户经理等，能够随时查看行内分支行及客户的存贷款状况，从而时刻把握全行的资产最新情况。

从数据的角度来看，分为三个局部，实时数据、离线数据、实时查问剖析数据，也就是在查问的时候才开始进行逻辑计算。

先来看一下实时数据，一直变动的有贷款余额、贷款余额、应解汇款、实时汇率、新开账户等。方才提到实时场景往往离不开离线数据一起进行配合计算，离线数据次要包含员工信息、机构层级、归属关系等根本信息，还有离线跑批生成的年末月末余额、绩效关系、管户关系等。

这两局部数据均载入到实时 OLAP 引擎，用户查问的时候在引擎内计算资产负债明细汇总，依据绩效关系对资产负债进行分组聚合。实时的存贷款和日终、月终进行比拟，分支行依据存贷款进行排序等。对公 CRM 提供的查问性能有全行汇总、分支行汇总、分支行明细、分支行下转、客户明细、年末月末比拟、趋势剖析等。

理解了实时存贷款业务性能，上面咱们来看一下是如何实现的。上图是该案例的技术架构图，也就是应用了实时的 ELT。

首先，实时数据全副来自于 Oracle 数据库，通过实时采集导入到 Kafka。应用流计算平台，以 CDC 的模式写入到 StarRocks，在其中构建全量和增量的数据。作为 ODS 原始层，离线数据在数仓中跑批生成，应用离线同步工具，百川平台以 T+1 的模式写入 StarRocks，而后在 StarRocks 中应用 view 灵便的对数据进行转换解决。View 视图能够随业务进行调整，下层利用间接查问封装好的视图实现即席查问。当用户进行点击的时候，触发原始的数据进行计算，如查问某分行的贷款余额。

该计划能够解决基于维表的实时全量计算场景，无需跑批，现场计算，端到端分钟级甚至秒级实现。尤其是在月末、季末等要害节点，给分支行的领导查问最新资产负债等信息带来了极大的便当。

当然，该计划并不完满，毛病是当 view 的逻辑较为简单，数据量较多时，查问性能影响较大，因而比拟适宜数据量不大、对 QPS 要求不高、灵活性要求较高的场景，且须要计算资源比拟短缺。

该计划的摸索也让咱们得出了一个贵重的教训。尽管 OLAP 引擎性能弱小，但依然不能把所有的计算逻辑全副在引擎中执行，必须向前推移。然而 Flink 只有计算没有存储，这个问题该怎么解决呢？具体有哪些方面的艰难呢？上面来剖析一下。

想要解决基于维度表的实时全量计算，存储须要以下三个能力。

第一、存储全量数据，并反对疾速更新。维度表有大量的更新操作，比方在结息日源库进行跑批的时候。
第二、反对流批写、流批读，尤其是流读。流读是数据驱动计算剖析，只有可能流读能力应用数据主动计算剖析，而不是应用微批调度或者查问时触发剖析计算。
第三、反对存储“残缺”的 changelog。残缺的数据库日志存储是数据驱动计算正确性的重要保障。

往年公布的 Flink Table Store(Apache Paimon) 可能很好的解决之前遇到的问题。Flink Table Store(Apache Paimon) 是一个对立的存储，用于在 Flink 中构建流式解决和批处理的动静表，反对高速数据摄取和疾速查问，是一种湖存储格局，存储和计算拆散。导入数据时双写到数据文件和日志零碎，并且反对流批写入、流批读取，反对疾速 update 操作。还反对丰盛的 OLAP 引擎生态，比方 Hive 等。我还理解到 StarRocks 也在反对数据湖查问，置信在不久的未来 StarRocks 也可能反对查问 Flink Table Store(Apache Paimon)。

在退出 Flink Table Store(Apache Paimon) 后，原有的 ELT 架构的根底上进行优化降级，带来了如下变动。

在流计算平台中，把原始数据写入 Flink Table Store(Apache Paimon)，实时存储历史全量和实时更新的表数据，而后计算逻辑应用 Flink SQL 实现，最初把初步汇总的数据写入 StarRocks 中，原始明细数据在 Flink 中计算，极大缩小了 StarRocks 的计算量。

这种架构咱们在生产上曾经进行了初步尝试，成果十分显著。但这并不是起点，上图展现的就是将来的蓝图，咱们将朝着流式数仓的方向进行演进。流式数仓可能反对存储全量的数据和残缺的 changelog，也反对批量导入离线数据。应用便宜的存储和存算拆散，可能更加灵便的进行弹性计算。

数仓的分层能够解决实时数据的复用，多指标随着数据的实时流动而实时变动，数据被动的变动驱动剖析，从另一个角度说也是在应用空间换取工夫。当数据在源头发生变化时就可能即刻捕捉到，让所有数据实时的流动起来，并且对所有流动中的数据都能够进行实时或批量的查问。

离线数据和实时数据独特存储在 Flink Table Store(Apache Paimon) 中，离线剖析 SQL 和实时 SQL 齐全一样，最终达到流批一体的成果。那么为什么当初不间接采纳这种架构进行构建呢？以后阶段这个架构还无奈落地，比方其中聚合计算有大量的撤销动作，多个档次间的实时数据流动也须要大量的资源和调试技能，不过我置信流式数仓肯定会到来。

点击查看原文视频 & 演讲 PPT

流动举荐

阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
0 元试用实时计算 Flink 版（5000CU* 小时，3 个月内）
理解流动详情：https://click.aliyun.com/m/1000372333/

正文完