中原银行
中原银行成立于年，是河南省唯一的省级法人银行，年在香港联交所主板上市，年5月经中国银保监会批准正式吸收合并洛阳银行、平顶山银行及焦作中旅银行。合并后总资产突破1.2万亿，在国内城市商业银行排名第八位。下辖18家分行、余家营业网点及17家附属机构，先后荣获“年度十佳城市商业银行”、“铁马十佳银行”、“最佳上市公司”等称号。近几年实时需求涌现，尤其是银行更加重视挖掘实时数据的使用与价值，主要表现在逐年增多的实时报表、实时大屏等面向BI的场景；还有实时指标或特征计算等面向AI的场景。
从技术角度，实时OLAP相较于传统OLAP发展起步较晚，多种多样的实时数据需求，对实时OLAP体系也提出了更高的要求。随着近年来技术迭代，如StarRocks、ClickHouse等支持实时OLAP场景的数据库也是推陈出新，对于解决银行业的实时场景带来了更多可能。
中原银行年首次引入实时计算业务，主要以代码开发为主。年开始系统的建设实时计算平台，以FlinkSQL开发实时业务，能够界面配置、启停、监控任务。年支持运行在K8s云平台上，能够手机小程序远程监控，承载的任务也达到了多个。年开始支持CDC同步场景，探索实时OLAP，承载的业务也达到了多个。年支持了最新的FlinkTableStore(ApachePaimon)湖存储，也引入了高性能的OLAP引擎StarRocks，探索实时报表场景，承载的业务也达到了00多个。
实时OLAP场景：当你存入一笔钱，银行的系统会有什么变化？以银行的典型动账场景为例，一次动账操作其实是一个事务，至少要操作两张表。第一张表是交易流水表，记录转账的一次行为；第二张则是用户的属性表，其中有一个字段是用户的余额，需要随着转账同步更新。
上图中的两个表是演示两次转账动作，该场景在12:00:01秒张三转入元，客户表张三的余额也从更新为。12:00:02秒，李四转出来元，客户表李四的余额也从元更新为元，在这个转账场景下进行分析。
流水表的特点，主要是insert操作，记录行为信息，适合增量计算，如统计开户、取款、贷款、购买理财等行为事件。基于Kafka的实时计算能够较好的解决该场景，比如实时营销包括大额动账提醒、工资代发、理财产品购买、申请反欺诈、交易反欺诈等。在贷后管理也有应用，如零贷贷后临期催收、扣款等。
客户属性表的特点，主要是update操作，记录属性信息，客户的总资产、贷款、理财、基金、保险等产品的余额是在维度表中，所以常使用维度表全量计算资产信息，如资产余额类的计算等。应用的场景主要是实时报表和实时大屏，比如对公CRM、零售CRM；经营管理；资产负债管理等。
在中原银行，基于事实表的场景基本上已经解决。但银行业的报表大多都基于维度表的统计分析，该场景也是银行业实时报表落地困难的关键因素之一。接下来主要探讨，基于维度表的实时全量计算场景。
以对公CRM实时存贷款场景为例：该业务面向总分行领导、支行行长、客户经理等，随时查看行内分支行及客户的存贷款情况，从而时刻掌握全行的资产最新状况。
实时场景仅有实时数据往往是不够的，需要配合离线数据才能计算出所需的业务数据。尤其是在银行体系下，面向规范化、精准化加工的传统离线数仓体系，能够较好的解决财务分析等场景，从该场景的数据角度来看，分为三个部分，实时数据、离线数据、实时查询分析数据，也就是在查询的时候才开始进行逻辑计算。
先来看一下实时数据，不断变化的有存款余额、贷款余额、应解汇款、实时汇率、新开账户等。离线数据主要包括员工信息、机构层级、归属关系等基本信息，还有离线跑批生成的年末月末余额、绩效关系、管户关系等。
这两部分数据均载入到实时OLAP引擎StarRocks，用户查询的时候在引擎内计算资产负债明细汇总，根据绩效关系对资产负债进行分组聚合。实时的存贷款和日终、月终进行比较，分支行根据存贷款进行排序等。对公CRM提供的查询功能有全行汇总、分支行汇总、分支行明细、分支行下转、客户明细、年末月末比较、趋势分析等。
了解了实时存贷款业务功能，再进一步详细拆解数据流程：
该案例的技术架构图，使用了实时的ELT
首先，实时数据全部来自于Oracle数据库，通过实时采集导入到Kafka。使用流计算平台，以CDC的形式写入到StarRocks，在其中构建全量和增量的数据。作为ODS原始层，离线数据在数仓中跑批生成，使用离线同步工具，百川平台以T+1的形式写入StarRocks，然后在StarRocks中使用view灵活的对数据进行转换处理。View视图可以随业务进行调整，上层应用直接查询封装好的视图实现即席查询。当用户进行点击的时候，触发原始的数据进行计算，如查询某分行的存款余额。该方案可以解决基于维表的实时全量计算场景，无需跑批，现场计算，端到端分钟级甚至秒级完成。尤其是在月末、季末等关键节点，给分支行的领导查询最新资产负债等信息带来了极大的便利。当然，该方案并不完美，缺点是当view的逻辑较为复杂，数据量较多时，查询性能影响较大，因此比较适合数据量不大、对QPS要求不高、灵活性要求较高的场景，且需要计算资源比较充足。该方案的探索也得出了一个宝贵的经验。虽然OLAP引擎性能强大，但仍然不能把所有的计算逻辑全部在引擎中执行，必须向前推移。但是Flink只有计算没有存储，这个问题该怎么解决呢？今年发布的FlinkTableStore(ApachePaimon)能够很好的解决之前遇到的问题。FlinkTableStore(ApachePaimon)是一个统一的存储，用于在Flink中构建流式处理和批处理的动态表，支持高速数据摄取和快速查询，是一种湖存储格式，存储和计算分离。还支持丰富的OLAP引擎生态，比如Hive等。我们还了解到StarRocks也支持数据湖查询，相信在不久的将来StarRocks也能够支持查询FlinkTableStore(ApachePaimon)。在加入FlinkTableStore(ApachePaimon)后，原有的ELT架构的基础上进行优化升级，带来了如下变化。
在流计算平台中，把原始数据写入FlinkTableStore(ApachePaimon)，实时存储历史全量和实时更新的表数据，然后计算逻辑使用FlinkSQL实现，最后把初步汇总的数据写入StarRocks中，原始明细数据在Flink中计算，极大减少了StarRocks的计算量。这种架构我们在生产上已经进行了初步尝试，效果非常显著。
中原银行OLAP全链路实时化架构从单一业务，上升到整体技术框架。中原银行的OLAP全链路实时化具体是怎么做的呢？承载哪些业务或者使用了哪些组件？最下面是数据源，分为了四类实时数据，分别是业务的数据库数据、客户的行为埋点数据、网络流量日志类数据、应用消息直接产生的数据。所有数据均打入Kafka，供后续的实时计算平台使用。中间是实时计算平台，加工逻辑使用FlinkSQL和自定义函数处理，Flink任务运行在Yarn或K8s上。当前主要推广运行在云环境上。使用Kafka和FlinkTableStore(ApachePaimon)作为数据的传输和存储，维表统一使用Elasticsearch提供。再往上来到了数据服务层，提供在线服务的同时，需要支持实时数据的写入，常用场景是直接写入业务目标数据库Oracle或MySQL提供在线服务。大多数场景数据是写入公共的Elasticsearch或者StarRocks，提供查询或者在线分析服务。后期也会提供直接对FlinkTableStore(ApachePaimon)的查询。针对全链路中的“典型ETL链路”和“实时查询”详细分享下。当前银行业的数据库主要还是Oracle，采用商业的AttunityReplicate实时采集数据。该工具提供全量和增量的实时同步，秒级时延，数据以JOSN格式统一写入Kafka，以便复用topic。也可以按照主键哈希顺序写入topic，以保证分区有序性。
然后基于FlinkSQL构建的实时计算平台进行业务逻辑处理，统一使用Elasticsearch作为维表，关联离线和实时的数据。这里没有选择Hbase和Redis作为维表是因为他们只能主建关联，构建二级索引又比较麻烦。另一方面，维表数据量最大也就是千万级别，使用Elasticsearch能够满足所有场景。
最后数据实时写入StarRocks中，StarRocks支持快速update，提供高效OLAP的能力，能够应对多种查询场景。这个典型的ETL链路对于事实表的行为分析有很好的效果，比如用来统计交易笔数、交易金额、业务量等指标。不管是在数据加工阶段，还是在查询分析阶段，实时数据主要是写入Oracle、MySQL、Elasticsearch、StarRocks等。
以StarRocks为例，写入的既有离线数据，也有实时数据。既有写入ODS层明细层数据，也有计算汇总后的ADS层汇总数据。StarRocks作为一款MPP架构的高性能数据库，能够支撑PB级的数据量，拥有灵活的建模方式，可以通过向量化引擎、物化视图、位图索引、稀疏索引等手段构建统一的数据存储系统。
中原银行搭建了一站式商业智能BI平台，该平台有客户行为分析系统-知秋、一站式报表平台-鲁班、一站式大屏-鸿图、自助分析平台-云间、一站式活动运营平台-智赢等系统，还会加大对TableStore的投入，作为实时数据的统一存储。
未来，中原银行还会携手StarRocks继续深入改造与优化包括数据分析平台在内的数据平台架构，挖掘更多业务场景下的实时报表，进一步探索优化OLAP性能，在StarRocks上实现极速分析与极速数据湖分析以提高用数效率并赋能业务增长与银行管理，迈向极速统一.0时代。