004_硅谷大数据技术_链路理论_Flink 简介（四）流处理的演变

那接下来我们给大家从比较高的层级上讲一讲数据处理的架构的发展演变的过程。首先我们讲的是传统的数据处理架构是什么样啊？大家看这张图的话，这就是传统数据处理里边非常经典的事物处理的架构，它的原则是什么呢？大家看它其实是划分成了两个不同的层级。上面这一层这个叫compute，就是计算层，然后下面这个叫storage，就是存储层，所以大家看这就是我们说的嘛，数据计算和数据存储分开啊，然后我们这里边什么叫事物处理呢？就是我当前应对的就是一个一个来的事物。最典型的就是比方说这里边你看CRM all system web啊，这就是我们上线的各种各样的系统吧，跟用户有交互的那些系统，CRM就是客户资源管理系统后面这是订单系统，或者网站应用的那个后台，所以用户那边会发各种各样不同的事件请求到这里来啊，比方说发了一个这个连接的请求，或者发了一个订单请求，或者说更简单的啊，我们那个外部应用，用户就是做了一次点击，大家想是不是对于我们网站而言也是一个HTP请求啊，啊，都是用户那边发过来的，所有发过来的数据都是一个事件，一个event。

然后接下来我的后台系统怎么做呢？大家就会发现我这后台这里边有一个业务处理的逻辑，我收到这个请求数据之后。接下来是不是有可能要依赖于其他存储的一些数据，那这些数据是不是就应该在诶存储成这是关系型数据库，这就是我们传统的像MySQL Oracle这样的一些数据库里边，诶我去做一个查询，得到相关的数据，然后呢，这些数据有可能又又会做更改，对吧？比方说你这里边我下了一次订单啊，那我获取到的对应的那些数据肯定要写入到数据库里嘛，所以数据库也可能有读有写，要更新，最后呢，结合数据库里边获取到的数据计算之后再得到一个，诶，一个response，一个响应，给用户那边一个返回。

大家看，这就是一个经典的事物型处理的一个过程。这其实不用说是传统的数据处理架构啊，就就在就在现在，就在今天所有的互联网公司后台业务处理流程是不是也是这样啊，大家想我们网站后台肯定就是这样的嘛，对吧？呃，有一个这个呃，后台的业务处理的这个计计算的这个服务器啊，然后有这个对应的关心数数据库，那用户那边发请求，我们这边做处理，给他返回响应。这就是事物处理的过程。它的特点。非常的明显，大家会发现它的实时性是不是很好啊，因为你要跟用户做交互啊，要不然用户这边做了一次点击你那边网网页卡住半天不返回，过了几分钟之后才返回，那那这个用户肯定不用这个东西了，所以它的特点是实时性很好，来一个数据，那就来一个事件，我就处理一个事件，我当前的后台系统其实一直都是在等待处理事件的一个状态。

然后这里面涉及到的一些额外的数据呢，存储在关系数据库里面，这是它的一个特点，那它的最大的问题是什么呢？就是能够同时处理的数据是不是有限啊，用户那边如果发发过来的请求，发过来的数据量特别特别大的话，那是不是就会导致首先我这边的服务器可能就处理不过来，那最最核心最大的一个问题，其实是我这边数据库做连表查询的时候，是不是就搞不定了。对吧，那边就是这里边本身呃服务器啊，我可以去扩展嘛，可以做这个做成这个集群啊，呃做这个呃负载均衡对吧？呃可可以做这样的一些调配，但是你后台这个业务数据库做连表查询的时候，数据量很大的时候，代价就非常高了。

所以接下来我们的问题就是，数据越来越多的时候怎么办呢？哦，很多公司于是就在之前我们的这个数据数据处理的基础上发展出了。分析处理的架构，诶整体来讲的话，这个这个流程大家看的更加熟悉对吧？啊，就是首先那个所有的数据来了之后，我就先都放在这个业务数据库里，然后我接下来要去做一个分析计算的时候，怎么办呢？把数据从业务数据库里边先做一个ETL先提取出来，对吧？啊先做这个清洗整合，然后统一都放到。数仓里边去，放到数仓里边去之后，然后接下来我再用一个数据分析计算的引擎，然后呃，我再写CQ去做查询，可以生成报表，或者做一些集析查询，这是不是大家更加熟悉的离线处理的这个过程啊，啊所以这就是跟数仓相关啊，做这个分析处理就非常的方便，那它的特点也非常明显，首先就是诶前边我们做的这个这个数据来源，我我不用直接去做那个连表查询，对吧，我是不同的那个数据库啊，甚至是就是不同的表，甚至是各种不同类型的数据库都可以，我从不同的地方把数据先提取出来，然后呢，诶我就把可以把这个非常量的数据全放在一起，按照我定义的这个规则啊，数据呃仓库分层，然后都放在这个数仓里面去，接下来呢，统一对它做查询处理。

