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

面包小狗
156 阅读13分钟

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

本节课程目录：

  1. Flink 概述
  2. Flink 整体架构
  3. Flink 架构优化
  4. FLink 使用案例

1. Flink 概述

1.1 Apache Flink 诞生背景

1.1.1 什么是大数据

  • 大数据(Big Data)：指无法在一定时间内用常规软件工具对其进行获取、存储、管理和处理的数据集合。
  • Value 价值化 Volumes 海量化 Variety 多样化 Velocity 快速化

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

截屏2022-07-27 11.48.53.png

1.1.3 为什么需要流式计算

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

截屏2022-07-27 11.54.32.png

1.2 Flink 为什么脱颖而出

1.2.1 流式计算引擎发展历程

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

截屏2022-07-27 11.56.33.png

1.2.2 流式计算引擎对比

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

截屏2022-07-27 11.57.44.png

1.2.3 Why Flink

Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams. Flink has been designed to run in all common cluster environments, perform computations at in-memort speed and at any scale.

  • Apache Flink 是一个框架和分布式处理引擎，用于在无界和有界数据流上进行有状态计算。Flink被设计为在所有常见的集群环境中运行，以内存中的速度和任何规模进行性能计算.

截屏2022-07-27 12.02.12.png

1.3 Apache Flink 开源生态

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

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

1.png

2. Flink 整体架构

2.1 Flink 分层架构

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

2.2 Flink 总体架构

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

  1. JobManager(JM)：负责整个任务的协调工作，包括：调度 task、触发协调 Task 做 Checkpoint、协调容错恢复等，核心有下面三个组件：
    • Dispatcher: 接收作业，拉起 JobManager 来执行作业，并在 JobMaster 挂掉之后恢复作业；
    • JobMaster: 管理一个 job 的整个生命周期，会向 ResourceManager 申请 slot，并将 task 调度到对应 TM 上；
    • ResourceManager：负责 slot 资源的管理和调度，Task manager 拉起之后会向 RM 注册；

截屏2022-07-27 17.00.32.png

  1. TaskManager(TM)：负责执行一个 DataFlow Graph 的各个 task 以及 data streams 的 buffer 和数据交换。

2.png

2.3 Flink 作业示例

  • 流式的 WorldCount 示例，从 Kafka 中读取一个实时数据流，每 10s 统计一次单词出现次数，DataStream 实现代码如下：

截屏2022-07-27 17.16.37.png

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

截屏2022-07-27 17.16.44.png

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

截屏2022-07-27 17.19.14.png

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

image-2.png

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

image.png

2.4 Flink 如何做到流批一体

2.4.1 为什么需要流批一体

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

image-3.png

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

2.4.2 流批一体的挑战

流和批业务场景的特点如下表：

截屏2022-07-27 17.46.00.png

批式计算相比于流式计算核心的区别如下表：

截屏2022-07-27 17.47.29.png

2.4.3 Flink 如何做到流批一体

  • 批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；因此，理论上我们是可以用一套引擎架构来解决上述两种场景，只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略

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

image-4.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 支持以下两种调度模式： 截屏2022-07-27 18.00.49.png

    • EAGER 模式： 12 个 task 会一起调度，集群需要有足够的资源。 image-5.png
    • LAZY 模式： 最小调度一个 task 即可，集群有一个 slot 资源就可以运行。 image-6.png

  • 由 Pipeline 的数据交换方式连接的 Task 构成为一个 Pipeline Region；本质上，不管是流作业还是批作业，都是按照 Pipeline Region 粒度来申请资源和调度任务。

image-7.png

  • ALL_EDGES_BLOCKING：（参考上图）

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

  • ALL_EDGES_PIPELINED：（参考上图）

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

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，而批作业则不同。

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

    • Netty Shuffle Service：即支持 pipeline 又支持 blocking，Flink 默认的 Shuffle Service 策略；
    • Remote Shuffle Service：即支持 pipeline 又支持 blocking，不过对于pipeline 模式，走 remote 反而会性能下降，主要是有用在 batch 的 blocking 场景。

2.4.6 Flink 流批一体总结

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

3. Flink 架构优化

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

  • 三种业务场景的特点对比如下表：

截屏2022-07-27 18.28.08.png

  • 三种业务场景的解决方案的要求及带来的挑战是：

截屏2022-07-27 18.28.15.png

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

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

image-4.png

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

截屏2022-07-27 18.35.25.png

3.3 FLink 的 OLAP 的优化之路

3.3.1 Flink 做 OLAP 的优势

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

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

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

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

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

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

image-8.png

3.3.2 Flink OLAP 场景的挑战

  • 秒级和毫秒级的小作业；

  • 作业频繁启停、资源碎片；

    • Flink OLAP 计算相比流式和批式计算，最大的特点是 Flink OLAP 计算是一个面向秒级和毫秒级的小作业，作业在启动过程中会频繁申请内存、网络以及磁盘资源，导致 Flink 集群内产生大量的资源碎片；

  • Latency + 高 APS 要求；

    • OLAP 最大的特点是查询作业对 Latency 和 QPS 有要求的，需要保证作业在 Latency 的前提下提供比较高的并发调度和执行能力，这就对 Flink 引擎提出了一个新的要求。

image-9.png

3.3.3 Flink OLAP 架构现状

  • Client：提交 SQL Query；

  • Gateway：接收 Client 提交的 SQL Query，对 SQL 进行语法解析和查询优化，生成 Flink 作业执行计划，提交给 Session 集群；

  • Session Cluster：执行作业调度及计算，并返回结果。

    • JobManager 管理作业的执行，在接收到 Gateway 提交过来的作业逻辑执行计划后，将逻辑执行计划转换为物理执行计划，为每个物理计算任务分配资源，将每个计算任务分发给不同的 TaskManager 执行，同时管理作业以及每个计算任务执行状态；
    • TaskManager执行具体的计算任务，采用线程模型，为每个计算任务创建计算线程，根据计算任务的上下游数据依赖关系跟上游计算任务建立/复用网络连接，向上游计算任务发送数据请求，并处理上游分发给它的数据。

image-10.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 总结

Apache Flink 最终演进到结果如下：

image-11.png

4. FLink 使用案例

4.1 电商流批一体实践

抖音电商业务原有的离线和实时数仓架构如下图：

image-12.png

Flink 社区的现状：

image-13.png

目前电商业务数据分为离线数仓和实时数仓建设，离线和实时数据源，计算引擎和业务代码没有统一，在开发相同需求的时候经常需要离线和实时对其口径，同时，由于需要维护两套计算路径，对运维也带来压力。 从数据源、业务逻辑、计算引擎完成统一，提高开发和运维效率。

image-14.png

4.2 字节 Flink OLAP 实践

Flink 在 OLAP 在字节内部的场景主要是 HTAP 场景。

image-15.png

  • 字节内部一个业务实践：
    • 上面是原来的链路；
    • 下面是走HTAP之后的链路，Flink 直接提供数据查询与分析的能力

Unknown.png

avatar
文章
阅读
粉丝