00:00
我们已经知道flink有非常多的应用了,那接下来我们来说一说为什么在企业当中要选择flink呢?诶,这主要就是涉及到了一个问题。就是我们要处理的数据到底是什么样的。数据处理它是有不同的方式的,很多场景下数据它是怎么样来的呢?正常情况下数据应该都是一个一个来的,哎,那当然有些场景下可以一直在那等着,一直攒着,让数据攒够一批之后,然后再去处理,这种处理方式就叫做批处理。然后另外一种方式呢,那就是来一个数据就处理一个,来一个数据就处理一个,这种方式就叫做流处理。所以这是两种截然不同的处理方式,基于这样不同的处理方式产生出来不同的设计理念,就能构建出不同的处理框架。那像之前哈杜Spark,它其实都是基于批处理思路,而flink呢,就是基于流处理的一个思路。
01:00
啊,那真实的场景下啊,到底数据它是一批一批来的多,还是一个一个像一个数据流一样来的多呢?我们仔细想一想,其实就可以发现在生活当中更多的。还是流逝的数据啊,当然其实在生活当中,这个各种数据都有啊,比方说我们举一个最简单的例子,就比方说我们平常发信息做交流,像不管是QQ还是微信啊,我跟一个人要聊天,我们可以打一句话,一回车马上就发过去,然后要说下一句话,然后再一回车再发过去,这就是一条一条的发送。当然你也可以用另外一种方式,就是把这段时间要说的话,所有的都换行全编辑好,然后一个回车,一下子发过去,甚至有可能你直接编辑成一份文件,编辑成一个word,一个TXT,直接发送过去,这也是一种方式。那大家想一想,平常我们聊天的时候,你用哪种方式聊呢?当然应该是一句话一句话的聊啊,因为我发一条信息,其实是你那边实时的获取到之后,应该要针对这条信息给我做一个反馈的。
02:07
这样的话,你一言我一语,这才叫聊天嘛,那如果说我要把所有说的话都放在里边的话,那就相当于在这个中间我是不需要你任何反馈的,你只要拿到我这里边的所有的话就可以了,那这个还叫聊天吗?这叫写信啊,如果要是真是想说更多的话的话,那你直接发邮件,直接写一封信不是更好吗?所以在这种场景下,更多的情况我们其实。使用的是流数据,我们产生出来的是流数据,那我们处理它的方式呢,其实就是一个流处理啊,那我经常看不到这个手机,我我们经常可能有有别的事儿在做别的事情,那手机来了信息,我不可能随时看到,随时去响应啊,那怎么办呢?那就先攒着呗,攒一批,等我有时间的时候,看到所有的信息,我再把它来做一个反馈。哎,所以大家其实会看到我们真实的数据是流数据,但是处理的时候呢,未必一定要用流处理的方式,就是来一个就马上实施响应。
03:08
那大家就会想到,对于这个真实的流数据来讲,到底是用批处理好还是流处理好呢?这个其实也两说,从实时性的角度来讲,聊天你当然就应该是实时的聊啊,那别人给你发这个及时的信息,就是希望及秒回,这个当然是最好的一种状态,但是很多情况下我们做不到那么实时啊,有可能我们手头有很多更加重要的事情,就是我们手头的要处理的数据太多了,你这个数据来了之后没办法直接处理,那怎么办呢?哎,那我们把它先攒起来,攒一批一起处理,也不失为一个非常好的方法,而且在现实当中,我们可能更习惯于批处理。因为如果你要实时去做响应的话,这个其实是代价很大的,相当于我们随时要在两种场景之间做切换,就相当于你随时等着接电话,那你这个精神是紧张的,你没有办法去集中精力做好一件事情。
04:06
那同样对于计算机系统,一个数据处理系统也是一样,如果说我要实时的去响应每一个新的事件,每一个新的数据的话,诶,那这个计算机系统要做的事情就非常多了,非常麻烦了,所以它更简单的设计是怎么设计呢?就是我攒着嘛,你要来的数据你先来吧,我先来一个缓存给你,先放在那儿,你把所有的数据都已经存好了,接下来我再统一把数据拿出来,统一去做一个处理计算。哎,所以批处理它尽管实时性不够好,但是他从系统设计和我们就是实际经验来看,都是一个比较方便也比较高效的方式,这也是为什么我们之前接触到的这种数据处理好像都是批处理。现在批处理的问题是什么呢?就是因为尽管它简单,但是它慢了,你如果要是一直等着,要等所有数据都到齐再去处理,那那这不就有了很高的延迟了吗?我们现在很多前面说的那些场景,就是要快,就是要马上来了一个事件之后就做出及时的反应,所以我们的目标是要低延迟。
05:15
也就是实时性要非常好,来了一个数据,立刻做出响应,立刻判断它带来了什么样的一个效果啊,进行计算处理。与此同时,你不能光快啊,网站服务啊,我们的后台系统,一个服务器,它不就很快吗?APP在应用上随便点一个页面,马上它刷新之后就给我们弹出了一个新的页面啊,我们点一个按钮就做出了相应的操作,这不就是一个实时的响应吗?没问题啊,但是如果数据量大到一定程度。可能我们的服务器就扛不住了,网络的吞吐量还在其次啊,因为网络的话我们可以增加带宽,可以增加这个集群的数量啊,机器可以可以更多更大的瓶颈其实是在于数据的处理以及处理的过程当中,需要去读取一些数据库,读取数据库里边的一些信息,对于数据库的读写,这个数据量很大的时候是非常麻烦的,特别是像我们之前涉及到连表操作的时候,连表查询的时候。
06:16
我们现在的问题就是要保证快、低延迟,还要保证高吞吐。很快的处理非常海量的数据。除此之外呢,还应该要保证结果的正确性和良好的容错性,这是什么意思呢?你要保证高吞吐,那正常来讲,现在我们肯定都是做一个集群嘛,分布式处理嘛,分布式处理有一个问题就是。当前数据的顺序就没有办法保证了啊,如果说我们是一台处理器去处理的话,那你这里边来的数据留数据嘛,一个一个来,一个一个处理,能保证它的顺序,但假如说我这里是很多个服务器同时处理的话,那数据有些分到这儿,有些分到这儿,他们在网络传输和这个处理过程当中会有差异,是不是就没有办法保证最初的原始的顺序了呢?
07:12
哎,所以这有可能导致我们最后结果不正确,对于批处理来讲,其实没有这个问题,因为批处理的话,我反正都要把它攒起来,那攒起来之后,我最后再去判断谁先谁后不就行了吗?再排个序不就行了吗?那流处理不行啊,流处理有可能我这个数据来了之后,本来应该在他之前的,结果因为他发到另外一个服务器了,还没来,哎,那我这个他还没来,我没办法处理啊,所以实时处理就有这个问题,我们怎么能保证它顺序是正确的,结果是准确的呢?这是另外一个问题,还有就是良好的容错性,什么叫容错?那就是如果发生故障。发生故障之后,还可以恢复到故障之前的某个状态,然后继续正确的处理。那对于一台服务器的话,这个非常简单,我重启服务器就完了嘛,所有的数据我都存在了数据库里边,服务器重启之后读取数据库加载进来,不就照样重新去计算了吗?但是对于大数据处理而言,它不是用数据库了。
08:16
那你存储的数据怎么样保证它不丢呢?哎,这就是另外一个问题,所以如果能够解决所有的这些问题,用之前接触过的那些框架是解决不了,谁能解决呢?弗link,可以啊,这就是flink给我们带来的革命性的变化,那他怎么样去做到的这几项,后面我们展开讲解它的原理之后就会有所了解吗?
我来说两句