风控系统实践之感: flink

个人线上经验不是很多，我做了风控系统之后，时常在想如何将flink，spark, clickhouse 等应用到风控系统中。 这里不谈flink 具体技术。

需求:  风控系统集成flink

首先，我们想想flink 是做什么的:

1. 实时

可以实时统计庞大的数据流, 并支持各种时间窗口。Flink CEP 可以天然当作风控规则引擎来用，当然flink CEP弊端也是显而易见的。

2. 批量

可以批量统计庞大的数据。

这个是我大概对flink 的印象(“能干什么”),  那么如何将flink 生态圈用在我们目前风控系统呢？ 我们风控系统设计比较简单，大致前两篇文章已经写了。主要包括规则引擎和计算引擎 两个部分。

1. 规则引擎 采用 drools， 支持动态规则的配置

2. 采用redis 做基于窗口的计算引擎。

显然如果使用flink 我们将风控分为实时风控和批量风控，flink 在他们中充当着不同的用途。

1. 在批量风控中，flink 可以用来计算衍生变量，比如 每张卡在一天消费的金额， 或者一张卡在一个商户的消费金额。 在跑批量风控之前 flink 可以快速的将这天的衍生变量和衍生变量之间关系(平均值，百分比等) 算出来。然后在使用drools 过规则引擎。 衍生变量是规则引擎中的一个变量条件

2. 在实时风控中, flink 可以用来实时 计算衍生变量的值， 这个和批量风控比较类似。 但是需要考虑是窗口的因素. 在批量风控中，我们默认窗口的步长是一天，并且可以支持的配置步长是 N * 一天， 其中N 是整数。

实时默认的步长，是根据窗口的大小。比如5分钟窗口，默认步长就是1分钟。 可以支持的步长是  N*1分钟。 步长应该小于窗口的大小。 按照这种方法，我们就可以将flink 累计的窗口种类缩小，并且都支持默认的步长。 然后将算出来的累计放到aerospike 中， 或者redis 中。 具体每个规则配置的步长在进行判断的时候做计算。

这样 flink 的窗口种类就缩小了，job 的数据量就少了很多:

1. 5分钟窗口，1分钟步长

2. 10 分钟窗口, 1 分钟步长

3. 30 分钟窗口， 1分钟步长

4. 2小时窗口， 5分钟步长

5. 6个小时， 10分钟步长

6. 一天的滚动窗口 (批量风控)

7. 一个月的滚动窗口(批量风控)

这样flink 通过提交job 的形式，将这些都计算好。 风控系统可以直接拿过来使用，而不用大量的计算了。这是我对使用flink这样的计算引擎的理解和使用。 这些是我的构想，没有实际的实践和上线。