Flink引擎 | 青训营笔记

这是我参与「第四届青训营 」笔记创作活动的第2天

今天我们学习了流/批/OLAP一体的Flink引擎，主要内容为以下四个部分：
Flink概述、Flink整体架构、Flink架构优化、例题讲解

Flink概述

Apache Flink 诞生背景

实时计算的业务场景需求、为什么会出现流式计算

• 数据实时价值更大；
• 大数据批式处理分钟级、小时级、天极，部分业务场景无法接受；

流式计算特点：

• 实时计算、快速、低延迟；
• 无限流、动态、无边界；
• 7*24 持续运行；

为什么 Flink 会脱颖而出

Storm API 的 low-level 以及开发效率低下；
一致性问题：Storm 更多考虑到实时流计算的处理时延而非数据的一致性保证；
Spark Streaming 相比于 Storm 的低阶 API 以及无法正确性语义保证，Spark 是流处理的分水岭：第一个广泛使用的大规模流处理引擎，既提供较为高阶的 API 抽象，同时提供流式处理正确性保证。

而对于Flink来说，具备如下技术特征：

• 完全一次保证：故障后应正确恢复有状态运算符中的状态；
• 低延迟：越低越好。许多应用程序需要亚秒级延迟；
• 高吞吐量：随着数据速率的增长，通过管道推送大量数据至关重要；
• 强大的计算模型：框架应该提供一种编程模型，该模型不限制用户并允许各种各样的应用程序在没有故障的情况下，容错机制的开销很低；
• 流量控制：来自慢速算子的反压应该由系统和数据源自然吸收，以避免因消费者缓慢而导致崩溃或降低性能；
• 乱序数据的支持：支持由于其他原因导致的数据乱序达到、延迟到达后，计算出正确的结果；
• 完备的流式语义：支持窗口等现代流式处理语义抽象；
• Google Dataflow Model 的开源引擎实现。

主要的流式计算引擎能力对比

Apache Flink 开源生态

Apache Flink 在开源生态上的能力比较强大，可以支持：

1. 流批一体：支持流式计算和批式计算；
2. OLAP：Flink 可以支持 OLAP 这种短查询场景；
3. Flink ML：pyFlink、ALink、AIFlow 等生态支持 Flink 在 ML 场景的应用；
4. Gelly：图计算；
5. Stateful Function：支持有状态的 FAAS 场景；

Flink 整体架构

• 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 和数据交换。

Flink 如何做到流批一体

为什么要做到流批一体

流批一体的一些挑战

Flink如何做到流批一体

Flink 流批一体总结

• 经过相应的改造和优化之后，Flink 在架构设计上，针对 DataStream 层、调度层、Shuffle Service 层，均完成了对流和批的支持。
• 业务已经可以非常方便地使用 Flink 解决流和批场景的问题了。

Flink 架构优化

流/批/OLAP业务场景概述

为什么三种场景可以用一套引擎来解决

• 场景上对比发现：
• 批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；
• OLAP 计算是一种特殊的批式计算，它对并发和实时性要求更高，其他情况与普通批式作业没有特别大区别。

Flink 如何支持 OLAP 场景

Flink做OLAP的优势

Flink OLAP 场景的挑战

Flink OLAP 架构现状

Flink 在 OLAP 架构上的问题与设想

• 架构与功能模块：
• JobManager 与 ResourceManager 在一个进程内启动，无法对JobManager 进行水平扩展；
• Gateway 与 Flink Session Cluster 互相独立，无法进行统一管理；
• 作业管理及部署模块：
• JobManager 处理和调度作业时，负责的功能比较多，导致单作业处理时间长、并占用了过多的内存；
• TaskManager 部署计算任务时，任务初始化部分耗时验证，消耗大量 CPU；
• 资源管理及计算任务调度：
• 资源申请及资源释放流程链路过长；
• Slot 作为资源管理单元，JM 管理 slot 资源，导致 JM 无法感知到 TM 维度的资源分布，使得资源管理完全依赖于 ResourceManager；
• 其他：
• 作业心跳与 Failover 机制，并不合适 AP 这种秒级或毫秒级计算场景；
• AP 目前使用 Batch 算子进行计算，这些算子初始化比较耗时；

设想

Flink使用案例

个人总结：

了解到了流式计算场景及流式计算框架的发展历程，以及为什么Flink能脱颖而出。并且知道了Flink的整体架构以及Flink如何调度和运行起来、如何做到流批一体，知道了Flink架构需要做哪些优化。