Day03：流/批/OLAP一体的Flink引擎介绍 课程笔记 ｜ 青训营笔记

Sefank
454 阅读21分钟

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

Apache Flink 概述

Apache Flink 诞生背景

为什么大数据需要流式计算？

什么是大数据

大数据（BigData）：无法在一定时间内用常规软件工具对其进行获取、存储、管理和处理的数据集合。

特点：4V

  • Volumes：数据规模海量化
  • Variety：数据源、种类多样化
  • Velocity：数据产生、处理快速化
  • Value：数据价值化（价值密度低，但由于规模大所以总体价值高）

大数据计算架构发展历史

  1. 史前阶段（2006年前）：传统数仓/Oracle
    • 注重单机性能
    • 黑箱使用
  2. Hadoop
    • 分布式
    • Map-Reduce（Reduce前需要将数据写入磁盘）
    • 离线计算

    Ref: Hadoop 解决了什么问题？（大数据十年回顾：浪潮之巅数英雄）

  3. Spark（取代了MapReduce）
    • 批处理
    • 流处理
    • SQL高阶API
    • 内存迭代计算（解决了Reduce前需要将数据写入磁盘的问题）
  4. Flink
    • 流计算
    • 实时、更快
    • 流批一体
    • Streaming/Batch SQL

为什么需要流式计算

大数据的实时性带来价值更大，部分业务场景甚至无法接受延迟在分钟级以上的批处理计算，比如：

  • 监控场景：如果能实时发现业务系统的健康状态，就能提前避免业务故障；
  • 金融风控：如果实时监测出异常交易的行为，就能及时阻断风险的发生；
  • 实时推荐：比如在抖音，如果可以根据用户的行为数据发掘用户的兴趣、偏好，就能向用户推荐更感兴趣的内容；

因此大数据计算架构逐渐从批式计算发展为流式计算：

批式计算流式计算
离线计算，非实时实时计算，快速、低延迟
静态数据集无限流、动态、无边界
按小时/天等周期性计算7*24h持续运行

为什么 Flink 会脱颖而出

流式计算引擎发展历史

  • Storm
    History of Apache Storm and lessons learned - thoughts from the red planet
    • Storm API 的 low-level 以及开发效率低下；
    • 一致性问题：Storm 更多考虑到实时流计算的处理时延而非数据的一致性保证；
  • Spark Streaming
    An Architecture for Fast and General Data Processing on Large Clusters
    • Spark Streaming 相比于 Storm 的低阶 API 以及无法正确性语义保证，Spark 是流处理的分水岭：第一个广泛使用的大规模流处理引擎，既提供较为高阶的 API 抽象，同时提供流式处理正确性保证。
  • Flink
    从产品技术来看，Flink 作为一个最新的实时计算引擎，具备如下流计算技术特征：
    • 完全一次保证：故障后应正确恢复有状态运算符中的状态；
    • 低延迟：越低越好。许多应用程序需要亚秒级延迟；
    • 高吞吐量：随着数据速率的增长，通过管道推送大量数据至关重要；
    • 强大的计算模型：框架应该提供一种编程模型，该模型不限制用户并允许各种各样的应用程序在没有故障的情况下，容错机制的开销很低；
    • 流量控制：来自慢速算子的反压应该由系统和数据源自然吸收，以避免因消费者缓慢而导致崩溃或降低性能；
    • 乱序数据的支持：支持由于其他原因导致的数据乱序达到、延迟到达后，计算出正确的结果；
    • 完备的流式语义：支持窗口等现代流式处理语义抽象；
    • Google Dataflow Model 的开源引擎实现。

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

对比项目StormSpark StreamingFlink
流处理模型Nativemini-batchNative
一致性保证At Least/Most OnceExactly-OnceExactly-Once
延迟低延迟（毫秒级）延迟较高（秒级）低延迟（毫秒级）
吞吐LowHighHigh
容错ACKRDD Based CheckpointCheckpoint (Chandy-Lamport)
Statefull×√ (DStream)√ (Operator)
SQL支持×√√

Mini-Batch：将流处理转化为针对特别小的批进行批处理

