003__尚硅谷_Flink理论_Flink简介（三）应用场景

接下来我们先给大家说一说flink，既然它有这么好的优势啊，有这么好的一些特点，那么到底哪些行业需要用到这样的一个大杀器呢？有些同学可能就说了，既然它这么这么好，这么好用，那你就所有的地方都用吧，但其实也未必啊，因为有一些场景里边，其实是不是你直接去攒一批做一个离线处理也很方便也很好啊，而且大家知道就是像现在我们做离线处理的这个框架，其实是已经非常成熟了，非常的方便了大家去写CQ，做这个相关的一些操作，这个是就是不需要去再做这个知识库的一个迁移了，那哪些行业非常的迫切就一定要用flink这样的大数据流失处理框架呢？这里给大家举几个例子，首先一个行业就是电商和市场营销。这个行业，呃，大家能想到一个典型的应用是什么呢？就是数据报表，产生数据报表的时候，可能就会用到这个非常实时的处理流数据的这种场景，我们举一个具体的例子吧，呃，大家可以设想一下这样一个场景啊，我们自己是一个大数据工程师，能在公司里边，比方说我们就是一个电商的公司，那市场总监他可能在每个月的月初，每个月一号的时候就要去给CEO去做一个汇报，他去做什么汇报呢？就是要把比方说上个月的数据进行分析，进行汇总，然后得到一个分析报表，拿着这个报表得到一些，呃，比方说我们这个首先做一些总结，然后可能会有一些销售策略，市场策略的一个改变，对吧？呃，要有这样的一个调整，他会把这个东西去给CEO做汇报，那在这种场景里边。

嗯，大家会想到啊，我们我们可能就对就就要跟这个市场总监去商量了，就说你这个一个月的数据有点太大了，我们这个做离线分析做处理呢，我得跑他，他本身就得跑几个小时，甚至得跑一天，要不我们商量一下，你这样吧，你到不要一号就去汇报了，二号再去汇报吧，那市场总监肯定不干啊，对吧，那怎么能行呢，CEO能等你的时间吗？不行，一号一定要去做处理，那我们想一想，那那既然这样，我们干脆退而求其次好了，呃，你如果对这个时效性的要求这么高的话，我干脆就这样，我在上个月月末的时候，29号或者30号，我就提前跑这个任务，就开始跑，诶跑个几个小时一天。

到一号的时候，所有结果都出了，你就可以拿去给CEO汇报了，对吧？啊，你看看这样行不行呢？市场总监说，说这个，诶，行啊，听起来没问题，呃，你既然能出来就行吧，于是很开心的拿着上个月的这个汇报的这个报表就给CEO做汇报，你看我们上个月销售数据是什么样，所以我们接下来策略需要调整成什么什么样，结果没成想，上个月的最后一两天数据发生了很大的变化，诶有可能一些点击量啊，销售量有一个很大的一个波动，那大家会想到这就带来一个什么问题呢？

对，我们之前收集的那些数据算出来那个结果是不是就不准确啊，就没有把最后这两年的数据带进去，对不对？呃，所以那这个时候我们就只能去跟销售总监说了，哎呀，不好意思，上一次跑的那个数据里边呢，没有把最后两天的数据含进去，所以呢，数据不准，我现在再跑一下，要不这样你看看是不是把我们更新之后的这个数据，你再去给COO重新做一个更正的汇报呢？那大家会想到市场总监听到这个话的时候，他内心的台词是什么样的，对吧？对，他肯定这这这这这这个肯定是非常非常愤怒的一个状态啊。呃，所以大家会想到在传统的这个数据处理架构里边，这个能怪我们吗？其实也怪不了我们，对不对，这个时效性和最后处理的结果正确性其实是不可兼得的，所以我们也可以理直气壮的跟他家说，呃，这个没有办法，这个我们。

