004.尚硅谷_Flink-流式处理的演变

我们现在已经知道引，我们可以引入有状态的流式处理，去解决之前我们在处理的架构里边，呃，数据量大和这个低延迟的这样的一个矛盾，对吧，和高延迟的这样一个矛盾，我们现在如果用了有状态流失处理的话，那就可以同时做到低延迟和高吞吐，哎，那这里还有一个问题，就是说我们想保证它能够呃有良好的容错性，对吧？所以我们要提出一个周期性的做checkpoint的保存这样一个操作，那另外还有一个问题是，你还得保证它处理的结果正确呀。之前我们说到你现在如果要做这个扩展的话，想要高存储的话，那必须得是一个分布式的价格，也就是当前我的这个处理的这个操作啊，不能只是有这么一个节点在做操作，在做本地的这个状态的管理和计算，可能同时还要有另外一个对吧？呃，可能可能还要有另外一个节点，同样。

所有的数据来了之后，一个一个在做这样的计算，本身这里本地也有一组状态在保持着，那这里就有问题了，那假如说后边我们之前大家可以认为这就是类似于每一个分区对吧，做不同这个数据处理的分区，那后边这个数据它有可能还会这个跨分区去做交互，对不对，那就是我们之前讲到的，有可能会有杀后这样的操作啊，那假如说这个数据再去做分这个交互之后，那往后的操作我怎么能保证之前的这个顺序还是保持正确的呢？也就是之前我们提到的那个问题，经过分布式系统这样的网络传输延迟之后，怎么能保证本来应该先进来的数据到后边处理的时候还是先处理呢？先把它统计进去呢？哎，这就是一个很大的问题了。那基于这样的一个考量。关于这个流式处理啊，大家会发现它的这个概念本身这个概念很好理解，对吧？哎，就是直接把这个数据的处理操作，我直接放在内存里边，然后我扩充集群嘛，呃，只要有这样的一个概念，其实整个这个大数据的处理架构就搭建起来了，所以大家看，呃，就是关于这个flink本身的概念和这个流逝处理的概念啊，提出都很早。

有很多项目其实跟Spark几乎是同时，就就已经都已经发展出来了，就就就都已经有雏形了，但是呢，它真正的长足发展啊，真正的完善要等到后来，主要的一个核心问题就在于早期的流失处理架构，它没有办法解决我们结果的正确性。就是你这里快是快了，但是呢，你这里的这个数不准啊，你就有可能比方说我们要统计这个，大家知道可以开窗口吗？我要统计今天之内的所有的访问量点击量啊，那有可能怎么样，有可能我该统计的今天的数据。

他前面经过这个网络传输延迟之后呢，我截止要要输出那个结果的时候，没把它统计上，他后面才来了，对吧，迟到了嘛，然后还有什么呢？还有我前面要统计做计算的时候呢，诶有一些数据可能并不是我我我们当前今天之内的数据对吧，就是后边已经是属于明天的数据了，赶在我这个统计之前，他就已经来了啊那那对于这样的这种乱序的场景，我怎么能保证最后统计的结果一定是正确的呢？为了解决这个问题。流式处理架构就有了发展和演变的过程，哎，那之前如果我们说这个最简单的这种架构，这个叫第一代流式处理框架的话啊，那么第二代流式处理架构就是传说中的所谓的拉姆达架构啊，这个拉姆达架构不是大家之前学函数式编程语言里面的那个拉姆达表达式啊，啊，这只是借用了这个名字，这个拉姆达表达，呃，拉姆达架构指的是什么呢？

它其实非常简单粗暴，就是两套系统，也就是说我们同时要用一套。流处理的系统，保证它的低延迟，然后同时呢，还有一套啊，这就是所谓的批处理系统，然后保证它结果的正确性，大家可以看一下这个架构图。上下分了两层，上面这一层叫做Bach layer，就是批处理层，然后下面这一层叫做speed layer快速层啊，那其实也就是流处理层了啊，大家看这里边是一个流处理的处理器。那上面这里边当然就是一个批处理的处理器了，然后我们用到的是批处理的那些存储空间，那整体的过程应该是什么样的呢？那大家看后面它处理的结果呢，分别放到两张表里面去，这就是我们的服务层了啊，给那个应用服务提供服务的这一层，它有两张表，一张表是我们快速层呃，得到的那个结果，另外一张表存储的是批处理最后的那个结果，然后最后呢，把两张表里面的结果做一个me，做一个合并，最后给我们的应用程序去提供数据，你看这个过程具体来看它的表现又是什么样呢？那那简单来看的话，就是我这里边的数据一个一个来，对吧，那大家看这里边就是我们的那个事件的日志直接提取出来，来了之后，我首先就是先去做。

