004__尚硅谷_Flink理论_Flink简介（四）流处理的演变

上节课给大家已经讲过了flink大概是一个什么东西，然后说了一下在哪些行业有比较典型的应用场景，接下来这一这一部分呢，就给大家站在一个比较高的视角上面。回顾一下整个数据处理的架构，它的一个发展和演变的过程，我先给大家回忆一下传统的数据处理架构是什么样的，嗯，大家会想到就是在可以说是近十几几十年来啊，数据和数据处理其实在企业里边已经是变得越来越重要了，可以说是无处不在，因为企业它一旦这个项目上线，一旦运转起来之后，数据就在不停的沉淀，在不停的积积累。然后这个数据量就会越来越大，对不对，那接下来他做的一件事情就是要把数据里边藏的那些信息要发掘出来，这个都都说这个数据是一个沉静的宝藏啊，你如果要是能对它做一些分析处理的话，是能挖掘出很多财富的。

因为现在很多公司都在这方面。挥的非常的多，都在这方面去发力。那大家知道传统的数据处理的架构的两种。非常典型的不同的这种架构。一种就是。针对每一个事物去做处理，一种就是把大量的数据都收集起来之后，然后统一去做分析处理，这就是我们已经听说过的OLATP和o lap，这个大家听说过概念吧吧，一个是连接事物处理，一个是连接分析处理啊，所以我们就一个一个来看，首先看一下这个事物处理的架构啊。这个架构其实整体来讲的话，就是我们业务处理的一个过程，因为我们想真实的这个业务系统里边往往是什么样的。

不就是从用户那里会来各种各样不同的请求，各种各样不同的事件，我们的业务后台业务系统就要做对应的处理和响应，然后呃，就把它处理完成之后，去给用户再返回一个response，那这样的一个过程，它的过程是不是就相当于是一个流失的处理过程啊，其实就是来一个事件，来一个数据处理一下，处理完成之后给一个返回。在这个梳理的过程当中，其实是涉及到两个层面。大家看。一个层面是我们所谓的计算的层面。这一部分可能是CRM，这是客户关系管理的系统啊，或者说像ERP，大家知道这个，呃，企业资源规划对吧，各种各样企业有各种各样的这些管理信息的平台和系统，这些系统是可以去收集这些请求的，另外还可以是业务里面相关的，可以是一个订单系统，Order system，或者呢，可以是我们就是一个这个外部APP啊，就是一个业务后台。

所有的系统都可以收集用户的各种各样的操作信息请求，拿到请求之后进行计算，最后给用户返回响应。与之对应，这这一层级是做计算，那另外一个层级做什么呢？那就是做存储。因为用户来的这些请求呢，有可能会涉及到一些需要做的，呃，查询其他的一些状态，查询一其他的一些信息，这些信息到哪里去找呢？传统来讲一般是不是要放在一个关系型数据库里面去啊，所以这就是我们平常的这种外部后台的一个架构嘛，我们把它搭建起来之后，呃，那就是。

来了一个请求。在我们的。后台里面去做响应，然后去从数据库里边查对应的信息，查出来之后去做计算，得到结果有可能需要再返回存储到数据库里边去，另外呢，再给用户那边做一个web的响应，对吧，就是这样的一个流程，这就是典型的事物处理，它其实是比较符合我们的流处理思路的，就是来一个数据处理一次，来一个响应一次。那跟他不一样的另外一种处理方式是什么呢？来看，就是下边要说的分析处理，分析处理又是什么呢？大家看这个架构是不是非常熟悉了，这其实是在我们大数据领域更加熟悉的一种场景，那就是传统的数据库里边得到的信息，有可能他有可能我们要对他做一个汇总库里对不对，那么要做的这个数据就来自于不同的数据库，不同的表，他们的数据结构有可能就不一样，所以我们第一步如果你直接去做连表查询，做汇总，去去这个做分析的话，显然是很复杂的过程，所以我们的做法往往第一步是先把他们从不同的数据库里边先提取出来，转换成统一的格式。

这一步大家很熟悉，是不是就是要做一个对ETL操作。把它做了ETL之后，是不是就可以放到。放到data warehouse放到数据仓库里面去了，啊，大家熟悉的数仓就来了，所以我们可以把它放到数仓里边，然后再应用一些其他的工工具去做分析、查询、处理，然后最后可以得到，最后得到的应用可能有两类，一类就是直接出分析报表，POS，另外一类可能是去做一些及时查询，对吧，那就可以做这样的一些应用了。

