01-Flink-概念:
笔记相关来源,尚硅谷:
https://www.bilibili.com/video/BV1qy4y1q728/?p=1&spm_id_from=pageDriver&vd_source=39a1ba1654411bc9ab90f6f2926600b7
以及部分csdn
https://ashiamd.github.io/docsify-notes/#/study/BigData/Flink/%E5%B0%9A%E7%A1%85%E8%B0%B7Flink%E5%85%A5%E9%97%A8%E5%88%B0%E5%AE%9E%E6%88%98-%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0
1. Flink的特点
-
事件驱动(Event-driven)
-
基于流处理
一切皆由流组成,离线数据是有界的流;实时数据是一个没有界限的流。(有界流、无界流)
-
分层API
- 越顶层越抽象,表达含义越简明,使用越方便
- 越底层越具体,表达能力越丰富,使用越灵活
1.1 Flink vs Spark Streaming
- 数据模型
- Spark采用RDD模型,spark streaming的DStream实际上也就是一组组小批数据RDD的集合
- flink基本数据模型是数据流,以及事件(Event)序列
- 运行时架构
- spark是批计算,将DAG划分为不同的stage,一个完成后才可以计算下一个
- flink是标准的流执行模式,一个事件在一个节点处理完后可以直接发往下一个节点处理
2.flink入门workcount测试
src/main/java/com/zh/flink/s01_wordcount
import org.apache.flink.api.java.tuple.Tuple2;
import org.apache.flink.api.java.utils.ParameterTool;
import org.apache.flink.streaming.api.datastream.DataStream;
import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
//1、给该类在Edit configurations 的 program arguments 添加 --host 自己使用的ip,本地或者虚拟机ip --port 7777
// 例如--host 192.168.10.101 --port 7777
//2、虚拟机,通过nc -lk <port>打开一个socket服务,用于模拟实时的流数据
//3、输入word 进行测试
public class StreamWordCount {
public static void main(String[] args) throws Exception{
// 创建流处理执行环境
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
// env.setParallelism(1);//分区的个数
// env.disableOperatorChaining();
// 设置并行度,默认值 = 当前计算机的CPU逻辑核数(设置成1即单线程处理)
// env.setMaxParallelism(32);
// // 从文件中读取数据
// String inputPath = "D:\\Projects\\BigData\\FlinkTutorial\\src\\main\\resources\\hello.txt";
// DataStream<String> inputDataStream = env.readTextFile(inputPath);
// 用parameter tool工具从程序启动参数中提取配置项
ParameterTool parameterTool = ParameterTool.fromArgs(args);
String host = parameterTool.get("host");
int port = parameterTool.getInt("port");
// 从socket文本流读取数据
DataStream<String> inputDataStream = env.socketTextStream(host, port);
// 基于数据流进行转换计算
DataStream<Tuple2<String,Integer>> resultStream = inputDataStream.flatMap(new WordCount.MyFlatMapper())
.keyBy(item->item.f0)
.sum(1);
resultStream.print().setParallelism(1);//设置并行度
// 执行任务
env.execute();
}
}
一个task占用的槽位=每个分组最大并行度的和。
3. Flink部署
3.1 Standalone模式、
参考:https://blog.csdn.net/qq_39657909/article/details/105823127
- Flink 中每一个 TaskManager 都是一个JVM进程,它可能会在独立的线程上执行一个或多个 subtask
- 为了控制一个 TaskManager 能接收多少个 task, TaskManager 通过 task slot 来进行控制(一个 TaskManager 至少有一个 slot)
- 每个task slot表示TaskManager拥有资源的一个固定大小的子集。假如一个TaskManager有三个slot,那么它会将其管理的内存分成三份给各个slot(注:这里不会涉及CPU的隔离,slot仅仅用来隔离task的受管理内存)
- 可以通过调整task slot的数量去自定义subtask之间的隔离方式。如一个TaskManager一个slot时,那么每个task group运行在独立的JVM中。而当一个TaskManager多个slot时,多个subtask可以共同享有一个JVM,而在同一个JVM进程中的task将共享TCP连接和心跳消息,也可能共享数据集和数据结构,从而减少每个task的负载。
- 默认情况下,Flink 允许子任务共享 slot,即使它们是不同任务的子任务(前提是它们来自同一个job)。 这样的结果是,一个 slot 可以保存作业的整个管道。
- Task Slot 是静态的概念,是指 TaskManager 具有的并发执行能力,可以通过参数taskmanager.numberOfTaskSlots进行配置;而并行度parallelism是动态概念,即TaskManager运行程序时实际使用的并发能力,可以通过参数parallelism.default进行配置。 举例:如果总共有3个TaskManager,每一个TaskManager中分配了3个TaskSlot,也就是每个TaskManager可以接收3个task,这样我们总共可以接收9个TaskSot。但是如果我们设置parallelism.default=1,那么当程序运行时9个TaskSlot将只有1个运行,8个都会处于空闲状态,所以要学会合理设置并行度!具体图解如下:
conf/flink-conf.yaml
配置文件中
taskmanager.numberOfTaskSlots
parallelism.default
# The number of task slots that each TaskManager offers. Each slot runs one parallel pipeline.
taskmanager.numberOfTaskSlots: 1
# The parallelism used for programs that did not specify and other parallelism.
parallelism.default: 1
注:Flink存储State用的是堆外内存,所以web UI里JVM Heap Size
和Flink Managed MEM
是两个分开的值。
3.1.1 Web UI提交job
Flink Savepoint简单介绍:https://blog.csdn.net/qq_37142346/article/details/91385333
启动Flink后,可以在Web UI:lcoalhost:8081的Submit New Job
提交jar包,然后指定Job参数。
-
Entry Class:程序的入口,指定入口类(类的全限制名)
-
Program Arguments:程序启动参数,例如
--host localhost --port 7777
-
Parallelism
设置Job并行度。
Ps:并行度优先级(从上到下优先级递减)
- 代码中算子
setParallelism()
ExecutionEnvironment env.setMaxParallelism()
- 设置的Job并行度
- 集群conf配置文件中的
parallelism.default
ps:socket等特殊的IO操作,本身不能并行处理,并行度只能是1
- 代码中算子
-
Savepoint Path
savepoint是通过checkpoint机制为streaming job创建的一致性快照,比如数据源offset,状态等。
(savepoint可以理解为手动备份,而checkpoint为自动备份)
ps:提交job要注意分配的slot总数是否足够使用,如果slot总数不够,那么job执行失败。(资源不够调度)
这里提交前面demo项目的StreamWordCount,在本地socket即nc -lk 7777
中输入字符串,查看结果
输入:
hello world, and thank you!
输出:
可以看出来输出的顺序并不是和输入的字符串严格相同的,因为是多个线程并行处理的。
1> (world,,1)
2> (and,1)
1> (thank,1)
2> (you!,1)
2> (hello,1)
3.1.2 命令行提交job
-
查看已提交的所有job
$ bin/flink list Waiting for response... ------------------ Running/Restarting Jobs ------------------- 30.01.2021 17:09:45 : 30d9dda946a170484d55e41358973942 : Flink Streaming Job (RUNNING) -------------------------------------------------------------- No scheduled jobs.
-
提交job
-c
指定入口类-p
指定job的并行度
bin/flink run -c <入口类> -p <并行度> <jar包路径> <启动参数>
$ bin/flink run -c wc.StreamWordCount -p 3 /tmp/Flink_Tutorial-1.0-SNAPSHOT.jar --host localhost --port 7777 Job has been submitted with JobID 33a5d1f00688a362837830f0b85fd75e
-
取消job
bin/flink cancel <Job的ID>
$ bin/flink cancel 30d9dda946a170484d55e41358973942 Cancelling job 30d9dda946a170484d55e41358973942. Cancelled job 30d9dda946a170484d55e41358973942.
注:Total Task Slots只要不小于Job中Parallelism最大值即可。
eg:这里我配置文件设置taskmanager.numberOfTaskSlots: 4
,实际Job运行时总Tasks显示9,但是里面具体4个任务步骤分别需求(1,3,3,2)数量的Tasks,4>3,满足最大的Parallelism即可运行成功。
3.2 yarn模式
https://blog.csdn.net/suyebiubiu/article/details/111874245
以Yarn模式部署Flink任务时,要求Flink是有Hadoop支持的版本,Hadoop 环境需要保证版本在 2.2 以上,并且集群中安装有 HDFS 服务。
3.2.1 Flink on Yarn
Flink提供了两种在yarn上运行的模式,分别为Session-Cluster和Per-Job-Cluster模式。
1. Sesstion Cluster模式
Session-Cluster 模式需要先启动集群,然后再提交作业,接着会向 yarn 申请一块空间后,资源永远保持不变。如果资源满了,下一个作业就无法提交,只能等到 yarn 中的其中一个作业执行完成后,释放了资源,下个作业才会正常提交。所有作业共享 Dispatcher 和 ResourceManager;共享资源;适合规模小执行时间短的作业。
在 yarn 中初始化一个 flink 集群,开辟指定的资源,以后提交任务都向这里提交。这个 flink 集群会常驻在 yarn 集群中,除非手工停止。
2. Per Job Cluster 模式
一个 Job 会对应一个集群,每提交一个作业会根据自身的情况,都会单独向 yarn 申请资源,直到作业执行完成,一个作业的失败与否并不会影响下一个作业的正常提交和运行。独享 Dispatcher 和 ResourceManager,按需接受资源申请;适合规模大长时间运行的作业。
每次提交都会创建一个新的 flink 集群,任务之间互相独立,互不影响,方便管理。任务执行完成之后创建的集群也会消失。
3.2.2 Session Cluster
-
启动hadoop集群(略)
-
启动yarn-session
./yarn-session.sh -n 2 -s 2 -jm 1024 -tm 1024 -nm test -d
其中:
-n(--container)
:TaskManager的数量。-s(--slots)
:每个TaskManager的slot数量,默认一个slot一个core,默认每个taskmanager的slot的个数为1,有时可以多一些taskmanager,做冗余。-jm
:JobManager的内存(单位MB)。-tm
:每个taskmanager的内存(单位MB)。-nm
:yarn 的appName(现在yarn的ui上的名字)。-d
:后台执行。
-
执行任务
./flink run -c com.atguigu.wc.StreamWordCount FlinkTutorial-1.0-SNAPSHOT-jar-with-dependencies.jar --host lcoalhost –port 7777
-
去 yarn 控制台查看任务状态
-
取消 yarn-session
yarn application --kill application_1577588252906_0001
3.2.3 Per Job Cluster
-
启动hadoop集群(略)
-
不启动yarn-session,直接执行job
./flink run –m yarn-cluster -c com.atguigu.wc.StreamWordCount FlinkTutorial-1.0-SNAPSHOT-jar-with-dependencies.jar --host lcoalhost –port 7777
3.3 Kubernetes部署
容器化部署时目前业界很流行的一项技术,基于Docker镜像运行能够让用户更加方便地对应用进行管理和运维。容器管理工具中最为流行的就是Kubernetes(k8s),而Flink也在最近的版本中支持了k8s部署模式。
- 搭建Kubernetes集群(略)
- 配置各组件的yaml文件
在k8s上构建Flink Session Cluster,需要将Flink集群的组件对应的docker镜像分别在k8s上启动,包括JobManager、TaskManager、JobManagerService三个镜像服务。每个镜像服务都可以从中央镜像仓库中获取。
-
启动Flink Session Cluster
// 启动jobmanager-service 服务 kubectl create -f jobmanager-service.yaml // 启动jobmanager-deployment服务 kubectl create -f jobmanager-deployment.yaml // 启动taskmanager-deployment服务 kubectl create -f taskmanager-deployment.yaml
-
访问Flink UI页面
集群启动后,就可以通过JobManagerServicers中配置的WebUI端口,用浏览器输入以下url来访问Flink UI页面了:
http://{JobManagerHost:Port}/api/v1/namespaces/default/services/flink-jobmanager:ui/proxy
4. Flink运行架构
4.1 Flink运行时的组件
Flink运行时架构主要包括四个不同的组件,它们会在运行流处理应用程序时协同工作:
- 作业管理器(JobManager)
- 资源管理器(ResourceManager)
- 任务管理器(TaskManager)
- 分发器(Dispatcher)
因为Flink是用Java和Scala实现的,所以所有组件都会运行在Java虚拟机上。每个组件的职责如下:
作业管理器(JobManager)
控制一个应用程序执行的主进程,也就是说,每个应用程序都会被一个不同的JobManager所控制执行。
JobManager会先接收到要执行的应用程序,这个应用程序会包括:
- 作业图(JobGraph)
- 逻辑数据流图(logical dataflow graph)
- 打包了所有的类、库和其它资源的JAR包。
JobManager会把JobGraph转换成一个物理层面的数据流图,这个图被叫做“执行图”(ExecutionGraph),包含了所有可以并发执行的任务。
JobManager会向资源管理器(ResourceManager)请求执行任务必要的资源,也就是任务管理器(TaskManager)上的插槽(slot)。一旦它获取到了足够的资源,就会将执行图分发到真正运行它们的TaskManager上。
在运行过程中,JobManager会负责所有需要中央协调的操作,比如说检查点(checkpoints)的协调。
资源管理器(ResourceManager)
主要负责管理任务管理器(TaskManager)的插槽(slot),TaskManger插槽是Flink中定义的处理资源单元。
Flink为不同的环境和资源管理工具提供了不同资源管理器,比如YARN、Mesos、K8s,以及standalone部署。
当JobManager申请插槽资源时,ResourceManager会将有空闲插槽的TaskManager分配给JobManager。如果ResourceManager没有足够的插槽来满足JobManager的请求,它还可以向资源提供平台发起会话,以提供启动TaskManager进程的容器。
另外,ResourceManager还负责终止空闲的TaskManager,释放计算资源。
任务管理器(TaskManager)
Flink中的工作进程。通常在Flink中会有多个TaskManager运行,每一个TaskManager都包含了一定数量的插槽(slots)。插槽的数量限制了TaskManager能够执行的任务数量。
启动之后,TaskManager会向资源管理器注册它的插槽;收到资源管理器的指令后,TaskManager就会将一个或者多个插槽提供给JobManager调用。JobManager就可以向插槽分配任务(tasks)来执行了。
在执行过程中,一个TaskManager可以跟其它运行同一应用程序的TaskManager交换数据。
分发器(Dispatcher)
可以跨作业运行,它为应用提交提供了REST接口。
当一个应用被提交执行时,分发器就会启动并将应用移交给一个JobManager。由于是REST接口,所以Dispatcher可以作为集群的一个HTTP接入点,这样就能够不受防火墙阻挡。Dispatcher也会启动一个Web UI,用来方便地展示和监控作业执行的信息。
Dispatcher在架构中可能并不是必需的,这取决于应用提交运行的方式。
4.2 任务提交流程
我们来看看当一个应用提交执行时,Flink的各个组件是如何交互协作的:
ps:上图中7.指TaskManager为JobManager提供slots,8.表示JobManager提交要在slots中执行的任务给TaskManager。
上图是从一个较为高层级的视角来看应用中各组件的交互协作。
如果部署的集群环境不同(例如YARN,Mesos,Kubernetes,standalone等),其中一些步骤可以被省略,或是有些组件会运行在同一个JVM进程中。
具体地,如果我们将Flink集群部署到YARN上,那么就会有如下的提交流程:
- Flink任务提交后,Client向HDFS上传Flink的Jar包和配置
- 之后客户端向Yarn ResourceManager提交任务,ResourceManager分配Container资源并通知对应的NodeManager启动ApplicationMaster
- ApplicationMaster启动后加载Flink的Jar包和配置构建环境,去启动JobManager,之后JobManager向Flink自身的RM进行申请资源,自身的RM向Yarn 的ResourceManager申请资源(因为是yarn模式,所有资源归yarn RM管理)启动TaskManager
- Yarn ResourceManager分配Container资源后,由ApplicationMaster通知资源所在节点的NodeManager启动TaskManager
- NodeManager加载Flink的Jar包和配置构建环境并启动TaskManager,TaskManager启动后向JobManager发送心跳包,并等待JobManager向其分配任务。
4.3 任务调度原理
-
客户端不是运行时和程序执行的一部分,但它用于准备并发送dataflow(JobGraph)给Master(JobManager),然后,客户端断开连接或者维持连接以等待接收计算结果。而Job Manager会产生一个执行图(Dataflow Graph)
-
当 Flink 集群启动后,首先会启动一个 JobManger 和一个或多个的 TaskManager。由 Client 提交任务给 JobManager,JobManager 再调度任务到各个 TaskManager 去执行,然后 TaskManager 将心跳和统计信息汇报给 JobManager。TaskManager 之间以流的形式进行数据的传输。上述三者均为独立的 JVM 进程。
-
Client 为提交 Job 的客户端,可以是运行在任何机器上(与 JobManager 环境连通即可)。提交 Job 后,Client 可以结束进程(Streaming的任务),也可以不结束并等待结果返回。
-
JobManager 主要负责调度 Job 并协调 Task 做 checkpoint,职责上很像 Storm 的 Nimbus。从 Client 处接收到 Job 和 JAR 包等资源后,会生成优化后的执行计划,并以 Task 的单元调度到各个 TaskManager 去执行。
-
TaskManager 在启动的时候就设置好了槽位数(Slot),每个 slot 能启动一个 Task,Task 为线程。从 JobManager 处接收需要部署的 Task,部署启动后,与自己的上游建立 Netty 连接,接收数据并处理。
注:如果一个Slot中启动多个线程,那么这几个线程类似CPU调度一样共用同一个slot
4.3.1 TaskManger与Slots
要点:
-
考虑到Slot分组,所以实际运行Job时所需的Slot总数 = 每个Slot组中的最大并行度。
eg(1,1,2,1),其中第一个归为组“red”、第二个归组“blue”、第三个和第四归组“green”,那么运行所需的slot即max(1)+max(1)+max(2,1) = 1+1+2 = 4
- Flink中每一个worker(TaskManager)都是一个JVM进程,它可能会在独立的线程上执行一个或多个subtask。
- 为了控制一个worker能接收多少个task,worker通过task slot来进行控制(一个worker至少有一个task slot)。
上图这个每个子任务各自占用一个slot,可以在代码中通过算子的.slotSharingGroup("组名")
指定算子所在的Slot组名,默认每一个算子的SlotGroup和上一个算子相同,而默认的SlotGroup就是"default"。
同一个SlotGroup的算子能共享同一个slot,不同组则必须另外分配独立的Slot。
-
默认情况下,Flink允许子任务共享slot,即使它们是不同任务的子任务(前提需要来自同一个Job)。这样结果是,一个slot可以保存作业的整个管道pipeline。
- 不同任务共享同一个Slot的前提:这几个任务前后顺序不同,如上图中Source和keyBy是两个不同步骤顺序的任务,所以可以在同一个Slot执行。
- 一个slot可以保存作业的整个管道的好处:
- 如果有某个slot执行完了整个任务流程,那么其他任务就可以不用继续了,这样也省去了跨slot、跨TaskManager的通信损耗(降低了并行度)
- 同时slot能够保存整个管道,使得整个任务执行健壮性更高,因为某些slot执行出异常也能有其他slot补上。
- 有些slot分配到的子任务非CPU密集型,有些则CPU密集型,如果每个slot只完成自己的子任务,将出现某些slot太闲,某些slot过忙的现象。
- 假设拆分的多个Source子任务放到同一个Slot,那么任务不能并行执行了=>因为多个相同步骤的子任务需要抢占的具体资源相同,比如抢占某个锁,这样就不能并行。
-
Task Slot是静态的概念,是指TaskManager具有的并发执行能力,可以通过参数
taskmanager.numberOfTaskSlots
进行配置。而并行度parallelism是动态概念,即TaskManager运行程序时实际使用的并发能力,可以通过参数
parallelism.default
进行配置。
每个task slot表示TaskManager拥有资源的一个固定大小的子集。假如一个TaskManager有三个slot,那么它会将其管理的内存分成三份给各个slot。资源slot化意味着一个subtask将不需要跟来自其他job的subtask竞争被管理的内存,取而代之的是它将拥有一定数量的内存储备。
需要注意的是,这里不会涉及到CPU的隔离,slot目前仅仅用来隔离task的受管理的内存。
通过调整task slot的数量,允许用户定义subtask之间如何互相隔离。如果一个TaskManager一个slot,那将意味着每个task group运行在独立的JVM中(该JVM可能是通过一个特定的容器启动的),而一个TaskManager多个slot意味着更多的subtask可以共享同一个JVM。而在同一个JVM进程中的task将共享TCP连接(基于多路复用)和心跳消息。它们也可能共享数据集和数据结构,因此这减少了每个task的负载。
4.3.2 Slot和并行度
- 一个特定算子的 子任务(subtask)的个数被称之为其并行度(parallelism),我们可以对单独的每个算子进行设置并行度,也可以直接用env设置全局的并行度,更可以在页面中去指定并行度。
- 最后,由于并行度是实际Task Manager处理task 的能力,而一般情况下,一个 stream 的并行度,可以认为就是其所有算子中最大的并行度,则可以得出在设置Slot时,在所有设置中的最大设置的并行度大小则就是所需要设置的Slot的数量。(如果Slot分组,则需要为每组Slot并行度最大值的和)
假设一共有3个TaskManager,每一个TaskManager中的分配3个TaskSlot,也就是每个TaskManager可以接收3个task,一共9个TaskSlot,如果我们设置parallelism.default=1
,即运行程序默认的并行度为1,9个TaskSlot只用了1个,有8个空闲,因此,设置合适的并行度才能提高效率。
ps:上图最后一个因为是输出到文件,避免多个Slot(多线程)里的算子都输出到同一个文件互相覆盖等混乱问题,直接设置sink的并行度为1。
4.3.3 程序和数据流(DataFlow)
- 所有的Flink程序都是由三部分组成的: Source 、Transformation 和 Sink。
- Source 负责读取数据源,Transformation 利用各种算子进行处理加工,Sink 负责输出
- 在运行时,Flink上运行的程序会被映射成“逻辑数据流”(dataflows),它包含了这三部分
- 每一个dataflow以一个或多个sources开始以一个或多个sinks结束。dataflow类似于任意的有向无环图(DAG)
- 在大部分情况下,程序中的转换运算(transformations)跟dataflow中的算子(operator)是一一对应的关系
4.3.4 执行图(ExecutionGraph)
由Flink程序直接映射成的数据流图是StreamGraph,也被称为逻辑流图,因为它们表示的是计算逻辑的高级视图。为了执行一个流处理程序,Flink需要将逻辑流图转换为物理数据流图(也叫执行图),详细说明程序的执行方式。
- Flink 中的执行图可以分成四层:StreamGraph -> JobGraph -> ExecutionGraph -> 物理执行图。
- StreamGraph:是根据用户通过Stream API 编写的代码生成的最初的图。用来表示程序的拓扑结构。
- JobGraph:StreamGraph经过优化后生成了JobGraph,提交给JobManager 的数据结构。主要的优化为,将多个符合条件的节点chain 在一起作为一个节点,这样可以减少数据在节点之间流动所需要的序列化/反序列化/传输消耗。
- ExecutionGraph:JobManager 根据JobGraph 生成ExecutionGraph。ExecutionGraph是JobGraph的并行化版本,是调度层最核心的数据结构。
- 物理执行图:JobManager 根据ExecutionGraph 对Job 进行调度后,在各个TaskManager 上部署Task 后形成的“图”,并不是一个具体的数据结构。
4.3.5 数据传输形式
-
一个程序中,不同的算子可能具有不同的并行度
-
算子之间传输数据的形式可以是 one-to-one (forwarding) 的模式也可以是redistributing 的模式,具体是哪一种形式,取决于算子的种类
- One-to-one:stream维护着分区以及元素的顺序(比如source和map之间)。这意味着map 算子的子任务看到的元素的个数以及顺序跟 source 算子的子任务生产的元素的个数、顺序相同。map、fliter、flatMap等算子都是one-to-one的对应关系。
- Redistributing:stream的分区会发生改变。每一个算子的子任务依据所选择的transformation发送数据到不同的目标任务。例如,keyBy 基于 hashCode 重分区、而 broadcast 和 rebalance 会随机重新分区,这些算子都会引起redistribute过程,而 redistribute 过程就类似于 Spark 中的 shuffle 过程。
4.3.6 任务链(OperatorChains)
Flink 采用了一种称为任务链的优化技术,可以在特定条件下减少本地通信的开销。为了满足任务链的要求,必须将两个或多个算子设为相同的并行度,并通过本地转发(local forward)的方式进行连接
- 相同并行度的one-to-one 操作,Flink 这样相连的算子链接在一起形成一个 task,原来的算子成为里面的 subtask
- 并行度相同、并且是 one-to-one 操作,两个条件缺一不可
为什么需要并行度相同,因为若flatMap并行度为1,到了之后的map并行度为2,从flatMap到map的数据涉及到数据由于并行度map为2会往两个slot处理,数据会分散,所产生的元素个数和顺序发生的改变所以有2个单独的task,不能成为任务链
如果前后任务逻辑上可以是OneToOne,且并行度一致,那么就能合并在一个Slot里(并行度原本是多少就是多少,两者并行度一致)执行。
- keyBy需要根据Hash值分配给不同slot执行,所以只能Hash,不能OneToOne。
- 逻辑上可OneToOne但是并行度不同,那么就会Rebalance,轮询形式分配给下一个任务的多个slot。
- 代码中如果
算子.disableChaining()
,能够强制当前算子的子任务不参与任务链的合并,即不和其他Slot资源合并,但是仍然可以保留“Slot共享”的特性。 - 如果
StreamExecutionEnvironment env.disableOperatorChaining()
则当前执行环境全局设置算子不参与"任务链的合并"。 - 如果
算子.startNewChain()
表示不管前面任务链合并与否,从当前算子往后重新计算任务链的合并。通常用于前面强制不要任务链合并,而当前往后又需要任务链合并的特殊场景。
ps:如果算子.shuffle()
,能够强制算子之后重分区到不同slot执行下一个算子操作,逻辑上也实现了任务不参与任务链合并=>但是仅为“不参与任务链的合并”,这个明显不是最优解操作
Flink slotSharingGroup disableChain startNewChain 用法案例
https://blog.csdn.net/qq_31866793/article/details/102786249