1 Apache Flink概述
1.1 Apache Flink 诞生
- 主要原因
- 业务发展对实时计算的需求更高
- 数据实时价值更大；
- 大数据批式处理分钟级、小时级、天极，部分业务场景无法接受；
- 流式计算特点：
- 实时计算、快速、低延迟；
- 无限流、动态、无边界；
- 7*24 持续运行；
1.2 Flink 的优势
1.2.1 流式计算引擎发展历史
- Storm：
- Storm API 的 low-level 以及开发效率低下；
- 一致性问题：Storm 更多考虑到实时流计算的处理时延而非数据的一致性保证；
- Spark Streaming：
- Spark Streaming 相比于 Storm 的低阶 API 以及无法正确性语义保证，Spark 是流处理的分水岭：第一个广泛使用的大规模流处理引擎，既提供较为高阶的 API 抽象，同时提供流式处理正确性保证。
- Flink脱颖而出的优势所在：
- 完全一次保证：故障后应正确恢复有状态运算符中的状态；
- 低延迟：越低越好。许多应用程序需要亚秒级延迟；
- 高吞吐量：随着数据速率的增长，通过管道推送大量数据至关重要；
- 强大的计算模型：框架应该提供一种编程模型，该模型不限制用户并允许各种各样的应用程序在没有故障的情况下，容错机制的开销很低；
- 流量控制：来自慢速算子的反压应该由系统和数据源自然吸收，以避免因消费者缓慢而导致崩溃或降低性能；
- 乱序数据的支持：支持由于其他原因导致的数据乱序达到、延迟到达后，计算出正确的结果；
- 完备的流式语义：支持窗口等现代流式处理语义抽象；
- 流批一体
- Google Dataflow Model 的开源引擎实现，较好支持Windows计算
1.2.2主要的流式计算引擎能力对比
1.3 Apache Flink 开源生态
Apache Flink 在开源生态上的能力比较强大，可以支持：
- 流批一体：支持流式计算和批式计算；
- OLAP：Flink 可以支持 OLAP 这种短查询场景；
- Flink ML：pyFlink、ALink、AIFlow 等生态支持 Flink 在 ML （机器学习）场景的应用；
- Gelly：图计算；
- Stateful Function：支持有状态的 FAAS 场景；
1 总结
Flink 是流批一体 的计算引擎，在大数据背景下，其具有 流批一体，精确一次的语义分析，高吞吐高容错，具有较好的生态支持 等优势，并支持 众多应用场景
2 Flink 整体架构
2.1 Flink 分层架构
- SDK 层
- 执行引擎层（Runtime 层）：执行引擎层提供了统一的 DAG，用来描述数据处理的 Pipeline，不管是流还是批，都会转化为 DAG 图，调度层再把 DAG 转化成分布式环境下的 Task，Task 之间通过 Shuffle 传输数据；
- Task 生命周期：Task Lifecycle；TM中的TaskSlot相当于线程，每一个Slot都会执行一个Task，基于不同的计算过程（算子不同），具体的Task也不同，但总体的生命周期都是一致的，正常来说分为以下三个阶段：
- 启动及初始化：
invoke（）（初始化算子）—>init( )执行基于任务的初始化—>initializeState( )检索状态—>open()执行所有操作的初始化—> - 运行：
run（）运行任务—> - 退出并关闭：
清除计时器—>finishAllOperators()通知finish（）算子—>释放算子资源，进行任务清理（关闭通道，清理缓冲区）
- Flink Failover 机制：Task Failure Recovery；
- 默认重启策略是通过 Flink 的配置文件设置的
flink-conf.yaml。配置参数_restart-strategy_定义采用哪种策略。如果未启用检查点，则使用“不重启”策略。如果检查点已激活且未配置重启策略，则使用固定延迟策略和Integer.MAX_VALUE重启尝试
- Flink 反压概念及监控：Monitoring Back Pressure；
- Flink HA 机制：Flink HA Overview；
- 状态存储层：负责存储算子的状态信息
2.2 Flink 整体架构（Flink Architecture）
- JobManager（JM）负责整个任务的协调工作，包括：调度 task、触发协调 Task 做 Checkpoint、协调容错恢复等，核心有下面三个组件：
- Dispatcher: 接收作业，拉起 JobManager 来执行作业，并在 JobMaster 挂掉之后恢复作业；
- JobMaster: 管理一个 job 的整个生命周期，会向 ResourceManager 申请 slot，并将 task 调度到对应 TM 上；
- ResourceManager：负责 slot 资源的管理和调度，Task manager 拉起之后会向 RM 注册；
- TaskManager（TM）：负责执行一个 DataFlow Graph 的各个 task 以及 data streams 的 buffer 和数据交换。
2.3 Flink 作业示例
- 2.3.1 数据流的处理
- 在 Flink 中，应用程序由流式数据流组成，Client端将这些流式数据流（用户代码）通过自定义算子抽象成有向图，以一个或多个源开始，以一个或多个终点结束，然后将该Graph作为Job提交给JM，JM进行task分配，然后TM去执行task
- ExecutionGraph 生成：DataStream API Code --> JobGraph --> ExecutionGraph（Parallelized） - 应用程序可以使用来自消息队列或分布式日志（如 Apache Kafka 或 Kinesis）等流式源的实时数据。但是 flink 也可以使用来自各种数据源的有限的历史数据。同样，Flink 应用程序生成的结果流可以发送到可以作为接收器连接的各种系统
- 2.3.2并行计算
- Flink 中的程序是并行和分布式的。在执行过程中，一个流有一个或多个流分区，每个算子都有一个或多个算子子任务。算子子任务相互独立，在不同的线程中执行，可能在不同的机器或容器上执行。
算子子任务的数量是该特定算子的**并行度。**同一程序的不同运算符可能具有不同级别的并行度
- OperatorChain（算子连接）：
- 为了更高效地分布式执行,Flink会尽可能地将不同的operator链接( chain)在一起形成Task。这样每个Task可以在一个线程中执行,内部叫做OperatorChain,如下图的source和map 算子可以Chain在一起。如下图所示：
将Source与map连接在一起，可以单线程执行，如此 避免了线程切换，序列反序列化带来的开销，就Flink的内部实现机制来讲，减少了数据在缓冲区的交换，在减少延迟的同时提高整体的吞吐力
- 并行执行
- 每个Slot在TM中相当于一个线程，但是并不完全独立，其CPU等物理资源并没有完全隔离开来，可以理解为:每个TM是一个进程，而每个TaskSlot都是其中的一个线程，同时执行task
- 2.3.3 状态快照容错机制
- 存储的状态只在本地访问，减少了网络开销，有助于Flink的高吞吐低延迟优势的实现，并且通过状态快照实现容错机制，这些快照捕获分布式管道的整个状态，将偏移量记录到输入队列中，以及整个作业图的状态，这些状态是由于在该点之前摄取数据而产生的。当发生故障时，源被倒带，状态被恢复，并且处理被恢复。如上所述，这些状态快照是异步捕获的，不会妨碍正在进行的处理。
2.4 Flink 如何做到流批一体
- 何为流？何为批？何为流批一体？
可以说 流是数据的 载体，在现实生活中，无论是网络服务器事件、证券交易所的资金交易、又或是工厂机器的传感器度数，这些数据都是作为流的一部分创建的。在分析数据时，选择一个较好的处理范式无疑是最佳选择，其带来的效果亦是无与伦比的。
首先，众所周知，批处理是处理有界数据流时的范例，在这种操作模式下，可以选择在生成任何结果之前提取整个数据集，这意味着可以对数据进行排序、计算全局统计数据或生成汇总所有输入的最终报告。
而对于 流处理来说，对于无限数据流的处理是其最大的优势，也就是 对于那些需要实时处理或者没有明确界限的数据进行处理时，就需要用到流处理。
在Flink看来，批数据也是数据流，可以被Flink支持，所以批式处理也可以看做是一种特殊形式的流式处理，并且Flink对于数据流的处理机制都是统一的，那么流批一批从理论上就得到了可行性支持，需要的便是框架的一些优化与扩展。 - 为什么需要流批一体
- 一些业务场景，除了实时的数据统计需求，为了确认运营或产品的效果，用户同时还需要和历史数据做比较，比如，抖音一些直播数据的统计；
既需要 流处理进行实时数据统计的需要， 也需要批处理 对数据进行 离线对比
- 这种架构有一些痛点： - 人力成本比较高：批、流两套系统，相同逻辑需要开发两遍； - 数据链路冗余：本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生一定的资源浪费； - 数据口径不一致：两套系统、两套算子、两套 UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰。
- 流批一体的挑战
- 批式计算相比于流式计算核心的区别：
- 无限数据集 --> 有限数据集；
- 低延迟 --> 实时性要求不高；
- Flink 如何做到流批一体
- 批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；
- 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 执行模式。
也就是 可以最小调度一个task资源，先申请一个slot，从A1—B1—C1C2这种路线进行执行
- Pipeline Region Scheduler 机制：FLIP-119 Pipelined Region Scheduling - Apache Flink - Apache Software Foundation；
所以在Flink中对于上述两种 数据Scheduler机制，实现了一个基于Pipeline Region架构的Scheduler机制
具体实现方法是 就上图十二个算子的场景来说： - 对于Blocking（批）模式，分为12个Pipeline Region - 对于Pipeline(流)，分为1 个Pipeline Region
这样就可以基于一个Scheduler 做到同时处理Blocking与Pipeline
- 流批一体的 Shuffle Service 层（FLIP-31: Pluggable Shuffle Service - Apache Flink - Apache Software Foundation）
- 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在Streaming和Batch模式下的Shuffle 架构, Flink实现了-一个Pluggable 的 ShuffleService框架,抽象出一些公共模块。
- Flink 流批一体总结
- 经过相应的改造和优化之后，Flink 在架构设计上，主要针对 DataStream 层、调度层、Shuffle Service 层的共同特点抽象出一些公共模块进行架构，均完成了对流和批的支持。
- 业务已经可以非常方便地使用 Flink 解决流和批场景的问题了。
🌹写在最后💖： 路漫漫其修远兮，吾将上下而求索！伙伴们，明天见！🌹🌹🌹
