追源索骥：透过源码看懂Flink核心框架的执行流程

flink

转载自：https://www.cnblogs.com/bethunebtj/p/9168274.html

---

• 追源索骥：透过源码看懂Flink核心框架的执行流程
  • 前言
  • 1.从 Hello,World WordCount开始
    • 1.1 flink执行环境
    • 1.2 算子（Operator）的注册（声明）
    • 1.3 程序的执行
      • 1.3.1 本地模式下的execute方法
      • 1.3.2 远程模式（RemoteEnvironment）的execute方法
      • 1.3.3 程序启动过程
  • 2.理解flink的图结构
    • 2.1 flink的三层图结构
    • 2.2 StreamGraph的生成
      • 2.2.1 StreamTransformation类代表了流的转换
      • 2.2.2 StreamGraph生成函数分析
      • 2.2.3 WordCount函数的StreamGraph
    • 2.3 JobGraph的生成
      • 2.3.1 JobGraph生成源码
      • 2.3.2 operator chain的逻辑
      • 2.3.3 JobGraph的提交
    • 2.4 ExecutionGraph的生成
  • 3. 任务的调度与执行
    • 3.1 计算资源的调度
    • 3.2 JobManager执行job
      • 3.2.1 JobManager的组件
      • 3.2.2 JobManager的启动过程
      • 3.2.3 JobManager启动Task
    • 3.3 TaskManager执行task
      • 3.3.1 TaskManager的基本组件
      • 3.3.2 TaskManager执行Task
      • 3.3.2.1 生成Task对象
      • 3.3.2.2 运行Task对象
      • 3.3.2.3 StreamTask的执行逻辑
    • 3.4 StreamTask与StreamOperator
  • 4. StreamOperator的抽象与实现
    • 4.1 数据源的逻辑——StreamSource与时间模型
    • 4.2 从数据输入到数据处理——OneInputStreamOperator & AbstractUdfStreamOperator
    • 4.3 StreamSink
  • 5. 为执行保驾护航——Fault Tolerant与保证Exactly-Once语义
    • 5.1 Fault Tolerant演进之路
      • 5.1.1 Storm的Record acknowledgement模式
      • 5.1.2 Spark streaming的micro batch模式
      • 5.1.3 Google Cloud Dataflow的事务式模型
      • 5.1.4 Flink的分布式快照机制
    • 5.2 checkpoint的生命周期
      • 5.2.1 触发checkpoint
      • 5.2.2 Task层面checkpoint的准备工作
      • 5.2.3 操作符的状态保存及barrier传递
    • 5.3 承载checkpoint数据的抽象：State & StateBackend
  • 6.数据流转——Flink的数据抽象及数据交换过程
    • 6.1 flink的数据抽象
      • 6.1.1 MemorySegment
      • 6.1.2 ByteBuffer与NetworkBufferPool
      • 6.1.3 RecordWriter与Record
    • 6.2 数据流转过程
      • 6.2.1 整体过程
      • 6.2.2 数据跨task传递
    • 6.3 Credit漫谈
      • 6.3.1 背压问题
      • 6.3.2 使用Credit实现ATM网络流控
  • 7.其他核心概念
    • 7.1 EventTime时间模型
    • 7.2 FLIP-6 部署及处理模型演进
      • 7.2.1 现有模型不足
      • 7.2.2 核心变更
      • 7.2.3 Cluster Manager的架构
      • 7.2.4 组件设计及细节
  • 8.后记

 

前言

Flink是大数据处理领域最近很火的一个开源的分布式、高性能的流式处理框架，其对数据的处理可以达到毫秒级别。本文以一个来自官网的WordCount例子为引，全面阐述flink的核心架构及执行流程，希望读者可以借此更加深入的理解Flink逻辑。

本文跳过了一些基本概念，如果对相关概念感到迷惑，请参考官网文档。另外在本文写作过程中，Flink正式发布了其1.5 RELEASE版本，在其发布之后完成的内容将按照1.5的实现来组织。

 

