《Apache Flink 案例集（2022版）》——5.数字化转型——工商银行-工商银行实时大数据平台建设历程及展望（1） https://developer.aliyun.com/article/1227993

应用场景

接下来介绍一些工行实施大数据平台的应用场景，主要包括余额提醒、损益预查询、实时大屏和实时对帐中心等四个方面。

在余额变动场景，客户进行一次动账交易，可能触发多种通知内容，例如账户支出提醒、账户收入提醒、积分消费提醒等，造成客户手机连续收到短信提醒，用户体验不佳。因此，工行基于 Flink 多流合并和会话窗口的能力，将同一时刻发生的多条消息关联，将通知的逻辑合并在一起发送给客户。而当一条消息出现晚到的情况，通过会话窗口的 GAP 设置能自动降级，将逻辑分为两条消息发出去。大幅提升对用户的友好性。

每家商业银行在每年 12 月 31 日时需要出年报，所以那天银行需要对全年的利润分配等指标进行试算。工行和其它商业银行一样早期使用 DB2 主机实现核心交易，年终时的损益、预查询都在主机上实现。但主机是按 MIPS 收费，所以当这种预查询多次执行时，成本很高。  

因此工行做了架构改造，通过 CDC 数据复制技术，将主机实时发生的数据复制到大数据平台，通过 Flink 进行实时 ETL，数据搬运过来之后，充分利用大数据平台海量的计算能力，大幅提升预查询效率。原来每天跑 10 轮，现在每天可以跑 30 轮，原来每轮 30 分钟，现在每轮只要 10 分钟，既提升了时效又节省了成本。

实时大屏场景一般都是基于日志采集或 CDC 技术实现数据的统一汇集，基于 Flink 进行实时的业务量统计。工行也是通过这种方式实现的实时大屏，并使用了 Flink 的 mini-batch 的特性。虽然 Flink 能逐条实时处理数据，但在大部分场景，它会有 1ms 和 100ms 的延时，mini-batch 的特性类似于 Spark Streaming 微批的处理方式，在增加小量数据延时的情况下，大幅提升海量数据的吞吐能力，非常适用于实时大屏的场景。

在银行业早期，大家基于 DB2 主机支撑核心业务。随着国内去 IOE 以及自主可控转型的浪潮，各家商业银行都开始将主机上的业务，迁移到分布式体系上，通过服务化接口的调用，满足不同业务系统之间的协作。业务迁移到分布式体系后，在调用多个服务化接口时，由于网络抖动等影响，会出现交易中，部分环节失败的情况。

为了解决这个问题，工行基于 Flink 研发了业务一致性对账中心，将服务化接口调用过程中的调用日志，统一汇集到 Kafka。基于 Flink 会话窗口的特性，判断交易中各个环节的调用是否完整。如果发现不完整的情况，会触发业务上的补账 / 核对动作，及时消除对客户账务的影响。

未来规划

目前在上线新的实时模型时如果涉及到历史数据的统计指标，需要分为两个作业来实现。以金融行业为例，在一个反欺诈模型里，如果需要最近 7 天累计交易额的统计指标，一般会先跑 Hive批量算出前 6 天的统计值放进 Redis，然后基于 Flink 读取 Kafka 中的数据，统计当天的增量数据，再进一步汇总成最近 7 天的统计值。而使用 HybridSource 可以将 Hive 和 Kafka 中的数据抽象成一张表，通过一个作业就可以统计出最近 7 天的值，在 Flink 内部自动实现类似于 union 的功能，大幅提升研发效率。

关于动态资源调整，随着平台规模越来越大，资源利用率的关注度就越来越高。实时计算在一定特定的场景，会出现交易量突增的情况。比如在双十一大促之前，工行都会提前一周对交易相关的实时计算模型，进行手工扩容，大促之后再手工缩容。这个过程，总体比较复杂。工行目前还是采用手工扩容，或者通过业务侧将批和流结合的方式解决。因此后续希望 Flink 通过具备动态扩缩容的自适应能力，配置 min 和 max，引擎可以自动根据数据量的负载在 min-max 之间，调整使用的资源量从而提高整个平台的资源利用率。

《Apache Flink 案例集（2022版）》——5.数字化转型——工商银行-工商银行实时大数据平台建设历程及展望（3） https://developer.aliyun.com/article/1227985