大家对这些是相对来讲比较熟悉的一些应用场景，那其实大家会想到，为什么会分这样的两类不同的数据处理架构呢？大家看这两类的话，是不是前面的事物处理相当于就是。式的处理方式，来一个事件，来一个事物处理一次，而后面的这个分析处理是不是就相当于是？批处理离线的这种方式啊，跟大家想实时性上是不是前一种更好啊。那为什么后面我们又会发展出这种离线的数据仓的这种分析的方式呢？其实就是因为数据量太大了，而且可能是来自不同的数据库，不同的地方，对不对啊，它的这个数据结构又不一样，如果说我们要在传统数据库里面实时的把它提取出来，连表查询去做分析处理的话，那是不是这个工作量就太大太大了呀？

这就是我们遇到的一个典型的问题，那所以说如果说我们要分析的这个内容不是那实时的就要得到结果的话，那是不是很好的一个方式，就是该来的数据都来了之后，把它再统一的提取出来，放在书仓里边。怎么去做离线处理啊，这就是批处理的一个思路。它整体来讲处理起来会更简单，而且应对更加大量的数据，应对这种处理情景的时候，他会有更好的表现。我们自然就会想到，那现在我们的需求还要低延迟啊，如果是只是把它放在离线这种环境去处理的话，大数据的场景是能处理的了啊，数据量上去了，吞吐量大了，但是延迟就比较高了。那能不能做到低延迟的大数据实时的分析呢？

这就提出了接下来是不是要用大数据的流式处理方式了。大家看，接下来我们讲到的就是有状态的流式处理。那么流式处理，有状态的流式处理是怎么去做的呢？大家看这张图，首先流式处理的思路。其实就跟之前我们讲的这个事物处理是非常接近的，大家看他的思路也是来一个就处理一个，来一个就处理一个，对不对，只不过这里边不再是用户那那边提起请求，然后我们这里这里边有一个这个相当于外B服务器web后台去给他做这个HTV请求的响应了。而是怎么样呢？这里边输入一个数据，经过处理逻辑计算之后得到另外的数据，直接就流逝的进行输出了，来看这边来的是圆圈，经过处理之后是不是变成三角了。

每一个经过处理之后都变成了三角，是这样的一个处理的过程，那至于这个三角到哪里去？我们其实会想到，是不是也可以有逻辑把它直接返回给用户，是不是也可以把它继续向这个数据流里面，向下游去传递啊，所以这里面大家会看到有一个典型应用，就是可以构建一个所谓的数据管道。A pipe烂这里边像水流一样，这边流入，我们这里边有一个水龙头，诶接出来之后做一些处理，然后得到的数据继续在这个管道里边向下游去流动，后边你如果还想用这个数据的话，还可以继续拿出来消费，对吧。这是流式处理的一个思路，那什么叫有状态的流式处理呢？

大家会看到啊，这个事物处理的时候，如果说我们做计算的时候需要一些其他的信息的话，是不是应该从数据库里面去做查询，然后做一些呃，其他的一些计算啊。那现在如果说我们也要做比较复杂的一些计算，需要其他的一些信息，怎么办呢？哦，那大家自然就会想到，我是不是相当于也需要有一个地方存储这些信息啊，所以这里边我们就把需要的那些数据，需要的那些信息作为一个状态保存下来。因为大家看这里边是把它保存到了一个本地的状态中，需要的内容从这里拿出来，然后跟当前的每一个数据去做比对，然后做呃，结合的一个计算得到的结果去输出。这个过程是不是完全可以跟之前的那个事物处理的流程比对起来啊？

所以这个过程其实是借鉴了事物处理的模式，那大家看这里面有一个问题。什么问题呢？跟我们事物处理它用的是传统的关系数据库相比，这里边把它放在本地状态里边，当然访问和计算就会很快。但是它会带来一个问题。本地状态是不是要占用内存，而且有可能有可能就丢了，对不对，可能会引发各种各样的问题。那这就涉及到一个，如果出现故障的时候，我能不能及时的在恢复呢？能不能恢复到之前正确的一个状态呢？呃，为了保证这样的一个问题，所以有状态的流失处理，还要把本地的状态保存到一个远程的一个存储空间里面去。那一般情况我们做的处理是什么呢？就是周期性的做一个检查，检查点操作，把状态里面的东西存到远程去。

