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

纯纯子
170 阅读23分钟

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

今日笔记:流/批/OLAP一体的Flink引擎介绍

概述

本节课程主要分为四个方面：

  1. Apache Flink 概述；

  2. 流批一体的 Apache Flink 架构；

  3. Apache Flink 的 OLAP 场景面临的问题及优化思路；

  4. Flink 使用案例；

课前

Apache Flink 概述

  • 大数据的发展背景及面临的问题，大数据解决方案的三驾马车；

    • 大数据产生的背景：数据管理技术经历人工管理，文件管理，数据库管理等时代，大数据技术的出现使该领域进入一个新的发展阶段。

    • 数据量剧增 → 海量数据

      超过 150 亿个设备连接到互联网

      全球每秒钟发送 290 万封电子邮件

      每天有 2.88 万小时视频上传到 Youtube

      Facebook 每日评论达 32 亿条，每天上传照片近 3 亿张，每月处理数据总量约 130 万 TB

      预计 2020 年将增长到 35ZB。

      大数据（Big Data）正迅速成为最值得关注的 IT 领域之一。

    • 三驾马车：业界一般以 Google 公司在2003到2006年之间发布的三篇论文作为大数据处理技术产生的起点，分别是：GFS、MapReduce和Bigtable。

  • Hadoop 发展历史：MapReduce 的概念；

    • Hadoop发展历程：

      • Hadoop在2008年正式成为Apache的顶级项目，发展也越来越迅速

      • 2008年9月，Hive成为Hadoop的子项目

      • 2010年5月，Hbase 从Hadoop子项目升级为 Apache 顶级项目

      • 2011年12月，Hadoop1.0.0版本发布，标志着Hadoop已经初具生产规模

      • 2013年10月，

      • 发布 Hadoop2.2.0 版本，Hadoop 正式进入 2.x 时代。

      • 2014 年，先后发布了 Hadoop2.3.0、Hadoop2.4.0、Hadoop2.5.0 和 Hadoop2.6.0

      • 2015 年 Hadoop 发布 2.7.0

      • 2016 年发布 Hadoop3.0-alpha 版本，预示着Hadoop 即将进入 3.x 时代。

      • 2017 年 12 月，Apache Hadoop3.0.0GA 版本正式发布。这个版本是 Apache Hadoop3.0.0 的第 一个稳定版本，有很多重大的改进，比如支持 EC、支持多于 2 个的 NameNodes、 Intra-datanode

    • MapReduce的概念：

      • MapReduce 由两个阶段组成：Map 和 Reduce。用

        户只需要编写 map()和 reduce()两个函数，即可完成分布式程序的设计。

        • 什么是 map，什么是 reduce? 这里解释下，输入一个大文件，我们将其分成多个小文件，每个小文件由单独的机器去处理， 并输出中间结果，这就是 Map 方法。 而将各个机器计算的结果进行汇总并得到最终结果，这就是 Reduce 方法。

大数据处理框架类型：批处理、流处理和混合处理

批处理：
  • 是指把一项数据处理任务先分解成更小的粒度的任务，把这些任务分布在集群中的各台实例上进行计算，之后把各实例上的计算结果重新计算和组合成最终结果。
  • 批处理系统通常会操作大量的静态数据，并等这些数据全部处理完成后才能得到返回结果。这种模式适用于需要访问的全量记录才能完成的工作，比如在计算总数和平均值时必须将数据集作为一个整体加以处理，而不能将其视作多条记录的集合。
  • 由于批处理在处理海量的持久数据方面表现出色，所以通常用于处理历史数据，很多在线分析处理系统底层计算架构就是使用批处理。
  • 批处理使用的数据集的特征：
    • 有界：批处理数据集代表数据的有限集合
    • 持久：数据通常始终存储在某种类型的持久存储位置中
    • 大量：批处理操作通常是处理极为海量数据集的唯一方法
    • 批处理框架的代表就是Hadoop
