共计 2559 个字符，预计需要花费 7 分钟才能阅读完成。
后面几篇文章带大家理解了 Flink 是什么、能做什么，本篇将带大家理解 Flink 到底是如何实现这些的，Flink 自身架构是什么样的，让大家先对 Flink 有整体认知，便于前期了解。
一、Flink 组件栈
Flink 是一个分层架构的零碎，每一层所蕴含的组件都提供了特定的形象，用来服务于下层组件。Flink 分层的组件栈如下图所示：
Deployment 层
该层次要波及了 Flink 的部署模式，Flink 反对多种部署模式：
- 本地、集群（Standalone/YARN）
- 云（GCE/EC2）
- Standalone 部署模式与 Spark 相似。
咱们看一下 Flink on YARN 的部署模式，如下图所示：
通过上图能够看到，YARN AM 与 Flink JobManager 在同一个 Container 中，这样 AM 能够晓得 Flink JobManager 的地址，从而 AM 能够申请 Container 去启动 Flink TaskManager。
待 Flink 胜利运行在 YARN 集群上，Flink YARN Client 就能够提交 Flink Job 到 Flink JobManager，并进行后续的映射、调度和计算解决。
Runtime 层
Runtime 层提供了反对 Flink 计算的全副外围实现，比方：
- 反对分布式 Stream 解决
- JobGraph 到 ExecutionGraph 的映射、调度等等，为下层 API 层提供根底服务。
API 层
API 层次要实现了面向无界 Stream 的流解决和面向 Batch 的批处理 API。
其中面向流解决对应 DataStream API，面向批处理对应 DataSet API。
Libraries 层
该层也能够称为 Flink 利用框架层，依据 API 层的划分，在 API 层之上构建的满足特定利用的实现计算框架，也别离对应于面向流解决和面向批处理两类。
- 面向流解决反对：CEP（简单事件处理）、基于 SQL-like 的操作（基于 Table 的关系操作）；
- 面向批处理反对：FlinkML（机器学习库）、Gelly（图解决）。
二、Flink 集群架构
次要为 Runtime 层细分。
Flink 的通用零碎架构如下图所示。
- 用户在客户端提交作业（Job）到服务端。
服务端为分布式的主从架构。
- Dispatcher 服务负责提供 REST 接口来接管 Client 提交的 Job，运行 Web UI，并负责启动和派发 Job 给 JobManager。
- Resource Manager 负责计算资源（TaskManager）的治理，其调度单位是 slots。
- JobManager 负责整个集群的工作治理、资源管理、协调应用程序的散布执行，将任务调度到 TaskManager 执行、检查点（checkpoint）的创立等工作。
- TaskManager（worker）负责 SubTask 的理论执行，提供肯定数量的 Slots，Slots 数就是 TM 能够并发执行的 task 数。当服务端的 JobManager 接管到一个 Job 后，会依照各个算子的并发度将 Job 拆分成多个 SubTask，并调配到 TaskManager 的 Slot 上执行。
工作的提交流程如下所示：
三、编程模型（API 层次结构 ）
次要为 API & Library 层细分。
Flink 提供了不同档次的接口，不便开发者灵便的开发流解决、批处理利用，依据接口应用的便捷性、表达能力的强弱分为四层：
- 最底层提供了有状态流：能够自定义状态信息和解决逻辑，然而也须要你本人治理状态的生命周期，容错，一致性等问题。
- 外围开发层：包含 DataStream API 和 DataSet API，它们提供了常见的数据转换，分组，聚合，窗口，状态等操作。这个层级的 api 适宜大多数的流式和批式解决的场景。
- 申明式 DSL 层：是以表为核心的申明式 DSL，其中表可能会动态变化（在表白流数据时）。Table API 提供了例如 select、project、join、group-by、aggregate 等操作
- 结构化层：SQL API，它是最高层的 api，能够间接应用 SQL 语句进行数据处理，无需编写 Java 或 Scala 代码。这个层级的 api 适宜须要疾速响应业务需要，缩短上线周期，和主动调优的场景，但也最不灵便和最不具备表现力。
四、Flink 数据流图
前一篇《WordCount 实现》文章中，咱们写了一个入门程序，那么代码中的输出、输入、计算等算子是如何与下面的概念对应起来的呢？
程序由多个 DataStream API 组成，这些 API，又被称为算子（Operator），独特组成了逻辑视角。在理论执行过程中，逻辑视角会被计算引擎翻译成可并行的物理视角。
在理论执行过程中，这些 API 或者说这些算子是并行地执行的。
- 分区：在大数据畛域，当数据量大到超过单台机器解决能力时，就将一份数据切分到多个分区（pattition）上，每个分区散布在一个虚拟机或物理机。
- 并行：从物理视角上看，每个算子是并行的，一个算子有一个或多个算子子工作（Subtask），每个算子子工作只解决一小部分数据，所有算子子工作独特组成了一个算子。依据算子所做的工作不同，算子子工作的个数可能也不同。
- 独立：算子子工作是互相独立的，一个算子子工作有本人的线程，不同算子子工作可能散布在不同的物理机或虚拟机上。
数据交换：
- 直传：source -> map，数据齐全传递
- 重调配：map -> keyBy，数据依照肯定形式重新分配到多个算子中
- 聚合：keyBy -> sink，多个算子的输入数据合并到一个算子中
五、小结
本篇文章从 Flink 组件栈开始，介绍 Flink 的分层架构，而后对每一层（Deploment、Runtime、API）进行了粗疏的解说，阐明每一层的作用和架构。最初对 Flink 数据流图进行了解说，阐明 Flink 代码是如何对应到具体执行的 task 的。
通过本篇解说带大家理解了 Flink 整体架构，对 Flink 工作构造有了一个根底的认知，前面将会对每个 Flink 外围概念和组件进行粗疏的解说。
参考文章：
Flink CookBook—Apach Flink 外围常识介绍
Flink 架构及工作原理介绍 – Workspace of LionHeart
Flink 架构 – 官网文档
God-Of-BigData/ 大数据框架学习 /Flink 外围概念综述.md at master · wangzhiwubigdata/God-Of-BigData
