一、Flink概述
Apache Flink 是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink 能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。
Apache Flink 功能强大，支持开发和运行多种不同种类的应用程序。它的主要特性包括：批流一体化、精密的状态管理、事件时间支持以及精确一次的状态一致性保障等。
Flink 不仅可以运行在包括 YARN、 Mesos、Kubernetes 在内的多种资源管理框架上，还支持在裸机集群上独立部署。在启用高可用选项的情况下，它不存在单点失效问题。
二、Flink整体架构
2.1 分层架构
- SDK层：Flink的SDK主要有三类，SQL/Table、DataStream、Python
- 执行引擎层（runtime层）：执行引擎层提供了统一的DAG，用来描述数据处理的Pipeline，不管是流还是批，都会转化为DAG图，调度层再把DAG图转化成分布式环境下的Task，Task之间通过Shuffle传输数据
- 状态存储层：负责存储算子的状态信息
- 资源调度层：目前Flink可以支持部署在多种环境
2.2 总体架构
- Dispatcher：接收作业，拉起JobManager来执行作业，并在JobMaster挂掉之后恢复作业
- JobMaster：管理一个job的整个生命周期（调度task、触发协调task做checkpoint、协调容错恢复等），会向ResourceManager申请slot，并将task调度到对应的TM上
- TaskManager（TM）：负责执行一个DataFlow Graph和各个task以及data streams的buffer和数据交换
- ResourceManager：负责slot资源的管理和调度，TaskManager拉起之后会向RM注册
2.3 工作示例（Dataflow Model）
流式的WordCount示例，从kafka中读取一个实时的数据流，每10秒统计一次单词出现的次数，DataStream实现的代码如下：
将业务逻辑转化为Streaming DataFlow Graph（假设作业的sink算子并发为1，其余算子的并发为2）
为了更高效地分布式执行，Flink会尽可能地将不同的operator链接在一起形成Task，这样每个Task可以在一个线程中执行，内部叫做OperatorChain。如下图的source和map算子可以Chain在一起
最后将上面的Task调度到具体的TaskManager中的slot中执行，一个slot只能运行同一个task的subTask
2.4 Flink如何做到流批一体
站在 Flink 的角度，Everything is Streams，无边界数据集是一种数据流，一个无边界的数据流可以按时间切段成一个个有边界的数据集，所以有界数据集（批式数据）也是一种数据流。
因此，不管是有边界的数据集（批式数据）还是无边界数据集，Flink 都可以天然地支持，这是 Flink 支持流批一体的基础。并且 Flink 在流批一体上，从上面的 API 到底层的处理机制都是统一的，是真正意义上的流批一体。
- Apache Flink 主要从以下几个模块来做流批一体：
- SQL 层
- DataStream API 层统一，批和流都可以使用 DataStream API 来开发
- Scheduler 层架构统一，支持流批场景
- Failover Recovery 层 架构统一，支持流批场景
- Shuffle Service 层架构统一，流批场景选择不同的 Shuffle Service
- 流批一体的 Scheduler 层：
- Scheduler 主要负责将作业的 DAG 转化为在分布式环境中可以执行的 Task
- 1.12 之前的 Flink 版本，Flink 支持两种调度模式：
- EAGER（Streaming 场景）：申请一个作业所需要的全部资源，然后同时调度这个作业的全部 Task，所有的 Task 之间采取 Pipeline 的方式进行通信
- LAZY（Batch 场景）：先调度上游，等待上游产生数据或结束后再调度下游，类似 Spark 的 Stage 执行模式
- 流批一体的 Shuffle Service 层：
- Shuffle：在分布式计算中，用来连接上下游数据交互的过程叫做 Shuffle。实际上，分布式计算中所有涉及到上下游衔接的过程，都可以理解为 Shuffle
- Shuffle 分类：
- 基于文件的 Pull Based Shuffle，比如 Spark 或 MR，它的特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好一些
- 基于 Pipeline 的 Push Based Shuffle，比如 Flink、Storm、Presto 等，它的特点是低延迟和高性能，但是因为 shuffle 数据没有存储下来，如果是 batch 任务的话，就需要进行重跑恢复
- 流和批 Shuffle 之间的差异：
- Shuffle 数据的生命周期：流作业的 Shuffle 数据与 Task 是绑定的，而批作业的 Shuffle 数据与 Task 是解耦的
- Shuffle 数据存储介质：流作业的生命周期比较短、而且流作业为了实时性，Shuffle 通常存储在内存中，批作业因为数据量比较大以及容错的需求，一般会存储在磁盘里
- Shuffle 的部署方式：流作业 Shuffle 服务和计算节点部署在一起，可以减少网络开销，从而减少 latency，而批作业则不同
- Pluggable Shuffle Service：
- Flink 的目标是提供一套统一的 Shuffle 架构，既可以满足不同 Shuffle 在策略上的定制，同时还能避免在共性需求上进行重复开发
三、Flink架构优化
3.1 流/批/OLAP业务场景概述
- 三种业务场景的特点
- 三种业务场景面临的挑战
3.2 为什么三种场景可以使用一套引擎解决
- 批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；
- OLAP 计算是一种特殊的批式计算，它对并发和实时性要求更高，其他情况与普通批式作业没有特别大区别。
3.3 Flink如何支持OLAP场景
- Client：提交 SQL Query；
- Gateway：接收 Client 提交的 SQL Query，对 SQL 进行语法解析和查询优化，生成 Flink 作业执行计划，提交给 Session 集群；
- Session Cluster：执行作业调度及计算，并返回结果。
- JobManager 管理作业的执行，在接收到 Gateway 提交过来的作业逻辑执行计划后，将逻辑执行计划转换为物理执行计划，为每个物理计算任务分配资源，将每个计算任务分发给不同的 TaskManager 执行，同时管理作业以及每个计算任务执行状态；
- TaskManager执行具体的计算任务，采用线程模型，为每个计算任务创建计算线程，根据计算任务的上下游数据依赖关系跟上游计算任务建立/复用网络连接，向上游计算任务发送数据请求，并处理上游分发给它的数据。
