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

Apache Flink 概述

Hadoop 诞生背景，Hadoop 解决了什么问题？（大数据十年回顾：浪潮之巅数英雄_大数据_宋词_InfoQ精选文章）

实时计算的业务场景需求、为什么会出现流式计算
- 数据实时价值更大；
- 大数据批式处理分钟级、小时级、天极，部分业务场景无法接受；

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

引擎对比

Flink开源生态

Flink架构

Flink 分层架构

1.SDK层: Flink的 SDK目前主要有三类，SQL/Table、DataStream、Python;

2.执行引擎层(Runtime层)∶执行引擎层提供了统一的 DAG,用来描述数据处理的 Pipeline，不管是流还是批，都会转化为DAG图，调度层再把DAG转化成分布式环境下的Task，Task 之间通过Shuffle传输数据;

3.状态存储层:负责存储算子的状态信息;

4.资源调度层:目前Flink可以支持部署在多种环境。

Flink 整体架构

一个Flink集群，主要包含以下两个核心组件:

1.JobManager (JM) :负责整个任务的协调工作，包括:调度task、触发协调Task做 Checkpoint、协调容错恢复等;

2.TaskManager (TM):负责执行一个DataFlowGraph 的各个task 以及data streams的 buffer和数据交换。

Flink 如何做到流批一体

流批一体的挑战
- 批式计算相比于流式计算核心的区别：
  - 无限数据集 --> 有限数据集；
  - 低延迟 --> 实时性要求不高；

Flink 如何做到流批一体
- 批式计算是流式计算的特例，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；
流批一体的 Scheduler 层

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

1.12 之前的 Flink 版本，Flink 支持两种调度模式：
- EAGER（Streaming 场景）：申请一个作业所需要的全部资源，然后同时调度这个作业的全部 Task，所有的 Task 之间采取 Pipeline 的方式进行通信；

LAZY（Batch 场景）：先调度上游，等待上游产生数据或结束后再调度下游，类似 Spark 的 Stage 执行模式。

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

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

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

Flink 架构优化

三种业务场景的特点

三种业务场景面临的挑战

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

了解即可

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

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

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

设想如下：

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