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

第二节课「流/批/OLAP 一体的 Flink 引擎」的内容主要包含 4 个方面：Flink 概述、Flink 整体架构、Flink 架构优化、案例讲解。这篇文章为 Flink 整体架构的相关内容，包括 Flink 的分层架构、Flink 的总体架构和 Flink 如何做到流批一体。

Flink 分层架构

• SDK 层：Flink 的 SDK 目前主要有三类，SQL/Table、DataStream、Python（详情参见 Flink's APIs Overview）

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

  • 调度：Jobs and Scheduling
  • Task 生命周期：Task Lifecycle
  • Flink Failover 机制：Task Failure Recovery
  • Flink 反压概念及监控：Monitoring Back Pressure
  • Flink HA 机制：Flink HA Overview

• 状态存储层：负责存储算子的状态信息

• 资源调度层：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 和数据交换。

Flink 如何做到流批一体

• 为什么需要流批一体

  • 一些业务场景，除了实时的数据统计需求，为了确认运营或产品的效果，用户同时还需要和历史数据做比较，比如，抖音一些直播数据的统计

  • 这种架构有一些痛点：

    • 人力成本比较高：批、流两套系统，相同逻辑需要开发两遍
    • 数据链路冗余：本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生一定的资源浪费
    • 数据口径不一致：两套系统、两套算子、两套 UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰

• 流批一体的挑战

  • 批式计算相比于流式计算核心的区别：

    • 无限数据集 --> 有限数据集
    • 低延迟 --> 实时性要求不高

• 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 版本支持两种调度模式：

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

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

个人总结

学习了 Flink 的分层架构和总体架构以及 Flink 如何做到流批一体。

参考

• 【大数据专场 学习资料一】第四届字节跳动青训营 - 掘金
• 流/批/OLAP 一体的 Flink 引擎 - 王蒙 - ppt.pptx - 飞书云文档