快速处理对吧？流处理这里边不就是来一个处理一个吗？像水流一样不停的来，不停的处理，那处理每来一个处理一个，得到的结果呢，就写到了我们这里边的快速表里边，Space table里边，然后它同时会做什么呢？红同时做的操作是放到我们的批处理的这个存储空间里面去存着。注意不往后做处理，那什么时候做批处理呢？那当然就是攒一批嘛，对吧，你攒到我们要的那个时间点的时候，我再去做处理。也就是说，比方说我们要这个过去一个小时或者是一天之内的访问量数据量啊，那这个当前每来一个访，每来一次访问呢，我就直接统计一下对吧，当前的那个访问量就加一，我就直接在这里边就输出了，然后另外呢，我还把所有的那个数据都在这儿攒着，然后这里边的这个批处理什么时候做计算呢？等到当前这一小时截止，对吧？哎，我当前看到现在是十点钟了，十点钟截止，九点到十点的数据全部拿出来，然后在这里边做一个计算，写入到当前的BA table里面去。

那大家看这两个table里面的结果，是不是当然是batch table里面的数据要更准确一些呀？对吧，因为你这里边流处理这里边的话，呃，它有可能有乱序嘛，我们说啊，有可能那个后边有些数据是这个十点以后的数据，比这个十点以前的数据还先来了，所以你这里边更新的时候有可能这个不准，而我们这里边best table里边呢，已经是所有数据都到齐了，把它都攒齐了，这个数据就肯定没没没问题了，对吧？哎，所以接下来我们要做的事情就是把它俩做一个合并，那最终我们在应用程序里边看到的效果是什么呢？诶，那就是我我当前假如说有一个大屏显示当前统计出来的数据，那我本身如我Bach table里边没数的话，那是不是本身显示的就是SP table里面的数。

啊，那一开始就是我会看到一个就是不停的增长的不太准的一个数据，对吧，那这个数据可能是在不停的改变，如果说我想很快的知道一个结果的话，现在你看这个数就够了。但是呢，它不准，如果我想要拿到一个非常准确的数据，那得看什么呢？诶，那就是过一段时间之后，我等到这个批处理，把这个结果都已经处理完成之后，Best table里边已经有数之后，我再把这两个数据一合并，得到的结果再显示出来，这就是我最终准确的一个结果。

哦，这就是这个所谓的拉姆达架构。那拉姆达架构大家会发现它其实尽管简单粗暴啊，但是其实非常的有用，因为它其实就是通过两种并行的保持两两套系统啊，同时实现了我们的两个要求，你之前不是要既要又要嘛，对吧，既要低延迟，又要结果结果正确，又要这个高吞吐，这个整个的这个并行处理能力比较强吗？哎，那我们现在就是你这个流处理，它的特点不是你你最后。呃，得到这个结果是非踌，但是结果可能不太准吧，诶，那我就让他专门做这个低延迟处理吧，然后你如果说这个批处理的话，你等一会儿之后能保证它结果肯定对，但是你不能保证它快，哎，那我就只用它来校正最后结果嘛。同时两套系统搞定就完事了。啊啊，那那所以大家会发现它的这个实现看起来很简单，但是它的这个缺点也非常明显啊，那就是说你这里边相当于是什么，我们对于同一个需求，你就得实现两套不同的系统，对吧。

而且最大的问题是在于我们传统的这个流处理和批处理啊，那它本身的这种这种应用架构，我们可能用到的这个框架都是不同的框架，它本身的这个，呃，这个语义表达，API的这种调用本身都完全不一样，那可能我们就是一个系统，相当于我们做了做了两套系统出来，对吧，一个需求做了两套系统出来。然后呃，就是另外一个问题，就是说既然我们开发的时候比较麻烦，那同样我们去进行维护和迭代的时候也很麻烦，对吧？你来了一个需求，如果要做改变的话，你是不是同时得改两个地方啊，你还得保证修改之后他俩的这个语义是完全等价的，你还得保证你有可能你一部分用的是这个Spark去实现，另外一部分你用了一个流处理器，它原来API完全不一样啊，你还得知道它底层必须这个含义是一样的才行，所以这个就非常痛苦了。

