Flink-SQL 实时统计在金融场景的应用

几个月前，Filnk社区发布了最新的稳定版：Flink-1.11.1

从2018年起就开始使用Flink解决金融业务场景的需求，我经历了Flink的1.6 -> 1.9 ->  Blink -> 1.10.1 -> 1.11.1

大概我总结了下，在我的工作中，Flink为我们带来了什么实际意义，在整个金融系统中，Flink扮演了一个什么角色呢？

 

1.实时数据传递与聚合（1.6）：

       想象一下，我们有一个接口场景，例如在金融后台系统中，可以通过输入金融单号查询这个金融单的全部流程与状态，想查出全部数据大概需要再后端去查30张表进行join，然后把结果返回给前端。慢到加索引也不能很好的解决问题，因为单表可能就有近千万条数据。在2018年Q4引入了flink，做下游的，根据主键的宽表实时聚合，拉出一个很大的宽表，通过监听上游的业务系统日志，按照主键做分批字段的实时CRUD。

       2018年底我们上线了基于Flink的实时金融单后台数据系统，将数据提供给业务人员展示和操作，它由5个job构成，上线后原本一线的业务员在给客户走线签时要等待半分钟甚至数分钟才能查询到的信息，可以在300毫秒内在页面上返回，在1分钟内即可出发业务下游操作，加速推动用户完成签约，极大的提升了效率。以此为起点，我们衍生出了金融流程可视化系统，实时交易统计等。

 

2.数据可视化（1.6，Blink，1.9，1.10，1.11）

      数据可视化前几年还是挺新潮的，不过最近几年，越来越多的公司在做出来各种炫酷的可视化系统。在2018年到现在我们仍在承接实时可视化项目需求。主要统计一些实时性的，有决策引导性的可视化指标例如：

      实时交易金额；

      实时在途金额/逾期统计；

      实时放款期数表；

      地域业务实时活跃情况；

      分期房产交易统计、带看保险业务类统计；

      放款平均利率（期限）变化情况；

      实时放款利率分布表（按照区间分布）；

      实时进件折线图；

      面向多个金融业务场景的申请信息统计与拦截统计如装修金融，房产金融，店东金融，现金贷金融，税款金融等；

      直观预警类如短信发送在行业、营销与催收场景下的实时统计；

      面向支付环节类的实时统计如通道、支付渠道、业务渠道、绑卡行为、银行录入行为等；

      面向交易流程类的实时统计如交易时长，平均交易时长，累计交易时长等；

      面向预警类的与额度预警、风险预警、支付失败预警等；

      掺杂一些临时活动的，业务发布零售产品销售情况统计，SKU销售统计，快到过年的授信与用信类高峰统计。

      对支持系统中台的实时监控，统计系统中台调用量，发送量一系列指标。

      总之数不胜数，只有你想不到的，没有数据产品和运营提不出来的。在可视化层面其实是一种探索，探索技术的稳定性，毕竟人看的东西，停个几秒，业务能够接受，会在群里@解决。这已经是一种比较高级的应用了。

 

3.衍生字段、衍生变量（1.9、1.10、1.11）：

      我觉得如果业务觉得你已经可以给我提供决策变量了，那看来这个技术已经被业务接受了，也是从去年开始会有很多这样的需求产生。比如一些需求，实时计算某个用户的逾期连续情况，拖欠，统计某个经纪人的实时带看情况与运动信息。为什么这种东西还一定要实时？我离线也没差多少，问题就在于对C端的一些产品，小额借，多期还，一天可能借款几十笔（比如花呗），跑离线一天的时间差可能就会差出去很多，如果这个用户昨天还没逾期，但今天就逾期了这离线就不好用了。

      另一些场景例如实时计算出发业务系统行为，比如每当前端用户发出用信的信号，会去实时计算的系统中查询这个用户的近30日用信情况与额度情况，来决定是否拒绝。比如当每个业务产品在给用户授信前，会与实时计算系统交互查询我这个产品今天还能有多少额度，当前还有多少余额，决定是否在前置层面拒绝。

       还有些如支持实时查询返回统计数值，接入风控决策引擎等。

 

 

       总体来说，在金融场景下，实时计算在不断发挥着更大的作用，并且金融的场景有很多的相似性，你会发现这个公司统计的东西和另一家好像没有太大的不同，无论在做高频短尾还是低频长尾的业务，围绕数据流的指标是具有一些相似性的。并且明显实时计算在不断的发挥着更高效的作用，面对这么多的指标与数据，SQL化无疑是一种最好的发展方向。