002_尚硅谷大数据技术_Flink理论_Flink简介（二）为什么要用Flink

再来呢，我们来看一看flink在全球范围内的一个热度的体现啊，大家看这张图其实看的一目了然啊啊flink其实现在从它产生啊开始发展之后，呃，其实就是在短短的几年时间内啊，已经得到了非踌速广泛的这种发展和应用，那在可以说是在全球范围内都有应用啊，那主要集中在其实就是欧洲北美对吧，然后还有这个金砖国家，大家看这个俄罗斯，巴西，中国印度啊，就主要就是这些比较发达，然后技术也走在这个全球前列的这些国家，那当前这个全球的热度，如果大家要来对比的话啊，大家会发现集中在哪里呢？啊，就集中在中国对吧？啊甚至我们看到如果说中国的热度是100是满分的话，其他地方，其他地区的热度可能只有个位数。为什么会出现这样的一种场景呢？啊，当然大家会想到，首先我们说这是因为中国国内有巨头在挑头做这件事儿啊，这个以阿里为首的啊，一众互联网巨头公司都在FNK上有很大的投入啊，都在着重发展这一块的流失处理计算啊，啊那为什么中国国内的公司就。

对flink的兴趣就这么浓厚呢？啊其实我们可以想到啊，首先一方面是因为呃，国内我们的这个技术实力也很强啊，很多这个大公司也是走在了这个国际的前列啊，我们会尝试一些新兴的这个框架和新兴的技术的，首先一方面是这个啊，我们创新能力是足够的，另外一方面，其实大家想到是不是主要是因为中国人多啊，啊对吧，大家想中国人多，那就是特别是中国的这个一线大厂，像像阿里，像京东啊，像这个腾讯这些大厂，他们会遇到一个什么样的一个问题呢？就是我在短时间内，假如说我想去做这个实时计算，是不是有可能那个数据量非常非常大呀，诶就有可能达到什么级别，就是达到直接就是上亿个用户的数据啊，就是几几亿条，十几亿几十亿的这个数据啊，短时间内大量的就来了啊，大家想这种场景，这在国外完全就不可想象啊，你说一个国家一共才几千万人啊，你。

总共这个上亿的用户，我到哪儿找那么多用户呢？啊，所以这种应用场景在国内来讲，可以说是很多公司的一个挑战，那也是一个推动公司技术进步的一个动力，对吧，你因为要解决这样的极端的场景，所以说我们就要找更新的技术，更好的框架来解决啊，那所以呃，Flink其实就是在这种场景下啊，有有了这个长足的进步和发展的。那我们再看一下，在目前国内企业里边，到底哪些企业有应用呢？啊，那这张图其实是很多，其实我们可以看到啊，几乎就是所有的这个一线大厂都有比较丰富的应用，那以阿里为首，阿里腾讯，华为，网易对吧？啊，滴滴饿了么，京东360啊就这涵盖的也是各行各业，包括啊电商，即时通讯啊，就包括这个偏硬件啊，做做硬件相关的内容，包括门户网站，包括我们这个安全方面的网络安全，还有这个呃，视频网站，还有这个出行打车啊，外卖的一些网站啊，就这些所有的场景下，其实都有flink的应用，那所以大家就会想到，呃，为什么在这些行业里边都会有应用，大家都想用flink去做数据处理呢？

哎，那接下来我们其实要解决的一个问题就是为什么选择flink。首先我们想这样的一个问题啊，我们在日常生活中，大家遇到的这个数据，我们现在要处理数据做计算呢，大家见到的这个数据应该是什么样的呢？啊，有同学可能说那数据长什么样，那不就是呃一开始我们那个收集日志嘛，是吧？啊，他本身那个当时那个日志写什么数据，不就是什么数据吗？我们这里说的并不是说它具体一条数据是什么样啊，因为我们现在是呃大数据处理嘛，我们说的是大量海量的数据，他来到我们的处理系统里边的时候是什么样子。

