00:00
我们现在已经了解了table API和Li CQ基本的用法,那我们会发现其实跟get vpi啊调用的过程是非常类似的,整体也是那么几步走,首先创建一个执行环境,我们现在创建的是一个表环境,然后接下来呢,创建一张输入表,一般我们是创建一个连接器表啊,连接到外部系统,读读取数据,然后接下来得到了表之后,就可以直接写CQ或者是调用table API的那些方法转换去进行表的查询转换了。得到的处理结果表呢,我们再把它写入到一个输出表里边啊,同样应该是一个连接到外部系统的连接器表,那整个的流程这样我们就讲完了,我们会发现啊,在这个过程当中可能比较麻烦,比较特殊的一步呢,其实是最后介绍的这个表和流的转换。那从方法调用上来讲还是比较简单的,那最麻烦的是什么呢?其实是要考察。
01:00
我们在将一个表转换成流的时候,诶,到底能不能直接调用to date string方法把它转换成一个普通的数据流啊,因为我们知道,假如说这张表里边有了一些更新操作的话,它就是当前某一个值,它不是直接追加上去了,而是要改之前的某个值,这个时候你就不能直接把它转换成流了,因为你没法撤回之前的数据嘛,所以就只能把它按照一个。更新日志的方式,进行一个流的改写啊,所以这就是我们说的啊,必须去调用一个to changelo streamam方法啊,这里就稍微的有一点麻烦,所以我们会发现啊,在flink这样的一个流处理框架当中,我们要进行这个表的操作,或者说直接去写CQ的话,其实有一点啊,有一点别扭的啊,就是本身这里的概念啊,好像就跟这个流处理是不太一致的啊,所以我们会发现啊,本身这个关系型表,或者说这个CQ啊,我们去进行结构化查询的这种定义,它本身我们处理的数据呢,其实就是一个有界的集合,那就是相当于我们这张表里边现有的所有数据啊,一框把它全框出来,拿到对应的数据集,然后去处理里边的计算结果,那所以我们发现它其实是更加适合批处理的场景。
02:19
所以之前我们在MYSQL或者在have里边啊,它都是固定的数据集都放在那里了,哎,我们进行一个查询处理,使用CQ就会非常的顺手。而对于flink这样的流处理框架呢,我们要处理的数据是源源不断到来的,并不是说哎,我这里边写一条CQ的话,一下就把所有的数据都收集齐框住了,不是这个数据在不停的来,不停的变,那所以这里边我们会发现啊,当前进行处理的过程也需要源源不断的去进行处理,而且得到的结果呢,也不是。一劳永逸一次就得到最后的结果,也要不停的更新,不停的变啊,所以我们看到啊,这里可以把关系音表或者CQ跟流处理里边的一些核心概念做一个对比,我们就知道想在流处理里边去使用table和CQ到底有多复杂了。好,我们首先可以去对比一下啊,就是当前我们处理的数据对象到底是什么样子呢?
03:18
啊,对于这个关系表里边,我们要处理的就是字段元组,哎,我们说每一行数据吧,每个肉它的一个有界集合,我们要处理的一条CQ,啊,查询的针对的这个数据集都是有限的。而流处理呢?流处理针对的是无限的蓄力,所有的数据是源源不断到来的无休无止。然后接下来我们要考虑这个查询query对于数据的访问。它是一次性的,能拿到所有完整的数据吗?啊,那对于CQ而言,当然是可以一次性获取到的,那对于流数据呢?数据是源源不断来的嘛,当然就必须持续的等待数据输入,没有办法一次性的访问到所有数据。
04:01
那最后这一个当前的CQL查询啊,到底什么时候终止呢?对于关系型表或者说这个CQL查询而言,那其实就是说我们所有的数据集已经是线程放在这儿了,我们执行当前的这个CQ查询,得到固定大小的结果集之后,哎,那就结束了一次计算得到结果完事儿啊,这就是我们所说的一劳永逸的过程,一锤子买卖。那如果要是流处理呢,流处理就永不停止,如果我们要进行查询的话,哎,那一旦要是数据发生更改,来了新的数据,那就相当于我们最后查询的结果集也要发生变化啊,所以现在的数据是源源不断到来的,那当然这个查询也就会永无休止啊,这就是流处理跟关系仪表里面进行查询的最大的根本性的不同。所以我们会发现啊,呃,CQ本身就是针对这个批处理设计的,这跟刘处理呢,可以说是天生八字不合啊,所以现在我们在flink当中。
05:01
设计了这样的table API和CQ,就是要使用CQ去进行流处理的处理转换,哎,那底层它又是怎么去做的呢?所以接下来我们就深入的探讨一下流处理里边表的概念和查询的概念。首先我们根据之前的分析啊,我们已经知道了,在流处理里边所有的数据它是源源不断到来的,哎,这是一个数据流,那如果现在我们想要把这个数据流转换成一个表的话,哎,那很显然就是每来一个数据,这个表就会增加一条数据嘛,那后面每来一条数据,后面就再增加一条数据,所以我们看到这张表它不是固定的大小。这张表是会不停的增长,不停的变化。所以我们看到啊,在link这样的流处理系统当中啊,我们定义出来的表,它不是静止不变的,而是不停的动态变化,所以我们这里的表table。
06:00
就叫做动态表dynamic。它里边的数据,这张表里的数据呢,会随着时间的推移而不停的变化啊,一般来讲呢,就是会不停的增长,当然了也有可能是做了一些更新操作,那要看我们具体执行的那个查询转换了啊,其实这个动态表的概念,我们说在传统关系数据库里边呢,已经有所体现了啊,我们知道在关系数据库里边对表做的一系列的啊,Insert update delete啊,各种各样去进行增删改这样一些操作的结果,诶,那其实是会改变我们数据库里边表里面的数据的,哎,那如果说我们想要直接以当前表里的数据去记录当前我们执行的操作的话,那显然是不可能的啊,我们必须要记录到底发生了什么样的操作,这就是我们所说的更新日志流啊,就到底你干了什么事啊,到底是增加了什么数据,然后更新了什么数据,删除了什么数据,那如果说我们保存了当前这张表,在某一。
07:04
时刻的一个状态,那就是当前这张表里边到底有哪些数据,我们可以说它这就是一个快照嘛,Snapshot,然后接下来呢,我又知道针对这张表的更新日志流啊,就是基于这张表做了哪些增删改的操作,那接下来其实就知道啊,就知道随着时间的推移,这张表到底会发生什么样的变化。啊,那所以在很多这种关高级的关系数据库里面啊,比如说像这个Oracle DB two啊,他们里边都有对应的这样一个概念,叫做物化视图啊,它其实就是可以缓存C9查询的结果,它的更新其实就是不停的处理更新日志流的过程啊,那这个概念我们就会发现啊,跟flink里边的动态表其实就是一致,Flink的动态表就借鉴了物化视图的概念。啊,有了这样一个基本的动态表啊,我们说所有的数据输入进来之后,源源不断的到来,哎,那首先它转换成的这张表就是不停的增长,不停的增长。
08:06
然后呢,我们基于这张表又要去定义一个CQ查询,诶,那这个CQ查询我们说它针对这个表不停的变化的话,这个CQ当然也要不停的把这个结果集进行更改,也就是每来一条数据,这个表变了之后,CQ就应该要重新执行一遍,所以这就是我们说的啊,当前的这个C查询,如果针对动态表,针对流处理去进行查的话。他就永远没有停止的时候。只要数据一更新,我就要重新执行一遍,那当然了,最后得到的结果集也是在不停的变化,当然这个变化就有可能是追加,有可能是更新啊,那所以我们看到啊,这个过程当中,CQ永无止境的在做查询,我们就把这个查询的过程叫做。持续查询。而持续查询的结果呢,同样也会是一个动态表啊,这样的话,我们就把这个流处理里边表和CQ查询的概念完全的贯穿起来,所以我们会发现啊,在这个过程当中,流里边每来一条数据都会触发一次我们当前的CQ查询操作啊,那所以可以认为啊,每一次查询的时候呢,都是由数据流里的事件来去触发的,那触发的时候呢,相当于是对于我们当前输入的这个动态表做了一个快照,就把当前所有的数据。
09:29
提取出来固定大小的有限数据集,做了一个批处理,得到的结果呢,哎,就是当前动态表的一个更新结果。所以我们会发现啊,就是在这个数据不停到来的时候,如果连续不断的针对当前输入动态表的这个快照进行一个持续查询,哎,那就相当于就像动画一样把这个连贯起来了啊啊,那得到的这个动态表也就在不停的变化,这就是流处理的过程,所以我们看流处理跟表跟CQ就可以用这种方式进行连接和转换,所以我们看如果总结一下的话,持续查询的步骤就是这样的,首先哎,我们输入的是数据流源源不断的来,然后呢,这个流需要被转换成一张表,这个表是动态增长的,哎,正常来讲这个就是不停的追加,然后接下来呢,基于这张表定义的一个CQ查询,它就是要持续执行的,每来一个数据就要去执行一遍啊,这就是我们所说的这个持续查询,它会生成一张新的动态表。
10:31
那最后基于这张新的动态表呢,我们又可以再把它提取出来,生成对应的这样一个流,当然这个流的话,有可能只是追加的一个流啊,不停的追加这样一个流,那就直接to STEM转换就可以了,那如果要是说中间出现了更新操作的话,那我们得到的就应该是更新日志流了。这就是所谓的动态表和持续查询的概念,在CQ当中,这两个概念非常的重要。
我来说两句