1.从 Hello,World WordCount开始

首先，我们把WordCount的例子再放一遍：

    public class SocketTextStreamWordCount {
    
    public static void main(String[] args) throws Exception {
        if (args.length != 2){
            System.err.println("USAGE:\nSocketTextStreamWordCount  ");
            return;
        }
        String hostName = args[0];
        Integer port = Integer.parseInt(args[1]);
        // set up the execution environment
        final StreamExecutionEnvironment env = StreamExecutionEnvironment
                .getExecutionEnvironment();

        // get input data
        DataStream text = env.socketTextStream(hostName, port);
        
        text.flatMap(new LineSplitter()).setParallelism(1)
        // group by the tuple field "0" and sum up tuple field "1"
                .keyBy(0)
                .sum(1).setParallelism(1)
                .print();

        // execute program
        env.execute("Java WordCount from SocketTextStream Example");
    }
    
        /**
         * Implements the string tokenizer that splits sentences into words as a user-defined
         * FlatMapFunction. The function takes a line (String) and splits it into
         * multiple pairs in the form of "(word,1)" (Tuple2<String, Integer>).
         */
        public static final class LineSplitter implements FlatMapFunction> {
            @Override
            public void flatMap(String value, Collector> out) {
                // normalize and split the line
                String[] tokens = value.toLowerCase().split("\\W+");
                // emit the pairs
                for (String token : tokens) {
                    if (token.length() > 0) {
                        out.collect(new Tuple2(token, 1));
                    }
                }
            }
        }
    }

首先从命令行中获取socket对端的ip和端口，然后启动一个执行环境，从socket中读取数据，split成单个单词的流，并按单词进行总和的计数，最后打印出来。这个例子相信接触过大数据计算或者函数式编程的人都能看懂，就不过多解释了。

 

1.1 flink执行环境

程序的启动，从这句开始：final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment()。 
这行代码会返回一个可用的执行环境。执行环境是整个flink程序执行的上下文，记录了相关配置（如并行度等），并提供了一系列方法，如读取输入流的方法，以及真正开始运行整个代码的execute方法等。对于分布式流处理程序来说，我们在代码中定义的flatMap,keyBy等等操作，事实上可以理解为一种声明，告诉整个程序我们采用了什么样的算子，而真正开启计算的代码不在此处。由于我们是在本地运行flink程序，因此这行代码会返回一个LocalStreamEnvironment，最后我们要调用它的execute方法来开启真正的任务。我们先接着往下看。

 

1.2 算子（Operator）的注册（声明）

我们以flatMap为例,text.flatMap(new LineSplitter())这一句话跟踪进去是这样的：

public  SingleOutputStreamOperator flatMap(FlatMapFunction flatMapper) {

        TypeInformation outType = TypeExtractor.getFlatMapReturnTypes(clean(flatMapper),
                getType(), Utils.getCallLocationName(), true);

        return transform("Flat Map", outType, new StreamFlatMap<>(clean(flatMapper)));

    }

 

里面完成了两件事，一是用反射拿到了flatMap算子的输出类型，二是生成了一个Operator。flink流式计算的核心概念，就是将数据从输入流一个个传递给Operator进行链式处理，最后交给输出流的过程。对数据的每一次处理在逻辑上成为一个operator，并且为了本地化处理的效率起见，operator之间也可以串成一个chain一起处理（可以参考责任链模式帮助理解）。下面这张图表明了flink是如何看待用户的处理流程的：抽象化为一系列operator，以source开始，以sink结尾，中间的operator做的操作叫做transform，并且可以把几个操作串在一起执行。 
 
我们也可以更改flink的设置，要求它不要对某个操作进行chain处理，或者从某个操作开启一个新chain等。 
上面代码中的最后一行transform方法的作用是返回一个SingleOutputStreamOperator，它继承了Datastream类并且定义了一些辅助方法，方便对流的操作。在返回之前，transform方法还把它注册到了执行环境中（后面生成执行图的时候还会用到它）。其他的操作，包括keyBy，sum和print，都只是不同的算子，在这里出现都是一样的效果，即生成一个operator并注册给执行环境用于生成DAG。

 