那主要的区分就是它是一整批来的呢，还是说数据是源源不断的产生，源源不断的来的呢？哎，有同学说，诶，那我们一般处理数据好像是一批一批来的，对吧？哎，那这个就我们要考虑一下，数据在真实生成的时候，在生产环境里边，它是一批一批产生的吗？对，所以这就涉及到一个问题了，大家其实会发现我们真实的这个生产环境里边，数据其实产生的过程是连续不断的，对不对？你说我们收集这个日志啊，往往我们都是一个这个网站应用嘛，有自己的这个后台处理系统，我们收集的是用户的一些行为，或者说系统内发生的一些事件，那这些事件是不是我并不能确定，他在哪个时间段内就可以生成一一组事件，然后一下子传输啊，它本身发生事件是不是随时都会发生，哎，你像用户那边有点击操作对吧，有这个下单行为，他那边是不是随时都有可能发生啊。

你并不可能限定说，诶一定就是这个时间段，你来来一批用户的点击直接发给我啊，所以在真实的处理场景下，数据是连续不断生成的，它的这种生成的模式，这就叫做数据流，或者说流逝的数据，就是前面我们提到的data streams，这个数据的特点就是它不是攒一批直接发出来，直接拿过来的，而是。一个一个连续不断，就像水流一样，这就是数据流的一个概念。啊，那举一个生活当中的例子，大家可能就理解的更加明显了啊，啊，那就是比方说像我们这个平常聊天，我们拿一些即时通讯的这个工具，QQ或者微信，大家在聊天的时候，你说你这个聊天数据是我们的数据，就是聊天要说的话，对吧，你是攒一堆话，然后一次回车，一下子发给对方呢，还是说我有一句就发一条，有一句发一条啊，一般我们肯定都是有一条就发一条，对不对，然后那对方那边直接收到之后，就可以跟你回复，就可以跟你聊天了，你如果要是攒一批一下子发过去的话，这这叫写信，这这叫写邮件，对不对，对吧？这其实就跟我们这个日常行为，大家就会看到啊，写信这种方式就有点儿像是一批攒一批，然后以下发的这种方式，而我们实时的聊天其实是一个流处理流数据，来一条数据就发一条，这样的一个状态。

那自然我们就想到另外一个问题了，为什么我们在真实处理的时候，大家感觉好像大部分我们用到的数据都是一批一批来的呢？啊，其实主要的问题就在于，如果你要是处理流数据的话，大家想他连续不断的来，那是不是我这边就得一直等着，然后来一个就得处理一个呀，这个过程是不是就会特别的麻烦，呃，像我们这个生活当中，大家也都很习惯嘛，就是你像我们这个聊天的话，最好的方式当然就是别人发一条，是不是我这边收到了之后处理也应该是看到一条信息，我就马上要处理一条啊，这样这才叫聊天嘛啊，你发一个我发一个，你一言我一语聊起来了，但是往往我们经翅出现什么状况，我这会儿有别的事儿在忙，对吧，那是不是我处理信息的时候就不会那么及时啊。

所以大家会想到，我们往往就会用一个什么样的方式。我就不要是说好像是时刻待命，随时都在盯着手机信息的这个状态，我就是我可以先干别的，然后呢，我过一段时间看一下，诶过去的这段时间到底有谁给我发信息了呢，然后我来，诶相当于是不是批量处理一下呀。所以大家会发现，对于这个人来讲是这样，对于机器来讲也是这样，你如果让这个机器，他要不停的等待随时发生的事件，然后来一个就处理一个，这对于机器来讲，它性能的要求是比较高的，那机器更容易做什么事情呢？那就是你隔一段时间数据都攒齐了，来一批放在那儿，然后你让我做什么计算，我就做什么嘛，对吧？你要统计这个求和，我就统计求和，你要算平均数，我就算一个平均数，这不是非常简单的一件事情吗？

