00:01
到目前为止,截止到第十章,我们已经对flink的底层原理和data API的调用有了充分的认识,那接下来我们要做的就是更上一层,站在应用层级的角度去看一看上层的API又有哪些更加容易、更加灵活的调用方式。首先我们要介绍的就是第11章table API和liq这部分在当前的项目应用当中,其实应用还是非常广泛的。那首先我们应该要回顾一下一张图,这是在第一张就已经提出的一个flink多层级分层API的一个结构图。我们知道在fli提供的API当中,最核心的其实就是中间的data stream API,当然了,这里写写出来的是包含了data stream和data set,而对于现在的Li架构已经是批流统一,Data set我们也可以认为已经要被用了啊。整个批处理也是直接基于data stream去进行转换就可以了,我们把它当成有界流处理就可以。所以我们真正意义上写出来的flink批处理或者流处理程序,它的核心都是data stream。我们的程序其实就是定义了一个一个的转换算子,让一个data stream通过转换计算之后得到另外一个data stream,在data stream之间进行转换,这是我们整个flink程序的核心逻辑。
01:29
而再往底层下层的话,那就是所谓的处理函数了,底层API就是process方式,Process里边我们可以访问到当前数据的时间戳啊,还可以访问到前的水位线,另外还可以自定义定时器去进进行时间上的一些精细化的操作啊。当然了,我们还可以去自定义状态,进行非常丰富的状态编程,可以定义算子状态,可以定义k set按键分区状态。
02:02
所以我们可以认为最底层就是直接调用处理函数去进行的有状态的流处理。关于这些内容,我们在前面的章节都已经做了充分的了解。其实。到目前为止,通过datatream API和底层的process function,我们已经可以理论上实现所有场景的需求了。啊,就不管是什么样的需求,不外乎就是我要获取到当前的数据,当前的事件,另外可能还依赖于之前的数据,之前的某种状态,那我进行有状态的处理,或者我们还需要对于时间有一些精细化的控制,那我可以直接使用data streampi里的window操作窗口操作,也可以在里边自定义定时器,这些都是可以实现。不过呢,在真正企业的实际应用当中,往往我们面对很多需求,它是有大量的同同类的类似的处理逻辑的。比如说像前面我们实现过一个求平均数,我们当时是求每五个数据的平均时间戳,那其实我们知道对于求平均数这个需求而言,没有必要。
03:17
来一次我们就重新写一次,之前我们做的是实现了一个aggregate function啊,我们需要实现整个接口里边的每一个抽象方法,都要把它重新去做计算有不同的数据类型,那对于这样的一个需求而言,可能我们当前是计算一下平均的时间戳,下一次可能就是计算一个呃,订单的平均金额啊,那再下一次有可能是计算一下。每个用户一天当中平均的点击次数,这些都是有可能去出现的,那我们计算的类型可能不一样,计算的数据可能不一样,但是这个需求都是计算平均数。我们就会想到,那能不能把这样一个相同相类似的需求,不要每次来了之后都调比较底层的接口,自己去实现gate function啊,那能不能包装成一个更加高层级的API,直接就一次调用,简单的就能把它实现呢?
04:14
啊,那所以我们就会想到应该要有一个我们。上层API的包装。方便应用的。重复调用啊,那另外还有就是我们还要考虑当前的这样的一个上层API接口的风格,要让大家更加容易接受,作为大数据工程师,我们其实比较熟悉的其实是数据库里边的操作方式,那数据库里边我们最熟悉的当然就是关系型数据库了,比如说像myq post postgq,它里边的核心其实就是结构化查询语言,就是我们所说的SQLQ。那么这样一个结构化查询语言,其实在大数据应用当中,为了方便我们直接使用这套语言,这套接口,那很多工具其实都提供了对应的CQ支持。比如说我们所熟悉的汉。
05:09
我们进行数据仓库的操作的时候,哎,那have里边有,那比如说Spark。重量级的,呃,行业重器进行大数据处理的一个可以说是典型的应用处理引擎,Spark里边为了更好的支持在当中的CQ查询也提供了Spark CQ啊,那所以我们就会想到那flink能不能也提供一个类似于CQ的接口,然后直接让我们通过写CQ的方式就把我们想要的功能直接。放进去,想要的数据都查询出来呢?啊,比如说前面我们所说的求平均数的这个功能,CQ里边不就是一个avg函数,我们就把后边想要计算的那个列字段写进去,然后AVG1调就把它计算出来了,这样难道不是非常简单的吗?所以基于这样的想法。
06:04
Link就给我们提供了更加高层级的API。那就是把data stream要转换成表这样的一个形式,类似于之前我们写CQ的时候对于关系型表的处理,把数据整理成组织成表的结构。所以在这之上,首先。Link就给我们提供了所谓的table API,顾名思义啊,Table API当然就是基于table的一整套API,之前我们的data stream API,那是整个所有的转换计算都是基于data stream的某一种data stream。经过一个算子调用之后。然后转换成了一个新的data stream啊,或者说我们多条流进行join进行连接,进行计算啊,合并之后,合流之后,然后得到经过计算还是一个data。或者说我们经过了分组,然后开窗,经过聚合计算,最后得到还是data stream,都是data stream之间的转换,这是这一整套API命名的规则。而现在的table API呢,当然也就是所有的东西都是table啊,那table基于table这样一个数据类型,我们在Java语言里面或者其他的语言里面,可以调用它的一系列方法进行各种各样的转换,类似于之前我们所做的map filter啊,或者是开窗聚合各种各样的计算啊,同样是由一个table再转换成另一个table,就变成了表之间的查询转换,那这一套所谓的上层API就是table API。
07:43
他是专门为了处理表而设计出来的一整套API。当然了,这一种table API,它本质上其实还是基于Java语言或者其他的一些语言之类的其他语言来调用,相当于在语言里边内嵌设置了这样一种数据类型,叫做table,然后基于它进行转换调用,所以本质上它是内嵌在语言里边,然后上层有声明出来的一种新的API接口调用,所以有时候把这个table API叫做DSL啊,它属于这个所谓的。
08:22
声明式的领域,专用特定语言啊,就专门为了当前flink流处理里边的表的转换而设计的一个语言,一种API。所以他就有点稍微有点尴尬,一方面诶,我们是使用了更加熟悉的关系表的这种结构,但是另外一方面呢,他又没有办法让我们用最熟悉的CQ去进行转换,还是要嵌在Java里面去进行方法的调用,所以我们自然就想到了最好的方式,当然是就完全不依赖任何的特定的语言,我们直接就写一句字符串类型的一个CQ select,什么什么东西from哪一张表,然后直接把这条CQ1执行,就可以得到一张新的表,这样的话当然是我们想到的最好的解决方案了,所以基于这样的思想,在cable API的基础上。
09:17
Flink也给我们实现了对CQ的真正意义上的支持,所以这其实是我们在应用层级的一个最高层的接口,或者说是最高层的语言,那弗link是基于阿帕奇的这样一个引擎来实现对于C的支持的,那这样一来我们就可以直接在flink程序当中。写书写CQ来进行表的转换处理了,但是我们知道CQ本身是针对关系型表的一个查询语言,结构化的查询语言,所以它的底层其实还是基于table这样一个数据类型的啊,所以本质上看的话,这两种API是集成在一起,CQ的执行对象依然是这里的。
10:02
所以我们一般情况认为这两者是一体的,这张我们也是把它合并在一起来进行讲解啊,那既然我们知道。对于弗林格而言,现在它已经是批流一体的大数据处理框架了,那无论是流处理还是批处理,在上层很显然都可以把它统一。转换成一个table啊,既然data stream可以转换成table的话,那就不管是流处理、批处理,当然都可以使用CQ去进行处理了啊,那不管是直接调用table API还是直接写一条CQ去进行查询,他们得到的转换结果都是完全一样的。啊,那当然了,在实际应用的过程当中,因为中间的table API稍微的有一点尴尬,它既不像下边的d stream API和process function那么底层能够获取到的底层的信息那么的多,另外呢,它也不像上层的CQ那么通用,就是直接我们从其他的这个数据库学习的过程当中就可以直接迁移过来,它也没有那么好用,所以往往在实际项目当中,要不我们就使用底层的data stream API和process去进行开发,要不就直接使用最高的cqlinkq去进开发,啊,那所以这一里边我们会以flink SQ作为重点讲解的对象,而table API的话,我们做一个简单的介绍,就不会作为重点的实现了。
11:34
这里另外需要特别说明的是table API和flink CQ,其实它的发展是相对于之前我们说的那些章节,属于flink底层或者说核心层的API,相对于那些章节而言,它的发展是比较慢的,最初是并不完善的,那它的一个重要节点就是flink的1.9版本,1.9版本的时候合并入了阿里巴巴内部的blink这样一个。
12:03
类似于flink CQ的一个特定特化的版本,把blink合并来之后,那link里边的CQ和table API就发生了非常大,LI2这个大版本才真正意义上基本做到了功能上的完善,整体功能开始可用了啊。那如果大家仔细关注官网的描述的话,也会发现Q这一部分直到一点。官网上才明确的说它的英文表述是feature completed,就是当前的功能是完整的啊,那当然了,所谓的功能完善并不代表就不再变化了,所以即使是现在目前最新的一点版本,以及马上即将要发布的01:14版本,Table API和flink CQ这一部分还在不停的变化,而且预计肯定是当前flink里边变化最大的部分。
13:07
所以这章节呢,我们也只是重点在于原理的理解和table apiflink CQ的基本用法的掌握,那具体每一个版本API的具体调用方式,我们还是要不停的关注官网的更新变化。
我来说两句