005.尚硅谷_Flink-Flink的特点

然后我们再来最后总结一下flink的一些主要特点，那flink有哪些主要特点呢？首先它最大的一个特点，诶我们知道它是这个流处理啊，流处理其实整个处理的过程当中呢，数据是源源不断来的，诶那这里边源源不断的来，那就代表一个什么含义，就是我们当前的这个程序，大家想啊，之前我们的这个处理写代码，我们这个跑程序，大家的印象应该都是顺序处理嘛，我的代码写好之后一步一步做，做完了之后，诶程序退出就结束了，对吧，那就就已经运行完了，应该就是这样的一个过程，它就是按照时间时间线一直处理的一个过程，但现在弗link不一样。Flink，如果你要做流式处理这个处理过程的话，大家想是不是应该是这个程序应该是一直起在这里，等在这里的一个状态，大家想想是不是这样，因为我并不知道数据什么时候来呀，我真正处理这个计算流程的时候，那是等到数据来了之后来一个再去按照我定义的那个处理过程，一步一步去做处理，对吧？哎，那你在这个之前，这个数据来之前，是不是我就应该把当前的，比方说哎，想要有的这些组件集群就都应该起好了，对吧？然后当前的这个任务，我当前各各个的这个任务都应该已经分配，分配好了，都应该等在那里了，然后就等数据来。

哎，所以这个处理的过程呢，就跟之前大家理解的就是流程驱动，或者说按照顺序执行的这个代码有所不同了，这种代码叫做事件驱动even event追问提出一个这样的一个概念啊，那其实这个也非常理解，大家可以对照我们传统的做这个比方说啊，一个web应用啊，大家有这样的业务数据，呃，处理系统，后台系统，然后他会跟那个数据库去做交互，对吧，那大家想它是不是也是一个事件驱动呢？对吧？我们当前的这个web服务器本身就是起在这里的嘛，你当前这个服务器，如果你不，如果不出故障，你也不去手动去停止它的话，它会一直跑在这里，对吧？就是我们说的这个，这个有头没尾嘛，只要有开始，后面是无休无止一直在那里运行的，然后他什么时候去处理数据，去做计算呢？等到有事件来的时候，有一个用户发起请求来了的时候，我这。

这里边就去根据自己的处理逻辑，去数据库里边读取数据，然后去更改数据，对吧，写入数据，然后最后返回用户那边一个啊当前的一个行为，一个response，一个响应，这就是传统的这个流程啊，这就是事件驱动啊。所以大家看现在，呃，我们这个流式处理啊，Flink其实是借鉴了传统的事件处理的这种模式啊，所以我们当前的事件驱动是什么呢？也是每来一条数据，我们当前一般这个数数据，这个事件就是当前的啊，用户的一个行为日志往往就是这样的，对吧？或者说业务日志，我们可能首先把它收集在一个啊，一个消息队列里边啊，大家可能想到了，首先可能我们从这个用flu对吧，去从这个日志里面去提取数据啊，然后有可能直接把它塞到卡夫卡，类似于这样的一些消息队列，然后接下来呢，诶，就用这个flink系统去做处理，处理的过程当中，我内部有一个自己的内部状态。

啊，去做不停的运算，这个状态就类似于我们这里边的数据库了，然后为了保证容错性，故障的时候可以恢复，我还要定期的去把它做一个远程的持久化的保存，对吧，做一个checkpoint的保存，然然后另外呢，这里面就是每来一条数据我都可以实时做计算，然后诶，有可能我写入到别的一些数据库，呃，数据系统，存储系统里边也有可能呢，直接触发一个操作，这就是我们这个事件驱动的过程，它相比之前我们的这种web应用的事件驱动的模式呢，首先处理更快，内存嘛，哎，更更简单，更更方便，另外还有一个就是更加灵活，它接下来能做的操作就更丰富了。

那这是这个世件驱动的特点，然后另外一个特点就是我们所说的基于流的世界观哈，这个概念就提的比较大了啊，就是上升到世界观的这个高度了，那这里边主要是说什么呢？主要就是跟SPA克哈杜这样的一个批处理的世界观来做对比了啊，那我们看在flink的世界观里边呢，一切都是流。哎，什么叫一切都是流呢？就是说我这里边数据处理所要处理的这个数据都是流，都是一个一个来的，对吧，我默认它就都是一个一个来的这样的一个状态，那对于我们要处理的离线数据，就是就是攒一堆攒一批数据，你要处理的这种数据，那又又应该是什么流呢？

