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

这是我参与【第四届青训营-大数据场】笔记创作活动的第3天

大数据计算架构

• 大数据是指无法在一定的时间内用用常规的工具进行获取存储和管理处理的数据集合
• 大数据具有海量化、多样化、快速化、价值化
• 海量化：大数据首先它的量是规模是非常非常大的
• 多样化：大数据它的数据源和数据种类也是非常多样的，举个例子就是不仅仅他有格式化的数据，还有很多半结构化的数据以及结构化的数据，比如说我们的即时消息图片音频流等数据
• 快速化：数据产生和处理的速度是非常非常快，特别是随着移动互联网的整个产业的一个存储，手机系统数据的规模它产生的速度都是非常非常快的
• 价值化：数据的价值密度是非常低的，但是数据整体价值它是有非常高的一个一个价值的

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

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

1.JobManager(JM):负责整个任务的协调工作，包括:调度 task、触发协调 Task 做 Checkpoint、协调容错恢复等; 2.TaskManager(TM):负责执行一个 DataFlow Graph 的各个 task 以及 data streams 的 buffer 和数据交换。

• Dispatcher: 接收作业，拉起 JobManager 来执行作业，并在 JobMaster 挂掉之后恢复作业;
• JobMaster: 管理一个job 的整个生命周期，会向 ResourceManager 申请 slot，并将 task 调度到对应 TM 上; ResourceManager:负责 slot 资源的管理和调度，Task manager 拉起之后会向 RM 注册;
• 最后将上面的 Task 调度到具体的 TaskManager 中的 slot 中执行，一个 Slot 只能运行同一 task 的 subTask
• 假设作业的 sink 算子的并发配置为 1，其余算子并发为 2
• 紧接着会将上面的 Streaming DataFlow Graph 转化 Parallel Dataflow(内部叫 Execution Graph):
• 为了更高效地分布式执行，Flink 会尽可能地将不同的 operator 链接(chain)在一起形成lask
• 这样每个 Task 可以在一个线程中执行，内部叫做 OperatorChain，如下图的 source 和 map 算子可以 Chain 在一起

流式计算

流式计算可以进行时式计算，它的延迟在秒级以内，大约零到一秒。它时常用于广告推荐和金融分款。

批式计算

批示计算是离线计算，它的处理时间为分钟到小时级别的，甚至是每一天的这一种级别。他的时间控制在十秒或者到一小时加，他用来搜索引擎构建索引和批示数据分析

• 1. SDK 层:Flink 的 SDK 目前主要有三类，SQL/Table、 DataStream. Python; 2.执行引擎层(Runtime 层):执行引擎层提供了统一的 DAG 用来描述数据处理的 Pipeline，不管是流还是批，都会转化为 DAG 图，调度层再把 DAG 转化成分布式环境下的 Task Task 之间通过 Shuffle 传输数据; 3.状态存储层:负责存储算子的状态信息; 4.资源调度层:目前 Flink 可以支持部署在多种环境。

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

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

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

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

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

• ALL EDGES BLOCKING:

• 所有 Task 之间的数据交换都是 BLOCKING模式;

• 分为 12个pipeline region ;

• ALL EDGES PIPELINED:

• 所有 Task 之间的数据交换都是 PIPELINE 模式;

• 分为 1个 pipeline region ;

- 流批一体的 Scheduler 层

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

在Streaming 和 OLAP 场景

• 为了性能的需要，通常会使用基于 Pipeline 的 Shuffle 模式在Batch 场景

• 一般会选取 Blocking 的 Shuffle 模式

• 为了统一 Flink 在 Streaming 和 Batch 模式下的

• Shuffle 架构，Flink 实现了一个 Pluggable 的 Shuffle Service 框架，抽象出一些公共模块。

• 2.4.5.流批一体的 Shuffle Service 层 川

• 对于 Shuffle Service，Flink 开源社区已经支持:

• 1. Netty Shuffle Service: 既支持 pipeline 又支持 blocking，Flink 默认的 shuffle Service 策略
• 2. Remote Shuffle Service: 既支持 pipeline 又支持 blocking，不过对于 pipeline 模式，走

• remote 反而会性能下降，主要是有用在 batch 的 blocking 场景，字节内部是基于 CSS 来实现的 RSS。

• 经过相应的改造和优化之后，Flink 在架构设计上，针对 DataStream 层、调度层、Shuffle Service 层，均完成了对流和批的支持。

• 至此，业务已经可以非常方便地使用 Flink 解决流和批场景的问题了。

Flink 如何支持 OLAP 场景

• Flink 做 OLAP 的优势

  • 统一引擎：流处理、批处理、OLAP 统一使用 Flink 引擎；

    • 降低学习成本，仅需要学习一个引擎；
    • 提高开发效率，很多 SQL 是流批通用；
    • 提高维护效率，可以更集中维护好一个引擎；

  • 既有优势：利用 Flink 已有的很多特性，使 OLAP 使用场景更为广泛；

    • 使用流处理的内存计算、Pipeline；
    • 支持代码动态生成；
    • 也可以支持批处理数据落盘能力；

  • 相互增强：OLAP 能享有现有引擎的优势，同时也能增强引擎能力

    • 无统计信息场景的优化；
    • 开发更高效的算子；
    • 使 Flink 同时兼备流、批、OLAP 处理的能力，成为更通用的框架。

• 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执行具体的计算任务，采用线程模型，为每个计算任务创建计算线程，根据计算任务的上下游数据依赖关系跟上游计算任务建立/复用网络连接，向上游计算任务发送数据请求，并处理上游分发给它的数据。