啊，这对于这个，呃，比方说产品经理，对于这个总监来讲啊，啊，他觉得诶没问题啊，你这个东西给我们保证了这个又快，然后结果又正确，很好啊，你就你就这么做吧，但是我们作为开发人员很痛苦啊，你你做一个需求，相当于我这这边要维护两套系统，表现出来好像还只是改了一个需求而已啊，所以说呃，这个其实现在已经就是说逐渐逐渐啊，我们要把这个拉姆达架构要要淘汰掉了，但尽管现在它已经不是最先进的架构了，但其实很多地方还在用。啊，为什么呢？就是因为它效果还是不错的，对吧，最后其实是相当于我们可以同时保证这我们想要的这两个特点的。那如果说不用拉姆达架构的话，那到底用什么架构呢？哎，当然就是在它的基础上演变出来的第三代流处理器啊，就是所谓的弗link啊，当然弗Li本身前身啊斯特fair尔，它它其实已经很早了，它其实其实是跟这个第一代流处理器是差不多同一时间出现的啊，那呃，大家可能也听说过有最早的一个流处理器叫做storm对吧？啊，那storm就是一个典型的第一代流处理器，它可以说是流处理界的先锋了啊啊，它其实最大的特点就是D池，就是我们给大家前面说的，把所有东西都放在这个内存里边，然后就是快，来一个就处理一个，但是呢，他为了这个快就付出了一些代价。

啊，一方面你是纯粹内存的这种处理，然后你做这个集群扩展的时候啊，它本身的这种扩展集群就就比较有限制，本身这个高吞吐，吞吐量就不够大，然后另外呢，我们想要的这个正确性也达不到所要求的这个水平，所以说呃，Storm呢，它其实早是早，但是它并没有啊扩展开来啊，并没有这个推广开来，呃，那弗link最早期的时候，其实跟storm的整体架构设计是差不多的，但是他考虑到了更多的东西，所以说哎，就可以是。

哎，就实现了我们前面所说的那么多的特点，对吧，它成为了真正现在第三代有处理器啊，那这个STEM这里边是第一代嘛，然后第二代我们说就是拉姆达架构了，然后在拉姆达架构出现的同时，我们会想到，哎，那有没有一套处理。处理器啊，大数据的这个处理框架，呃，就就能够同时的处理这个快速的处理低延迟的数据，然后又能保证这个结果的正确性呢，来一批处理一批呢，这里面有一种折中的处理的方案，那就是所谓的SPA streaming SPA SPA streaming大家也比较熟悉了，就是它的处理思路是把所有的数据流逝，源源不断来的数据作为划分成。

一小批一小批的这个V批次去做处理，对吧？啊，那所以它的这个特点是我可以实现高吞吐，因为Spark嘛，整个这个架构对于这种大量的这个数据处理的场景就是非常适合的，那另外还有就是我在加力下可以保持正确，对吧，那整个这个处理过程的话，结果正确在我当前支持的语义下边啊呃，是可以保证正确的，这个是没有问题的。但是SPA streaming最大的一个特点就是你还是一批一批对吧？啊，它比这个我们传统的你在数仓里边做的那个离线分析是要快很多了，但是呢，假如说我们当前的这种应用场景要求对低低延迟，这个延迟的要求非常非常高。那Spark stream可能就做不到了，大家可能知道这个Spark streaming差不多得是呃，几秒钟的延迟对吧，秒级别的至少是秒级别的延迟，一般我们设置那个best duration的时候，一般都会设置到几秒以上啊，那所以它跟。

真正的流处理还是有差距的。那另外还有一个问题就是说，如果说我们还想处理那个乱序数据呢，那其实SPA streaming是没有这样的概念的，所以说它其实是并不能支持更加丰富的时间语义，也不能处理乱序数据，而所有的这些东西，Flink全部搞定了。啊，所以我们说这个flink是最新的啊，第三代流处理器，最新的流处理界的一个，可以说是集大成者啊，也是现在最热门的一个流处理框架啊，当然另外还有一个特点，我们这里面列出来说，它的操作简单，表现力好啊，这个当然就是见仁见智了啊，Flink里边提供了非常丰富的灵活的API调用啊，但是呢，呃，就是整体上来讲，它的编程风格可能跟之前我们这个Spark里边还会略有不同。呃，有很多人可能还是认为Spark的那种API的调用方式啊，那种风格会更容易接受一些，弗林的话就有点儿太灵活了啊，这个就是我们后边到具体的讲解，大家写代码的过程当中可以再去体会啊，这就是关于这个流处理的演变过程。