一致性：

  • At Least Once：数据至少被处理一次，保证可用性
  • At Most Once：数据至多被处理一次，保证处理性能
  • Exactly-Once：可以保证数据一定且只会被处理一次，可用性与性能都高

Statefull：引擎自己是否支持状态在两次数据处理之间保留、传递

Apache Flink 开源生态

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

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

生态示意图

图中左侧黄色的项目都是 Flink 支持的数据流来源， 最大的框内是 Flink 的内部架构（见下一节）， 最上方绿色的项目是基于 Flink 的更高层的应用/框架。

Flink 整体架构

Flink 分层架构

Flink 分层架构

  • SDK 层：Flink's APIs Overview
    • SQL/Table
    • DataStream
    • Python (pyFlink)
  • 执行引擎层（Runtime 层，图中从 DAG API 到 Shuffle Service 的部分）
    1. DAG API 将 SDK 中的操作描述转为统一的抽象 DAG（逻辑的图表达方式），用来描述数据处理的 Pipeline，不管是流还是批，都会转化为 DAG 图
    2. DAG Scheduler 调度层再把 DAG 转化成分布式环境下的 Task（Jobs and Scheduling）
    3. Task 之间通过 Shuffle 传输数据
  • 状态存储层 State Backend：负责存储算子的状态信息
  • 资源调度层：目前 Flink 可以支持部署在多种环境

Flink 整体架构（Flink Architecture）

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

  • Job Manager（JM）：负责整个任务的协调工作
    • 调度 Task
    • 触发协调 Task 做 Checkpoint
    • 协调容错恢复
    • ……
  • Task Manager（TM）：负责执行一个 DataFlow Graph（DAG） 的各个 Task 以及各个 Data Stream 的 Buffer 和数据交换。

计算架构图【重点】：

Flink 整体架构

Flink 程序中的 Client 端只会生成程序的逻辑执行图，将其提交给 JM 后，由 JM 生成具体的、实际的物理执行图，并据此把真正的 Task 分发给 TM 来执行。

Job Manager 的核心三组件

Job Manager的构架

  • Dispatcher: 接收作业，拉起 Job Manager 来执行作业，并在 JobMaster 挂掉之后恢复作业；
  • JobMaster: 管理一个 job 的整个生命周期，会向 ResourceManager 申请 slot（slot = 可以执行 task 的位置），并将 task 调度到对应 TM 上；
  • ResourceManager：负责 slot 资源的管理和调度，Task manager 拉起之后会向 RM 注册；

Flink 作业示例

Ref: Flink Learn: Hands-On Training

流式的 WordCount 示例（Flink 版 Helloworld），从 kafka 中读取个实时数据流，每 10s 统计一次单词出现次数。

使用 DataStream API 编写的代码如下：

WordCountd代码

注：

  • env 是预先声明好的 Flink 环境变量
  • Source 这一行表明是一行一行处理语句
  • keyBy（详见文档）：在逻辑上将流（Stream）分为互不相交的分区（Partition），具有相同 Key 的所有记录都被分配到同一分区。具体这里代码的意思是将相同的单词分发到同一分区来处理。
  • timeWindow 将流按时间周期切分为一个个窗口
  • apply 这里是写了一个自定义的聚合函数，表明如何处理同一个窗口的数据，按照设计目的应当是每来一个单词就给计数器加一。
  • addSink 保存处理的结果，这里的 BucketingSink 是存储到文件中。

在 Flink 中，应用程序由用户自定义算子转换而来的流式 dataflows 所组成。这些流式 dataflows 形成了有向图，以一个或多个源（source）开始，并以一个或多个汇（sink）结束。

这段代码对应的 DataFlow Graph (DAG)：

WordCountd DAG

ExecutionGraph 的生成过程：

flowchart LR
s1["DataStream API Code"] --> s2[JobGraph] --> s3["ExecutionGraph (Parallelized)"]

Flink 程序本质上是分布式并行程序。在程序执行期间，一个流有一个或多个流分区（Stream Partition），每个算子有一个或多个算子子任务（Operator Subtask）。每个子任务彼此独立，并在不同的线程中运行，或在不同的计算机或容器中运行。

