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

流/批/OLAP 一体的 Flink 引擎介绍

1.Flink概述

1.1.Apache Flink诞生背景

1.1.1.大数据

大数据的定义：指无法在一定时间内用常规软件I具对其进行获取、存储、管理和处理的数据集合。

4V特性：

1.1.2.大数据计算架构的发展历史

谷歌提出的三驾马车（论文）：分布式文件系统GFS、分布式计算框架MapReduce、Bigtable

1.1.3.为什么需要流式计算？

大数据的实时性带来的价值更大，比如：监控场景、金融风控、实时推荐...

大数据实时性的需求，带来了大数据计算架构模式的变化：

1.2.为什么 Flink 会脱颖而出

1.2.1.流式计算引擎的发展历史

Storm：

Storm API 的 low-level 以及开发效率低下；
一致性问题：Storm 更多考虑到实时流计算的处理时延而非数据的一致性保证；

Spark Streaming：

Spark Streaming 相比于 Storm 的低阶 API 以及无法保证语义的正确性；
Spark 是流处理的分水岭：第一个广泛使用的大规模流处理引擎，既提供较为高阶的 API 抽象，同时提供流式处理正确性保证。

Flink：从产品技术来看，Flink 作为一个最新的实时计算引擎，具备如下流计算技术特征：

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

1.2.2.流式计算引擎对比

mini-batch 微批处理，不是按条处理

At Least/Most Once 至少处理一次（可能会多处理） / 至多处理一次（可能会处理不到）

1.2.3.Why Flink？

Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams. Flink has been designed to run in all common cluster environments, perform computations at in-memory speed and at any scale.来自 Apache Flink社区官方介绍

Apache Flink是一个框架和分布式处理引擎，用于在无界和有界数据流上进行状态计算。Flink 被设计为在所有常见的集群环境中运行，以内存中速度和任何规模执行计算。

Flink：从产品技术来看，Flink 作为一个最新的实时计算引擎，具备如下流计算技术特征：

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

1.3.Apache Flink的开源生态

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

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

2.Flink整体架构

2.1.分层架构

SDK 层: Flink 的SDK目前主要有三类，SQL/Table、DataStream（java/scala）、 Python;
执行引擎层(Runtime 层) ：执行引擎层提供了统一的DAG（有向无环图），用来描述数据处理的Pipeline，不管是流还是批，都会转化为DAG图，调度层再把DAG转化成分布式环境下的Task， Task 之间通过Shuffle传输数据；

Flink 中的执行资源是通过Task Slots定义的。每个TaskManager 都会有一个或多个任务槽，每个任务槽可以运行一个并行任务的管道。管道由多个连续任务组成。

Flink 内部通过 SlotSharingGroup 和 CoLocationGroup 定义了哪些任务可以共享一个槽（permissive），哪些任务必须严格放在同一个槽中。

状态存储层：负责存储算子的状态信息；
资源调度层：目前Flink 可以支持部署在多种环境。

2.2.整体架构

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

2.3.作业示例

2.4.如何做到流批一体

2.4.1.为什么需要流批处理？

一些业务场景，除了 实时的数据统计需求，为了确认运营或产品的效果，用户同时还需要和历史数据做比较，比如，抖音一些直播数据的统计；
这种架构有一些痛点：
- 人力成本比较高：批、流两套系统，相同逻辑需要开发两遍；
- 数据链路冗余：本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生一定的资源浪费；
- 数据口径不一致：两套系统、两套算子、两套 UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰。

2.4.2. 流批一体的挑战

流式处理/批式处理的业务场景的特点：
批式计算相比于流式计算核心的区别：

2.4.3.如何做到流批一体

为什么可以做到流批一体？

批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流。理论上，我们可以用一套引擎架构来解决上述两种场景。
站在 Flink 的角度，Everything is Streams，无边界数据集是一种数据流，一个无边界的数据流可以按时间切段成一个个有边界的数据集，所以有界数据集（批式数据）也是一种数据流。
因此，不管是有边界的数据集（批式数据）还是无边界数据集，Flink 都可以天然地支持，这是 Flink 支持流批一体的基础。并且 Flink 在流批一体上，从上面的 API 到底层的处理机制都是统一的，是真正意义上的流批一体。

