1. 核心特点

批流一体

1. 无界数据
   无界数据是持续产生的数据，所以必须持续地处理无界数据流。数据是无限的，也就无法等待所有输入数据到达后处理，因为输入是无限的，没有终止的时间。处理无界数据通常要求以特定顺序获取，以便于判断事件是否完整，有无遗漏
2. 有界数据
   有界数据，就是在一个确定的时间范围内的数据流，有开始有结束，一旦确定了就不会再改变

Flink的设计思想和谷歌Cloud Dataflow的编程模型较为接近，都以流为核心，批是流的特例

可靠的容错能力

在分布式系统中，硬件故障，进程异常，应用异常，网络故障等多种多样的异常无处不在。像Flink这样的分布式计算引擎必须能够从故障中恢复到正常状态，以便于实现全天候运行。这就要求引擎在故障发生后不仅可以重新启动应用程序，还要确保其内部状态保持一致，从最后一次正确的点重新执行，从用户的角度来说，最终的计算结果与未发生故障是一样的

集群级容错

1. 高可用
2. 与集群管理器集成

应用级容错

1. 一致性
   Flink的恢复机制基于应用程序状态的一致性检查点。如果发生故障，将重新启动应用程序并从最新检查点加载其状态。结合可重放的流数据源，此特性可以精准，一次的状态一致性
2. 轻量级
   对于长期运行的Flink应用程序，其检查点的状态可能高达TB级，生成和保存检查点应用程序的检查点成本非常高，所以Flink提供了检查点的执行异步和增量检查点，以便于尽量降低生产和保存检查点带来的计算负荷，避免数据处理的延迟异常变大和吞吐量的短暂剧增

高吞吐，低延迟

Flink借助于轻量级分布式快照机制，能够定时生成分布式快照，并将快照保存到外部存储中。检查点之间的数据处理被当成是原子的，如果失败，直接回到上一个检查点重新执行即可

大规模复杂计算

多平台部署

2. 架构

从概念上讲来说，所有的计算都符合“数据输入 - 处理转换 - 数据输出”的过程，这个过程有时候叫作数据处理流水线（pipeline），流水线的概念来自生产制造中的流水线

技术架构

应用框架层

1. Table&SQL
   SQL基于Calcite，支持标准SQL
2. CEP
   CEP本质上是一种实时事件流上的模式匹配技术，是实时事件流上常见的用例。CEP通过分析事件间的关系，利用过滤，关联，聚合等技术，根据事件间的时序关系和聚合关系制定匹配规则，持续地从事件流中匹配出符合要求的事件序列，通过模式组合能够识别更加复杂的事件序列，主要用于反欺诈，风控，营销决策，网络安全分析等场景
3. Gelly
4. ML

API层

API层时Flink对外提供能力的接口，实现了面对流计算的DataSteam API和面对批处理的DataSet API,Dataset API未来会被废弃

运行时层

1. DAG抽象：将分布式计算作业拆分成并行子任务，每个子任务表达数据处理的一个步骤，并且在上下游之间建立数据流的流通关系
2. 数据处理：包含了开发层面，运行层面的数据处理抽象
3. 作业调度：
4. 容错：提供集群级，应用级容错处理机制，保障集群，作业的可靠性
5. 内存管理，数据序列化：通过序列化，使用二进制方式在内存中存储数据，避免JVM的垃圾回收带来的停顿问题
6. 数据交换：数据在计算任务之间的本地，跨网络传递

部署层

1. Standalone模式
2. Yarn,Mesos,K8s等资源管理集群模式
3. 云上模式

连接器

3. 运行架构

Flink运行时架构

Flink客户端

Flink提供的CLI命令行工具，用来提交Flink作业到Flink集群，在客户端中负责流图和作业图

JobManager

1）控制一个应用程序执行的主进程，也就是说每一个应用程序都会被一个不同的JobManager所控制。
2）JobManager会先接收到要执行的应用程序，这个应用程序会包括：作业图（JobGraph）、逻辑数据流图（logical dataflow graph）和打包了所有的类、库和其他资源的JAR包。
3）JobManager会把JobGraph转换成一个物理层面的数据流图，这个图被叫做“执行图”（ExecutionGraph），包含了所有可以并发执行的任务。
4）JobManager会向资源管理器（ResourceManager）请求执行任务必要的资源，也就是任务管理器（TaskManager）上的插槽（slot）。一旦它获取到了足够的资源，就会将执行图分发到真正运行它们的TaskManager上。而在运行过程中，作业管理器会负责所有需要中央协调的操作，比如说检查点（checkpoints）的协调。

TaskManager

1）Flink中的工作进程（是一个JVM进程，里面可以有多个线程，线程数量由slot数量决定）。通常在Flink中会有多个TaskManager运行，每一个TaskManager都包含了一定数量的插槽（slots）。插槽的数量限制了TaskManager能够执行的任务数量。
2）启动之后，TaskManager会向资源管理器注册它的插槽，收到资源管理器的指令后，TaskManager就会将一个或者多个插槽提供给JobManager调用。JobManager就可以向插槽分配任务（tasks）来执行了。（TaskManager向资源管理器说明自己插槽的可用情况，在JobManager向资源管理器请求资源即插槽的时候，直接就可以看到哪个TaskManager有空闲的插槽，那么就可以分配任务给这些TaskManager了）
3）在执行过程中，一个TaskManager可以跟其它运行同一应用程序的TaskManager交换数据。（一个任务执行完之后，就要将数据发送到下一个任务里，下一个任务可能在一个TaskManager里的不同插槽上，也可能在别的TaskManeger上）

ResourceManager

1）主要负责管理任务管理器（TaskManager）的插槽（slot），TaskManager插槽是Flink中定义的处理资源单元。
2）Flink为不同的环境和资源管理工具提供了不同资源管理器，比如Yarn、Mesos、K8s，以及standlone部署。
3）当JobManager申请插槽资源时，ResourceManager会将有空闲插槽的TaskManager分配给JobManager。如果ResourceManager没有足够的插槽来满足JobManager的请求，它还可以向资源提供平台发起会话，以提供TaskManager进程的容器（如果是standlone这种没有资源管理平台的环境只能一直转圈，不能申请了，也一直无法执行）。

Dispatcher

1）可以跨作业运行，它为应用提交提供了REST接口。
2）当一个应用被提交执行时，分发器就会启动并将应用移交给一个JobManager。（就是一个桥梁的作用）
3）Dispatcher也会启动一个Web UI，用来方便地展示和监控作业执行的信息。
4）Dispatcher在架构中可能并不是必需的，这取决于应用提交运行的方式。

4. Flink的未来