00:00
到目前为止,可以说我们已经掌握了弗link编程的所有手段啊,那这个时候我们就可以回过头来回顾一下第一章曾经介绍过的这张图,也就是flink当中的分层API,哎,我们知道啊,学习的重点其实主要就是中间的这一层所谓的核心API,那就是现在批流统一的话,主要介绍的就是data stream API。那另外呢,我们还介绍了更加底层的有状态的流处理,也就是所谓的处理函数process方式,另外呢,哎,我们前面又介绍了更加上层的应用层级的API,也就是table API和linkq。那我们现在所有层级的API都已经学习完了,在实际应用的过程当中,到底应该选择哪一层API去进行编程呢?啊,那这就跟我们面对的实际需求的业务逻辑有关了,一般情况呢,哎,我们肯定就会想到对于一些常见的统计需求,诶,比如说我们对于这个网站啊,以电商网站为例,统计最多的可能就是像。
01:05
PVUV诶这样的一些统计指标来统计我们当前的一些访问量,那所以对于这些统计指标而言呢,很简单的,我们就可以直接用一个CQ搞定啊,那当然了,我们也可以用streampi去实现啊,但是我们前面就会发现啊,对于这个CQ而言更加的简单,特别是在计算这个UV的时候,我们之前data stream API可能还需要用自定义的一个set啊,去进行一个去重,那如果说是CQ的话,直接在原有的CQ基础上加一个distinct的关键字,直接做去重就可以了,哎,那所以能用CQ肯定是更加简单的。那如果说我们使用CQ搞不定的呢?诶,那有时候我们可能就是调用到这个核心层的data vpi,它可以支持更加灵活的这种窗口操作,窗口聚合,然后呢,诶,我们还可以去自定义状态啊,使用状态编程的各种手段,这就可以实现更多的功能了。那假如说我们还想要用到跟时间相关的一些操作啊,比方说想要获取当前的处理时间,或者说当前的watermark水位线,那或者呢,呃,我还要去注册一个定时器,指定隔多长时间之后触发什么样的操作,那这个时候就必须要用到底层的process function式了啊。那所以整体来讲,我们在去编程的时候啊,肯定就是从上到下依次去使用对应的这些API啊,能用上层的话,上层直接搞定就最简单,不行的话再去下沉到底层,哎,我们再去调用更加复杂的功能更强大的底层API。
02:37
啊,那之前我们说过啊,所谓的底层的这个处理函数,其实就是我们进行弗link实时流处理的一个大招啊,可以说所有的需求啊,理论上用这个处理函数都可以直接搞定,但是我们就会想到啊,实际在工作当中呢,有一些需求,它的业务逻辑可能会非常的复杂,诶,比方说之前我们讲过一个。
03:00
实时对账的需求啊,那个是我们在讲到第八章多流转换的时候,两条流需要去做一个合流操作,哎,那这个时候呢,我们最好的方式就是读取两条流,然后呢,使用一个状态编程啊,那保存之前已经有的状态,然后还要注册一个定时器去等待另外一条流理来对应的那个匹配数据,哎,这是我们能想到的一种方式啊,但是在实际应用的过程当中呢,有可能就不仅仅是两个数据这样的一个匹配检测,诶,那更多的场景是这样,我们可能要去检测用户的一些行为习惯。比如说诶就是检测一个用户先做了一个访问,然后呢,诶又下了一个订单,之后呢,又有一个支付的行为,诶那怎么样能把这用户一连串的行为全部按照先后发生的顺序检测到,然后把它包装在一起,做一个匹配检测,进而探索出用户的行为模式,对用户做一些分析呢?
04:01
诶,那这个需求其实就会复杂很多了啊,那或者还有一些场景呢,我们可能要检测用户的一些连续的行为,主要是要做一些风险的控制和管理啊,比如说用户当前这个在做登录,那假如说登录失败了,那一次登录失败没关系,哎,我们知道用户有可能输错密码,但是如果说他短时间内连续的登录失败。这个可能就会有问题了,所以我们应该把这些有可能有风险的用户行为要检测出来,那往往这个检测的过程当中呢,它就是先发生什么,后发生什么,我们是指定顺序的,而且有可能还有一个时间限制啊,就是在这段时间内连续发生这样的事情,我们就要把它检测到。那这样的一个需求,能不能用底层的处理函数或者状态编程,这样去把它搞定呢?啊,当然理论上是可以的啊,哎,我们知道所有的这些东西先发生什么,后发生什么,那先到的那些事件,我都可以保存成一个状态,先把它存起来。
05:01
然后呢,哎,你如果要是有这个时间的限定的话,我就去注册一个定时器嘛,诶直接设一个闹钟在这儿,就等着他去触发,等他去响了。但是这个过程当中,如果我们想要去判断的事件太多,逻辑太复杂的话,诶,那我们的那个process方式里边可能就是各种if else,各种条件判断,各种分支,而且有可能还要设置很多个定时器,可能我们的代码就会越来越混乱啊,到最后哎,那可能就乱到不可维护了,我们自己写的代码自己都看不懂了。哎,那怎么办呢?啊,其实这个过程我们就会发现啊,需要有一整套的体系,帮我们建立一个标准化的模型,处理这种场景。那对于这种事件先发生什么后发生什么,诶他们的先后顺序有比较复杂的要求,而且有可能还有一些时间限制啊,这样的合并在一组的需要去检测匹配的事件,我们把它叫做复杂事件。
06:00
对于复杂事件的检测和处理。就是所谓的复杂事件处理。那对于复杂事件处理的这种特定的场景呢?啊,弗link其实给我们提供了专门的一个库来解决这个问题啊,所以接下来呢,我们最后要介绍的一张内容就是所谓的flink cep啊,这里的cep到底是什么呢?其实我们知道啊,它就是一个英文缩写cep,就是complex的event processing,那么首字母就是cep,翻译过来的话就是复杂事件处理啊。那所以flink c呢,其实就是flink给我们实现的一个用于做复杂事件处理的库,一个library。啊,那到底什么是复杂事件处理呢?其实就是前面我们提到的这个概念啊,就是在当前的这个事件流里边,我们需要去检测先后发生的很多个事件,他们应该有一个组合的关系,把这这一组关系对应的这个事件组合在一起,检测到,然后进行处理,这就是所谓的复杂事件处理啊,比如说我们说一段时间内用户连续登录失败,这就是一个复杂事件,或者说诶,用户先下了一个订单,然后呢,要检测他的支付行为,一段时间如果没有支付,这就相当于订单超时了嘛,诶那所以对于这种情况,订单支付超时,这也是一个复杂事件处理。
07:27
啊,那接下来我们可以看一看复杂事件处理的具体流程,我们可以看一下这张图,首先呢,诶,我们当前应该有这个输入的事件流啊,那这里我们可以看作是一条流,进行了一个KBY之后的分组,也可以是认为是多条流,这个都没关系啊,那所以我们看这是一个输入的事件流,在这个输入事件里边呢,不同的形状就代表当前事件的一些不同的特征啊,比方说就是某一个字段。表示它当前的形状,有一些是圆的,有一些是三角,还有一些是正方形,那接下来呢,我们就要定义一个匹配的规则,也就是说我们不是要做复杂事件处理吗?诶,所以我现在先得规定,就是先来什么事件,后来什么事件,很多个事件要组合在一起,这样一个组合的规则就是我们所谓的要做匹配的模式,哎,所以这里是定义了这样一个匹配规则啊,我们把它叫做模式,比方说这里我们定义的就是先来一个三角,后边要紧跟着一个圆圈,哎,这就是我们想要检测的啊,先后发生的两个事件组成了一个复杂事件。
08:38
那我们定义好了这个匹配规则之后,把它应用在当前的这一个输入事件流上面,那接下来就可以在里边进行检测提取了,所以我们看这个规则就有点儿像一个我们的filter条件一样,然后呢,应用在这个输入事件流上面啊,就相当于做了一个筛选,对应的匹配项就提取出来了,所以我们看检测到符合这样一个匹配规则的事件呢,哎,那就是一组一组的提取出来这两个,诶这其实就是我们看到是这两个事件,前面一个三角,后边一个圆圈啊,然后呢,后边紧跟着还有一个。
09:14
另外不同K上面也同样有这样的一个匹配事件,那我们可能看到啊,那你像这里有一个三角后边有一个圆圈,它两个算不算也是一个匹配的复杂事件呢?哎,这个不算,因为我们定义的匹配规则是三角后边紧跟着圆圈,哎,那你这个三角后边它紧跟着是一个三角,再来一个圆圈,这就不不算了,只有后边的这个三角后面紧跟着圆圈,这个才算。啊,所以这就是我们所说的这个检测复杂事件的过程啊,我们要定义这样的一个匹配规则,应用到输入事件流上之后,就检测到了对应的复杂事件,然后接下来呢,当然就可以定义一个转换的规则,定义一个比方说map操作,或者定义一个更加复杂的处理操作,就可以把检测到的这个复杂事件打包在一起的这一组事件,然后我们想对它进行什么样的处理转换,就可以去自定义了啊,那最终得到的当然就是一个新的data,一个新的数据流。
10:14
这就是复杂事件处理cep的完整流程。所以我们也能看到啊,Cep的主要目的,它其实呢,就是对于我们当前的输入事件里边海量的数据啊,要做一个筛选,按照某个规则进行一个筛选,那这个规则其实就是提取了当前我们数据里边的某些特征,哎,那所以它其实就是在这个无界的流里边,要检测出特定的一些事件组合,这样的话,让我们就可以对于数据的高阶特征有更多的了解啊,那所谓的这个数据挖掘啊,主要其实就是做的这样一件事情。那在进行CP处理的过程当中呢,其实有一个非常重要的概念,就是我们这里所提到的模式,这就对应着我们当前定义的这个匹配规则,复杂事件提取的规则,这个概念其实非常的重要,所以这里呢,我们再展开的介绍一下所谓的模式到底是什么。
11:13
啊,那在CP的底层呢,直接就把这个模式叫做pattern啊,那所谓的模式就是CP定义的匹配规则,它主要有两部分,一个就是要指定我们当前所提取的每一个单独事件的特征是什么,比如说这里边我们指定第一个事件必须是三角,第二个事件必须是圆圈,哎,那所以针对每一个事件其实都有一个筛选匹配的规则。其次呢,我们还要定义他们俩之间到底是什么样的关系,谁前谁后啊,而且我们还可以定义是不是三角后面紧跟着就是圆圈呢啊,就是他们之间到底是紧挨着,还是中间可以隔着其他的事件啊,那所以就是除了定义每个事件的单独特征之外,另外我们还可以定义事件之间的组合关系。
12:03
这里所谓的组合关系啊,简单来讲就是谁后边跟着谁啊,那另外我们还可以定义就是是不是紧挨着啊,这就是所谓的严格的竞邻关系,就是两个事件之间不能有任何其他的事件啊,那与之对应的就还可以有宽松的竞邻关系啊,就是只要前后顺序对了就行了,中间可以插着别的啊,那另外还可以反向定义啊,当然了,我们还可以进一步扩展这个模式的一些功能,比如说还可以加上时间限制。啊,就是在多长时间内先来一个三角,后来一个圆圈,这个也是可以去定义的,另外呢,我们还可以去。指定每一步我们检测的这个简单事件是否可以重复出现啊,就是说我们这里边啊,假如说不是说一个三角后边来一个圆圈,我们是连续三个三角后边来一个圆圈,哎,这个三角就可以不用重复定义了嘛,能不能直接让它重复出现三次呢?这样也是可以去定义的啊,相当于循环检测三次。
13:03
这就是所谓这个模式能够做的事情。弗link cp当中呢,给我们提供了非常丰富的对于模式的定义和处理的方式啊,那这套API呢,就叫做模式APIAPI啊,这个也是我们后面要讲解的一个重点,这里需要多说一句的就是。定义了模式之后,正常情况下呢,我们就基于它检测出了匹配的数据,那除了我们可以提取检测到的匹配复杂事件去进行处理,另外呢,我们还可以检测所谓的超时事件啊,那就是之前我们说的不是可以定义一个时间范围吗?时间限制吗?那就有这种情况,那就是如果在这个时间范围内真的来了一个三角,后面跟着圆圈,那这个就是正常匹配,那也有可能呢,哎,在这个时间范围内,三角后边来的不是圆圈,来了一个方框,那这个就是不匹配。那还有一种情况是三角先来了,但是呢,在接下来我们等待的这个检测的时间范围内。
14:02
既没有来圆圈,也没有来其他的时间,也就是说它既没有正常匹配到,也没有直接我们就检测到它不匹配,哎,那所以这种情况它相当于是一个超时未匹配的一种情况,哎,那所以在有一些场景下呢,可能我们要单独处理这种超时的情况,所以CP是允许我们单独把这个超时的事件单独检测出来去进行处理的。啊,所以可以扩展出非常丰富的功能,这就是关于这个模式的一些特点和概念,哎,那整体来看的话,这样一个CP啊,到底能用在什么样的场景呢?最后我们再来总结一下Li cp它的应用场景啊,那整体来说的话,主要就是检测那些。先后发生的不同事件的这些组合啊,那首先我们就可以做风控,因为我们可以设定一些行为模式,对用户的异常行为进行实时的检测啊,那比方说像前面我们说的啊,短时间内频繁登录失败,诶,那这个就有可能账户有风险了,有可能被恶意攻击了啊,那或者呢,就是短时间内大量的下单却不支付,这就相当于在做刷单嘛,诶所以这个时候我们就可以直接检测到对应的行为,做一个报警提示,诶那或者呢,还可以直接把用户的这个权限进行一些封禁。
15:24
这样就可以去控制啊用户账户和这个平台的风险啊,风控这个是用的最多的一个场景啊,另外还有一个应用非常经典的场景,那就是做用户画像,因为我们知道啊,CB可以用预先定义好的规则,就是指定我们要检测用户哪些连续的行为嘛,那也就是我们说的,比如说用户先做了一个访问,诶,然后马上就下了一个订单,那所以说符合这种行为规则的用户,那我们就可以给他贴上一个标签啊,比如说他就是一看了之后就会买,或许这就是一个剁手党啊的,当然这个并不太准确啊呃,但是我们至少可以根据用户的各种行为把它的一些特征提取出来,诶,那所以这样的话就可以做出相应的用户画像,基于用户画像,当然就可以做精准营销了啊,那针对某些特征的用户就可以推荐一些相关的信息,也可以做对应的这个个性化推荐啊,所以这个在现在的网站当中啊,特别是这个电商网站。
16:24
或者说我们这个内容类的网站啊,像这个短视频平台里边用的还是非常非常多的。那另外还有一个场景呢,就是所谓的运维监控了,诶那我们知道在企业当中的运维监控,往往可能它的这个指标是非常灵活,非常丰富的,那使用CP呢,就可以进行这样的一个灵活配置啊,所以CP的应用场景还是非常的丰富的,呃,其实很多其他的这个大数据框架也有对应的这样的一些需求啊,啊像Spark或者bam这些大数据框架其实也都提供了CP的解决方案,但是呢,都没有提供专门的库。
17:02
Flink就专门提供了一个CP这样的库来解决我们对应的需求啊,所以这一部分也算是flink的一个特色啊,是它非常好用的一个地方,所以接下来呢,我们就来专门的讲解一下flink cp的用法。
我来说两句