流处理

  • 流处理：流处理 方式会随时对进入系统的数据进行实时的计算，这种模式不需要针对整个数据集执行操作，而是对通过系统传输的每个数据项执行操作。流处理中的数据集是 无边界 的，这就产生了几个重要的影响：

    • 完整数据集只能代表截至目前已经进入到系统中的数据总量。
    • 工作数据集也许更相关，在特定时间只能代表某个单一数据项。
    • 处理工作是基于事件的，除非明确停止否则没有“尽头”。处理结果立刻可用，并会随着新数据的抵达继续更新。

  • 小学时我们都会做过这样的数学题：一个水池有一个进水管和一个出水管，只打开进水管x个小时充满水，只打开出水管y个小时流光水，那么同时打开进水管和出水管，水池多长时间充满水？流处理系统就相当于这个水池，把流进来的水（数据）进行加工，然后再把加工过的水（数据）从出水管放出去。这样数据就像水流一样永不停止，而且在水池中就被处理过了。这种处理永不停止的接入数据的系统就叫做流处理系统。流处理系统并不对已经存在的数据集进行操作，而是对从外部系统接入的的数据进行处理。流处理系统可以分为两种：

    • 逐项处理：每次处理一条数据，是真正意义上的流处理。
    • 微批处理：这种处理方式把一小段时间内的数据当作一个微批次，对这个微批次内的数据进行处理。

  • 由于海量数据的处理需要耗费大量的时间，所以批处理的方式不适合对处理结果时延要求较高的场景。而不管是逐项处理还是微批处理，其实时性都要远好于批处理模式，因此流处理适用于有接近实时处理需求的任务场景，比如日志分析，设备监控、网站实时流量变化等。因为这些领域对数据的变化做出及时反馈是很常见的需求，流处理适用于必须对变动或峰值做出响应，并且关注一段时间内变化趋势的数据。

混合处理

  • 在大数据处理技术中流派中，除了单纯的批处理和流处理模式之外，还有一些处理框架既可以进行批处理也可以进行流处理，我们称之为混合处理框架。

    虽然专注于一种处理方式可能非常适合特定场景，但是混合框架为数据处理提供了通用的解决方案。这些框架可以用相同或相关的组件和 API 处理两种类型的数据，借此让不同的处理需求得以简化。混合处理框架中目前比较著名的就是 Spark 和 Flink 。

  • Spark 是一种包含流处理能力的批处理框架，它既有自带的实时流处理工具，也可以和 Hadoop 集成，代替其中的 MapReduce。

    • Spark 还可以拿出来单独部署集群，但是得借助 HDFS 等分布式存储系统。
    • Spark 的强大之处在于其运算速度，与 Storm 类似 Spark 也是基于内存的，并且在内存满负载的时候，硬盘也能运算.
    • Spark 最初的设计受 MapReduce 思想的启发，但不同于 MapReduce 的是 Spark 通过内存计算模型和执行优化大幅提高了对数据的处理能力。
    • 除了最初开发用于批处理的 Spark Core 和用于流处理的 Spark Streaming 之外，它还提供了其他编程模型用于支持图计算（GraphX）、交互式查询（Spark SQL）和机器学习（MLlib）。

  • Flink 则是一种可以处理批处理任务的流处理框架。在设计初始，Fink 的侧重点在于处理流式数据，这与 Spark 的设计初衷恰恰相反。

    • Spark 把流拆分成若干个小批次来处理，而 Flink 把批处理任务当作有界的流来处理
    • Flink 中把批处理的数据看做是具备有限边界的数据流，借此将批处理任务作为流处理的子集加以处理。
    • Flink 除了处理提供流处理（DataStream API）和批处理（DataSet API）能力之外，还提供了类SQL查询（Table API）、图计算（Gelly）和机器学习库（Flink ML）。
    • Flink 还兼容原生 Storm 和 Hadoop 程序，可以在 YARN 管理的集群上运行。虽然 Spark 同样也提供了批处理和流处理的能力，但 Spark 流处理的微批次架构使其响应时间略长。
    • Flink 流处理优先的方式实现了低延迟、高吞吐和真正逐条处理。虽然这两种框架经常被拿来做对比，但在市场需求的驱使下，其实两者都在朝着更多的兼容性发展。