现有的这个技术框架，现有的这个情况就是这样，你不能说既要处理的快，又要又要呃正确性那么好，对吧，实时的就能给你出那么大数据的一个分析结果，没办法解决，但是大家看现在我们其实就有了更好的解决方案，对吧？啊，如果我们用这个流式处理的大数据处理框架的话，其实是可以做到很实时的，就把之前的处理结果统计出来，而且可以做到结果的正确性保证啊这这就是呃，Flink一个。

比较好的一个应用场景，另外还有哪些地方可能可能对这个实时性要求会比较高呢？大家可能会想到像这个广告投放。呃，大家会想到广告投放，我们一般做这个，呃，很多网站上都有广告对吧？呃，在这个页面的空白处，空缺处，其实都会有一些广告的这个设置，那广告本身它其实是需要有一个报价，这个报价根据什么来定呢？呃，其实大家知道，像现在在这个电商网站，不光是电商网站啊，很多网站它最重要做分析的最重要的一个数据是什么。其实就是点击量对吧？呃，因为现在在很多网站上，点击量其实就能代表用户的关注度，用户啊，甚至可以跟这个销量能够关联起来，对吧，跟这个最后的这个商业指标都能关联起来，那所以越来越多的分析，我们直接用的数据就是点击量，而点击量这个数据是不是就非常非常的大，数据量非常的大，而且它的产生是连续不断，而且没什么规律，对不对啊，这就是我们说的典型的一个流失数据，呃，那广告投放如果我们要以这个典击量作为这个报价的一个原则的话，那大家想，如果说我们的实时性不好的话，我们攒一段时间对吧，把这个前一周的这个点击量统计出来，然后去算，算个几个小时，算上一两天，然后得出来的一个结果，去对这个页面上的广告做一个定价的一个策略，那他有可能出现的一个问题就是。

是点击量有可能是浮动的，对吧，不同的时间段，有可能你这个页面它就这几天点击量特别的高，结果呢，你统计的时候滞后了，本来那几天点击量高的时候，定价应该高，结果你没有统计进去，反而是在后几天，有可能这个网站点击量已经回落，已经变冷清的时候，你给他算的那个点击量高了，对不对？诶所以这种情形其实定价策略就会有所偏差，所以大家看在这种场景下，我们是不是就相当于也是要很实时的处理比较大量的这种数据啊，去对大量的流失数据做分析啊，这是我们比较也比较常见的一个应用场景。

呃，另外还有什么呢？还有一些是业务流程的需要，呃，这一部分呢，其实就是说，呃，一个典型的例子就是像航空公司，大家可能会想到航空公司处理的数据其实是非常非常大的，他可能同时要处理什么数据，首先他要处理这个用户的信息，对吧？啊，你自己的一些个人身份信息啊，啊各种各样的一些其他的一些数据，另外呢，还要处理航班的信息，航班本身对吧，哪个班次，什么样的时间，另外呢，还有航班的实时状态信息，另外我们是不是还得把用户的状态啊，用户的这个比方说还有订单的一些信息，对吧，跟航班的状态还得关联起来，然后去做大量的处理，而且这个状态信息还是在实时变更，实时变化的，对吧？呃，最后我们还要把它对应的一些实时状态去给用户做推送。所以这个过程其实。

是涉及到大量数据的实时处理的，对于这个这样的场景，我们也可以把它用这个流失的处理引擎来做一个来做一个处理分析，呃，那如果说大家大家其实会想到这种场景，一般情况传统是放在哪里去处理的呢？其实一般不会用这个大数据处理引擎，对吧，一般情况是不是我们就会把它放在业务系统里边搞定了，是不是你应该是就是你这里边用户定了哪个航班，然后我这里边状态改变的话，那是不是他的这个状态都应该在数据库里边存着，是我就做一个连表查询，把这个全部查出来之后，那边有改变，然后去做实时推送啊，啊其实就是这样的一个业务流程，但是传统的这种处理方式，他会遇到一个问题，就是如果数据量非常非常大的时候怎么办呢？