这是它的优势啊，它的特点，那它的问题也非常明显，哎，大家看这个过程是不是就很慢啊。这个过程就没办法做到实时处理了，对吧，你前面这里边这个用户来了一个点击数据，我最多就是只把它存到那个数据库里嘛，你要是做那个统计分析处理的话，直接返回这个对应的那个分分析结果，那就不行了，你至少要经过ETL对吧，然后放到数仓，数仓里边再去做查询，至少要经过这么几步，实时性做不到那么好啊，这就是我们当前大家比较熟悉的两种不同的架构啊，那所以他们的优缺点也非常的明显，如果说做这个事物处理的话，实时性好，但是。

整个这个数据量大的时候，海量处理的时候，高并发搞不定，那如果说这个离线分析处理的话，它的数据量是上去了，高并发可以做到，但是呢，低延迟做不到，那怎么样把这两者结合起来呢？啊，其实大家可以有一个非常简单的想法，我如果要想结合起来的话，哎，那是不是最基本的做法就是我必须要保持之前那个事物处理的原则啊，来一个处理一个对吧，那你要来一个处理一个，规模上不去，主要是瓶颈在哪里呢？是不是主要就是因为关系数据库做连表查询的时候，这个很麻烦啊。

所以现在我干脆有这样一个简单的想法，我不要把就是要找的那些数据放在什么关系数据库里了，我直接简单粗暴放在本地内存里边，然后把它存成一个本地状态，这接下来的话，是不是来一个我直接去判断当前本地的状态是什么，结合这个状态，哎，去做一个，呃，计算输出对应的这个结果，然后状态如果有更新的话，我把这个状态一改，是不是就完事了？整个这个过程就相当于我用一个本地内存里边的状态代替了关系数据库里边的表，对吧？啊，所以这个过程就会快很多，那如果我用成这样的状态的话，在高并发的时候怎么样去做扩展呢？哎，这个就更简单，是不是直接做集群就可以了，哎，你不同的这个集群，不同的节点，诶你分配一块单独的内存，然后我做这个高并发啊，分别各自按照自己的本地状态去做处理，这不就完事了吗？啊，最终得到结果，呃，你想汇总了的话，再把它们汇总起来，这就是整个的这个基本的思路啊，所以这就是所谓的有状态的流失处理。什么叫有状态呢？就是我把当前做数据计算处理过程当中需要的那些东西，不要去到关型数据库里面去查了，我直接存到本地状态就完事了，哎，这就是这个有状态啊，然后这里边就是你看来了一个圆圈经过。

结合这个状态啊，做这个方框，做这个查询转换之后啊，得到一个三角来一个就处理一个来一个处理一个数据流，对吧？流式处理的过程就是这样的，那这里面还涉及到一个问题，就是那你既然是放在内存，那就不够稳定啊，那假如说我这数据丢了呢，对吧，当前这个节点挂了这个这个整个一掉电，那么内存里面数据都没了吗？那怎么办呢？

那是不是要有一个存盘和故障恢复的机制啊，哎，所以这里边我就在设计一个周期性的检查点，Checkpoint这个概念其实我们在Spark里面也见到过，那现在其实这个概念也类似，就是我要针对这一个状态定期的去做一个保存，假如说出现故障的话，那我是不是从之前保存的存盘的那个状态恢复出来继续做就可以了，原先这个我的状态是放在本地内存里边，它不稳定，那我当前的这个检查点呢，就要放在远程的一个持久化的存储空间，这个就比较稳定了啊，所以这就是同时保证了低延迟高吞吐，另外还可以做到良好的容错，出现故障的时候可以恢复啊，那大家就想到这个看起来很完美啊，这这看起来这个很简单，就可以把这个前面我们要求的那些功能搞定，直接把当前我们要处理的那个数据放在本地状态，然后做一个分布式的集群不就完事了吗？

来一个处理一个搞定了，这其实就是最初第一代流处理器的架构，它就是这么去设计的，但是它有一个非常严重的问题。啊对，大家其实会想到就是这里边我如果要是分布式架构下，是不是数据的顺序就保证不了了呀，你到后边这个数据处理的过程当中啊，啊，经过不同的分区任务进行处理之后，到后边那就可能就乱续了，那这种情况下，我怎么保证它的这个时间顺序是对的呢？这个就很麻烦了。所以基于这样的考虑，在第一代流处理器基础上就啊产生了第二代流处理器。人们往往把这一代流处理器叫做拉姆达架构啊，有这样的一个概念啊，那这个拉姆达架构跟我们之前讲到的编程语言里面的拉姆达表达式不一样啊，跟那个不是一回事，他其实说的是什么呢？简单来讲就是。