​

离线与实时

假如把大数据技术按数据集处理的时效性来划分则有离线计算和实时计算两类

离线计算：是在计算开始前已知所有输入数据，输入数据不会产生变化，且在解决一个问题后就要立即得出结果的前提下进行的计算。一般来说，离线计算具有数据量巨大且保存时间长；在大量数据上进行复杂的批量运算；数据在计算之前已经完全到位，不会发生变化；能够方便的查询批量计算的结果的特点

实时计算：是计算机科学中对受到 实时约束 的计算机硬件和计算机软件系统的研究，实时约束是从事件发生到系统系统的研究，实时约束是从事件发生到系统回应之间的最长时间限制。

实时程序必须保证在严格的时间限制内响应。通常要求实时计算的响应时间是以毫秒为单位，有时也是以微秒为单位。

相比之下，非实时系统是一种无法保证在任何条件下，回应时间均匹配实时约束限制的系统。有可能大多数的情形下，非实时系统都可以匹配实时约束限制，甚至更快，只是无法保证在任何条件都可以匹配约束限制。与离线计算对应的则是实时计算，数据实时产生后就立刻处理，这种计算方式倾向于把数据看作是流。实时计算一般都是针对海量数据进行的，一般要求为秒级。实时计算主要分为两块:数据的实时入库、数据的实时计算。


## 流批一体的 Apache Flink 架构

- Flink 架构的概念：
  - JobManager、TaskManager；
  - Task、Slot、Operator；
  - Dataflow、DAG、JobGraph；

- 分布式计算系统概念及作用：
  - 调度器；
  - Shuffle Service；
  - HA；
  - Failover Recovery；

- 流批一体：
  - 流式计算与批式计算；

