00:00
已经知道flink是什么了，也知道它有非常广阔的应用，在很多公司都有这个应用场景，那为什么这些公司都选择了flink呢？呃，一方面大家可能想到，首先是有这个领头的头部的行业公司在，呃在在引领潮流嘛，那那另外一方面，大家会想，为什么我们这些大公司，头部的这些大企业，他们就要引领这个flink这个潮潮流呢？它到底好在哪里呢？这里我们首先要有一个这样的概念啊，那就是flink到底要处理什么数据呢？前面我们通过官网上面的那一句定义，大家也看到了，他处处理的是什么，是data streams，也就是说它处理的是数据流，处理的是流逝数据，那这个流式数据有什么特点呢？就是我们前面说的像水流一样连续不断，这个在生活场景里边怎么样去，呃，考虑这个什么叫做流式数据呢？数据流呢？哎，我们可以想象一个这个场景啊，呃，那比方说我们在平常大家都很熟悉实时通讯的时候，我们有聊天软件，你在聊天的时候，大家想想产生的这个数据应该是连续不断产生的呢，还是啊，与之对应，如果不是连续不断产产生，那就应该是，哎，比方说隔一段时间我一下子产生，而且是产生一批，对吧？哎，所以流式数据处理，它与之对应的概念一般就是P式数据处理，批处理。
01:37
那大家想一想，我们在这个聊天的场景里边，你应该是连续不断产生，还是隔段时间产生一批啊，那当然。当然应该是连续不断对吧？啊，就是你那边产生一条数据，产生了之后马上发过来，我收到之后呢，诶就做一个回复，然然后回复过去，你一言我一语，这样一交互，这才叫聊天嘛。那如果说你要是攒一堆信息，然后一下子再给我发过来，那我这边也是收到了之后呢，呃，我我我这个有可能这会儿正正在忙，对吧，我可能攒一段时间，然后看到所有的内容之后，再一批再给你回复过去，这就不叫聊天了啊，这不叫这个信息的聊天对吧，实时通讯的这个聊天，这叫发邮件。
02:23
所以大家会发现，发邮件更像的就是一个类似于批示处理，一批处理的这个过程，而聊天实时的这个聊天就更像是一个哎，流逝数据的一个过程。那另外我们在其他的一些场景里边，其实流失数据也非常常见，比方说我们这个汽车在驾驶的过程当中，大家知道现在都有这个GPS定位嘛，那你说他发出的这个GPS信号啊，去做定位的这个信号，这个数据是应该隔一段时间发出一堆数据批量去处理呢？还是说应该只要有新的定位信息，有新的数据就马上去发送，马上去处理。
03:04
当然应该是实时处理对吧？啊，因为汽车当前的位置，它高速行驶过程当中，你如果要是隔一段时间再去处理的话，哎哟，那这这车都已经不知道跑到哪里去了，哎，你这个定位肯定不准吧，所以我们这里边要做的这些场景，大家会发现啊，其实在生活当中更多的场景。都是流失数据，因为我们本身数据产生的这个时间，它本来就就是不固定的呀，啊，本来就是随时都有可能产生，我们也希望只要它产生出来，是不是就应该随时去处做处理呢？所以说在这种场景下啊，那流逝的数据其实是更加真实的反映了我们的生活方式的。啊，你像那个发邮件，那其实主要是在工作场景下，我们可能为了正式对吧？呃，那另外也为了就是我不可能随时的去查收邮件，我可能就是隔一段时间去查查一下，然后去回复一下，当然你如果要是做到有这个呃，邮件邮箱提醒的话，大家想到那也就类似于一个流失数据了，对不对啊，就是产生之后马上接收，马上去回复，这也就跟聊天一样了啊，所以说正常来讲，生活当中我们更多的。
04:20
都是流失数据。而且我们希望更快速的对他做出反应，做出处理。那我们就会有一个疑惑，为什么我们之前好像印象当中其他的这些框架和这个呃，处理的工具不是这么去做的呢？诶大家可以回回忆一下像这个哈，Spark它是怎么做的。他其实是要把这些数据都收集齐了，对吧，那它其实是整个已经数据都攒够一批之后放在那里，然后我们再去做数据处理。再去做分析，那为什么是这样的呢？啊呃，这其实这主要是在实际应用过程当中的一个考量了，传统的数据架构里边呢，我们会想到实际的这个流失数据，我想去处理对吧，但是它它它连续不断啊，没头没尾的，呃，或者说是这个有头没尾对吧，连续的无限产生的，另外它还是它还是这个不均匀的，有时候多，有时候少，那这个时候我怎么能保证它这个每来一条就马上去做处理呢？那这个整个这个架构不好去做，不好去设计，那更简单的方式是什么样的呢？啊，相比之下更容易实现的方式就是我就等着对吧，就就一直等你这个数据来，你先来，等你都来齐了之后，我把你所有的数据统一拿出来，然后去做一下计算，你该加加，该减减，对吧？哎，各种运算一做处理就完事了。
05:50
这个过程就非常的简单，所以大家看到为了计算机实现方便，所以传统的数据架构呢，它一般都是基于所谓的有限数据集的，有限数据集就是诶，当前的这个数据，它本身规模大小是一定的，而且我们在处理的过程当中呢，它不会继续去增长，对吧？啊，就是当前这个是多少数，放到这儿就是这么多。
06:17
那我们现在的目标是什么呢？呃，这之之前我们用这个有限数据集去处理问题，我们说了这个主要就是基于这个应用实际实操方便来考虑的，那这个方便是方便了，它有没有什么问题呢？这个问题最大的一个问题就在于，你既然是要等所有数据都到齐攒一批去处理，那是不是它的实时性就没那么好啊？啊，所以说这其实就是流式处理，或者说flink最主要的想要去解决的一个场景解决的一个问题，那就是我们希望在做这个大数据处理计算的时候呢，做到低延迟，就是整个处理的延迟不要那么高，不要攒一批再去处理，来一个就马上处理。
07:06
啊，那另外我们还得有有一个要求，就是说你不能说有有同学可能想到，那这还不简单吗？你像我们传统的这个服务器，哎，我们的这个web服务器，或者说我们传统的一个单机的这个应用程序，那它不就是一个一个低延迟的吗？你来一条数据，我我就顺序的处理不就完了吗？啊，那我们现在的处理场景不能这么简单，因为我们是大数据环境，你还得怎么样，哎，还得满足这个高吞吐的要求。你必须要数据量大，你不能说，诶我这里边就那么，呃，就是一个小时来一条数据对吧？啊，那我一台机器肯定可以搞定啊，你你实时处理低延迟完全没问题，我们处理的不是这种场景，我要的是呃，你比方说这个每秒钟这个上万条数据对吧，甚至几十万条数据就来了，你这样的场景怎么样去处理？啊，这是我们要考虑的场景，那对于这个高吞吐啊，那其实就是想要做并发处理嘛，并行处理嘛，并行处理的话，基本的一个思路，当然就是说扩展集群分布式嘛，哎，所以这这个思路其实非常简单的能够想到的，但是在分布式场景下呢，又有另外一个问题。
08:21
就是大家可能会想到，我们之前如果说你是攒一批，然后去分布式做计算的话，这个比较简单，因为我们数据都到齐了嘛，你把它分开，该分到哪个分区，然后去做计算，这个是现成的。但是现在你如果说他数据还不确定对吧，来随时要来新的，然后我还要低延迟随时做做处理，做计算，那就涉这就涉及到一个问题，我怎么能保证他最后处理的结果是对的呢。另外还有一个问题，就是说我在这个处理的传输的过程当中，分布式架构嘛，那本身它传输过程当中也有延迟，那是不是就有可能我之前的数据，本来先进先到的数据，经过网络传输之后，到后面处理的时候它滞后了。
09:08
那对于这样的一些乱序数据的情况，我怎么能保证他最后是正确处理的呢？啊，这些都是问题对吧？啊，另外还涉及到一个就是分布式架构，假如说我里边某一个节点挂掉了，这个节点节点出错了，那我最后怎么保证它能够容错，能够再恢复过来呢？这些都是我们要要去处理的问题啊，那那就是flink会帮我们解决这些问题，对吧？这是我们现在的目标，我们希望同时做到低延迟，高吞吐，以及保保证结果的准确性和良好的容错性。哎，那这里边接下来我们再给大家说一下，到底flink应用的行业啊，哪些行业需要有这么高的要求，其实整体来讲的话，大家会想到，诶，那你说什么样的行业需要这个低延迟高吞吐，而且要求结果的准确性呢？
10:06
那我们看的话，这个目标其实他对行业没有要求，对吧。你任何一个行业低延迟我能处理的更快，难道你不希望吗？当然希望吗？呃，或者说我高吞吐，我能同时处理的这个数据量更大，你不希望吗？当然是希望的，所以说所有的这些目标可以说是我们在做数据处理的过程当中的核心目标，所有行业都能够做，都能够用。啊，那后面大家又看到，呃，这里边列出来的有这么主要的啊，有这么几大行业啊，具体的应用场景，但是远远不止这这几大行业啊，那这里边我可以给大家举一个例子啊，比方说我们以第一个行业就电商和市场营销，这个里边例子是非常非常的经典啊，也是非常的，呃，就是最初我们去考虑这个问题的时候，其实就是从这个市场营销的这个角度出发啊，提出这样一个问题啊，那大家知道在现代零售业里边啊，我们平常要统计的这个数据，要去做大数据处理分析的数据，很重要的一个指标就是网站的点击量啊，对吧？哎，我们有些时候这个生成数据报表的时候，统计这个浏览量，访问量，统计当前的这个热度，甚至统计销量，我们直接就是按照点击量去做，做这个统计处理的啊，那另外还有一些广告投放啊，像我们说一个页面上，我可以这个怎么样去判断这个。
11:34
这个广告它的这个收费标准呢，对吧，或者说我当前这个广告到底应该放在哪个页面上呢？这些我们都是基于当前网页的浏览量，访问量或者说点击量来去做处理的。而点击量大家想这个数据，这你跟这个本身那个订单就不是一回事了，订单可能这个数据量比较少，因为用户不可能他频繁的刷单嘛，那那是一种异常行为了啊，那这里边如果要是点击量的话，有可能短时间就非常非常多，数据量非常非常大，而且它是连续不断。
12:10
而且是不均匀的。所以对于这种场景，用以往的手段，而且我这里还还要去实时反馈，对吧，你你想想就是说这个呃，广告的投放，我可能实时要对他这个策略进行调整啊，或者说这里边生成数据报表啊，有时候我要求他这个实时性就得非常非趁啊，那那像这个，呃，这个数据报表，这个给大家可以举一个例子，大家可能觉得你数据报表吗？那那直接你把这个东西生成不就完事了吗？这个对实时性要求有多高呢？诶，我们想一个这样的场景，比方说呃，我们是这个大数据的开发人员啊，那公司里边这个销售总监啊，他每个月的这个。一号啊，啊，那比方说这个8月1号，9月1号，他上来之后都要去把上个月的所有数据生成一张报表统计出来，然后他要照着这个报表去给CEO去做一个汇报啊，去解释一下哦，我们上个月的这个，或者说甚至我们上个季度，对吧，当前的这个数据怎么样，我们接下来的策略要去做什么样的调整，然后这个数据呢，大家会想到你，你假如说我们收集的是这个点击数据的话，那可能数据量非常非常大，对吧？啊，你一个月甚至一个季度，那可能这个数据量是，呃是是是一个天文数字啊，那我们这里面统计收集的时候，如果用传统的架构应该怎么样啊，那你比方说啊，这个一号要去做这个，呃，要去生成这个报表了，那我当然就是截止到31号晚上24点，哎，这个时候停，然后我把所有的数据都收集起来，然后跑一个任务，对吧，大家大家开始跑一个这个任务，去各种做这个，呃，增删。
13:52
代查各种各种写CQ，做这个统计，然后算出一个结果来，因为数据量非常大。
14:00
啊，传统的这种架构里边，我们如果要是说离线去跑这个任务的话，那可能需要的这个时间就会非常非常长了啊，有可能我们跑的这个几个小时，甚至有可能要跑一天啊，那那你说这个这种情况下。我们作为技术人员去跟销售总监去解释，对吧，这个当前数据量太大了，呃，你这个需要需要跑一天，你不要一号给CEO去汇报了，二号再去汇报吧。啊，那你想销售总监是怎么样一个想法，对吧？哎，怎么可能让CEO来等你的时间呢，不行，一号我必须把这个东西报表要拿到，你必须统计出来，那这个我们就没办法了，那那只好说，呃，那要不这样吧，我提前一天对吧，30号或者29号我就开始跑这张报表，诶到时候一号你可以准时的拿到你去给CEO看。当然这个是一个权衡啊，可以的，可以做的一种方式，但是你想想这会带来一个什么问题呢？假如说这个月最后的两天，刚好这个点击量数据量就发生了比较大的变化，哎，那就会导致CEO拿到这个数据之后给。
15:06
呃，这个呃，销销售总监已经做了一个汇报了，啊，CEO已经看到这个汇报了，然后呢，诶我们发现。后面的这个数据有了大量的这个新来的数据，以至于会影响我们当前的这个整个数据的分析总结的结果啊，影响到我们之后的这个销售策略，那我们只能跟跟销售总结去去做这个解释，哎呀，不好意思，我们这个数据呢，又有这个大的变化，你看是不是，呃，我们我我再重新跑一下，对吧，然后你二号或者三号再去给CEO重新重新重新做一下这个汇报呢。啊，你想想这个销售总监内心又是什么样的一个台词啊，这种情况如果出现这种问题的话，那可能还不如之前，你不要提前跑，对吧，你你至少拿到这一个准确的数据啊，你总得保证数据对啊。所以大家看这就是我们当前的这个要求，就是同时要保证低延迟，我要快，而且还要高分图对吧，数据量很大，非常非常大，最后还要保证结果，结果的准确性和良好的容错性。
16:13
啊，那所以之前的话，哎，我们可能没有这样的。这样的技术啊，就是传统的这种技术架构很难处理这样的数据，像这个网站点击量这样的数据啊，啊那。我们现在如果有了flink的话，这些东西就全部可以处理了，同时可以做到这些特点。啊，那除了这个生成数据报表之外啊，就电电商和市场营销这个领域之外，其他还有比较典型的应用场景，一个就是物联网IOT，这大家可能也听说过，它主要就是什么，用传感器去采集实时的数据，然后做这个收集啊处理，最后我们做一些报警提示，对吧？啊，这个行业大家会发现这可能对于我们那个实时性的要求啊，低延迟的要求甚至比其他行业还要高，哎，为什么你想传感器做这个采集和实时报警的时候，比方说交通运输业啊，我们说这个你这个汽车现在我们做智能驾驶，你假如说他收集到的数据发发现了一些异常，发现了一些问题的话，你要需要让他及时做出应对，马上去避开前方的这个障碍，各种各样的这些东西啊，当当然本身智能驾驶前方有障碍的话，这个显然不可能再去做这个网络传输之后得到统一的这种调度再去做处理，对吧。
17:34
啊啊，就是这个肯定不是这样啊，那比方说像我们这个对于路路径的判断，当前道路是否拥堵的这个判断，你如果要是不及时的话，那可能我当前已经走上这条路了，对吧，已经堵在那儿了，没有办法回来了，那这怎么办呢？当然就要更加的实时啊，你稍微这个慢一点儿，那可能就已经偏差很大了，没有1000里了啊，那另外还有这个比较常见的应用场景，就是这里举的其实都是对实时性要求比较高的啊，一个就是电信行业，就是基站的流量调配对吧，大家知道这个不同地区都有不同的数量的这个基站，那其实呢，你在某一个地区，它这个呃，数据量有这个峰值的时候，其实可以把周围的流量给它调配过来，那基站调配过来分摊一下当前的这个流量，那这样的话就不会出现我们通信的拥堵，另外还有就是银行和金融业啊，这个也比较典型啊，这主要是做什么呢？主要就是做实时的结算和通知的推送。
18:34
实时去做一些分析，包括实时检测一些异常行为，做一些风控风险的控制啊，那之前大家可能听说过，就是对于这个银行业啊，它有一个说法叫。银行家工作时间啊，就是说呃，什么叫银行家工作时间，就是每天到下午大概三四点的时候，银行就关门了，银行家就直接下班了，为什么呢？呃，不是因为这个行业有钱，然后不需要工作时间太长，对吧？不需要996，是因为每天到这个时间截止，我就得关闭所有的交易，然后开始进行当天所有数据的盘点结算，那传统的做法就是一天做完了之后，我把它诶做一个整体的梳理，现在就不需要了，现在你如果要有这种大数据的处理框架，实时就可以搞定啊，所以大家其实也会发现，现在我们做这个转账啊，对吧？做这个金融业呃，相关的一些操作的时候，你会发现速度快了很多，根本不需要等那么久啊，我们现在做任何的操作，其实都可以实时的得到结果，收到通知，这就是当前比较常见的一些应用场景。
我来说两句