003.尚硅谷_Flink-流式处理的提出

我们现在已经知道了，关于流式处理在实际生活当中的一个重要，各行各业其实都需要用这样的处理方式啊，那我们知道其实在呃，现在啊，传统的处理架构里边，好像并没怎么听说有这样的流式处理这样的概念。那传统的数据处理架构是什么样的呢？啊，我们知道在这个数十年来啊，最近几十年来，数据和数据处理在每个行业的企业当中都无处不在，呃，那我们行业里边的这个数据一直在增长，那公司呢，就会设计相应的这些数据结构基础架构来管理数据。最早期的时候，我们知道这个数据比较少嘛，那我当然就是直接放数据库就完了啊，而且之前的话，我们会有自己的一套这个业务响应系统，需要跟用户或者说呃，就是跟这个操作人员啊，内部的管理人员去做一些交互，所以大家看最经典的数据处理架构，就是所谓的事物型处理的这样的一个架构。

啊，那我们看到这个整个的处理结构呢，可以分成两层，上面这一部分叫compute，叫计算层，那下面这一部分叫storage storage叫存储层，那所以这两部分它的功能分的非常的开，就是首先计算层这里是干什么呢？就是接收用户的请求，或者接收外部的某个事件，大家看这里面都是event events嘛，都是事件，事件来了之后，我这里边有一整套系统，比方说CRM，这是客户关关系管理系统啊，或者说像ERP啊，像这个企业资源管理系统，对吧？啊，那另外还有这个订单系统，哎，我这里边用户下了一个订单，或者说我们就是一个网站的APP，用户有一个点击操作，不管是什么样，它其实都是会发送一条数据，作为一个事件进入到当前我们的处理系统来。

然后处理系统呢，这里边就会啊，就最后我们的想要的这个处理结果是得到一个响应反馈给用户，那在这个计算的过程当中呢，可能需要用到一些外部数据，可能还需要改动外部数据里边存储的一些东西，那这个过程我们就要去跟。传统的关系型数据库去做交互了DBMF对吧？啊，那这一部分数据我们都是存在关系型数据库里，所以我们接到请求之后，业务系统会去查询数据库里边的信息，拿到想要用到的那些信息，然后结合当前的请求去做计算处理，得到的结果呢，可能有一部分要改动数据再写入回到关系型数据库里边来，然后另外包装成一个响应返回给用户，这就是我们最传统的这种事物处理的过程啊，我们所所有的这个应用程序啊，所有的现在这个互联网前后台的这种架构都是基于这样的。

处理架构去搭建的啊，这是大家比较熟悉的过程。那在呃，处理应用的过程当中，可能我们就会发现了这个数据库，传统的关系型数据库，它所能存储的数据毕竟有限，而且这里边我们所想要的是什么呢？想要的就是那些对于用户行为啊，我们想要去获取一个实时的反馈，对吧，实时的响应，我们其实想要存的就是那些强业务关联的那些数据。那对于有一些数据，你比方说就说这个点击对吧，用户这里边点了一下页面，那当前的这个点击的数据，我需要每次都存到这个数据库里边吗？其实是没有必要的啊，那我们就想到其实可以怎么样，当这个数据越来越大对吧，就是数据库有可能已经存不下，而且我们发现它这个使用的时候呢，也未必一定要把它都存到关系型数据库里的时候。

那就衍衍生出了另外的一种数数据处理架构，就是大家更加熟悉的所谓的这种分析处理的架构，它的主要思路是什么呢？就是数据已经非常多了，哎，我们先把它就是该存在哪里存在哪里，对吧？有可能就是传统的关系数据库，也有可能我们就是直接从一些日志log里边去做提取，不管是从哪里来吧，我们整个要有一个这样的所谓的提取转换的进程，也就是ETL的一个进程，把它做统一的转换处理，得到的结果呢？格式化之后，我们放在所谓的data warehouse里边，也就是数仓里面去，那这样的一个过程就是放到数字仓里边去之后呢，接下来我就可以，哎，直接跑一个，呃，分析的这个统计统计分析对吧？呃输出生成一张这个报表，或者说呢，还可以基于当前的数仓，或者说其他的一些数据库去做一些及时查询，这些都是可以做到的。

啊，那这个过程主要主要的一个问题就在于我需要先把数据从业务数据库或者从业务日志里边先复制出来，做ETL转换，把它塞到存储到数仓，然后再去做分析和查询。啊，那所以这个过程大家比较熟悉，这就是一个离线处理对吧，大数据的离线处理转换的过程啊，那我们呃，它的跟前面这个事物处理相比，它的特点在于我们能够处理的数据更多更丰富了。呃，那那它这算是一个优点吧，它的缺点在哪里呢？啊，缺点就在于你必须要把所有的数据都提取出来，放在数仓里，才能去跑那个C口，对吧，才能去去运行，呃，统计它的这个查询结果，所以这个过程实时性就差了很多。