我们说它是一个有界流邦的string。大家看什么叫有界流，有界流你放在我们这个图里边看的话，数据本身产生的时候，按道理你即使是攒一批，它其实产生也有先后，对吧，那所以我还是按照先后顺序，先后顺序一个一个来。然后如果说它是一个离线处理的话，那我就把它挨个收集，收集什么样的呢？诶有头有尾，把它截取这样的一批数据截取出来，对吧？这样截取出来的数据你去做离线数据到这个位置，哎，所有所有数据都到齐了，我把它截取出来去做离线数据，这个就跟批处理几乎就一模一样了，对吧。啊，所以在这个过程当中，不存在批处理和流处理的区别，那我可以认为批处理就是一个特殊的流处理，对吧？哎，这就是所谓的这个，呃，Flink官网第一句话啊，当时给大家提到的所谓的有界和无界数据流的这样一个处理。

他最终把所有的这个批处理、流处理，有界无界，都是看作流来去处理的。那当然与之对应，在这个批处理里边，你像Spark里边，那就是一切都是都是P对吧，那就是我们说的，即使你是流出流数据啊，是连续不断，我要做实时处理的时候，我也是把它就是一小段一小段截成这样的小V批次来去做处理的啊，这样的话，这就是相当于一个批处理的世界观了。后面我们还会再给大家详细对比一下弗林和Spark stream啊，然后另外还有一个特点，就是弗林给我们提供了分层API。主体来看的话啊，Flink提供的API呢，分成这样的三层，从下到上依次是process function，这是最底层，然后中间呢是data stream API。

最上边是flink给我们提供的flink CQ和table API。那这三层API越往上越到顶层呢，它就会越抽象，然后整个我们这个使用起来就会越简单，表达的含义就会越简，越简单明了，对吧？嗯，所以一般情况下，大家可能会想到我比较熟悉这个CQ啊，写CQ啊，那我们其实调用的这个link CQ和table API，用到的就是最顶层的API。然后它的这个中间层呢，中间层是data STEM API，这就是我们进行flink流式处理的最核心的一层API，它所能使用的这个操作就会比上层的API呢，整体来讲会更加的灵活，更加的丰富一些，就是在这里边，呃，你你在上层这个CQ和这个table API里边，必须得就是API给我们提供的一些函数，一些操作你才能调用，如果它不支持的话，我们这里边什么都不能做，对吧？啊，所以现在当前的这个table API和福CQ啊，还在一个丰富和发展的过程当中，尽管我们知道就是自从这个阿里的blink啊这个版本合并进来之后，这块已经极大丰富了，已经是可用了啊，但是呢，现在它还还不完全完善，还在发展变化啊，所以如果说有一些需求它不能实现，那怎么办呢？我们就要用到比较。

就是下层的这个API data stream，它本身就是处理流里边的数据的，我们在这个流处理的过程当中可以。对这个流做各种各样的转换操作，可以自己自定义各种各样的这个丰富的操作还可以呢，哎，有非常灵活的开窗，各种各样的一些应用啊，所以这个层级其实在目前为止是使用最为常见和最为呃，就是频繁啊，最为重要的一个API的层级啊，那当然了，这里边这个data stream API，大家一看这就是做流处理的对吧？那如果你要做批处理的话，还有一个API叫做data set API。

啊，就是有时候是把它区分来看，有时候呃，就是我们现在可能也呃不做那个更多的呃区别啊，大家主要用到的就是这个流处理data stream API对吧，你如果想做批处理的话，Data set API和这个data stream API呢，略有不同，但是整体其实是差不多的，所以后续给大家做讲解的时候呢，我们也会主要以这个data STEM API作为作为一个例子，那data set这一部分就就简略了，就就不会给大家做太多展开了。那然后可能有一些非常复杂的场景啊，甚至于连我们这个data threepi都搞不定啊，那这种情况下怎么办呢？那还有更底层就是所谓的process function啊，这个就是我们整个架构里边啊，能够提供出来让我们能够做操作的最底层的API了，在这个里边几乎你就什么东西都可以自定义，除了你能做的这些关于流里边做数据转换，做各种操作，做开窗，对吧，运算这些操作之外，还能够获取到当前所有的状态和时间相关的信息，甚至还可以干什么呢？这里面有一个非常好玩的应用。

还可以定义定时器，就我可以定义一个过多长时间之后，然后要去做一个什么操作啊，所以说这个process function式就特别特别灵活啊，就是越往下它是越具体，它的表达能力是特就会越来越丰富，使用起来越越来越灵活，当然了可能用起来也就会越越难，对吧，大家可能会发现他可能用起来就没那么简单，你可能需要了解的东西更多。啊，具体在使用的过程当中，大家就是你你什么样的需求，用什么样的东西，对吧，如果说上层这个简单的API能够搞定的事情，那我们当然你用上层就够了啊，那更多的话，我们现在可能用这个DSSTEMAPI，第二层这个API用的是最多的。

