006_尚硅谷大数据技术_Flink理论_Flink简介（六）Flink vs Spark Streaming

我们最后再来对比一下flink跟Spark streaming，因为大家知道Spark streaming也是用来做实时处理的嘛，它的特点也是实时延迟比较低，那如果说要把它俩做一个对比的话，他们主要的区别在哪里呢？首先大家就会想到flink跟Spark streaming，尽管他们都是用来处理实时的场景的，他们的延迟好像都比较低，但是他们的延迟是不一样的，哎，大家会想到这个SPA streaming，我们之前做计算的时候会发现它的这个延迟时间至少要达到。几百毫秒，一般我们设置都是在秒级的，呃，几秒钟啊，一般都要设一个几秒钟的这个延迟，因为它是要攒一批嘛，而flink的话，它其实是毫秒级别的延迟，它真的是来一个就处理一个，所以这个延迟上的不同，他们的区别，核心的区别，往本质去说的话，还是他们整个架构的不同。

对于flink而言，它是。真正意义上的理由处理，而Spark streaming其实它是一个对，它还是一个批处理的过程，所以为了跟真正的理由处理做做对比，我们经常把SPA stream是叫做VP处理，对吧？啊，Micro BAT的一个处理方式啊，所以它其实核心的理念是把连续来的这个流逝的数据啊。他也是在攒批，他是只不过就是把这个批次攒的很小，那是不是从架构上来讲，看起来好像就是，诶我变成了这个很短时间内的，来了数据就处理，来了数据就处理啊，只要我这个批次足够小，那是不是相当于我这个实时性就会足够好啊啊那有同学可能会想到，那要这么说的话，如果我要把这个VP做到极极致的话，来一个数据就就攒一个一个批次，那是不是就跟我们的流处理一样了呢？呃，对，就是从本身从这个数据处理来讲，看起来是一样了，但是从架构上来讲，它还有一个攒批，然后按照划分我们这个数据集，然后去做数据集计算的这个过程，对吧？所以这个过程是没有办法去节省的，所以架构上设计SPA streaming整体来讲就要慢一些。

这个延迟是不可避免的，而对于flink而言，他的这个观点就是底层就是流，就是来一个处理一个，那大家知道如果说用flink要去做这个P计算怎么办呢？那就是前面我们说的对，是不是把它转换成一个有界流啊，所以大家看到就是对于Spark而言，它可以认为。就是Spark认为啊，我也是批流统一，我可以去处理流失数据，只不过我把流失数据是看成一个，是不是看成一种特殊的P啊VP去做处理，对吧？啊，那flink呢，Flink就是所有的数据都是流，对于我来讲一切都是流式数据，那你如果要是一个离线的一批数据，我把它看成一个有界的流是不是就可以了，所以大家看这就是一个世界观的不同啊，本身架构对于这个数据的处理过程就是不一样的。

然后另外还有一个非常重要的区别就在于他们底层的数据结构、数据模型是不一样的，我们知道Spark里边数据模型是RDD，我们处理的这个底层都是弹性分布式数据集，那对于Spark streaming而言其实也是一样的，我们所处理的那个stream是不是也是一组一组小批的这个数据集的集合集合啊啊，所以我们在做处理的时候，往往也是直接就for each r DD直接就做计算了。而对于flink而言，它的底层数据模型真的意义上就是data flow就是数据流。所以它处理的是什么呢？是事件序列，就是一个一个的事件，或者说我们说的一条一条的数据。它是不存在这样一个数据集RDD这样的一个概念的啊，所以本质上就是有所区别。

那最后还有一个就是运行式架构啊，那我们知道Spark里边做的是P计算嘛，它是将整个任务处理的这个dag，大家知道本身我们这个大数据处理的过程当中是任务是有先后发生的顺序的，对吧？诶所以说我们把那个dag画出来之后，Spark里边是要划分不同的stage，呃，所以一个stage完成之后，然后才去做下一个计算啊，那大家也非常熟悉，Spark里边我们要有有不同的这个算子，有这个呃，转换算子和行动算子，这个其实就是在运行式架构里边带来的这样一个问题啊，它做计算的时候是划分stage，那大家想一下，既然你划分了stage。就会导致一个什么问题。是不是假如说我当前的这个分布式处理啊，不同的分区，不同的节点处理有先后，那我当前一个节点已经处理完了，但是别的没处理完。

那会怎么样呢？是不是就还得等啊，等当前这个stage结束才能进行下一步计算啊，因为你中间还要杀做其他的一些调整嘛，你不能直接就就打乱啊，那flink里边它会等待吗？大家注意flink里边没有这样的一个过程。弗link真的就是标准的流执行模式，什么叫流执行模式呢？它真的就是说这里边我们的所有这个节点啊，没有stage的概念，我们这里边就是所有数据来了之后要处理你就发到，比方说有一个任务，它它在一个分区里边，对吧？啊，那么我们这里边就是来一个来一个数据啊。比方说这里边，我把这个数据来了之后放在这里，哎，我们有一个分区啊，做这样的一个处理啊，然后处理完成之后，它就会直接发送到。

下一个处理的流程里面去，下一个要处理它的这个节点里面去，那这个过程它是完全不等待的，就是假如说我下边又有一个。又有一个跟他并行的这样的一个任务，那大家会想到正常来讲是不是。下面我这里边也可以有数据去处理啊。那这里面就有一个问题啊，假如说我们按照之前的那个概念有这个stage的话，那是不是就是我要等到所有的这个当前啊，这部任务，这个数据全处理完成之后才能做下一步啊，但是大家注意我现在这个数据。有可能是无界的呀，是连续不停的来对不对，那我这个数据有处理完的那个时候吗？没有啊，那我那我等到什么时候才是个完呢。所以大家注意啊，真正的流处理里边没有stage，我不要去等，你等是等不完的，对吧？所以我怎么办呢？我只要关心当前这个数据就够了，我当前这个数据这一步做完操作之后，直接发到下一下一步操作的那个任务里边去执行就完事了，那同样这里边的数据也是你你做完了之后直接发到下一步，对吧？诶，当然他他有可能是发到下一个是同一个分区，所以他只管这一个操作做传输就完事了，并不涉及到stage的划分，所以也就没有中间的延迟的时间，这就是flink的特点啊，大家看就是flink跟SPA streaming底层架构不一样，实现思路原理不一样，其实就导致了对于流处理这种方式，是不是明显flink就要占上风啊，对吧？它的延迟就会低一点，因为它本身架构设计就是针对流式数据的这种场景来设计的。