定义
∙ 一个批处理和流处理结合的统一计算框架
∙ 核心是一个提供了数据并发以及并行化计算的流数据处理引擎
特性
∙ 提供准确的结果，甚至在出现无序或者延迟加载的数据的情况下
∙ 它是状态化的容错的，同时在维护一次完整的的应用状态时，能无缝修复错误
∙ 大规模运行，在上千个节点运行时有很好的吞吐量和低延迟
无界流和有界流
任何类型的数据都是作为事件流产生的。信用卡交易、传感器测量、网站或移动应用程序上的用户交互等，所有这些数据都作为流生成。
数据可以作为无界或有界流处理。
无界流有一个开始但没有定义的结束。系统必须持续处理无界流，即必须在摄取事件后立即处理事件，无法等待所有输入数据到达，因为输入是无界的，在任何时间点都不会完成。处理无界数据通常要求以特定顺序（例如事件发生的顺序）摄取事件，以便推断结果完整性。
有界流具有定义的开始和结束。可以在执行任何计算之前通过摄取所有数据来处理有界流。处理有界流不需要有序摄取，因为可以始终对有界数据集进行排序。
系统架构
Flink将批处理视作一种特殊的流处理（有界流）。
抽象层API
基于流执行引擎，Flink提供了诸多更高抽象层的API以便用户编写分布式任务：
∙ DataSet API——对静态数据进行批处理操作，将静态数据抽象成分布式的数据集，用户可以方便地使用Flink提供的各种操作符对分布式数据集进行处理。
∙ DataStream API——对数据流进行流处理操作，将流式的数据抽象成分布式的数据流，用户可以方便地对分布式数据流进行各种操作。
∙ Table API——使用类SQL进行流和批处理。
∙ CEP API——支持在流中发现复杂的事件模式，快速筛选用户感兴趣的数据。
领域库
Flink针对特定的应用领域提供了领域库，例如：
∙ FlinkML——Flink的机器学习库，提供了可扩展的机器学习算法、简洁的API和工具简化机器学习系统的开发。
∙ Gelly——Flink的图计算库，提供了简化开发和构建图计算分析应用的接口。
工作流程
用户提交Flink程序到JobClient，JobClient经过处理、解析、优化提交到JobManager，最后由TaskManager运行task。
三大组件
∙ JobClient
Flink程序和JobManager交互的桥梁，主要负责接收程序、解析并优化程序的执行计划，然后提交执行计划到JobManager。
∙ JobManager
主要负责申请资源，协调以及控制整个job的执行过程，在接收到JobClient提交的执行计划之后，针对收到的执行计划继续解析，最后向集群申请资源，一旦资源就绪，就调度task到TaskManager。
∙ TaskManager
主要负责接收并执行JobManager发送的task，并且与JobManager通信，反馈任务状态信息。
工作原理
Flink程序是由Stream和Transformation这两个基本构建块组成。从概念上讲，Stream是可能永无止境的数据记录流。 Stream是一个中间结果数据，而Transformation是算子，它对一个或多个输入Stream进行计算处理，输出一个或多个结果Stream。
执行时，Flink程序映射到多个Streaming Dataflow，由Stream和Transformation组成。每个数据流都以一个或多个source开始，并以一个或多个sink结束。 数据流类似于任意有向无环图（DAG）。
窗口
在流处理应用中，数据是连续不断的，因此我们不可能等到所有数据都到了才开始处理。当然我们可以每来一个消息就处理一次，但是有时我们需要做一些聚合类的处理，例如：在过去的1分钟内有多少用户点击了我们的网页。在这种情况下，我们必须定义一个窗口，用来收集最近一分钟内的数据，并对这个窗口内的数据进行计算。
窗口可以是时间驱动的(Time Window，例如: 每30秒钟)，也可以是数据驱动的(Count Window，例如: 每一百个元素)。
时间
处理Stream中的记录时，记录中通常会包含各种典型的时间字段：
∙ Event Time：事件时间，表示事件的创建时间，通常由事件中的时间戳描述。
∙ Ingestion Time：摄取时间，表示事件进入到Flink Dataflow的时间。
∙ Processing Time：处理时间，表示某个Operator对事件进行处理的本地系统时间。
消息传递语义
∙ At Most once：对于一条message，receiver最多收到一次(0次或1次)。即sender把message发送给receiver，无论receiver是否收到message，sender都不再重发message。
∙ At Least once：对于一条message，receiver最少收到一次(1次及以上)。即sender把message发送给receiver，当receiver在规定时间内没有回复ACK或回复了error信息，那么sender重发这条message给receiver，直到sender收到receiver的ACK。
∙ Exactly once: 对于一条message，receiver确保只收到一次。
Flink — Exactly once
Flink实现Exactly once的策略：Flink会持续地对整个系统做快照，然后把global state(根据config文件设定)储存到master node或HDFS。当系统出现failure，Flink会停止数据处理，然后把系统恢复到最近的一次checkpoint。
这样就保证了对于consumer来说，每条消息只消费了一次，同时也为Flink的容错性提供了保障。
Flink — Checkpoint
Checkpoint机制是Flink运行过程中容错的重要手段。
Checkpoint能够根据配置周期性地基于Stream中各个Operator/task的状态来生成快照，从而将这些状态数据定期持久化存储下来。当Flink集群在某个算子因为某些原因(如异常退出)出现故障时，能够将整个应用流图的状态恢复到发生故障之前的某一状态，保证应用流图状态的一致性。
Flink分布式快照机制的核心是barriers，这些barriers周期性插入到数据流中，并作为数据流的一部分随之流动。
∙ 一旦Operator从输入流接收到Checkpoint barrier n，它就不能处理来自该流的任何数据记录。Operator将该流的分区数据缓存起来以等待来源较慢的流分区，直到它从其他所有输入流接收到barrier n为止。如下图2，虽然数字流对应的barrier已经到达了，但是barrier之后的1、2、3这些数据只能放到buffer中，等待字母流的barrier到达。否则，它会混合属于快照n的记录和属于快照n + 1的记录。
∙ 一旦最后所有输入流都接收到barrier n，Operator就会检查其状态(如果有)并写到持久存储中，然后把缓冲区中pending的输出数据发出去，把CheckPoint barrier n接着往下游发送。