1.3 程序的执行

程序执行即env.execute("Java WordCount from SocketTextStream Example")这行代码。

 

1.3.1 本地模式下的execute方法

这行代码主要做了以下事情：

• 生成StreamGraph。代表程序的拓扑结构，是从用户代码直接生成的图。
• 生成JobGraph。这个图是要交给flink去生成task的图。
• 生成一系列配置
• 将JobGraph和配置交给flink集群去运行。如果不是本地运行的话，还会把jar文件通过网络发给其他节点。
• 以本地模式运行的话，可以看到启动过程，如启动性能度量、web模块、JobManager、ResourceManager、taskManager等等
• 启动任务。值得一提的是在启动任务之前，先启动了一个用户类加载器，这个类加载器可以用来做一些在运行时动态加载类的工作。

 

1.3.2 远程模式（RemoteEnvironment）的execute方法

远程模式的程序执行更加有趣一点。第一步仍然是获取StreamGraph，然后调用executeRemotely方法进行远程执行。 
该方法首先创建一个用户代码加载器

ClassLoader usercodeClassLoader = JobWithJars.buildUserCodeClassLoader(jarFiles, globalClasspaths,   getClass().getClassLoader());

 

然后创建一系列配置，交给Client对象。Client这个词有意思，看见它就知道这里绝对是跟远程集群打交道的客户端。

        ClusterClient client;

        try {
            client = new StandaloneClusterClient(configuration);
            client.setPrintStatusDuringExecution(getConfig().isSysoutLoggingEnabled());
        }
        }
        try {
            return client.run(streamGraph, jarFiles, globalClasspaths, usercodeClassLoader).getJobExecutionResult();
        }

 

client的run方法首先生成一个JobGraph，然后将其传递给JobClient。关于Client、JobClient、JobManager到底谁管谁，可以看这张图： 
 
确切的说，JobClient负责以异步的方式和JobManager通信（Actor是scala的异步模块），具体的通信任务由JobClientActor完成。相对应的，JobManager的通信任务也由一个Actor完成。

        JobListeningContext jobListeningContext = submitJob(
                actorSystem,config,highAvailabilityServices,jobGraph,timeout,sysoutLogUpdates,    classLoader);

        return awaitJobResult(jobListeningContext);

 

可以看到，该方法阻塞在awaitJobResult方法上，并最终返回了一个JobListeningContext，透过这个Context可以得到程序运行的状态和结果。

 

1.3.3 程序启动过程

上面提到，整个程序真正意义上开始执行，是这里：

 

1. env.execute("Java WordCount from SocketTextStream Example");

远程模式和本地模式有一点不同，我们先按本地模式来调试。 
我们跟进源码，（在本地调试模式下）会启动一个miniCluster，然后开始执行代码：

// LocalStreamEnvironment.java

    @Override
    public JobExecutionResult execute(String jobName) throws Exception {
        
        //生成各种图结构
        ......

        try {
            //启动集群，包括启动JobMaster，进行leader选举等等
            miniCluster.start();
            configuration.setInteger(RestOptions.PORT, miniCluster.getRestAddress().getPort());
            
            //提交任务到JobMaster
            return miniCluster.executeJobBlocking(jobGraph);
        }
        finally {
            transformations.clear();
            miniCluster.close();
        }
    }

 

这个方法里有一部分逻辑是与生成图结构相关的，我们放在第二章里讲；现在我们先接着往里跟：

//MiniCluster.java
public JobExecutionResult executeJobBlocking(JobGraph job) throws JobExecutionException, InterruptedException {
        checkNotNull(job, "job is null");
        
        //在这里，最终把job提交给了jobMaster
        final CompletableFuture submissionFuture = submitJob(job);

        final CompletableFuture jobResultFuture = submissionFuture.thenCompose(
            (JobSubmissionResult ignored) -> requestJobResult(job.getJobID()));

    ......
    
    }

 