我用两套系统来同时保证低延迟和结果正确，什么意思？看一下这个这幅图，这幅图的处理流程还是事件出发，大家看这是一个呃，事件日志，每一条日志就应该对应着一个事件的发生啊，那所以接下来我做处理的时候。大家看这里边是有两条不同的处理路径，上面这一条呢，叫batch layer，这个叫批处理层，然后接下来下面这一层叫speed layer，这其实就是一个流处理层，快速层，所以它其实相当于同时应用了流处理和批处理的两套系统，两套架构来保证我们的这两个特点的。这个其实很好理解，就是首先刘处理这边保证的是什么呢？这当然保证的就是速度对吧，因为他来一个就处理一个嘛，很快速的就处理完了，然后就把这个处理结果输出到一个speed table，一个快速的处理结果表里。

这个表里边的结果大家会想到它是不是可能有问题啊，哎，那最后我想得到一个正确的结果又怎么办呢？诶，那就是我这里边再去做一个批处理，这里边我需要把当前的这个数据呢，诶大家知道批处理嘛，那是不是我就得攒着呀？哎，来了之后，可能我一开始就不是来一个马上处理，而是先攒一批，把这一批数据都攒齐，得到的结果放在这个batch table里边，这就是一个最终正确的结果啊。哎，然后我最终把这两个表再做一个结合给应用程序那边显示出来，所以最终用户看到的结果应该是什么样子呢？它应该是啊，这就是我们应用得做处理了，对吧，你什么时候拿这个表，什么时候拿这个表啊，啊做这样的一个处理，所以我们最后最终看到的应该是很快速的啊，就能看到一个结果输出，但这个结果呢可能不准。

可能后面还要做调整变化，我快速先得到一个近似正确的结果，然后之后隔一段时间之后我再来看，哎，那个结果是最终正确的结果。啊，所以就是这样的一个思路啊，我同时用批处理和流处理实现了低延迟和结果正确。啊，大家想一想这个拉姆达架构有没有什么问题，这看起来之前我们提到的那个所有的需求都搞定了，对吧？低延迟高吞吐，然后还要良好的容错性和结果的正确性。那他有没有什么问题呢？呃，其实问题也非常的直观，非常明显，就是我们现在实现一个需求，是不是要实现两套系统啊，啊，不光你要实现两套架构，另外你是不是还得维护这两套系统啊，所以接下来就是你一旦需求有所变化，一一旦，呃，有有任何的调整，是不是你要同时在两套不同的系统里边实现对应需求的增加和变化啊，大家就会发现你这个批处理跟流处理，我们还用的有可能是不同的框架呀，里边的API用法都不一样，你得自己保证他们做处理之后的那个结果是等效的，所以这个过程就非常的麻烦，代价是非常高的。那有没有更好的一套系统就能够把这个所有的任务都完成的东西呢？当然有，那就是flink。

啊，所以flink如果从这个意义上来讲，大家可以认为它就是第三代流处理器，它同时做到了低延迟高吞吐啊，那时间还能保证正确啊，能够有非常好的这种表现力和这个比较容易的操作啊，这都是flink的特点，那这里边必须要提的就是首先有一个stop，大家看。STEM它其实可以认为就是流处理器的这个先锋了啊，它其实就是第一代流处理器，所以它的主要特点就是。

只是快，只有低延迟啊，那么它的这个吞吐量呢，其实也做不到特别特别大，对吧，尽管它已经是一个大数据的处理引擎了，但它的吞吐量其实就做不到，那另外就是也保证不了时间正确，对吧？啊，就是乱序的那个数据它是搞不定的，那另外需要给大家说的一个就是SPA streaming，它比较特殊一点，它其实并不是这个标准的流处理一代一代演变过来的结果，它其实是。从批处理那边演变过来的一种处理方式啊，那它的特点是什么呢？它的特点其实就是高吞吐，那另外就是它，它可以保证在压力下保持正确啊，这个都是没有问题的啊，容错这个也是非常好的，但是他就做不到。啊，非常低的延迟，对吧，他就做不到像STEM那样的一个毫秒级别的延迟，那另外就是对于这个时间正确，大家想一下SPA streaming里边，假如说我出现这个乱序数据，它能处理吗。好像也没有这样的概念，对吧，你要想直接去处理的话，那是不是还是得自己在代码逻辑里面定义，我把它攒一批，然后你去做排序，做比对，再去做处理的话，是可以做到的啊，所以就是flink其实是把所有的这些优点啊，所有的这些特征都做到了，这就是flink最有优势的地方。