Apache Flink 主要从以下几个模块来做流批一体：

SQL 层；
DataStream API 层统一，批和流都可以使用 DataStream API 来开发；
Scheduler 层架构统一，支持流批场景；
Failover Recovery 层架构统一，支持流批场景；
Shuffle Service 层架构统一，流批场景选择不同的 Shuffle Service；

2.4.3.1.流批一体的 Scheduler 层

Scheduler 主要负责将作业的 DAG 转化为在分布式环境中可以执行的 Task；

eager模式：12个task会一起调度，集群需要有足够的资源
lazy模式：最小调度一个task就可以，集群有一个slot资源就可以运行 (slots就是TaskManager的固定大小资源的一个集合。ResourceManager在做资源分配管理的时候，最小的单位就是slot。)

Pipeline Region Scheduler 机制：由Pipeline的数据交换方式连接的Task构成为一个Pipeline Region;

本质上，不管是流作业还是批作业，都是按照Pipeline Region粒度来申请资源和调度任务。

2.4.3.2.流批一体的 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 在策略上的定制，同时还能避免在共性需求上进行重复开发

2.4.4.流批一体总结

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

3.Flink架构优化

3.1.流/批/OLAP 业务场景概述

三种业务场景的特点：

三种业务场景的解决方案的要求及带来的挑战：

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

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

因此，理论上，我们是可以用一套引擎架构来解决上述三种场景，只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略。

3.3.Flink 如何支持 OLAP 场景

3.3.1.Flink做OLAP的优势

统一引擎：流处理、批处理、OLAP 统一使用 Flink 引擎；
- 降低学习成本，仅需要学习一个引擎；
- 提高开发效率，很多 SQL 是流批通用；
- 提高维护效率，可以更集中维护好一个引擎；
既有优势：利用 Flink 已有的很多特性，使 OLAP 使用场景更为广泛；
- 使用流处理的内存计算、Pipeline；
- 支持代码动态生成；
- 也可以支持批处理数据落盘能力；
相互增强：OLAP 能享有现有引擎的优势，同时也能增强引擎能力
- 无统计信息场景的优化；
- 开发更高效的算子；
- 使 Flink 同时兼备流、批、OLAP 处理的能力，成为更通用的框架。

3.3.2.Flink做OLAP 场景的挑战

秒级和毫秒级的小作业；
作业频繁启停、资源碎片；
- Flink OLAP 计算相比流式和批式计算，最大的特点是 Flink OLAP 计算是一个面向秒级和毫秒级的小作业，作业在启动过程中会频繁申请内存、网络以及磁盘资源，导致 Flink 集群内产生大量的资源碎片；
Latency + 高 APS 要求；
- OLAP 最大的特点是查询作业对 Latency 和 QPS 有要求的，需要保证作业在 Latency 的前提下提供比较高的并发调度和执行能力，这就对 Flink 引擎提出了一个新的要求。

3.2.3.Flink OLAP 架构现状

Client：提交 SQL Query；
Gateway：接收 Client 提交的 SQL Query，对 SQL 进行语法解析和查询优化，生成 Flink 作业执行计划，提交给 Session 集群；
Session Cluster：执行作业调度及计算，并返回结果。
- JobManager 管理作业的执行，在接收到 Gateway 提交过来的作业逻辑执行计划后，将逻辑执行计划转换为物理执行计划，为每个物理计算任务分配资源，将每个计算任务分发给不同的 TaskManager 执行，同时管理作业以及每个计算任务执行状态；
- TaskManager执行具体的计算任务，采用线程模型，为每个计算任务创建计算线程，根据计算任务的上下游数据依赖关系跟上游计算任务建立/复用网络连接，向上游计算任务发送数据请求，并处理上游分发给它的数据。

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

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

3.3.5.总结

Apache Flink最终演进到结果如下:

4.精选案例讲解

从原有的分场景处理演变为流批一体处理

流/批/OLAP 一体的 Flink 引擎介绍 | 青训营笔记