正如我在注释里写的，这一段代码核心逻辑就是调用那个submitJob方法。那么我们再接着看这个方法：

    public CompletableFuture submitJob(JobGraph jobGraph) {
        final DispatcherGateway dispatcherGateway;
        try {
            dispatcherGateway = getDispatcherGateway();
        } catch (LeaderRetrievalException | InterruptedException e) {
            ExceptionUtils.checkInterrupted(e);
            return FutureUtils.completedExceptionally(e);
        }

        // we have to allow queued scheduling in Flip-6 mode because we need to request slots
        // from the ResourceManager
        jobGraph.setAllowQueuedScheduling(true);

        final CompletableFuture jarUploadFuture = uploadAndSetJarFiles(dispatcherGateway, jobGraph);

        final CompletableFuture acknowledgeCompletableFuture = jarUploadFuture.thenCompose(
        
        //在这里执行了真正的submit操作
            (Void ack) -> dispatcherGateway.submitJob(jobGraph, rpcTimeout));

        return acknowledgeCompletableFuture.thenApply(
            (Acknowledge ignored) -> new JobSubmissionResult(jobGraph.getJobID()));
    }

 

这里的Dispatcher是一个接收job，然后指派JobMaster去启动任务的类,我们可以看看它的类结构，有两个实现。在本地环境下启动的是MiniDispatcher，在集群上提交任务时，集群上启动的是StandaloneDispatcher。 

那么这个Dispatcher又做了什么呢？它启动了一个JobManagerRunner（这里我要吐槽Flink的命名，这个东西应该叫做JobMasterRunner才对，flink里的JobMaster和JobManager不是一个东西），委托JobManagerRunner去启动该Job的JobMaster。我们看一下对应的代码：

//jobManagerRunner.java
    private void verifyJobSchedulingStatusAndStartJobManager(UUID leaderSessionId) throws Exception {

        ......

        final CompletableFuture startFuture = jobMaster.start(new JobMasterId(leaderSessionId), rpcTimeout);

        ......
    }

 

然后，JobMaster经过了一堆方法嵌套之后，执行到了这里：

    private void scheduleExecutionGraph() {
        checkState(jobStatusListener == null);
        // register self as job status change listener
        jobStatusListener = new JobManagerJobStatusListener();
        executionGraph.registerJobStatusListener(jobStatusListener);

        try {
            //这里调用了ExecutionGraph的启动方法
            executionGraph.scheduleForExecution();
        }
        catch (Throwable t) {
            executionGraph.failGlobal(t);
        }
    }

 

我们知道，flink的框架里有三层图结构，其中ExecutionGraph就是真正被执行的那一层，所以到这里为止，一个任务从提交到真正执行的流程就走完了，我们再回顾一下（顺便提一下远程提交时的流程区别）：

• 客户端代码的execute方法执行；
• 本地环境下，MiniCluster完成了大部分任务，直接把任务委派给了MiniDispatcher；
• 远程环境下，启动了一个RestClusterClient，这个类会以HTTP Rest的方式把用户代码提交到集群上；
• 远程环境下，请求发到集群上之后，必然有个handler去处理，在这里是JobSubmitHandler。这个类接手了请求后，委派StandaloneDispatcher启动job，到这里之后，本地提交和远程提交的逻辑往后又统一了；
• Dispatcher接手job之后，会实例化一个JobManagerRunner，然后用这个runner启动job；
• JobManagerRunner接下来把job交给了JobMaster去处理；
• JobMaster使用ExecutionGraph的方法启动了整个执行图；整个任务就启动起来了。

至此，第一部分就讲完了。

 

2.理解flink的图结构

第一部分讲到，我们的主函数最后一项任务就是生成StreamGraph，然后生成JobGraph，然后以此开始调度任务运行，所以接下来我们从这里入手，继续探索flink。

 