啊，大家会想到在传统数据库里边，如果遇到数据量非常大的场景，你要做大量的这种连表查询操作，是不是对数据库性能的影响非常的严重啊，啊，我们的成本可能就会比较高，所以如果说我们能够把这一部分功能剥离出来，让大数据的处理引擎把它搞定的话，那业务系统就可以解放出来，专注于其他一些更加核心的业务流程处理了，对吧？呃，这个性能就可以得到极大的释放啊，所以这也是一种发展的一个方向啊，一个业务流程的处理的一个过程。

除了电商和市场营销这一部分呢，另外还有一个应用的行业是物联网，就是所谓的IOT，这个大家听说过吗？没用就是啊，都听说过啊，但是可能没用过啊，就是Internet of things，它的一个基本的理念其实就是所谓的万物互联啊，每一个物体相当于都有自己的一个ID，然后呢，都能产生自己的数据，大家都联网连起来之后，那数据就可以传输收集起来，去做分析，去做管理了，对吧？啊是这样的一个过程，那在这种应用场景里边，最典型的一个应用是什么呢？呃，其实就是大家会想到每一个物体如果都要能收集数据的话，是不是就应该要有一些传感器类似的东西啊。

啊，所以它在工业工业上面啊，这个其实是有很多应用的，比方说传感器实时数据的采集和显示，然后收集起来之后，有可能我们要去做一个实时的分析和报警处理，大家会想到这个像有一些这个工业设备，它的温度是不是必须要做实时监控，假如说一段时间它这个温度上升特别的快啊，温度一下子变到到了一个这个很高的程度，超过了我们报警的阈值的话，那我们是不是需要非常实时的把它检测出来，去做预警啊。呃，这个东西我们可以把数据攒一段时间，过一段时间做离线处理吗？那如果你这么干的话，那可能那那机器过一会儿已经出现严重事故，直接爆炸了，对吧？啊，这个结果就会比较后果比较严重啊，所以这是可以说是比上面我们讲的电商这种场景对实时性要求更高的一个呃应用的环境，所以这也是flink可以说是一个最典型的应用场景啊，啊但大家可以想到在这个领域用的是非常多的。

呃，相关的还有一个行业就是交通运输业，这个大家也能想到，比方说像我们这个，呃，车载GPS信号对吧？呃，如果现在我们做这个这个智能驾驶无人车啊，或者说大家想到现在我们的这个高铁啊，或者其他的一些快速快速的交通运输工具，它的数据产生是不是也非常的实时，而且现在越来越多交通工具，它产生的数据都是非常非常大量。如果说我们不能实时的处理这些连续不断产生的大量数据的话，那是不是你把它攒一批去处理，那有可能下一秒就撞上了，对吧？啊，这个后果也会非常的严重，所以在这种场景下，我们对实时性的要求非常高，所以我们就一定得用这种大数据的流式处理框架把它搞定。

另外还有一个例子是电信业啊，电信业这一部分就涉及到了这个基站流量的调配，这个可能会比较特殊一点，呃，它主要说的是什么呢？大家可能知道在这个，呃，移动联通他们这些电信的基站其实是需要去分区域，分分点去设置的，那么在一些特殊的场景下，某一个片区有可能会出现这个流量激增的情况，对不对啊，就是在这个地区发生了一个热点事件的时候，有可能这个流量的需求就会特别特别大，这个这个里边打进去的电话接触接通的这个信号就会特别特别的多，这个时候其实我们是需要实时的做一个监控，然后把附近的基站都调配过去做，这个相当于做一个负载均衡，呃，做一个这样的处理的，对吧？所以大家会想到，如果说我们不能做到很实时的话，那有可能就会出现什么，就是短。

之间内整个网络就就瘫痪了，对吧，电话打不进去，也接不出来了啊，这个给大家举一个比较极端的例子啊，呃，这个可能大家没有经，大家也经历过，但是可能印象不是特别的深刻，就是零八年时候的汶川地震，不知道大家有没有这个经历啊，因为当时我还是在学校里边，所以说呃，就是在大学里边，所以印象就非常非常深刻，就大家可能年纪小一点，就就没有没有太太强烈的感觉啊，就当时发生这个事情的时候，因为我有很多同学朋友是在四川那边上学嘛，就当时第一时间我就想去打个电话去去问一问什么情况，对吧，去关心一下，当时几个小时内，甚至我印象当时应该是两三天之内啊，电话都打不进去，短信都发不过去。

