1.是什么？
Apache Flink是一种可以处理批处理任务的流处理框架。该技术可将批处理数据视作具备有限边界的数据流，借此将批处理任务作为流处理的子集加以处理。为所有处理任务采取流处理为先的方法会产生一系列有趣的副作用。
这种流处理为先的方法也叫做Kappa架构，与之相对的是更加被广为人知的Lambda架构（该架构中使用批处理作为主要处理方法，使用流作为补充并提供早期未经提炼的结果）。Kappa架构中会对一切进行流处理，借此对模型进行简化，而这一切是在最近流处理引擎逐渐成熟后才可行的。
1.主要概念：
Job Managers，Task Managers，Clients
Flink的运行时，由两种类型的进程组成：
- JobManagers： 也就是masters ，协调分布式任务的执行 。用来调度任务，协调checkpoints，协调错误恢复等等。至少需要一个JobManager，高可用的系统会有多个，一个leader，其他是standby
- TaskManagers： 也就是workers，用来执行数据流任务或者子任务，缓存和交互数据流。 至少需要一个TaskManager
- Client: Client不是运行是和程序执行的一部分，它是用来准备和提交数据流到JobManagers。之后，可以断开连接或者保持连接以获取任务的状态信息。
2、watermark有什么用？
watermark是用于处理乱序事件的，而正确的处理乱序事件，通常用watermark机制结合window来实现。
我们知道，流处理从事件产生，到流经source，再到operator，中间是有一个过程和时间的。虽然大部分情况下，流到operator的数据都是按照事件产生的时间顺序来的，但是也不排除由于网络、背压等原因，导致乱序的产生（out-of-order或者说late element）。
但是对于late element，我们又不能无限期的等下去，必须要有个机制来保证一个特定的时间后，必须触发window去进行计算了。这个特别的机制，就是watermark。
3.Flink框架的整体架构
- Deploy层
- Local：本地JVM进程中运行Flink程序
- Cluster：集群中运行Flink程序，分独立集群和Yarn集群（公司统一集群）
- API层
- DataStream：Flink提供的流处理API
- DataSet：Flink提供的批处理API
- Table：Flink提供的高级API，可以直接写类似SQL的代码来计算数据
4.Flink中的数据流模型：Source -> Transformation -> Sink
5.四个窗口
CountWindow： 按条数切分数据（也分滚动、滑动），每1000次点击中下单数统计等。
- TimeWindow
• TumblingWindow
• 滚动窗口，按固定时间切分数据，无重叠
• 每个时间段的聚合计算，BI报表 - SlidingWindow
• 滑动窗口，按固定时间和滑动间隔切分，有重叠
• 最近一段时间范围统计，系统监控 - SessionWindow
• 会话窗口，按两条记录时间差来切分数据
• 活跃期用户量等
6.Time类型及解释
- EventTime:事件发生时间
- IngestionTime:数据到来时间
- ProcessingTime:数据处理时间（默认）
7.Flink中容错性
- Savepoint机制：手动触发的checkpoint，可以指定存储路径，下次启动时可以从savepoint处执行
- Checkpoint机制：用户可以根据的程序里面的配置将checkpoint打开，给定一个时间间隔后，框架会按照时间间隔给程序的状态进行备份。当发生故障时，Flink会将所有Task的状态一起恢复到Checkpoint的状态。从哪个位置开始重新执行。
8.Flink状态管理
- state backend方式
- MemoryStateBackend: 将状态数据保存到内存中，存储受限，推荐测试时使用，线上不推荐
- FsStateBackend: 将状态数据保存到文件系统中，单TaskManager不超过内存，总存储不超过文件系统容量，如分钟级统计
- RocksDBStateBackend：将状态数据保存到缓存中，缓存存不下，会持久化一部分到磁盘，如天级别统计
- 当节点接收到barrier时，将自己的状态进行快照存储在配置好的state backend中，节点确认存储好之后，将barrier输出，下一个节点进行同样的操作，直到所有的节点都完成快照。source节点存储的是offset/position，其它节点存储的是指向快照的指针
9.数据的准确性控制
- Flink中端到端的exactly-once保证：两阶段提交
- 在data sink中要保证Exactly-Once语义，它必须将所有的写入数据通过一个事务提交到Kafka。在两个checkpoint之间，一个提交绑定了所有要写入的数据。
这保证了当出错的时候，写入的数据可以被回滚。
然而在分布式系统中，通常拥有多个并行执行的写入任务，简单的提交和回滚是效率低下的。为了保证一致性，所有的组件必须先达成一致，才能进行提交或者回滚。Flink使用了两阶段提交协议以及预提交阶段来解决这个问题。 - 预提交阶段：
- 在checkpoint开始的时候，即两阶段提交中的预提交阶段。首先，Flink的JobManager在数据流中注入一个checkpoint barrier，barrier通过operator传递。对于每一个operator，它将触发operator的状态快照写入到state backend。当checkpoint barrier在所有operator中都传递了一遍，以及它触发的快照写入完成，预提交阶段结束。
- 提交阶段：
- Jobmanager为程序中的每一个operator发起checkpoint已经完成的回调。data source和window operator没有外部的状态，在提交阶段中，这些operator不会执行任何动作。data sink拥有外部状态，所以通过事务提交外部写入。
- 外部状态通常由需要写入的外部系统引入，例如Kafka。因此，为了提供Exactly-Once保证，外部系统必须提供事务支持。
2.怎么干？
流处理模型
Flink的流处理模型在处理传入数据时会将每一项视作真正的数据流。Flink提供的DataStream API可用于处理无尽的数据流。Flink可配合使用的基本组件包括：
- Stream（流）是指在系统中流转的，永恒不变的无边界数据集
- Operator（操作方）是指针对数据流执行操作以产生其他数据流的功能
- Source（源）是指数据流进入系统的入口点
- Sink（槽）是指数据流离开Flink系统后进入到的位置，槽可以是数据库或到其他系统的连接器
为了在计算过程中遇到问题后能够恢复，流处理任务会在预定时间点创建快照。为了实现状态存储，Flink可配合多种状态后端系统使用，具体取决于所需实现的复杂度和持久性级别。
此外Flink的流处理能力还可以理解“事件时间”这一概念，这是指事件实际发生的时间，此外该功能还可以处理会话。这意味着可以通过某种有趣的方式确保执行顺序和分组。
批处理模型
Flink的批处理模型在很大程度上仅仅是对流处理模型的扩展。此时模型不再从持续流中读取数据，而是从持久存储中以流的形式读取有边界的数据集。Flink会对这些处理模型使用完全相同的运行时。
Flink可以对批处理工作负载实现一定的优化。例如由于批处理操作可通过持久存储加以支持，Flink可以不对批处理工作负载创建快照。数据依然可以恢复，但常规处理操作可以执行得更快。
另一个优化是对批处理任务进行分解，这样即可在需要的时候调用不同阶段和组件。借此Flink可以与集群的其他用户更好地共存。对任务提前进行分析使得Flink可以查看需要执行的所有操作、数据集的大小，以及下游需要执行的操作步骤，借此实现进一步的优化。
3.优势和局限
Flink目前是处理框架领域一个独特的技术。虽然Spark也可以执行批处理和流处理，但Spark的流处理采取的微批架构使其无法适用于很多用例。Flink流处理为先的方法可提供低延迟，高吞吐率，近乎逐项处理的能力。
Flink的很多组件是自行管理的。虽然这种做法较为罕见，但出于性能方面的原因，该技术可自行管理内存，无需依赖原生的Java垃圾回收机制。与Spark不同，待处理数据的特征发生变化后Flink无需手工优化和调整，并且该技术也可以自行处理数据分区和自动缓存等操作。
Flink会通过多种方式对工作进行分许进而优化任务。这种分析在部分程度上类似于SQL查询规划器对关系型数据库所做的优化，可针对特定任务确定最高效的实现方法。该技术还支持多阶段并行执行，同时可将受阻任务的数据集合在一起。对于迭代式任务，出于性能方面的考虑，Flink会尝试在存储数据的节点上执行相应的计算任务。此外还可进行“增量迭代”，或仅对数据中有改动的部分进行迭代。
在用户工具方面，Flink提供了基于Web的调度视图，借此可轻松管理任务并查看系统状态。用户也可以查看已提交任务的优化方案，借此了解任务最终是如何在集群中实现的。对于分析类任务，Flink提供了类似SQL的查询，图形化处理，以及机器学习库，此外还支持内存计算。
Flink能很好地与其他组件配合使用。如果配合Hadoop 堆栈使用，该技术可以很好地融入整个环境，在任何时候都只占用必要的资源。该技术可轻松地与YARN、HDFS和Kafka 集成。在兼容包的帮助下，Flink还可以运行为其他处理框架，例如Hadoop和Storm编写的任务。
目前Flink最大的局限之一在于这依然是一个非常“年幼”的项目。现实环境中该项目的大规模部署尚不如其他处理框架那么常见，对于Flink在缩放能力方面的局限目前也没有较为深入的研究。随着快速开发周期的推进和兼容包等功能的完善，当越来越多的组织开始尝试时，可能会出现越来越多的Flink部署。
4.总结
Flink提供了低延迟流处理，同时可支持传统的批处理任务。Flink也许最适合有极高流处理需求，并有少量批处理任务的组织。该技术可兼容原生Storm和Hadoop程序，可在YARN管理的集群上运行，因此可以很方便地进行评估。
工作中开发的例子(待我处理处理再公开)：
参考：
1.https://www.jianshu.com/p/8301d49595f7
2.https://www.jianshu.com/p/2ee7134d7373【很多漂亮的图，可以借鉴】
