一、核心特点
1.1、流批一体
1、无界数据
无界数据是持续产生的数据，所以必须持续的处理无界数据流。因为输入是无限的，没有终止时间。处理无界数据通常要求以特定顺序获取，以便判断事件是否完整、有无遗漏。
2、有界数据
有界数据就是在一个确定的时间范围内的数据流，有开始有结束，一旦确定了就不会再改变。
1.2、可靠的容错能力
1、集群级容错
与集群管理器集成
Flink与集群管理器紧密集成，例如Yarn、K8s。当进程挂掉时，将自动启动一个新进程来接管它工作。
高可用性设置
Flink具有高可用性模式特性，可消除所有单点故障。HA模式基于Apache Zookeeper。
2、应用级容错
Flink使用轻量级分布式快照机制，设计了检查点(CheckPoint)来实现可靠的容错。
一致性
Flink的恢复机基于应用程序状态的一致性检查点。如果发生故障，将重新启动应用程序并从最新的检查点加载其状态。Flink利用检查点特性，在框架层面提供了Exactly-Once的支持，内置了支持Exactly-Once语义的Sink,即使出现故障，也能保证数据只写出一次。
轻量级
对于长期运行的Flink，其检查点的状态可能高达TB级，生成和保存检查应用程序的检查点成本非常高。所以Flink提供了检查点的执行异步和增量检查点，以便尽量降低生成和保存检查点带来的计算负荷，避免数据处理的延迟异常变大和吞吐量的短暂剧降。
1.3、高吞吐、低延迟
Flink借助轻量级分布式快照机制，能定时生成分布式快照，并保存到外部存储中。检查点之间的数据处理被当做是原子的。如果失败，直接回到上一个检查点重新执行。在整个数据处理过程中不会产生阻塞。Flink在数据的计算、传输、序列化等方面也做了大量的优化，既能保持数据处理的低延迟，也能尽可能提高吞吐量。
1.4、大规模复杂计算
有状态计算
轻量级容错
1.5、多平台部署
Flink是一个分布式计算系统，可以与常见的集群管理器（如Hadoop Yarn、K8s）集成，也可以在物理服务器上作为独立集群运行。
二、架构
2.1、技术架构
Flink技术架构图如下：
对于开发者而言，直接使用API层和应用框架层，两者的差别在于API的层次不同，API层是Flink对外提供的核心API，应用框架层是在核心API之上提供的面向特定计算场景、更加易用的API。
应用框架层
指根据API层的划分，在API层之上构建的满足特定应用场景的计算框架，总体上分为流计算（Flink Table&SQL、FlinkCEP）和批处理（Flink Table&SQL、FlinkML、FlinkGelly）两类应用框架。
API层
API层是Flink对外提供能力的接口，实现了面向流计算的DataStream Api和面向批次处理的DataSetApi。为了推进流批API的统一，DataSet API未来会被废弃。
运行时层
DAG抽象：将分布式计算作业拆成并行子任务，每个子任务表示数据处理的一个步骤，并在上下游之间建立数据流的流通关系。
数据处理：包含了开发层面、运行层面的数据处理抽象。如 Join、Filter等。
作业调度：调度流批作业的执行。
容错：提供了集群级、应用级容错处理机制，保障集群、作业的可靠运行。
内存管理、数据序列化：通过序列化，使用二进制方式在内存中存储数据，避免JVM的垃圾回收带来的停顿问题。
数据交换：数据在计算任务之间的本地、跨网络传递。
部署层
Flink提供了灵活的部署模式，如 Strandalone、Yarn、Mesos、K8s、云服务
连接器
Connector是Flink计算引擎与外部存储交互的IO抽象，是Source和Sink的具体实现。
2.2、运行架构
Flink运行架构图如下：
Flink采用Master-Slave架构，Master的角色是JobManager,负责集群和作业管理，Slave的角色是TaskManager，负责执行计算任务。
Flink客户端：是Flink提供的CLI命令行工具，用来提交Flink作业到Flink集群，在客户端中负责Stream Graph（流图）和Job Graph（作业图）的构建。
JobManager：根据并行度将Flink客户端提交的Flink应用分解为子任务，从资源管理器申请所需要的的计算资源，资源具备后，开始分发任务到TaskManager执行Task,并负责应用容错，跟踪作业的执行状态，发现异常则恢复作业等。
TaskManager：接收JobManager分发的子任务，根据自身的资源情况，管理子任务的启动、停止、销毁、异常恢复等生命周期阶段。
接下来Flink应用篇，如果对Flink感兴趣或者正在使用的小伙伴，可以加我入群一起探讨学习。
参考书籍《Flink 内核原理与实现》