啊，当然当时的那个情况比较极端，就是说很多基础设施可能都给震坏了，对吧？啊，这个会呃，就是比较极端，但其实在那种场景下，周边的一些基站，如果要是可用的基站，也应该赶快把它调配过去，对吧？啊，周边那个信号其实可以覆盖到的啊，但是当时就没有这样的一个处理的过程，所以当时其实这个这个情况就导致当时当地的这个通讯完全中断，完全瘫痪了，那对于我们一般人而言，你只是想打个电话问候一下，可能还不是那么的严重，对吧，就听起来你也做不了什么嘛，但是大家想当时有大量的救援队，其实是在开赴那个现场的，这个时候你如果要是没有联系方式的话，其实这个就可以说后果就比较严重了，对吧，所以大家能够想到这样的一些场景啊，还是对它比较有更高的要求，如果你能做到的话，显然效果会更好。呃，最后给大家。

大家讲一个银行和金融业的应用，这个领域它的应用是什么呢？一个比较典型的应用就是结算，大家可能知道在银行里边盘点结算其实是一个比较重的操作，呃，传统来讲的话，银行可能会花费大量的时间，专门把一段时间的所有账目去做一个清点，做一个结算，呃，然后然然后统一把它，呃，这个对账对完了之后啊，再去能能进行接下来的操作，对吧？呃，大家可能听说过一个叫做有一个叫银行加时间的一个概念啊，就是银行加工作时间，不知道大家听说过没有，就是在最早期的时候，银行家是一个不能说很很轻松的活啊，就是大家听到可能会觉得很羡慕，就是什么呢？早上正常干活，下午的时候可能很早啊，两三点钟就下班了。为什么呢？因。

因为这个时候你就不能再去做处理一些交易，做一些别的事情了，要干什么啊，要开始对开始对账，开始去做这个清算处理了，把这个一天当中发生的所有交交易去做一下对账，做一个处理，做一个结算，然后才能保证第二天正常能够进行新的交易，对吧？啊，大家必须要做这个过程，这个过程很花时间啊，那之前其实大家有应该大家是有类似的经历的啊，在可能在十几年前那个时候，如果我们要是做一笔银行转账的话，是马上就能到账吗？其实不是对吧，其实往往可能是要等好几个工作日才能够真正的到账，那这个过程银行在做什么呢？一开始还真的是他有必要，为什么他就是要攒一段时间的数据，然后去统一做结账，做对账，那你没有办法啊，你最后到账一定得等他清算结果，结果出来之后才能到账，那大家看现在其实就没有必要了啊，其实我们可以用这个实时做到这个实时的对账结算。

那当然了，如果要是数据量非常非常大的时候，那需要用到我们的大数据的流失处理的引擎，呃，另外还有一个是实时的异常行为检测，呃，在进业里边这个应用还是比较普遍的啊，大家能想到像有一些交易所之类的地方。现在他其实已经不是人在去做交易了，大家知道吗？很多其实这个交易所它上面都是什么呢？很多这个操盘手他都他都是写好的程序再去做交易了，就是所谓的高频交易啊呃，那大家会想到这种情况下是不是。同时一个时间段发起的交易就会特别特别多，数据量非常非常大，那假如说一段时间出现了一些异常交易的话，是不是我们应该非常快的把它检测到，然后去实时的做一些对应的处理或者报警啊，假如说你处理慢了的话，那有可能很多比较严重的后果就发生了，对吧？所以你马上就得该冻结账户，冻结账户啊，或者是呃，之前的这个无效的交易就得去做回滚，要不然的话，有可能别人的这个巨额的金额就都已经提走了啊，后果就会比较严重，呃，所以这种实时的检测在大数据的应用场景里边，也是可以用流处理的处理引擎去做做这件事情，所以这是我们比较常见的一些应用场景啊，在这里给大家做一个大概的一个了解。