1. FlinkSql 快速认识1.1 基本原理和架构Flink Sql是架构于Flink core之上用sql语义方便快捷的进行结构化数据处理的上层库；(非常类似Spark sql和Spark core的关系) 整体架构和工作流程 核心工作原理如下： 将数据源(数据集)，绑定元数据(schema)后，注册成catalog中的表(table，view)； 然后由用户通过tableAPI或者sql来表达计算逻辑 由table-planner利用apache calcite对sql语义解析，绑定元数据得到逻辑执行计划 再用Optimizer进行优化后，得到物理执行计划 物理计划经过代码生成器后生成代码，得到Transformation Tree Transformation Tree转成JobGraph后提交到Flink集群执行 关于元数据管理 关于逻辑执行计划 关于查询优化 Flink Sql中有两个优化器 RBO(基于规则的优化器) CBO(基于代价的优化器) RBO(基于规则的优化器) 遍历一系列规则(RelOp ...

14. Flink 程序分布式部署运行14.1 Job执行流程 四层 说明 备注 StreamGraph 代码生成的最初的图 表示程序的拓扑结构 JobGraph 将多个符合条件的节点，链接为一个节点 可减少数据在节点之间流动所需要的序列化传输消耗 ExecutionGraph JobGraph的并行化版本 是调度层最核心的数据结构 PhysicalGraph JobManager根据ExecutionGraph对Job进行调度后，在各个TaskManager上部署Task后形成的“图” 并不是一个具体的数据结构 14.2 Flink集群运行时架构 14.3 Flink standalone集群Flink程序中如果要访问到hdfs，则需要添加2个jar包到Flink的lib目录中flink-shaded-hadoop-3-uber-3.1.1.7.2.9.0-173-9.0.jarcommons-cli-1.4.jar standalone集群模式的缺点： 资源利用弹性不够(资源总量是定死的，job退出后也不能立即回收资源) ...

13. Flink 容错配置及测试13.1 task级失败重启恢复状态Task级别的故障重启，是系统自动进行的 13.1.1 内置的重启策略1. Fixed Delay Restart Strategy固定延迟重启策略 会尝试一个给定的次数来重启Job 如果超过最大的重启次数(默认Integer.MAX_VALUE次)，Job最终会失败 在连续两次重启尝试之间，重启策略会等待一个固定时间 2. Exponential Delay Restart Strategy本策略：故障越频繁，两次重启间的惩罚间隔就越长 initialBackoff 重启间隔惩罚时长的初始值：1s maxBackoff 重启间隔最大惩罚时长：60s backoffMultiplier 重启间隔时长的惩罚倍数：2(每多故障一次，重启延迟惩罚就在上一次的惩罚时长*倍数) resetBackoffThreshold 重置惩罚时长的平稳运行时长阈值(平稳运行达到这个阈值后，如果再故障，则故障重启延迟时间重置为初始值：1s) jitterFactor 取一个随机数，来加在重启时间点上，已让每次重启的时间点 ...

12. Flink sink端容错机制12.1 幂等写入方式Sink端主要的问题是，作业失败重启时，数据重放可能造成最终目标存储系统中被写入了重复数据； 如果目标存储系统支持幂等写入，且数据中有合适的key(主键)，则Flink的sink端完全可以利用目标系统的幂等写入特点，来实现数据的最终一致(精确一次)； 只是，幂等写入的方式，能实现最终一致，但有可能存在过程中的不一致； 注意：动态过程不一致，主要出现在”输出结果非确定”的计算场景中，如，输出guid，event_id，event_count，insert_time则重复写入guid，event_id相同的两次数据时，第一次的值和后面覆盖的值，是发生了变化的 12.2 两阶段事务写入12.2.1 核心流程Flink中的两阶段事务提交sink，主要是利用了上述的”checkpoint两阶段提交协议”和目标存储系统的事务支持机制(比如mysql等)； Flink中两阶段事务提交的核心过程如下： Sink算子在一批数据处理过程中，先通过预提交事务开始对外输出数据 待这批数据处理完成(即收到了checkpoint信号)后，向checkp ...

11. Flink checkpoint机制11.1 分布式checkpoint的难题由于Flink是一个分布式的系统，数据在流经系统中各个算子时，是有先后顺序的，换个角度来说就是：整个系统对一条数据的处理过程，并不是一个原子性的过程； 这样一来，对系统中各算子的状态进行持久化(快照)，就成了一件棘手的事情； 来看如下数据处理场景： 算子1：从kafka中读取数据，并在状态中记录消费位移 算子2：对流入的整数进行累加，并输出累加结果 算子3：对流入是整数进行累加，并输出累加结果 先注意观察正常情况下，整个系统的各算子状态变化及最终输出结果 出于容错考虑，需要在某个时机对整个系统各个算子的状态数据进行快照持久化，如下 系统重启后加载快照数据，恢复各算子崩溃前的状态，但是会发现，处理结果相对正常时完全错误 从最终结果来看，整个计算 丢失了数据2的结果 数据3则因为内部状态的紊乱而产生了错误的结果 发生错误的根本原因是：简单粗暴的快照所得到的快照状态在各个算子间不统一(不是经过了相同数据的影响) 11.2 Checkpoint的核心要点chec ...

10. Flink 容错机制概述10.1 为什么要容错机制Flink是一个stateful(带状态)的数据处理系统，系统在处理数据的过程中，各算子所记录的状态会随着数据的处理而不断变化；一旦系统崩溃，需要重启后能恢复出崩溃前的状态才能进行数据的接续处理，因此，必须要有一种机制能对系统内的各种状态进行持久化容错； 10.2 Flink的Exactly-Once概述10.2.1 EOS基本概念Exactly-Once语义：指端到端的一致性，从数据读取、引擎计算、写入外部存储的整个过程中，即使机器或软件出现故障，都确保数据仅处理一次，不会重复也不会丢失。 对于Flink程序来说，端到端EOS语义则包含source、state、sink三个环节的紧密配合 10.2.2 Flink的精确一致核心要素 要实现端到端的EOS保证，核心点在于：一条(或者一批)数据，从注入系统、中间处理、到输出结果的整个流程中，要么每个环节都处理成功，要么失败回滚(回到从未处理过的状态)！ Flink在目前的各类分布式计算引擎中，对EOS的支持是最完善的；在合理的数据源选择，合理的算子选择，合理的目标存储系统选择 ...

9. Flink 状态(state)及使用9.1 状态基本概念什么是状态(raw状态) 在稍复杂的流式计算逻辑中，基本都需要记录和利用一些历史累积信息；例如，对整数流进行全局累计求和的逻辑： 我们在算子中定义一个变量来记录累计到当前的总和； 在一条新数据到达时，就将新数据累加到总和变量中； 然后输出结果； 由上可知：状态就是用户在程序逻辑中用于记录信息的变量 （当然，依据不同的需求，状态数据可多可少，可简单可复杂！） 如上所述，state只不过是用户编程时自定义的“变量”，跟Flink又有何关系呢？ 因为状态 (状态中记录的数据) 需要容错！！！程序一旦在运行中突然失败，则用户自定义的状态所记录的数据会丢失，因而无法实现失败后重启的接续！ Flink托管状态 Flink提供了内置的状态数据管理机制(简称状态机制)；Flink会进行状态数据管理：包括故障发生后的状态一致性维护、以及状态数据的高效存储和访问。 用户借由Flink所提供的状态管理机制来托管自己的状态数据，则不用担心状态数据在程序失败及恢复时所引入的一系列问题，从而使得开发人员可以专注于应用程序的逻辑开发； 9.2 ...

8. Flink 窗口计算API8.1 窗口(window)概念窗口，就是把无界的数据流，依据一定规则划分成一段一段的有界数据流；既然划分成有界数据段，通常都是为了”聚合”； Keyed Window重要特性：任何一个窗口，都绑定在自己所属的key上，不同key的数据肯定不会划分到相同窗口中去！ 8.2 窗口细分类型滚动窗口 滚动窗口，是滑动窗口的特例，可以用滑动窗口来表达。(窗口长度 = 滑动步长) 滑动窗口 会话窗口 会话窗口的触发机制，当Flink检查到前后两条数据中间间隔的时长超过了你指定的间隔时长，那么后面的数据就会进入一个新的窗口，而前面的窗口就闭合触发计算了。 8.3 窗口计算API模板下面展示了 Flink 窗口在 keyed streams 和 non-keyed streams 上使用的基本结构。 我们可以看到，这两者唯一的区别仅在于：keyed streams 要调用 keyBy(…)后再调用 window(…) ， 而 non-keyed streams 只用直接调用 windowAll(…)。留意这个区别，它能帮 ...

7. Flink 事件时间语义中的watermark7.1 事件时间推进的尴尬由于在事件时间语义的世界观中，时间是由流入系统的数据(事件)而推进的；而事件时间，并不能像处理时间那样，由宇宙客观规律以恒定速度，不可停滞地推进；从而，在事件时间语义的世界观中，时间的推进，并不是一件显而易见的事情； 场景1： 数据时间存在乱序的可能性，但时光不能倒流啊！ 场景2： 下游分区接受上游多个分区的数据，数据时间错落有致，那以谁为准？ 7.2 watermark推进时间 所谓watermark，就是在事件时间语义世界观中，用于单调递增向前推进时间的一种机制； 它的核心机制是在数据流中周期性的插入一种时间戳单调递增的特殊数据元素(watermark)，来不可逆转的在整个数据流中进行时间的推进； watermark中的时间戳到了哪里，算子的时间就推进到了哪里； Watermark是从某一个算子实例(源头)开始，根据数据中的事件时间，来周期性的产生，并插入到数据流中，持续不断的往下游传递，以推进整个计算链条上各个算子实例的时间！ 12//watermark的生成周期(默认 ...