2.1 flink的三层图结构

事实上，flink总共提供了三种图的抽象，我们前面已经提到了StreamGraph和JobGraph，还有一种是ExecutionGraph，是用于调度的基本数据结构。 
 
上面这张图清晰的给出了flink各个图的工作原理和转换过程。其中最后一个物理执行图并非flink的数据结构，而是程序开始执行后，各个task分布在不同的节点上，所形成的物理上的关系表示。

• 从JobGraph的图里可以看到，数据从上一个operator流到下一个operator的过程中，上游作为生产者提供了IntermediateDataSet，而下游作为消费者需要JobEdge。事实上，JobEdge是一个通信管道，连接了上游生产的dataset和下游的JobVertex节点。
• 在JobGraph转换到ExecutionGraph的过程中，主要发生了以下转变： 
  • 加入了并行度的概念，成为真正可调度的图结构
  • 生成了与JobVertex对应的ExecutionJobVertex，ExecutionVertex，与IntermediateDataSet对应的IntermediateResult和IntermediateResultPartition等，并行将通过这些类实现
• ExecutionGraph已经可以用于调度任务。我们可以看到，flink根据该图生成了一一对应的Task，每个task对应一个ExecutionGraph的一个Execution。Task用InputGate、InputChannel和ResultPartition对应了上面图中的IntermediateResult和ExecutionEdge。

那么，flink抽象出这三层图结构，四层执行逻辑的意义是什么呢？ 
StreamGraph是对用户逻辑的映射。JobGraph在此基础上进行了一些优化，比如把一部分操作串成chain以提高效率。ExecutionGraph是为了调度存在的，加入了并行处理的概念。而在此基础上真正执行的是Task及其相关结构。

 

2.2 StreamGraph的生成

在第一节的算子注册部分，我们可以看到，flink把每一个算子transform成一个对流的转换（比如上文中返回的SingleOutputStreamOperator是一个DataStream的子类），并且注册到执行环境中，用于生成StreamGraph。实际生成StreamGraph的入口是StreamGraphGenerator.generate(env, transformations) 其中的transformations是一个list，里面记录的就是我们在transform方法中放进来的算子。

 

2.2.1 StreamTransformation类代表了流的转换

StreamTransformation代表了从一个或多个DataStream生成新DataStream的操作。顺便，DataStream类在内部组合了一个StreamTransformation类，实际的转换操作均通过该类完成。 
 
我们可以看到，从source到各种map,union再到sink操作全部被映射成了StreamTransformation。 
其映射过程如下所示： 

以MapFunction为例：

• 首先，用户代码里定义的UDF会被当作其基类对待，然后交给StreamMap这个operator做进一步包装。事实上，每一个Transformation都对应了一个StreamOperator。
• 由于map这个操作只接受一个输入，所以再被进一步包装为OneInputTransformation。

• 最后，将该transformation注册到执行环境中，当执行上文提到的generate方法时，生成StreamGraph图结构。

  另外，并不是每一个 StreamTransformation 都会转换成runtime层中的物理操作。有一些只是逻辑概念，比如union、split/select、partition等。如下图所示的转换树，在运行时会优化成下方的操作图。 
  

 

2.2.2 StreamGraph生成函数分析