当然了，这个所谓的远程存储空间，这就可以是各种各样不同的东西了。我也是。也可以是远程的一个类似于内存的东西，也可以是文件系统，也可以是数据库相关的一些东西。这是我们给大家讲的有状态的流式处理的一个过程。诶，大家会想到就是有了这样一个东西之后，我们可以很简单的。现在数据量大了之后怎么办呢？是不是就可以把它做一个分布式对吧，所有不同的数据来了之后，你可以去分区处理啊可以。做一个分布式的处理，那它带来一个问题是什么呢？还有另外一个问题就是如果要是做了分布式的话，是不是会有网络延迟带来的乱序问题。我们前面提到的。

遇到乱序问题的时候，你这里边来一个处理一个，是不是这个就有点不对啊。因为有时候我要处理的时候，是不是应该得等他前面的都来了之后，可能才能处理下面的数据啊。那比方说我们比较常见的像这个窗口操作，大家会想到我处理一个窗口，把这个窗口关闭的时候，是不是应该等这个窗口里边所有的数据都到齐了之后，才去关闭窗口做一个统计输出啊。那如果这个时候。我有数据是延迟到了呢，断续后面才来了呢，那这个时候是不是就相当于没有统计到一个窗口里面去啊。这个整个处理结果的正确性就得不到保证了。那在这种情况下，我们怎么做呢？给大家看啊，这里边的这个流失处理其实就是第一代，这只是第一代的大数据流失处理器的一个价格。

基于我们刚才的讨讨论啊，考虑考虑到他在状态处理乱序数据的时候出现的状态的不一致的这种情况。进行了一个演变。第二代的架构叫做。拉达架构。他的一个想法是什么呢？其实很简单，他其实就是用了两套。不同的处理架构对不对，大家看那现在的状态是不是这里边来的是流逝的数据，这里面是事件的那个日志啊，就写到日志里边，然后大家会想到我们用做一个采集，然后放到卡卡里面，这是不是就相当于一个流式的数据源了。这里面去做读取，读取之后经过一系列处理之后，最后要得到一个统计分析的结果，给到应用句对吧，这是我们能够想到的，中间分成了两部分。走两条路。

上边这一条路叫做，诶，大家看这是一个Bach layer，就是一个批处理层，那么它主要是做什么事情呢？它相当于就是做了一个批处理了，对吧，那与之对应的下边这一个是什么呢？下边叫speed layer快速处理层，它是不是就是相当于做了一个流处理啊，啊，这里边用了一个流处理器。那其实它的整体思路也非常明显了，就相当于是把流处理和批处理做了一个结合。它的好处是什么呢？那其实就很简单，流处理不是快吗？我们不是是来一个数据就可以处理一次吗？所以我用下边的这一个快速处理层，用一个流处理器，把每一个当前来的数据马上就做一个处理，做一个计算，然后输出到我的结果里面去。那么。我们的应用程序用户那边是不是就可以得到一个实时的显示的结果。

但是这个结果是不是有可能不正确？那不正确怎么办呢？那我是不是可以隔一段时间把之前所有的数据，就是前一段时间的啊，所有的数据做一个汇总，等他的数据都到齐了之后，做一个批处理啊，那这个数据是不是就会比较正确，就会正确度更高，但是他可能会有一个延迟，所以我用上面这个批处一层。保证我最后处理的结果的正确性，最后我可能要把两个层次得到的结果做一个合并，那么用户这里面看到的结果就是一个什么样的状态呢？很快速的，很实时的就能看到一个结果，但是可能它不太准，之后还会变化，隔一段时间之后，它有可能有一些变化，变化之后的这个结果就是很正确的一个结果了。

那大家想这个过程是不是就是看起来是比较可接受的一个状态啊，这个就是看起来比较合理的一个状态了。那大家会想到LA达架构，它用了两套系统保证我们同时保证低延迟和结果正确，它有没有什么问题呢？大家自然也可以想到，它既然是用了两套系统，然后把两者的优点结合在了一起，那它的问题也非常明显，那就是同一套逻辑，同样的一个目的，用了两套不同的东西啊。而且很烦的一件事情，就是在我们传统的这个流处理和批处理的这个框架，其实都是不同的东西。对吧，传统的这种快速的流处理，其实是跟我们熟悉的这个哈，Spark它做批处理的时候用的这个框架，用的这个编程习惯用的语，甚至用的语言啊，整个完全是另外一套API都不一样，那我们开发起来是不是相当于开发了两套系统，开发了两次维护，是不是也要维护两套啊。

