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

冕临
195 阅读10分钟

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

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

1.Apache Flink 概述

Apache Flink是由Apache软件基金会开发的开源流处理框架，其核心是用Java和Scala编写的分布式流数据流引擎。Flink以数据并行和流水线方式执行任意流数据程序，Flink的流水线运行时系统可以执行批处理和流处理程序。此外，Flink的运行时本身也支持迭代算法的执行。

1.为什么需要流计算

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

2.流计算的特点

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

3.流计算框架对比

image.png

4.Flink具备的流计算技术特征

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

5.Apache Flink 开源生态

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

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

image.png

2.Flink整体架构

1.分层架构

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

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

image.png

3.Flink如何做到流批一体

1.为什么需要流批一体

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

2.流批一体的挑战

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

3.Flink 如何做到流批一体

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

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

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

5.流批一体的 Scheduler 层

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

image.png

1.12 之前的 Flink 版本，Flink 支持两种调度模式：

  1. EAGER（Streaming 场景）：申请一个作业所需要的全部资源，然后同时调度这个作业的全部 Task，所有的 Task 之间采取 Pipeline 的方式进行通信；
  2. LAZY（Batch 场景）：先调度上游，等待上游产生数据或结束后再调度下游，类似 Spark 的 Stage 执行模式。

6.流批一体的 Shuffle Service 层

image.png

Shuffle：在分布式计算中，用来连接上下游数据交互的过程叫做 Shuffle。实际上，分布式计算中所有涉及到上下游衔接的过程，都可以理解为 Shuffle

Shuffle 分类：

  1. 基于文件的 Pull Based Shuffle，比如 Spark 或 MR，它的特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好一些
  2. 基于 Pipeline 的 Push Based Shuffle，比如 Flink、Storm、Presto 等，它的特点是低延迟和高性能，但是因为 shuffle 数据没有存储下来，如果是 batch 任务的话，就需要进行重跑恢复

流和批 Shuffle 之间的差异：

  1. Shuffle 数据的生命周期：流作业的 Shuffle 数据与 Task 是绑定的，而批作业的 Shuffle 数据与 Task 是解耦的
  2. Shuffle 数据存储介质：流作业的生命周期比较短、而且流作业为了实时性，Shuffle 通常存储在内存中，批作业因为数据量比较大以及容错的需求，一般会存储在磁盘里
  3. Shuffle 的部署方式：流作业 Shuffle 服务和计算节点部署在一起，可以减少网络开销，从而减少 latency，而批作业则不同

Pluggable Shuffle Service：Flink 的目标是提供一套统一的 Shuffle 架构，既可以满足不同 Shuffle 在策略上的定制，同时还能避免在共性需求上进行重复开发

为了统-Flink在Streaming和Batch模式下的Shufle架构，Flink 实现了一个Pluggable的ShuffleService框架，抽象出一些公共模块。

  1. 在Streaming和OL AP场景：为了性能的需要，通常会使用基于Pipeline 的Shuffle模式
  2. 在Batch场景：一般会选取 Blocking的Shufle模式

4.Flink 架构优化

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

  • 三种业务场景的特点 image.png
  • 三种业务场景面临的挑战 image.png

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

场景上对比发现：

  1. 批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；
  2. OLAP 计算是一种特殊的批式计算，它对并发和实时性要求更高，其他情况与普通批式作业没有特别大区别。 因此，理论上我们是可以用一套引擎架构来解决上述三种场景，只不过需要对不同场景支持相应的扩展性、并运行做不同的优化策略。

Apache Flink 从流式计算出发，需要想支持 Batch 和 OLAP 场景，就需要解决下面的问题

image.png

3.Flink 如何支持 OLAP 场景

Flink 做 OLAP 的优势

  • 统一引擎：流处理、批处理、OLAP 统一使用 Flink 引擎
    1. 降低学习成本，仅需要学习一个引擎
    2. 提高开发效率，很多 SQL 是流批通用
    3. 提高维护效率，可以更集中维护好一个引擎
  • 既有优势：利用 Flink 已有的很多特性，使 OLAP 使用场景更为广泛
    1. 使用流处理的内存计算、Pipeline
    2. 支持代码动态生成
    3. 也可以支持批处理数据落盘能力
  • 相互增强：OLAP 能享有现有引擎的优势，同时也能增强引擎能力
    1. 无统计信息场景的优化
    2. 开发更高效的算子
    3. 使 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执行具体的计算任务，采用线程模型，为每个计算任务创建计算线程，根据计算任务的上下游数据依赖关系跟上游计算任务建立/复用网络连接，向上游计算任务发送数据请求，并处理上游分发给它的数据。 image.png

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

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

image.png

avatar
文章
阅读
粉丝