我们之前在这个传统的事物处理的过程当中，用户那边的响应是实时拿到的，现在做不到了啊，所以这里边大家就会想到我如果说啊，如果我现在想要的这个报表，或者说这个机器查询。我要求实时性很高呢，我必须要这边就是业务数据那边一一改变，我这边就要做一个统计，做一个输出，能不能做到呢？啊，有一种思路我们可能想到就是像之前学习过的这个实施项目里边啊，我们用Spark streaming对吧？啊，那么Spark streaming它的一个处理思路其实是什么啊，其实还是基于整个我们离线处理这个思路，它是把我们来的所有数据呢，你不要等到所有数据都到期，因为你现在是连续不断来的嘛，流失数据嘛，我想要做实时处理，那怎么办呢？我就。分成一个一个小的批次对吧？来一小批我处理一次，来一小批处理一次，那最后的本质相当于还是把它攒齐了啊，尽管我不一定非要扔到数仓里对吧？呃，我也可以在其他地方去做这个处理啊，最后得到这样的一个统计结果。

那这个过程大家会发现你还是有一个就相当于架构上，我还是要先把它做一个转换，把它做一个提取啊，对吧，有一个攒一批的过程啊，那这个过程能不能省掉呢。哎，从这个角度出发，那其实就有了所谓的流处理架构的出现，我们自然就会想到你，你何必那么麻烦呢，对吧？你何必非要把这个数据都攒齐了就去做处理呢？我就直接借鉴之前的事物处理的这个过程，来一个数据，我当前的这个业务数据库，呃，不不不是业务数据库啊，就是当前的这个业务系统直接就做反应，然后给他一个返回，不就完了吗？哎，那我们就想到我之前的这个架构主要的问题在哪儿，主要是因为我还有数据得从数据库里拿呀，好，那我现在既然是想要做这个扩充，那我就不要依赖之前的数据库了，我干脆怎么样，我直接就把所有的数据都放在当前机器的内存里边，那大家想你如果都放在内存的话，是不是一方面这个存取速度更快了，比之前的这个事物处理我们这个响应的过程还快，对吧？啊，那另外一方面呢，你如果放在内存里边，我们扩展起来怎么扩展？

那就是整个分布式架构，你扩展这个集群，机器数量增加就可以了嘛，就跟这个数据库完全没关系了。啊，所以这里边的一个基本的想法就是说。诶，构建这样的一一个这样一套架构，就是数据来了之后，大家看这里边的圆圈一个一个来，我们这里边的机器处理呢，有一整套应用逻辑，然后通过这个逻辑，我想要每一个数据来了之后呢，对应的都有一个输出，然后在做这个输出计算的时候，我可能需要应用到其他的一些数据，这些数据叫做什么呢？

诶，我之前是把它存在数据库里边，业务叫做业务数据对吧，把它这个存储在数据库里，现在我跟数据库没关系了，我直接把它叫做本地状态，放在本地内存里边就完事了。啊，所以大家看这个交互的过程，这不就相当于我们前面做事物处理时候跟数据库的交互过程吗？而且它还更快。啊，那你这样去做这个架构调整，它有没有什么问题呢？当然有问题，你既然放在这个内存里边，我们知道内存最大的一个问题就在于它快是快，但是不稳定啊，你一旦要是掉电，一旦要是出现故障，所有的东西都没了，都丢掉了。啊，所以这里面我们为了保证它的容错性，出现故障的时候能够恢复，还需要定期的去对当前的状态做一个存盘。

啊，所以大家看，就是关于这个本地状态呢，我还应该有一个周期性的，哎，叫做检查点的操作啊checkpoint，关于检查点我们之前在Spark里边也接触过，大家也已经接触过，那弗link里边这个检查点的概念呢类似，但是它底层的机制又会不同啊，这个我们到后边涉及到的时候，再给大家详细做展开，这里我们只要需要就是周只只要需要知道就是周期性的要去做一个检查点操作，把当前的状态保存在远程的存储空间，哎，把它持久化，这样的话，到时候如果出现故障要恢复的时候，我还有一个持久化的空间，可以把状态恢复出来。这样就解决了我们这样一个问题啊，所以这就是呃，从这个传统的处处理架构啊，数据处理架构，我们发现它的这个不足，然后提出的这样一个流式处理的数据处理架构。