算子的并行度：该算子的子任务数。在同一程序中，不同算子也可能具有不同的并行度。

以 sink 的并行度 = 1，其余 Operator 的并行度 = 2 为例：

JM 会将 DataFlow Graph 转化为 如下图下方所示的 Parallel Dataflow（内部称为 Execution Graph）：

image.png

Stream 可以在两个 Operator 之间传输数据，传输方式有以下两种：

  • 一对一/直传（One-to-One / Forwarding）：这种方式保留了元素的分区和顺序信息。上图中的从 Source 到 map() 之间的流就是这种传输方式。
    在这种传输方式下，map() 算子的子任务 [1] 输入的数据以及其顺序与 Source 算子的子任务 [1] 输出的数据和顺序完全相同，即同一分区的数据只会进入到下游算子的同一分区。
  • 重新分配（Redistributing）：这种方式会更改数据所在的流分区。根据选定的数据变换方式，每个算子的子任务会给不同的目标子任务发送数据。
    当你在程序中选择使用不同的 transformation，每个算子子任务也会根据不同的 transformation 将数据发送到不同的目标子任务。例如以下这几种 transformation 和其对应分发数据的模式：keyBy()（按照 key 的 hash 重新分区）、broadcast()（广播）或 rebalance()（随机重新分区）。在重新分发数据的过程中，元素只有在每对输出和输入子任务之间才能保留其之间的顺序信息（例如，keyBy/window 的子任务 [2] 接收到的 map() 的子任务 [1] 中的元素都是有序的）。因此，上图所示的 keyBy/window 和 Sink 算子之间数据的重新分发时，不同 key 的聚合结果到达 Sink 的顺序是不确定的。

为了更高效地分布式执行，Flink 会尽可能地将算子的子任务链接（chain）成任务（task），也称为构成算子链（Operator chain）。

由于每个任务只在一个线程中执行，尽可能多地构成算子链就可以：

  • 减少线程间切换、缓冲的开销
  • 在减少延迟的同时增加整体吞吐量

如下图的 Source 和 map() 可以链接在一起。

算子链

最后将上面的任务调度到具体的 TaskManager 中的 slot 中执行，一个 slot 只能运行同一个任务的各个子任务。

Slot 不会对 CPU 隔离，内存隔离也仅是有限部分的隔离。

任务与slot

Ref:

流批一体

为什么需要流批一体？

一些业务场景，除了实时的数据统计需求，为了确认运营或产品的效果，用户同时还需要和历史数据做比较（比如，抖音一些直播数据的统计），这里给一个传统的流批分离版本的解决方案：

流批分离的解决方案

这种架构有一些痛点：

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

流批一体的挑战

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

对比项目实时计算离线计算
处理延迟延迟在秒级以内处理时间为分钟到小时级别，甚至天级别
应用场景广告推荐、金融风控搜索弓擎构建索引、批式数据分析

流式计算 & 批式计算 核心区别：

对比项目流式计算批式计算
数据流无限数据集有限数据集
时延低延迟，业务会感知运行中的情况实时性要求不高，只关注最终结果产出时间

Flink 为什么可以做到流批一体

Flink 的设计思路：批式计算是流式计算的特例，Everything is Streams。

因此，理论上我们是可以用一套引擎架构来解决上述两种场景，只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略。

  • 无边界数据集是一种数据流，一个无边界的数据流可以按时间切段成一个个有边界的数据集；
  • 有界数据集（批式数据）是一种特殊的数据流。

Flink 对批数据的处理架构：

Flink对批数据的处理架构

Flink 如何做到流批一体

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

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

流批一体的 Scheduler 层

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

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

  • EAGER（Streaming 场景）：申请一个作业所需要的全部资源，然后同时调度这个作业的全部 Task，所有的 Task 之间采取 Pipeline 的方式进行通信。
    EAGER调度
    图中的这个例子需要12个Task一起调度，集群需要有足够的资源。
  • LAZY（Batch 场景）：先调度上游Task，等待上游产生数据或结束后再调度下游Task，类似 Spark 的 Stage 执行模式。
    LAZY调度
    图中的这个例子最小调度一个Task即可，集群有1个slot资源可以运行，但执行时间会增加。

