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

红豆奶茶少冰半糖
175 阅读9分钟

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

1、 Flink 概述

1.1 Apache Flink 诞生背景

1.1.1 什么是大数据

  • 指无法在一定时间内用常规软件工具对其进行获取、存储、管理和处理的数据集合
  • 4V（价值低、数据量大、速度快、多样化）

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

image.png

1.1.3 为什么需要流式计算

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

image.png

1.2 为什么 Flink 会脱颖而出

1.2.1 流式计算引擎发展历史

image.png

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

image.png

1.2.3 Why Flink

image.png

  • 翻译：ApacheFlink是一个框架和分布式处理引擎，用于在无界和有界数据流上进行有状态计算。Flink被设计为在所有常见的集群环境中运行，以内存中的速度和任何规模进行性能计算——来自apache flink社区官方介绍

image.png

1.3 Apache Flink 开源生态

image.png

2、 Flink 整体架构

2.1 Flink 分层架构

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

2.2 Flink 总体架构

一个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

2.3 Flink 作业示例

  • 流式的 WordCount示例，从 kafka 中读取一个实时数据流，每10s统计一次单词出现次数，DataStream 实现代码如下: image.png

  • 业务逻辑转换为一个 Streaming DataFlow Graph image.png

  • 假设作业的sink算子的并发配置为1，其余算子并发为2 紧接着会将上面的Streaming DataFlow Graph转化 Parallel Dataflow(内部叫Execution Graph):

image.png

  • 为了更高效地分布式执行，Flink 会尽可能地将不同的operator链接( chain)在一起形成Task，这样每个Task可以在一个线程中执行，内部叫做OperatorChain，如下图的source和map算子可以Chain在一起

image.png

  • 最后将上面的Task调度到具体的TaskManager 中的slot中执行一个Slot只能运行同一个task的subTask image.png

2.4 Flink 如何做到流批一体

2.4.1 为什么需要流批一体

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

2.4.2 流批一体的挑战

image.png

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

2.4.3 Flink 如何做到流批一体

  • 批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；
  • 站在 Flink 的角度，Everything is Streams，无边界数据集是一种数据流，一个无边界的数据流可以按时间切段成一个个有边界的数据集，所以有界数据集（批式数据）也是一种数据流。因此，不管是有边界的数据集（批式数据）还是无边界数据集，Flink 都可以天然地支持，这是 Flink 支持流批一体的基础。并且 Flink 在流批一体上，从上面的 API 到底层的处理机制都是统一的，是真正意义上的流批一体。 image.png
  • Apache Flink 主要从以下几个模块来做流批一体：
    • SQL 层
    • DataStream API 层统一，批和流都可以使用 DataStream API 来开发
    • Scheduler 层架构统一，支持流批场景
    • Failover Recovery 层 架构统一，支持流批场景
    • Shuffle Service 层架构统一，流批场景选择不同的 Shuffle Service

2.4.4 流批一体的 Scheduler 层

  • Scheduler 主要负责将作业的 DAG 转化为在分布式环境中可以执行的 Task
  • 1.12 之前的 Flink 版本，Flink 支持两种调度模式：

image.png

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

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

  • ALL_EDGES_BLOCKING:

    • 所有Task之间的数据交换都是BLOCKING模式
    • 分为12个pipeline region

  • ALL_EDGES_PIPELINED:

    • 所有Task之间的数据交换都是PIPELINE模式
    • 分为1个pipeline region

image.png

2.4.5 流批一体的 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，而批作业则不同

2.4.6 Flink 流批一体总结

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

3、 Flink 架构优化

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

  • 三种业务场景的特点：

image.png

  • 三种业务场景面临的挑战：

image.png

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

  • 场景上对比发现：

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

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

image.png

3.3 Flink 的 OLAP 的优化之路

3.3.1 Flink 做 OLAP 的优势

image.png

3.3.2 Flink OLAP 的挑战

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

image.png

3.3.3 Flink OLAP 架构现状

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

image.png

3.3.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 总结

image.png

4、 Flink 使用案例

4.1 电商流批一体

image.png

4.2 字节 Flink OLAP 实践

image.png

avatar
文章
阅读
粉丝