啊，所以大家看，就是我们传统的数据架构，一般即使是处理这个流式的数据，我们现在也都是用攒成一批，我们都是把它当成一个数据集来进行处理的，这就是我们想要的这个实际处理流程和现实的一个差别。那大家想一下，就是我们传统的这种处理方式，基于数据集有什么问题没有？它做起来是比较比较容易是吧，很很容易实现，但是对大家就想到你既然要攒一批再去做处理嘛，那这个攒一批的过程是不是就需要等一段时间啊，那就没有那么实时了，所以大家会发现，就像前面我们呃讲过这个实时处理的时候，可以用Spark streaming Spark streaming，他在处理这个数据的时候。

是不是也是一批一批的攒起来的，那这个过程它能达到非常实时吗？啊，其实我们知道一般情况我们要设置那个back Du对吧，就是批处理的那个时间的这个，呃，持续的长度啊，那个间隔，呃，一般情况我们可能都要设一个。啊，就是几百毫秒到几秒对吧，诶可能要达到一个秒级的延迟，那所以现在我们的目标我们就要提出一个新的任务了，我们希望要做到的是。更低的延迟，我们要做到毫秒级别的延迟。哦，那有同学可能想，那你这个要延迟比较低的话，这个简单吗？之前你不是说了吗？那我们就来一个处理一个吗？你数据这个每来一条数据，我马上接收到之后就直接处理，这不就完事了吗？哎，这个还没完，我们不简简单单的只是要做低延迟，我还需要。

对，还要吞吐量大，对吧，我还要能处理非常海量的数据，你像我们之前这个大数据处理的架构里边，大家想我们是怎么样处理海量数据的呢。之前我们是不是直接做一个分布式的扩展啊。只要我当前这个处理引擎是一个分布式的集群结构，那接下来是不是所有数据来了之后，我可以给他做这个分区处理，对吧，分区完了之后，然后然后再再合并在一起啊，最后得到一个最终的结果，这个就完事了，所以这是一个基本的思路。那我怎么样能够同时做到低延迟和高吞吐呢？啊，所以这就是接下来flink啊，呃，我们想要的这种新式的处理引擎，它要解决的这样一个问题。那最后呢，我还要保持一个结果的正确性和良好的容错性，这说的是什么呢？这其实大家会想到，就是如果说我要想实现这个高吞吐，那我是不是必须要做分布式，诶你一台机器搞不定了嘛，你直接加这个机器的性能，你CPU再强劲，这个内存再大，它它总也是有限的，对吧？啊，这个往上扩容，而且那个代价会越来越高，所以我们现在的大数据处理的方式，一般都是做这个分布式的扩展，那这种扩展的话就就会带来另外一个问题，我们还要低延迟。

低延迟的话，那是不是来一个就处理一个马上就处理啊，那就带来一个非常显著的问题，就是说我既然是分布式了，是不是在传输过程和中间处理的过程当中，数据有可能会出现这种乱序的情况啊。什么叫乱序呢？就是本来我这个数据，因为你是来一个就处理一个嘛，本来我这个数据是在前面的，然后经过这个网络传输啊，本来就有延迟，然后呢，它又分开分布式的去做处理，那是不是到后边去合并的时候，就有可能导致本来是在前面的，经过传输之后到后边了，对吧？那是不是就会导致我们最终结果不正确啊。

哎，所以这个问题就来了，你怎么能在这种场景下有保证结果正确呢？那当然最后还有一个就是容错性，这也是分布式架构里边的一个必须要解决的问题，因为分布式里边如果我们要有一个节点挂了的话。那大家想是不是就整个都都挂了，我得重新来了，所以在整个我们如果要是你对实时性很高的话，一个节点挂了，你就所有节点都回滚，就是全部都重新来做计算，这个代价太高，而且我们现在要处理的是流市数据，流市数据是不是源源不断的来啊，那你现在如果要是直接回滚到最早的那个源头的话，哇，那那这个数据量太大了是吧？啊，所以我们当然是要有良好的容错性，就是一个挂了之后，我还可以回滚到非常近的一个状态，然后直接跟上去去做计算就可以了，不要让所有的状态都回退到最初啊，所以这就是我们接下来要去实现的一些内容啊，我们的目标就是这几点。