我们从StreamGraphGenerator.generate()方法往下看：

    public static StreamGraph generate(StreamExecutionEnvironment env, List> transformations) {
        return new StreamGraphGenerator(env).generateInternal(transformations);
    }
    
    //注意，StreamGraph的生成是从sink开始的
    private StreamGraph generateInternal(List> transformations) {
        for (StreamTransformation transformation: transformations) {
            transform(transformation);
        }
        return streamGraph;
    }
    
    //这个方法的核心逻辑就是判断传入的steamOperator是哪种类型，并执行相应的操作，详情见下面那一大堆if-else
    private Collection transform(StreamTransformation transform) {

        if (alreadyTransformed.containsKey(transform)) {
            return alreadyTransformed.get(transform);
        }

        LOG.debug("Transforming " + transform);

        if (transform.getMaxParallelism() <= 0) {

            // if the max parallelism hasn't been set, then first use the job wide max parallelism
            // from theExecutionConfig.
            int globalMaxParallelismFromConfig = env.getConfig().getMaxParallelism();
            if (globalMaxParallelismFromConfig > 0) {
                transform.setMaxParallelism(globalMaxParallelismFromConfig);
            }
        }

        // call at least once to trigger exceptions about MissingTypeInfo
        transform.getOutputType();

        Collection transformedIds;
        //这里对操作符的类型进行判断，并以此调用相应的处理逻辑.简而言之，处理的核心无非是递归的将该节点和节点的上游节点加入图
        if (transform instanceof OneInputTransformation) {
            transformedIds = transformOneInputTransform((OneInputTransformation) transform);
        } else if (transform instanceof TwoInputTransformation) {
            transformedIds = transformTwoInputTransform((TwoInputTransformation) transform);
        } else if (transform instanceof SourceTransformation) {
            transformedIds = transformSource((SourceTransformation) transform);
        } else if (transform instanceof SinkTransformation) {
            transformedIds = transformSink((SinkTransformation) transform);
        } else if (transform instanceof UnionTransformation) {
            transformedIds = transformUnion((UnionTransformation) transform);
        } else if (transform instanceof SplitTransformation) {
            transformedIds = transformSplit((SplitTransformation) transform);
        } else if (transform instanceof SelectTransformation) {
            transformedIds = transformSelect((SelectTransformation) transform);
        } else if (transform instanceof FeedbackTransformation) {
            transformedIds = transformFeedback((FeedbackTransformation) transform);
        } else if (transform instanceof CoFeedbackTransformation) {
            transformedIds = transformCoFeedback((CoFeedbackTransformation) transform);
        } else if (transform instanceof PartitionTransformation) {
            transformedIds = transformPartition((PartitionTransformation) transform);
        } else if (transform instanceof SideOutputTransformation) {
            transformedIds = transformSideOutput((SideOutputTransformation) transform);
        } else {
            throw new IllegalStateException("Unknown transformation: " + transform);
        }

        //注意这里和函数开始时的方法相对应，在有向图中要注意避免循环的产生
        // need this check because the iterate transformation adds itself before
        // transforming the feedback edges
        if (!alreadyTransformed.containsKey(transform)) {
            alreadyTransformed.put(transform, transformedIds);
        }

        if (transform.getBufferTimeout() > 0) {
            streamGraph.setBufferTimeout(transform.getId(), transform.getBufferTimeout());
        }
        if (transform.getUid() != null) {
            streamGraph.setTransformationUID(transform.getId(), transform.getUid());
        }
        if (transform.getUserProvidedNodeHash() != null) {
            streamGraph.setTransformationUserHash(transform.getId(), transform.getUserProvidedNodeHash());
        }

        if (transform.getMinResources() != null && transform.getPreferredResources() != null) {
            streamGraph.setResources(transform.getId(), transform.getMinResources(), transform.getPreferredResources());
        }

        return transformedIds;
    }

 

因为map，filter等常用操作都是OneInputStreamOperator,我们就来看看transformOneInputTransform((OneInputTransformation) transform)方法。