- 实践：
  - 本地跑一个 Flink Job：[First steps](https://link.juejin.cn?target=https%3A%2F%2Fnightlies.apache.org%2Fflink%2Fflink-docs-release-1.15%2Fdocs%2Ftry-flink%2Flocal_installation%2F)、[Intro to the DataStream API](https://link.juejin.cn?target=https%3A%2F%2Fnightlies.apache.org%2Fflink%2Fflink-docs-release-1.15%2Fdocs%2Flearn-flink%2Fdatastream_api%2F)、[Learn Flink Overview](https://link.juejin.cn?target=https%3A%2F%2Fnightlies.apache.org%2Fflink%2Fflink-docs-release-1.15%2Fdocs%2Flearn-flink%2Foverview%2F)；
  - DataFlow Model 设计思想：[现代流式计算的基石：Google DataFlow](https://link.juejin.cn?target=https%3A%2F%2Fzhuanlan.zhihu.com%2Fp%2F54739130)；

推荐文档：

1. [Flink Architecture](https://link.juejin.cn?target=https%3A%2F%2Fnightlies.apache.org%2Fflink%2Fflink-docs-release-1.15%2Fdocs%2Fconcepts%2Fflink-architecture%2F)；

1. [Glossary](https://link.juejin.cn?target=https%3A%2F%2Fnightlies.apache.org%2Fflink%2Fflink-docs-release-1.15%2Fdocs%2Fconcepts%2Fglossary%2F)；

1. [Deployment Overview](https://link.juejin.cn?target=https%3A%2F%2Fnightlies.apache.org%2Fflink%2Fflink-docs-release-1.15%2Fdocs%2Fdeployment%2Foverview%2F)；

1. [Jobs and Scheduling](https://link.juejin.cn?target=https%3A%2F%2Fnightlies.apache.org%2Fflink%2Fflink-docs-release-1.15%2Fdocs%2Finternals%2Fjob_scheduling%2F)；

1. [一文读懂Apache Flink技术 - 掘金](https://juejin.cn/post/6844903700964589576)；

1. [Flink入门宝典(详细截图版) - 掘金](https://juejin.cn/post/6844903944271953928)；

## Apache Flink 的 OLAP 场景面临的问题及优化思路

- OLAP 业务场景；

- Flink Session Cluster 集群；

推荐文档：

1. [OLAP技术选型思路总结，你绕不开的“不可能三角”_关二爷大数据笔记_InfoQ写作社区](https://link.juejin.cn?target=https%3A%2F%2Fxie.infoq.cn%2Farticle%2F3865135874fb09a587103918a)；

1. [字节跳动的 Flink OLAP 作业调度和查询执行优化实践 - 掘金](https://juejin.cn/post/7109380937707683877)；

# 课中

## Apache Flink 概述

### Apache Flink 诞生背景

#### 什么是大数据？

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

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

- 史前阶段~2006
  - 传统数仓
  - Oracle
  - 单机
  - 黑箱使用
- Hadoop
  - 分布式
  - map-reduce
  - 离线计算
- Spark
  - 批处理
  - 流处理
  - SQL高阶API
  - 内存迭代计算
- Flink （业内对数据的实时性有更高的要求）
  - 流计算
  - 实时、更快
  - 流批一体
  - streaming/Batch SQL



#### 为什么需要流式计算

- Hadoop 诞生背景，Hadoop 解决了什么问题？（[大数据十年回顾：浪潮之巅数英雄_大数据_宋词_InfoQ精选文章](https://link.juejin.cn?target=https%3A%2F%2Fwww.infoq.cn%2Farticle%2Fo2wfzkiwfu*lnp3ijxgz)）

- 实时计算的业务场景需求、为什么会出现流式计算
  - 数据实时价值更大；
  - 大数据批式处理分钟级、小时级、天极，部分业务场景无法接受；

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



### 为什么 Flink 会脱颖而出

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

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



因为Flink有Native化，低延迟，高吞吐和 checkpoint 的容错，支持 StateFul 和支持 SQL ，使得它脱颖而出，成为批/流/OLAP的使用引擎。



### Apache Flink 开源生态

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

1. 流批一体：支持流式计算和批式计算；

2. OLAP：Flink 可以支持 OLAP 这种短查询场景；

3. Flink ML：pyFlink、ALink、AIFlow 等生态支持 Flink 在 ML 场景的应用；

4. Gelly：图计算；

5. Stateful Function：支持有状态的 FAAS 场景；

6. ...








## Flink 整体架构

### Flink 分层架构

架构图参考上面

- SDK 层：[Flink's APIs Overview](https://link.juejin.cn?target=https%3A%2F%2Fnightlies.apache.org%2Fflink%2Fflink-docs-release-1.15%2Fdocs%2Flearn-flink%2Foverview%2F)
  - Flink 的 SDK 目前主要有三类，SQL/Table、DataStream、Python


- 执行引擎层（Runtime 层）：执行引擎层提供了统一的 DAG，用来描述数据处理的 Pipeline，不管是流还是批，都会转化为 DAG 图，调度层再把 DAG 转化成分布式环境下的 Task，Task 之间通过 Shuffle 传输数据；
  - 调度：[Jobs and Scheduling](https://link.juejin.cn?target=https%3A%2F%2Fnightlies.apache.org%2Fflink%2Fflink-docs-release-1.15%2Fdocs%2Finternals%2Fjob_scheduling%2F)；
  - Task 生命周期：[Task Lifecycle](https://link.juejin.cn?target=https%3A%2F%2Fnightlies.apache.org%2Fflink%2Fflink-docs-release-1.15%2Fdocs%2Finternals%2Ftask_lifecycle%2F)；
  - Flink Failover 机制：[Task Failure Recovery](https://link.juejin.cn?target=https%3A%2F%2Fnightlies.apache.org%2Fflink%2Fflink-docs-release-1.15%2Fdocs%2Fops%2Fstate%2Ftask_failure_recovery%2F)；
  - Flink 反压概念及监控：[Monitoring Back Pressure](https://link.juejin.cn?target=https%3A%2F%2Fnightlies.apache.org%2Fflink%2Fflink-docs-release-1.15%2Fdocs%2Fops%2Fmonitoring%2Fback_pressure%2F)；
  - Flink HA 机制：[Flink HA Overview](https://link.juejin.cn?target=https%3A%2F%2Fnightlies.apache.org%2Fflink%2Fflink-docs-release-1.15%2Fdocs%2Fdeployment%2Fha%2Foverview%2F)；

- 状态存储层（State Backend）：负责存储算子的状态信息

- 资源调度层（Resource Manager）：目前 Flink 可以支持部署在多种环境





### Flink 整体架构（[Flink Architecture](https://link.juejin.cn?target=https%3A%2F%2Fnightlies.apache.org%2Fflink%2Fflink-docs-release-1.15%2Fdocs%2Fconcepts%2Fflink-architecture%2F)）

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









作业

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

（使用Java代码编写）

DataStream lines = env.addSource( new FlinkKafkaConsumer<>(···)); DataStream events = lines.map((line) -> parase(line)); DataStream stats = events .keyBy(even -> event.id) .timeWindow(Time.seconds(10)) .apply(new MyWindowAggregationFunction()); stats.addSink(new.BucketingSink(path));


假设作业的 sink 算子的并发配置为1，其余算子并发为2

紧接着会将上面的 streaming DataFlow Graph 转化 Parallel Dataflow（内部叫做 Execution Graph）：


为了更高效地分布执行，Flink 会可能的将不同的 operator 链接（chain）在一起形成 task

这样每个 Task 可以在一个线程中执行，内部叫做 OperationChain，如下图：source 和 map 算子可以 chain在一起


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








### Flink 如何做到流批一体

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

  

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




  - **批式计算相比于流式计算核心的区别**：
    
    |维度|流式计算|批处理|
    |:---:|:-------:|:-----------:|
    |数据流|无限数据集|有限数据集|
    |时延|低时延、业务会感知运行中的情况|实时性要求不高，只关注最终结果产出时间|
    
  - 无限数据集 --> 有限数据集；
    
    - 低延迟 --> 实时性要求不高；




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

|模式|特点|场景|
|:----:|:--------------------------:|:---------------|
|EAGER|申请一个作业所需要的**全部资源**，然后同时调度这个作业的全部 Task，所有的 Task 之间采取 Pipeline 的方式进行通信 |Stream场景|
|LAZY|先调度上游，等待上游产生数据或结束后再调度下游，类似 Spark 的 Stage 执行模式|Batch作业场景|
  - 
    - EAGER（Streaming 场景）：申请一个作业所需要的全部资源，然后同时调度这个作业的全部 Task，所有的 Task 之间采取 Pipeline 的方式进行通信；
    - LAZY（Batch 场景）：先调度上游，等待上游产生数据或结束后再调度下游，类似 Spark 的 Stage 执行模式。
  - Pipeline Region Scheduler 机制：[FLIP-119 Pipelined Region Scheduling - Apache Flink - Apache Software Foundation](https://link.juejin.cn?target=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FFLINK%2FFLIP-119%2BPipelined%2BRegion%2BScheduling)；



All_EDGES_BLOCKING;

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

All_EDGES_PIPELINED:

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







- **流批一体的 Shuffle Service 层（**[FLIP-31: Pluggable Shuffle Service - Apache Flink - Apache Software Foundation](https://link.juejin.cn?target=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FFLINK%2FFLIP-31%3A%2BPluggable%2BShuffle%2BService)）

  - Shuffle：**在分布式计算中，用来连接上下游数据交互的过程叫做 Shuffle**。实际上，分布式计算中所有涉及到上下游衔接的过程，都可以理解为 Shuffle；
  - **Shuffle 分类：**
    - **<u>基于文件的 Pull Based Shuffle</u>**，比如 Spark 或 MR，它的特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的**容错性和稳定性**会更好一些；、
    - **<u>基于 Pipeline 的 Push Based Shuffle</u>**，比如 Flink、Storm、Presto 等，它的特点是**低延迟和高性能**，但是因为 <u>shuffle 数据没有存储下来</u>，如果是 batch 任务的话，就需要进行重跑恢复；
  - **流和批 Shuffle 之间的差异：**
    - <u>Shuffle 数据的生命周期</u>：流作业的 Shuffle 数据与 Task 是绑定的，而批作业的 Shuffle 数据与 Task 是解耦的；
    - <u>Shuffle 数据存储介质</u>：流作业的生命周期比较短、而且流作业为了实时性，Shuffle 通常存储在内存中，批作业因为数据量比较大以及容错的需求，一般会存储在磁盘里；
    - <u>Shuffle 的部署方式：</u>流作业 Shuffle 服务和计算节点部署在一起，可以减少网络开销，从而减少 latency，而批作业则不同。
  - Pluggable Shuffle Service：Flink 的目标是提供一套统一的 Shuffle 架构，既可以满足不同 Shuffle 在策略上的定制，同时还能避免在共性需求上进行重复开发




对于 shuffle service，Flink 开源社区已经支持

- 1. Netty Shuffle Service: 既支持 pipeline 又支持 blocking，Flink 默认的shuffle Service 策略；
  2. Remote Shuffle Service : 既支持 pipeline 又支持 blocking，不过对于 pipeline 模式，走 remote 反而会性能下降，主要是有用在 Batch 的 blocking 场景，字节内部是基于 CSS 来实现 RSS。



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







## Flink 架构优化

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

- 三种业务场景的特点



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













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

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






### Flink 如何支持 OLAP 场景

- Flink 做 OLAP 的优势
  - 统一引擎：流处理、批处理、OLAP 统一使用 Flink 引擎；
    - **降低学习成本**，仅需要学习一个引擎；
    - **提高开发效率**，很多 SQL 是流批通用；
    - **提高维护效率**，可以更集中维护好一个引擎；
  - 既有优势：利用 Flink 已有的很多特性，使 OLAP 使用场景更为广泛；
    - 使用流处理的内存计算、Pipeline；
    - 支持代码动态生成；
    - 也可以支持批处理数据落盘能力；
  - 相互增强：OLAP 能享有现有引擎的优势，同时也能增强引擎能力
    - 无统计信息场景的优化；
    - 开发更高效的算子；
    - 使 Flink 同时兼备流、批、OLAP 处理的能力，成为更通用的框架。
  - 生态支持：
    - 跨数据源查询支持
    - TCP-DS基准测试性能强
  
- Flink OLAP 场景的挑战
  - 秒级和毫秒级的**小作业**；
  - **作业频繁启停、资源碎片**；
    - Flink OLAP 计算相比流式和批式计算，最大的特点是 Flink OLAP 计算是一个面向秒级和毫秒级的小作业，作业在启动过程中会**<u>频繁申请内存、网络以及磁盘资源</u>**，导致 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执行具体的计算任务，采用线程模型，为每个计算任务创建计算线程，根据计算任务的上下游数据依赖关系跟上游计算任务建立/复用网络连接，向上游计算任务发送数据请求，并处理上游分发给它的数据。

![img](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b85f7896ee97481aa522c3ce5dbac9ca~tplv-k3u1fbpfcp-zoom-in-crop-mark:3024:0:0:0.awebp)

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