一旦有一个功能升级啊，Fix的一个bug，呃，做了一个版本迁移，是不是两套同时都得都得变都得改。当然了，还涉及到就是。咱的一件事情就是说像这个项目经理，这个boss啊，Manager，他考虑你工作量的时候，他并不认为你实现了两套系统，对不对，我明明就给你提了一个需求，你说诶不行，我这是双倍的工作量，那怎么可能对吧，这是不是你能力的问题啊，你为什么要做的那么那么复杂呢？但其实我们知道在这个过程当中没有办法，你要同时保证D延值和结果正确性，我就只能用这样的两套系统去保证。A，其实对于我们来讲，同样的效果工作量翻倍，那其实是不太好的一个状态。有没有更好的处理方式呢？

当然就是有，那就是所谓的第三代处理流程器，就是弗link，他把我们这里面讲到的所有的优势都集中在一起了，同时做到用一套API，一套系统全部搞定这些内容。我已说link现在才会这么火，才会这么受欢迎啊，那这里边给大家看一下这个这个图，这里边其实就涵盖了flink里边的几大重要的特点了。那这里边呢，还给大家说一下就是。其他几个不同的相当于流处理的框架，一个很很经典的流处理框架叫stop，不知道大家听说过没有啊。呃，听说过STEM，其实可以说它是比较早了，早早一些啊，应该是大概10年一年那个时候就已经就已经有这个大数据流处理框架了，他其实可以说是流处理的一个先锋，呃，但是他的问题是什么呢？它主要保证的就是。

就是快，因为你在传统这个批处理里边，不是这个延迟太大，不可接受吗？那我的目标就是要快，那确实解决了，他就是来一个处理一个，对吧？啊就是做到了这样的一个情况，他做到了低延迟，但是它的问题在于。首先如果说吞吐量比较大的时候，数据量比较大的时候就搞不定。它吞吐量相对来讲比较小，另外你既然是大数据处理框架吧，分布式的这种处理环境里面，如果乱序数据来了的话，它的结果正确是完全保证不了，所以这就是这个。Storm的一个问题，那当然了，就是第二代这个，呃，这个我们前面讲到的这个拉姆达架构的数据处理引擎呢，就相当于是用一个storm这样的处理框架，然后再用一个批处理框架，结合起来，是不是就能同时做到这两点了？

这里边后面就又发展出了另外一个一个体系啊，就是所谓的STEM的这种处理的架构，它的思路是什么呢。对，他其实核心还是用批处理解决我们这个问题了，对，但是他在批处理的基础上做了一点小小的改进，什么样的改进呢？那就是想你既然这个比处理是来一个处理一个嘛，我批处理是攒一批去处理嘛，那我如果攒这一批，我攒的小一点，是不是它实时性就会更好啊，所以说这就相当于我把这个P变成一个很微小的P，它是就近似于流了，因为这是Spark streaming的一个处理思路。所以在这种。模型下啊，在这种架构下，它其实是能够做到高吞吐，吞吐量是很大的，另外也能够做到在压力下保持正确，对，对于很大量的数据，它的正确性还是保持的不错的，但是SPA也有他的问题。

他的问题其实也是就是。对，大家可能知道这个SPA streaming，一般情况我们都会配一个这个best，你间隔时间一般情况下的那个延迟你是给多久啊。一般可能给几秒钟对不对，对吧，两三秒，或者说甚至有时候配五秒啊十秒，呃，这个就是说你必须要在这个时间段等待他把前一批数据全处理完成，对吧，那这个过程是不可避免的。那所以如果说我们在这个应用场景非常极端的那些情况下，要想这个传感器的温度监控，对吧？呃，高铁的那个数据，或者说那个智能汽车的那个监控，你等两三秒之后，那真的是有可能该撞的已经撞上了，对不对？所以在这种极端的场景下，这个延迟也是不可接受的。

而更好的流处理的这个大数据处理框架，它的延迟其实是可以做到毫秒级别的。所以对于flink而言，它不仅能够做到高吞吐和正确，还能够同时做到低延迟，而且还能够处理乱序数据，还能够做到对于不同的时间语义做到这个时间处理的正确性。最后呢，还能够做到这个操作简单，表现力比较。能做的事情也很多，这就是flink的一个特点。