private  Collection transformOneInputTransform(OneInputTransformation transform) {

        Collection inputIds = transform(transform.getInput());

        // 在递归处理节点过程中，某个节点可能已经被其他子节点先处理过了，需要跳过
        if (alreadyTransformed.containsKey(transform)) {
            return alreadyTransformed.get(transform);
        }

        //这里是获取slotSharingGroup。这个group用来定义当前我们在处理的这个操作符可以跟什么操作符chain到一个slot里进行操作
        //因为有时候我们可能不满意flink替我们做的chain聚合
        //一个slot就是一个执行task的基本容器
        String slotSharingGroup = determineSlotSharingGroup(transform.getSlotSharingGroup(), inputIds);

        //把该operator加入图
        streamGraph.addOperator(transform.getId(),
                slotSharingGroup,
                transform.getOperator(),
                transform.getInputType(),
                transform.getOutputType(),
                transform.getName());
        
        //对于keyedStream，我们还要记录它的keySelector方法
        //flink并不真正为每个keyedStream保存一个key，而是每次需要用到key的时候都使用keySelector方法进行计算
        //因此，我们自定义的keySelector方法需要保证幂等性
        //到后面介绍keyGroup的时候我们还会再次提到这一点
        if (transform.getStateKeySelector() != null) {
            TypeSerializer keySerializer = transform.getStateKeyType().createSerializer(env.getConfig());
            streamGraph.setOneInputStateKey(transform.getId(), transform.getStateKeySelector(), keySerializer);
        }

        streamGraph.setParallelism(transform.getId(), transform.getParallelism());
        streamGraph.setMaxParallelism(transform.getId(), transform.getMaxParallelism());
        
        //为当前节点和它的依赖节点建立边
        //这里可以看到之前提到的select union partition等逻辑节点被合并入edge的过程
        for (Integer inputId: inputIds) {
            streamGraph.addEdge(inputId, transform.getId(), 0);
        }

        return Collections.singleton(transform.getId());
    }
    
    public void addEdge(Integer upStreamVertexID, Integer downStreamVertexID, int typeNumber) {
        addEdgeInternal(upStreamVertexID,
                downStreamVertexID,
                typeNumber,
                null,
                new ArrayList(),
                null);

    }
    //addEdge的实现，会合并一些逻辑节点
    private void addEdgeInternal(Integer upStreamVertexID,
            Integer downStreamVertexID,
            int typeNumber,
            StreamPartitioner partitioner,
            List outputNames,
            OutputTag outputTag) {
        //如果输入边是侧输出节点，则把side的输入边作为本节点的输入边，并递归调用
        if (virtualSideOutputNodes.containsKey(upStreamVertexID)) {
            int virtualId = upStreamVertexID;
            upStreamVertexID = virtualSideOutputNodes.get(virtualId).f0;
            if (outputTag == null) {
                outputTag = virtualSideOutputNodes.get(virtualId).f1;
            }
            addEdgeInternal(upStreamVertexID, downStreamVertexID, typeNumber, partitioner, null, outputTag);
            //如果输入边是select，则把select的输入边作为本节点的输入边
        } else if (virtualSelectNodes.containsKey(upStreamVertexID)) {
            int virtualId = upStreamVertexID;
            upStreamVertexID = virtualSelectNodes.get(virtualId).f0;
            if (outputNames.isEmpty()) {
                // selections that happen downstream override earlier selections
                outputNames = virtualSelectNodes.get(virtualId).f1;
            }
            addEdgeInternal(upStreamVertexID, downStreamVertexID, typeNumber, partitioner, outputNames, outputTag);
            //如果是partition节点
        } else if (virtualPartitionNodes.containsKey(upStreamVertexID)) {
            int virtualId = upStreamVertexID;
            upStreamVertexID = virtualPartitionNodes.get(virtualId).f0;
            if (partitioner == null) {
                partitioner = virtualPartitionNodes.get(virtualId).f1;
            }
            addEdgeInternal(upStreamVertexID, downStreamVertexID, typeNumber, partitioner, outputNames, outputTag);
        } else {
        //正常的edge处理逻辑
            StreamNode upstreamNode = getStreamNode(upStreamVertexID);
            StreamNode downstreamNode = getStreamNode(downStreamVertexID);

            // If no partitioner was specified and the parallelism of upstream and downstream
            // operator matches use forward partitioning, use rebalance otherwise.
            if (partitioner == null && upstreamNode.getParallelism() == downstreamNode.getParallelism()) {
                partitioner = new ForwardPartitioner