在最新的 Flink 版本中还提供了名为 Pipeline Region 的调度机制。

这种机制下会把所有的任务分割成若干个流水线区域（region）。对于包含多个 region 的流作业，在开始部署任务之前，它不再等待所有任务获取 slot。取而代之的是，一旦一个 region 获得了足够的任务 slot 就可以部署它。本质上，不管是流作业还是批作业，都是按照 Pipeline Region 粒度来申请资源和调度任务。

Pipeline Region

可以看到这种机制的性能与资源需求介于 EAGER 模式和 LAZY 模式之间。

Ref: Pipeline Region Scheduler 机制：FLIP-119 Pipelined Region Scheduling - Apache Flink - Apache Software Foundation

Pipeline Region 调度机制可以定制分割流水线区域的策略，实现自定义调度细粒度，以其中最极端的两种策略为例：

  • ALL_EDGES_BLOCKING
    • 所有Task之间的数据交换都是 BLOCKING 模式（数据输出后需要写入文件，然后在被下游任务读出，写入文件后资源可以被释放，但需要更多 I/O 时间）
    • 下面的调度例子：分为 12 个 pipeline region
  • ALL_EDGES_PIPELINED
    • 所有Task之间的数据交换都是 PIPELINE 模式（数据直接输出给下游任务，即保留在内存中）
    • 下面的调度例子：分为 1 个 pipeline region

调度例子图

流批一体的 Shuffle Service 层

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

Shuffle 分类：

  • 基于文件的 Pull Based Shuffle（如 Spark 或 MR）：具有较高的容错性和稳定性，适合较大规模的批处理作业
  • 基于 Pipeline 的 Push Based Shuffle（如 Flink、Storm、Presto 等）：低延迟和高性能；但是因为 shuffle 数据没有存储下来，如果是 batch 任务的话，就需要进行重跑恢复；

流和批 Shuffle 之间的差异：

  • 数据生命周期
    • 流作业的 Shuffle 数据与 Task 是绑定的（任务不在，数据就不在）
    • 批作业的 Shuffle 数据与 Task 是解耦的（任务不在，数据还在）
  • 数据存储介质
    • 流作业的生命周期比较短、而且流作业为了实时性，Shuffle 通常存储在内存中
    • 批作业因为数据量比较大以及容错的需求，一般会存储在磁盘里
  • 部署方式
    • 流作业一般要求 Shuffle 服务和计算节点部署在一起（可以减少网络开销，从而减少延迟）
    • 批作业则可以容忍 Shuffle 服务和计算节点不部署在一起（可以远端存储/备份，提高容错率）

各个 Shuffle 策略的常见使用场景：

  • 在 Streaming 和 OLAP 场景：为了性能的需要，通常会使用基于 Pipeline 的 Shuffle 模式
  • 在 Batch 场景：一般会选取 Blocking 的 Shuffle 模式

虽然 Streaming 和 Batch Shuffle 在具体的策略上存在一定的差异，但本质上都是为了对数据进行重新分区，因此不同的 Shufle 之间是存在一定的共性的。所以 Flink 的目标是提供一套统一的 Shuffle 架构，既可以满足不同 Shufle 在策略上的定制，同时还能避免在共性需求上进行重复开发。

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

Pluggable Shuffle Service 框架

Ref: 流批一体的 Shuffle Service 层（FLIP-31: Pluggable Shuffle Service - Apache Flink - Apache Software Foundation）

对于 Shufle Service, Flink 开源社区已经支持：

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

字节内部是基于一种名为 CSS 的 Shufle Service 来实现的 Remote Shuffle Service。

Flink 架构优化

流/批/OLAP 业务场景概述

典型场景：

  • 流：在抖音中，实时统计一个短视频的播放量、点赞数，也包括抖音直播间的实时观着人数等
  • 批：在抖音中，按天统计创造者的一些数据信息，比如昨天的播放量有多少、评论量多少、广告收入多少
  • OLAP：在抖音的一些推广活动（如多轮红包雨）中，运营同学需要对一些实时产出的结果数据做一些实时多维分析，来帮助后面活动的决策

