《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