背景
前面分析了Flink在计算处理流过程中Stream转为动态表、动态表上进行连续查询、生成新的动态表、动态表转为Stream将其写入外部表，本篇从对以下三个问题进行解剖分析：
- 如何进行计算
- 如何处理乱序
- 如何处理容灾
如何进行计算
我们可以从下面的一个简单SQL开始，这是一个计算累计金额与订单的事件监听计算
从上面可以看出，每条数据进入Apache Flink系统都会触发计算。Apache Flink是基于上一次的计算结果进行增量计算的。那么问题来了: "上一次的计算结果保存在哪里，保存在内存可以吗？"，当然不是，如果保存在内存，在由于网络，硬件等原因造成某个计算节点失败的情况下，上一次计算结果会丢失，在节点恢复的时候，就需要将历史上所有数据（可能十几天，上百天的数据）重新计算一次，为了避免这种灾难性的问题发生，Apache Flink 会利用State存储计算结果
State
流式计算分为无状态和有状态两种情况。无状态的计算观察每个独立事件，并根据最后一个事件输出结果。例如：
- 流处理应用程序从传感器接收温度读数，并在温度超过 90 度时发出警告。
有状态的计算则会基于多个事件输出结果。例如：
- 所有类型的窗口。例如，计算过去一小时的平均温度，就是有状态的计算
- 所有用于复杂事件处理的状态机。例如，若在一分钟内收到两个相差 20 度以上的温度读数，则发出警告，这是有状态的计算
- 流与流之间的所有关联操作，以及流与静态表或动态表之间的关联操作，都是有状态的计算
与批计算相比，State是流计算特有的，批计算没有failover机制，要么成功，要么重新计算。流计算在 大多数场景 下是增量计算，数据逐条处理（大多数场景)，每次计算是在上一次计算结果之上进行处理的，这样的机制势必要将上一次的计算结果进行存储（生产模式要持久化），另外由于 机器，网络，脏数据等原因导致的程序错误，在重启job时候需要从成功的检查点(checkpoint，后面篇章会专门介绍)进行state的恢复。增量计算，Failover这些机制都需要state的支撑
有了state，每个事件流经过算子处理时，算子任务就可以从state获取上一次计算结果，与当前的结果进行计算，然后更新state
State分类
Apache Flink内部有三种state的存储实现，具体如下：
•基于内存的HeapStateBackend - 在debug模式使用，不 建议在生产模式下应用；
•基于HDFS的FsStateBackend - 分布式文件持久化，每次读写都产生网络IO，整体性能不佳；
•基于RocksDB的RocksDBStateBackend - 本地文件+异步HDFS持久化；
如何处理乱序
同样我们看下一个很常见的TimeWindow中数据乱序的问题：计算每5秒内的pv，这个时候有一个EventTime是11秒的数据，在16秒的时候到来了，怎么处理？
乱序是相对于事件产生时间和到达Apache Flink 实际处理算子的顺序而言的
在讨论Apache怎么处理乱序前，我们先从讲解几个概念：Time、Window、Watermark
Time
Time，分为Event time、Ingestion time、Processing time，Flink的无限数据流是一个持续的过程，时间是我们判断业务状态是否滞后，数据处理是否及时的重要依据。
Flink流式处理中，绝大部分的业务都会使用EventTime，一般只在EventTime无法使用时，考虑其他时间属性。
Window
Window，即窗口，我们前面一直提到的边界就是这里的Window(窗口)。
官方解释：流式计算是一种被设计用于处理无限数据集的数据处理引擎，而无限数据集是指一种不断增长的本质上无限的数据集，而window是一种切割无限数据为有限块进行处理的手段。
所以Window是无限数据流处理的核心，Window将一个无限的stream拆分成有限大小的”buckets”桶，我们可以在这些桶上做计算操作。
Window分类
- 滚动窗口
将数据依据固定的窗口长度对数据进行切片。
特点：时间对齐，窗口长度固定，没有重叠。
滚动窗口分配器将每个元素分配到一个指定窗口大小的窗口中，滚动窗口有一个固定的大小，并且不会出现重叠。
例如：如果你指定了一个5分钟大小的滚动窗口，窗口的创建如下图所示：
适用场景：适合做BI统计等（做每个时间段的聚合计算）。
- 滑动窗口
滑动窗口是固定窗口的更广义的一种形式，滑动窗口由固定的窗口长度和滑动间隔组成。
特点：时间对齐，窗口长度固定，有重叠。
滑动窗口分配器将元素分配到固定长度的窗口中，与滚动窗口类似，窗口的大小由窗口大小参数来配置，另一个窗口滑动参数控制滑动窗口开始的频率。因此，滑动窗口如果滑动参数小于窗口大小的话，窗口是可以重叠的，在这种情况下元素会被分配到多个窗口中。
例如，你有10分钟的窗口和5分钟的滑动，那么每个窗口中5分钟的窗口里包含着上个10分钟产生的数据，如下图所示：
适用场景：对最近一个时间段内的统计（求某接口最近5min的失败率来决定是否要报警）。
- 会话窗口
由一系列事件组合一个指定时间长度的timeout间隙组成，类似于web应用的session，也就是一段时间没有接收到新数据就会生成新的窗口。
特点：时间无对齐。
session窗口分配器通过session活动来对元素进行分组，session窗口跟滚动窗口和滑动窗口相比，不会有重叠和固定的开始时间和结束时间的情况，相反，当它在一个固定的时间周期内不再收到元素，即非活动间隔产生，那个这个窗口就会关闭。一个session窗口通过一个session间隔来配置，这个session间隔定义了非活跃周期的长度，当这个非活跃周期产生，那么当前的session将关闭并且后续的元素将被分配到新的session窗口中去。
Watermarker
我们知道，流处理从事件产生，到流经 source，再到 operator，中间是有一个过程和时间的，虽然大部分情况下，流到 operator 的数据都是按照事件产生的时间顺序来的，但是也不排除由于网络、背压等原因，导致乱序的产生，所谓乱序，就是指 Flink 接收到的事件的先后顺序不是严格按照事件的 Event Time 顺序排列的，所以 Flink 最初设计的时候，就考虑到了网络延迟，网络乱序等问题，所以提出了一个抽象概念：水印（WaterMark）；
如上图所示，就出现一个问题，一旦出现乱序，如果只根据 EventTime 决定 Window 的运行，我们不能明确数据是否全部到位，但又不能无限期的等下去，此时必须要有个机制来保证一个特定的时间后，必须触发 Window 去进行计算了，这个特别的机制，就是 Watermark。
- Watermark 是用于处理乱序事件的，而正确的处理乱序事件，通常用 Watermark 机制结合 Window 来实现。
- Watermark 可以理解成一个延迟触发机制，我们可以设置 Watermark 的延时时长 t，每次系统会校验已经到达的数据中最大的 maxEventTime，然后认定 EventTime 小于 maxEventTime - t 的所有数据都已经到达，如果有窗口的停止时间等于 maxEventTime – t，那么这个窗口被触发执行。
有了上面的几个改娘我们可以看下，Flink是如何利用Watermarker处理乱序上de1
从上面可以看出，正确处理的根源是我们采取了 延迟触发 window 计算 的方式正确处理了 Late Event. 与此同时，我们发现window的延时触发计算，也导致了下游的LATENCY变大，本例子中下游得到window的结果就延迟了5s。
如何处理容灾
同样举例，上面的SQL计算运行了20天后，突然机器故障了怎么处理？
全局一致性快照
容错(Fault Tolerance) 是指容忍故障，在故障发生时能够自动检测出来，并使系统能够自动恢复正常运行。当出现某些指定的网络故障、硬件故障、软件错误时，系统仍能执行规定的一组程序，或者说程序不会因系统中的故障而中止，并且执行结果也不包含系统故障所引起的差错。
Apache Flink的Fault Tolerance机制核心是持续创建分布式流数据及其状态的快照。这些快照在系统遇到故障时，作为一个回退点。Apache Flink中创建快照的机制叫做Checkpointing，Checkpointing的理论基础 Stephan 在 Lightweight Asynchronous Snapshots for Distributed Dataflows 进行了细节描述，该机制源于由K. MANI CHANDY和LESLIE LAMPORT 发表的 Determining-Global-States-of-a-Distributed-System Paper，该Paper描述了在分布式系统如何解决全局状态一致性问题。
在Apache Flink中以Checkpointing的机制进行容错，Checkpointing会产生类似binlog一样的、可以用来恢复任务状态的数据文件。Apache Flink中也有类似于数据库事物控制一样的数据计算语义控制，比如：At-Least-Once和Exactly-Once。