然后除了这一部分之外呢？呃，那弗林克还有一些其他的特点，这就是我们前面已经提到的，它还支持事件时间和处理时间不同的时间语义啊，那关于这个又是什么呢？呃，后面我们讲到时间语义的时候再做详细解释啊。另外它还能保证exactly one精确一次的状态一致性，保证这就是我们说的处理数据只处理一次，对吧？能够处理数据处理一次，而且只处理一次，保证它结果正确，另外呢，低延迟。高吞吐对吧，它是每秒可以处理百万级的事件，也就是数据的这个并发量啊，并行处理的这个量可以达到每秒钟百万级毫秒级别的延迟。

啊，这是这个flink的关于低延迟和高吞吐，还有这个结果正确性，大家看它能所能达到的这个级别，这里边明确的给出了，另外还有一些特点，就是可以和众多的常用的存储系统去做连接啊，那比方说像我们这个卡夫卡对吧？啊，像这个阿帕奇的卡an ES，呃，包括这个h base have，包括这个，呃，像我们这个MYSQ啊，JBJDBC的一些连接，这些其实都是可以去做这个连接的，都是没有问题的。那另外还有就是高可用，可以实现动态扩展七乘24小时全天候运行，容错性非常的好。这就是flink的所有的特点，那这里面重点还要给大家再来强调一下flink跟Spark swimming的区别。那大家从之前的这个描述其实也可以总结出来，他们最大的区别是什么呢？就是我们说的世界观不一样吧，本来就是两种处理思路，整个架构的本质就不一样，Flink的话，我们认为一切都是流啊，那所以说这个我们认为就是来了一个P计算，我们要做这个P处理的时候，也认为它是一个特殊的流，对吧，有界流，而对于SPA stream呢，它相当于是把这个流处理转成了批，转成了微微批次的一个处理，对吧？Micro的这样的一个处理模式，所以有些人也会说就是SPA swimming敏，它不是真正意义上的。

流处理啊，就是或者说有人说SPA swimming做的这个实时是一个伪实时啊，因为它的这个实时程度呢，因为你必须要做这个攒一批的这个操作嘛，有这个VP做这个架构上的这样这样的一个限制，所以说它的这个本身的处理延迟就一定是秒级别的，没有办法再低了。所以对于延迟性要求非常高的场景，那可能就只能用flink了啊，SPA stream在这种场景可能就不适用了。

然后另外还有比较重要的这个对比啊，重重要的这个不同，还有一个就是数据模型。大家知道在Spark里边，Spark streaming本身还是Spark那一套嘛，我们采用的数据模型是RDD对吧？啊，就是弹性分布式数据集这样的一个数据集的，呃，RDD这样的一个数据结构，那么SPA streaming里边的stream我们做操作的时候，其实都是一组一组的小批数据的RDD对吧？啊，这样的一组集合，我们做它的操作的时候也都直接就是for r DD去做操作了，所以我们最终操作的还是数据集。而flink里边呢，本身它底层没有数据集的概念啊，当然上层是有data set API嘛，对吧，但你是可以做批处理的时候有这个数据集的概念，但是本身它的底层基本的数据结构。

没有这个数据集的概念，它本身底层的数据模型就是数据流以及事件的序列，Event的这个序列啊，所以大家看它就是事件驱动嘛，标准的数据流对吧？Data flow啊，就是大家可能听说过谷歌有一篇这个data flow那篇论文，非常著名的那篇论文对吧，那flink它其实就是很可以说比较完美的实现了那篇论文里边的架构。啊，另外还有一个特点就是运行时架构不一样啊，那Spark本身是P计算，所以说本身我们根据它的那个所有任务的啊，定义出来的那个结构，大家知道是那个DA对吧，它是要划分stage的，哎，我们是一个完成之后才能进行下一个啊，然后我们中间可能还要做沙uffle之类的这些这些过程，对吧？啊，那这是Spark的这个过程，那这个划分step，也就导致我们中间可能必须要有一个等待的过程。你不可能特别的快。

而flink呢，它是标准的流式执行，它在这个运行架构上没有Switch，没有没有这个阶段的这个概念啊，我们当前这个节点就是按数据来，只要有数据来我就处理，然后就发往下一个节点，下一步操作去做计算，对吧？那这个过程当中就是只要来了数据就做处理，来一个处理一个，处理完了发向下一步，所以这个过程当中并没有任何的延迟。这一点也是从架构上保证了它的低延迟。啊，这就是关于弗link所有的特点。