三种业务场景的特点：

流式计算批式计算交互式分析
实时计算离线计算OLAP
延迟在秒级以内处理时间为分钟到小时级别，甚至天级别处理时间秒级
0~1s10s~1h+1~10s
广告推荐、金融风控搜索引擎构建索引、批式数据分析数据分析BI报表

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

模块流式计算批式计算交互式分析（OLAP）
SQL√√√
实时性高（处理延迟毫秒级别）低高（查询延迟在秒级，但要求高并发查询）
容错能力高中，大作业失败重跑代价高No，失败重试即可
状态√××
准确性Exactly Once，要求高，重跑需要恢复之前的状态Exactly Once，失败重跑即可Exactly Once，失败重跑即可
扩展性√√√

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

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

Flink 对 OLAP 的处理架构：

Flink对OLAP的处理架构

Batch 场景需求：流批一体支持

  • Unify DataStream APl
  • Scheduler
  • Shuffle Service
  • Failover Recovery

OLAP 场景需求：短查询作业场景

  • 高并发支持
  • 极致处理性能

Flink 如何支持 OLAP 场景

Flink 做 OLAP 的优势

  • 统一引擎：流处理、批处理、OLAP 统一使用 Flink 引擎
    • 降低学习成本，仅需要学习一个引擎
    • 提高开发效率，很多 SQL 是流批通用
    • 提高维护效率，可以更集中维护好一个引擎
  • 既有优势：利用 Flink 已有的很多特性，使 OLAP 使用场景更为广泛
    • 使用流处理的内存计算、Pipeline
    • 支持代码动态生成
    • 支持批处理数据落盘能力
    • 支持 Session 模式的 MPP 架构
  • 生态支持：
    • 跨数据源查询支持
    • TCP-DS 测试性能强
  • 相互增强：OLAP 能享有现有引擎的优势，同时也能增强引擎能力
    • 无统计信息场景的优化
    • 开发更高效的算子
    • 使 Flink 同时兼备流、批、OLAP 处理的能力，成为更通用的框架。

Flink OLAP 场景的挑战

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

Flink OLAP 架构现状

Flink OLAP 架构

  • Client：提交 SQL Query；
  • Gateway：接收 Client 提交的 SQL Query，对 SQL 进行语法解析和查询优化，生成 Flink 作业执行计划，提交给 Session 集群；
  • Session Cluster：执行作业调度及计算，并返回结果。

架构与功能模块：

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

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

架构与功能模块：

  • JobManager 与 ResourceManager 在一个进程内启动，无法对JobManager 进行水平扩展
  • Gateway 与 Flink Session Cluster 互相独立，无法进行统一管理

作业管理及部署模块：

  • JobManager 处理和调度作业时，负责的功能比较多，导致单作业处理时间长、并占用了过多的内存
  • TaskManager 部署计算任务时，任务初始化部分耗时验证，消耗大量 CPU

资源管理及计算任务调度：

  • 资源申请及资源释放流程链路过长
  • Slot 作为资源管理单元，JM 管理 slot 资源，导致 JM 无法感知到 TM 维度的资源分布，使得资源管理完全依赖于 ResourceManager

其他：

  • 作业心跳与 Failover 机制，并不合适 AP 这种秒级或毫秒级计算场景；
  • AP 目前使用 Batch 算子进行计算，这些算子初始化比较耗时；

最终的演进总体架构：

image.png

Flink 使用案例

电商流批一体实践

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

流批分离的解决方案

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

随着 Flink 发展（逐步发展为流批一体引擎）：

Flink 发展

演进目标：从数据源，业务逻辑，计算引擎完成统一，提高开发和运维效率。

演进目标

字节 Flink OLAP 实践

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

字节内部一个业务实践：

  • 上面是原来的链路；
  • 下面是走HTAP之后的链路，Flink直接提供数据查询与分析的能力。
avatar
文章
阅读
粉丝