开发者学堂课程【开源 Flink 极速上手教程：走进 Apache Flink】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/331/detail/3707
走进 Apache Flink（二）
三、秉轴持钧-流计算的核心
1.流计算的核心问题
流计算其实就是实时计算，实时就意味着快，也就是说流计算首先要解决批计算计算延时的一个问题。
所以流计算的第一个问题就是微秒、毫秒的计算延时问题。
它是流计算第一个要解决的问题。
第二个问题是持续更新甚至有撤回的问题。
那比如刚才对流批对比的那个示例，那流计算是在每一条记录，到那时候都出牌阶段，计算结果也需要不断的更新的，还需要对上次结果进行一个撤回需求，比如上次有一个结果是一，这次就变二了，那个一到底怎么处理呢？是否要告诉用户，结果那个一现在已经无效了。现在的结果，是不是需要？
第三个问题是容错的续跑。
流计算作业要常年不断的进行运行，难免会有机器问题，或者网络问题，发生异常，面对这样的异常问题？计算的引擎，要具备一个自动恢复的容错能力。
第四个问题是透明升级。
流计算作业要持续运行，但是业务往往不是一成不变的，业务的不断的改进，再升级等变化。当某个作业需要升级作业的时候，流计算的引擎流引擎要有能力，在升级作业的时候，可以继续之前的计算的一个状态进行续跑，也就是有状态的流计算，在这时候不要影响到业务的作业升级。
第五个问题是流计算中非常典型的问题，是流计算数据如流水般流入，那么尤其在系统中，由于网络的原因，上游业务的各种原因会导致一个业务处理乱局。那么如果乱序影响到业务计算，流计算也应该有机制来解决这种乱序对业务的影响。
第六个问题是正确性。
要有计算正确性的保障，当流计算异常恢复的时候，如何精确的知道上一次计算到什么位置了。那只有记录到精准的记录，记录到上次的消费，只从上次位置进行计算，并且基于原有的状态进行计算，才能真正的解决这个计算正确行为。
第七问题和第八个问题，是部署和扩容的问题。
是所有的计算引擎必须要面临和解决的基础问题。
2.Flink 如何解决核心的方法
流计算是一个非常复杂的领域和计算。要解决的挑战很多，先从宏观的认识到前面的这几个典型问题，看看flink是以怎样的机制来解决流计算的典型问题。
第一个延时问题的解决。
首先是架构的优势，纯流架构专门为延时而设计，就省去了迈克尔百姓架构的攒的和调度的这种计算时间。同时 Flink还具备一个奥利菲尔的机制。用户点击事件不断的流入，对于一个 count count 的计算，用户点击事件永远都不会结束，不会停止，永远都会有用户。所以不能等待所有的点击时间都急需时，再进行计算。只有提前的在用户注意没到来之前，只要来一个计算一个，但是后面再来的时候，用户数据就有可能被更新。这种来一个时间，虽然数据每道题，但是来一个时间就出牌一次，计算这款结果下发的这种机制就是典型的合理费用。第二个更新和撤回问题。
流计算要持续的计算，每次计算结果，都会由上下游发出，但是每次发出这些结果，对于上一次来说，上一次发出的结果就是一个旧的计算结果，应该有某种机制来告诉计算机这个结果是无效的，如果不告诉，可能在业务上就会产生一些计算上的错误。在复习当中告诉下一个节点，上一次的计算结果是失效了的。这种机制就称作撤回机制，那么同样没有撤回机制会造成的业务问题。那么假设有一张区域订单表，那么ID就是订单，信息就是地区信息。统计需求是这样的，首先需按地区分组统计每个地区的订单数量，按地区统计订单数量，然后再按照订单数量分组订单数数量，统计相同订单数量的地区数量。本质上它是一个嵌套的一个撤回语句，第一个第一层，一层的折扣，这个是一个embrace地区分组，那么外层是按订单数量，看一看计算中过程中，如果没有撤回机制会有怎样的问题。
这个表里的数据非常的少，非常简单，用肉眼看一下，要求的是相同订单数量的地区数量，这里面的H是上海，D是北京，SC是深圳，会发现这里面有两个上海。三个北京，一个深圳。那么如果说，每个相同订单的地区数量，一个订单的只有一个深圳，两个订单的只有上海，三个订单只有北京。其实已经知道这个结果了，应该是每个订单一二也是一三也是一，就是一个订单是一个地区，两个订单是一个地区，三个订单也是一个地区。结果到底是怎么样，按照所有的计算，每条记录每个订单来都产生一个计算结果来说，第二次产生了计算结果之后，第二次再按照订单数量进行统计的时候，一个订单的地区有三个，两个订单区地反而有了两个，三个订单有一个地区，那么为什么前面两个订单数量的地区数量是错的？其实这个问题发生在上面这个计算结果，发生在哪？每一次阿利菲尔这个数据到下一个，但是在更新这个结果的时候，没有对以前的数据进行处理，所以就造成了刚才的统计错误。
正确的处理方式是要在发生数据更新之后，把上一次数据告诉下游，数据已经更新了，用当前这条，上一条是无效的。简单讲，是当SH上海的订单数量变成二的时候，需要把之前上海的订单的数量一的结果标记为失效，在Flink里面标记失效，是用这个加减号，或者说用正负来表示。一个正常记录，还是撤回的记录。当然不用关心内部的实现，只需要知道有这么一套机制来告诉下游或者数据计算结果是无效的，那么这种机制，在Flink里面就是撤回机制。但这样的机制，也会感知到数据的有效性，进而得到想要的正确的查询结果。
第三个问题是容错续保问题。
这个问题最核心的需要是在发生异常的时候可以自动恢复作业，但是自动恢复作业，不能从头重新计算。比如已经运行了两天的业务计算，那么上游消费卡数据已经消费到当前位置。不能作业恢复，就重新使两天前的数据失效，从头进行计算。这种现象，重启或者恢复机制是不被认可的。那就需要记住当前的计算状态，也就是有状态的流进算，同时要有某种机制在合适的时间进行状态的持久化。在flash里面，状态的存储和保证状态持久化的机制在Flink中对应stayed或者stayed back and he took，胖子机制。
第四个问题透明升级。
本透明升级是必不可少的一个功能，业务的变化或者程序的 bug，都会主动的升级代码逻辑，进行作业的升级，这个时候，要确保业务数据的正确性，尤其是要有exactly once 语义的支持。这个问题 Name 依靠的是 stayed de c u LB 机制进行解决。
第五个问题乱序问题。
乱序问题使流计算的典型问题，也是非常棘手的问题。由于网络的问题，比如手机米信号的强弱，造成实际收上来的一些数据，会造成乱序，怎样通过技术手段，解决或者缓解乱序问题？
如图，图里面有两个传感器，那么两个传感器在收集数据，那么小圆圈内的数字代表事件产生的事件，小圈圈的位置代表到来进入这个流系统的时间。如果这时候想要零到五或者五到十的窗口进行划分的话，显然其中的试卷四和试卷八九是乱序的。如果不进行技术处理，那么计算就出错了，也就是说八九和四无法分到正确的窗口里面。
面对这样的问题，Flink如何解决？
EventTime
什么是EventTime？简单的介绍一下，Flink中有三种时间类型。这三种时间类型分别是event time in Justin time he present，这三种类型是根据时间产生的位置不同而划分的。如图，Event是事件产生时候标记的，In just in time是事件进入Flink系统时候产生的。那么processing time？就是事件被处理的时候标记的，这里有一个直观的认知和记忆就好。
Watermark
Watermark也是流计算中处理乱序的一个非常重要的机制，也是非常重要的概念。Watermark的设计是计算延时和数据完整性的权能，看一下视频，它是怎么选。左边使要求我所有的数据都是完整的，不丢任何一条数据，那么很明显，这个数据的延迟很强，这进而让出发计算的时间就会推迟，延迟性增强。右边是一个折中的沃尔玛提升策略，那么延时会缩小，但是会有局部的数据会丢失，已经被丢失掉，所以这是一个权衡。是一个case by case，根据业务来权衡的。那么关于word的详细的一个原理和剖析。
第六个问题正确性问题。
数据的正确性问题。正确性问题的核心是参与计算的这个数据是否有丢失，是否这些数据精准的被计算了一次这么一个问题。Flink 知识 at least once 和 exactly once，那么按照 list 的单词是说，只有参与计算的数据，保证数据都参与计算了，但是可能数据有重复计算。Exactly once，是指参与了，并且只参与一次这么一个语义。这个机制，也涉及到了退化的机制，也可能涉及到了 flink 的 job master，Masters 之间和查尔斯之间的一个通讯相关的内容。
那么对于流计算典型的问题的认知，对于后续课程而言，如果事先知道这些概念，或者先有这些意识，先知道这些问题用哪些技术手段。用这个机制来解决，但现在的脑海里先不关心机制的内部是什么，因为知道问题以及对应的技术手段，在后面的学习课程当中如果学习到了技术点的时候，就会映射出来。这个技术的知识点，这个机制，是为了解决这种类型的问题的。机制的细节又可以在当时的那些课里面进行学习，就会形成一个系统的认知，自己就会具备了这种主动去判断问题，利用一种机制去解决。
