Flink – submitJob

Jobmanager的submitJob逻辑,

/**
   * Submits a job to the job manager. The job is registered at the libraryCacheManager which
   * creates the job's class loader. The job graph is appended to the corresponding execution
   * graph and the execution vertices are queued for scheduling.
   *
   * @param jobGraph representing the Flink job
   * @param jobInfo the job info
   * @param isRecovery Flag indicating whether this is a recovery or initial submission
   */
  private def submitJob(jobGraph: JobGraph, jobInfo: JobInfo, isRecovery: Boolean = false): Unit = {
    if (jobGraph == null) {
      jobInfo.notifyClients(
        decorateMessage(JobResultFailure(
          new SerializedThrowable(
            new JobSubmissionException(null, "JobGraph must not be null.")))))
    }
    else {
      val jobId = jobGraph.getJobID
      val jobName = jobGraph.getName
      var executionGraph: ExecutionGraph = null

      try {
        // Important: We need to make sure that the library registration is the first action,
        // because this makes sure that the uploaded jar files are removed in case of
        // unsuccessful
        try {
          libraryCacheManager.registerJob(jobGraph.getJobID, jobGraph.getUserJarBlobKeys,
            jobGraph.getClasspaths)
        }
        var userCodeLoader = libraryCacheManager.getClassLoader(jobGraph.getJobID) //加载Jar

        val restartStrategy = //加载重启策略
          Option(jobGraph.getSerializedExecutionConfig()
            .deserializeValue(userCodeLoader)
            .getRestartStrategy())
            .map(RestartStrategyFactory.createRestartStrategy)
            .filter(p => p != null) match {
            case Some(strategy) => strategy
            case None => restartStrategyFactory.createRestartStrategy()
          }

        val jobMetrics = jobManagerMetricGroup match { //生成job manager metric group
          case Some(group) =>
            group.addJob(jobGraph) match {
              case (jobGroup:Any) => jobGroup
              case null => new UnregisteredMetricsGroup()
            }
          case None =>
            new UnregisteredMetricsGroup()
        }

        val numSlots = scheduler.getTotalNumberOfSlots() //现有的slots数目

        // see if there already exists an ExecutionGraph for the corresponding job ID
        val registerNewGraph = currentJobs.get(jobGraph.getJobID) match {
          case Some((graph, currentJobInfo)) =>
            executionGraph = graph
            currentJobInfo.setLastActive()
            false
          case None =>
            true
        }

        executionGraph = ExecutionGraphBuilder.buildGraph( //build ExecutionGraph
          executionGraph,
          jobGraph,
          flinkConfiguration,
          futureExecutor,
          ioExecutor,
          userCodeLoader,
          checkpointRecoveryFactory,
          Time.of(timeout.length, timeout.unit),
          restartStrategy,
          jobMetrics,
          numSlots,
          log.logger)

        if (registerNewGraph) { //如果是新的JobGraph,注册到currentJobs
          currentJobs.put(jobGraph.getJobID, (executionGraph, jobInfo))
        }

        // get notified about job status changes
        executionGraph.registerJobStatusListener( //jobmananger加到通知listeners
          new StatusListenerMessenger(self, leaderSessionID.orNull))

        jobInfo.clients foreach { //client加到通知listeners
          // the sender wants to be notified about state changes
          case (client, ListeningBehaviour.EXECUTION_RESULT_AND_STATE_CHANGES) =>
            val listener  = new StatusListenerMessenger(client, leaderSessionID.orNull)
            executionGraph.registerExecutionListener(listener)
            executionGraph.registerJobStatusListener(listener)
          case _ => // do nothing
        }

      } catch { //失败
        case t: Throwable =>
          log.error(s"Failed to submit job $jobId ($jobName)", t)

          libraryCacheManager.unregisterJob(jobId)
          currentJobs.remove(jobId)

          if (executionGraph != null) {
            executionGraph.fail(t) //fail executionGraph
          }

          val rt: Throwable = if (t.isInstanceOf[JobExecutionException]) {
            t
          } else {
            new JobExecutionException(jobId, s"Failed to submit job $jobId ($jobName)", t)
          }

          jobInfo.notifyClients(
            decorateMessage(JobResultFailure(new SerializedThrowable(rt)))) //通知提交失败
          return
      }

      //上面是准备executionGraph,下面是异步提交
      // execute the recovery/writing the jobGraph into the SubmittedJobGraphStore asynchronously
      // because it is a blocking operation
      future {
        try {
          if (isRecovery) {
            // this is a recovery of a master failure (this master takes over)
            executionGraph.restoreLatestCheckpointedState(false, false) //加载checkpoint状态
          }
          else {
            // load a savepoint only if this is not starting from a newer checkpoint
            // as part of an master failure recovery
            val savepointSettings = jobGraph.getSavepointRestoreSettings
            if (savepointSettings.restoreSavepoint()) { //处理savePoint
              try {
                val savepointPath = savepointSettings.getRestorePath()
                val allowNonRestored = savepointSettings.allowNonRestoredState()

                log.info(s"Starting job from savepoint '$savepointPath'" +
                  (if (allowNonRestored) " (allowing non restored state)" else "") + ".")

                  // load the savepoint as a checkpoint into the system
                  val savepoint: CompletedCheckpoint = SavepointLoader.loadAndValidateSavepoint(
                    jobId,
                    executionGraph.getAllVertices,
                    savepointPath,
                    executionGraph.getUserClassLoader,
                    allowNonRestored)

                executionGraph.getCheckpointCoordinator.getCheckpointStore
                  .addCheckpoint(savepoint)

                // Reset the checkpoint ID counter
                val nextCheckpointId: Long = savepoint.getCheckpointID + 1
                log.info(s"Reset the checkpoint ID to $nextCheckpointId")
                executionGraph.getCheckpointCoordinator.getCheckpointIdCounter
                  .setCount(nextCheckpointId)

                executionGraph.restoreLatestCheckpointedState(true, allowNonRestored)
              } catch {
                case e: Exception =>
                  jobInfo.notifyClients(
                    decorateMessage(JobResultFailure(new SerializedThrowable(e))))
                  throw new SuppressRestartsException(e)
              }
            }

            try {
              submittedJobGraphs.putJobGraph(new SubmittedJobGraph(jobGraph, jobInfo)) //存储该JobGraph到zk,ZooKeeperSubmittedJobGraphStore
            } catch {
              case t: Throwable =>
                // Don't restart the execution if this fails. Otherwise, the
                // job graph will skip ZooKeeper in case of HA.
                jobInfo.notifyClients(
                  decorateMessage(JobResultFailure(new SerializedThrowable(t))))
                throw new SuppressRestartsException(t)
            }
          }

          jobInfo.notifyClients(
            decorateMessage(JobSubmitSuccess(jobGraph.getJobID))) //通知clients提交成功

          if (leaderElectionService.hasLeadership) {
            // There is a small chance that multiple job managers schedule the same job after if
            // they try to recover at the same time. This will eventually be noticed, but can not be
            // ruled out from the beginning.

            // NOTE: Scheduling the job for execution is a separate action from the job submission.
            // The success of submitting the job must be independent from the success of scheduling
            // the job.
            log.info(s"Scheduling job $jobId ($jobName).")

            executionGraph.scheduleForExecution(scheduler) //开始调度
          } else {
            // Remove the job graph. Otherwise it will be lingering around and possibly removed from
            // ZooKeeper by this JM.
            self ! decorateMessage(RemoveJob(jobId, removeJobFromStateBackend = false))

            log.warn(s"Submitted job $jobId, but not leader. The other leader needs to recover " +
              "this. I am not scheduling the job for execution.")
          }
        } catch {
          case t: Throwable => try {
            executionGraph.fail(t)
          } catch {
            case tt: Throwable =>
              log.error("Error while marking ExecutionGraph as failed.", tt)
          }
        }
      }(context.dispatcher)
    }
  }

可以看到executionGraph在调度前就已经通知用户提交成功

 

当job发生问题,需要调用到tryRestartOrFail

private boolean tryRestartOrFail() {
        JobStatus currentState = state;

        if (currentState == JobStatus.FAILING || currentState == JobStatus.RESTARTING) {
            synchronized (progressLock) { //锁

                final boolean isFailureCauseAllowingRestart = !(failureCause instanceof SuppressRestartsException);
                final boolean isRestartStrategyAllowingRestart = restartStrategy.canRestart(); //重启策略是否允许重启
                boolean isRestartable = isFailureCauseAllowingRestart && isRestartStrategyAllowingRestart;

                if (isRestartable && transitionState(currentState, JobStatus.RESTARTING)) {
                    restartStrategy.restart(this);

                    return true;
                } else if (!isRestartable && transitionState(currentState, JobStatus.FAILED, failureCause)) { //如果不允许重启,就failed
                    final List<String> reasonsForNoRestart = new ArrayList<>(2);
                    if (!isFailureCauseAllowingRestart) {
                        reasonsForNoRestart.add("a type of SuppressRestartsException was thrown");
                    }
                    if (!isRestartStrategyAllowingRestart) {
                        reasonsForNoRestart.add("the restart strategy prevented it");
                    }

                    LOG.info("Could not restart the job {} ({}) because {}.", getJobName(), getJobID(),
                        StringUtils.join(reasonsForNoRestart, " and "), failureCause);
                    postRunCleanup();

                    return true;
                } else {
                    // we must have changed the state concurrently, thus we cannot complete this operation
                    return false;
                }
            }
        } else {
            // this operation is only allowed in the state FAILING or RESTARTING
            return false;
        }
    }

 

有两处会调用到tryRestartOrFail

1. ExecutionGraph.jobVertexInFinalState

void jobVertexInFinalState() {
    synchronized (progressLock) {
        if (numFinishedJobVertices >= verticesInCreationOrder.size()) {
            throw new IllegalStateException("All vertices are already finished, cannot transition vertex to finished.");
        }

        numFinishedJobVertices++;

        if (numFinishedJobVertices == verticesInCreationOrder.size()) { //当所有的vertices都已经finished

            // we are done, transition to the final state
            JobStatus current;
            while (true) {
                current = this.state;

                if (current == JobStatus.RUNNING) {
                    if (transitionState(current, JobStatus.FINISHED)) {
                        postRunCleanup();
                        break;
                    }
                }
                else if (current == JobStatus.CANCELLING) {
                    if (transitionState(current, JobStatus.CANCELED)) {
                        postRunCleanup();
                        break;
                    }
                }
                else if (current == JobStatus.FAILING) {
                    if (tryRestartOrFail()) { //如果failing,调用tryRestartOrFail
                        break;
                    }
                    // concurrent job status change, let's check again
                }

2. 显式的调用到ExecutionGraph.fail

} else if (current == JobStatus.RESTARTING) {
    this.failureCause = t;

    if (tryRestartOrFail()) {
        return;
    }
    // concurrent job status change, let's check again
}

 

上面调用到restartStrategy.restart(this);

restartStrategy有很多种,我们先看看

FixedDelayRestartStrategy

 

@Override
    public void restart(final ExecutionGraph executionGraph) {
        currentRestartAttempt++;
        FlinkFuture.supplyAsync(ExecutionGraphRestarter.restartWithDelay(executionGraph, delayBetweenRestartAttempts), executionGraph.getFutureExecutor());
    }

异步的调用,ExecutionGraphRestarter.restartWithDelay

最终调用到

executionGraph.restart();

public void restart() {
        try {
            synchronized (progressLock) {
                this.currentExecutions.clear();

                Collection<CoLocationGroup> colGroups = new HashSet<>();

                for (ExecutionJobVertex jv : this.verticesInCreationOrder) {

                    CoLocationGroup cgroup = jv.getCoLocationGroup();
                    if(cgroup != null && !colGroups.contains(cgroup)){
                        cgroup.resetConstraints();
                        colGroups.add(cgroup);
                    }

                    jv.resetForNewExecution();
                }

                for (int i = 0; i < stateTimestamps.length; i++) {
                    if (i != JobStatus.RESTARTING.ordinal()) {
                        // Only clear the non restarting state in order to preserve when the job was
                        // restarted. This is needed for the restarting time gauge
                        stateTimestamps[i] = 0;
                    }
                }
                numFinishedJobVertices = 0;
                transitionState(JobStatus.RESTARTING, JobStatus.CREATED);

                // if we have checkpointed state, reload it into the executions
                if (checkpointCoordinator != null) {
                    checkpointCoordinator.restoreLatestCheckpointedState(getAllVertices(), false, false);
                }
            }

            scheduleForExecution(slotProvider); //加入schedule
        }
        catch (Throwable t) {
            LOG.warn("Failed to restart the job.", t);
            fail(t);
        }
    }

 

关于重启策略,

参考https://ci.apache.org/projects/flink/flink-docs-release-1.2/dev/restart_strategies.html

If checkpointing is not enabled, the “no restart” strategy is used. If checkpointing is activated and the restart strategy has not been configured, the fixed-delay strategy is used with Integer.MAX_VALUE restart attempts.

 

StreamingJobGraphGenerator

private void configureCheckpointing() {
        CheckpointConfig cfg = streamGraph.getCheckpointConfig();

        long interval = cfg.getCheckpointInterval();
        if (interval > 0) {
            // check if a restart strategy has been set, if not then set the FixedDelayRestartStrategy
            if (streamGraph.getExecutionConfig().getRestartStrategy() == null) {
                // if the user enabled checkpointing, the default number of exec retries is infinite.
                streamGraph.getExecutionConfig().setRestartStrategy(
                    RestartStrategies.fixedDelayRestart(Integer.MAX_VALUE, DEFAULT_RESTART_DELAY));
            }
        }

当打开checkpoint的时候,默认是使用fixedDelayRestart,并Integer.MAX_VALUE次重启

时间: 2024-08-31 12:07:05

Flink – submitJob的相关文章

Flink运行时之TaskManager执行Task

TaskManager执行任务 当一个任务被JobManager部署到TaskManager之后,它将会被执行.本篇我们将分析任务的执行细节. submitTask方法分析 一个任务实例被部署所产生的实际影响就是JobManager会将一个TaskDeploymentDescriptor对象封装在SubmitTask消息中发送给TaskManager.而处理该消息的入口方法是submitTask方法,它是TaskManager接收任务部署并启动任务执行的入口方法,值得我们关注一下它的实现细节.

Flink运行时之客户端提交作业图-上

客户端提交作业图 作业图(JobGraph)是Flink的运行时所能理解的作业表示,无论程序通过是DataStream还是DataSet API编写的,它们的JobGraph提交给JobManager以及之后的处理都将得到统一.本篇我们将分析客户端如何提交JobGraph给JobManager. 流处理程序提交作业图 在前面讲解Flink的核心概念的时候我们谈到了Flink利用了"惰性求值"的概念,只有当最终调用execute方法时,才会真正开始执行.因此,execute方法是我们的切

Flink原理与实现:如何生成ExecutionGraph及物理执行图

阅读本文之前,请先阅读Flink原理与实现系列前面的几篇文章 : Flink 原理与实现:架构和拓扑概览Flink 原理与实现:如何生成 StreamGraphFlink 原理与实现:如何生成 JobGraph ExecutionGraph生成过程 StreamGraph和JobGraph都是在client生成的,这篇文章将描述如何生成ExecutionGraph以及物理执行图.同时会讲解一个作业提交后如何被调度和执行. client生成JobGraph之后,就通过submitJob提交至Job

Flink - Checkpoint

Flink在流上最大的特点,就是引入全局snapshot,   CheckpointCoordinator 做snapshot的核心组件为, CheckpointCoordinator /** * The checkpoint coordinator coordinates the distributed snapshots of operators and state. * It triggers the checkpoint by sending the messages to the re

Flink - StreamJob

fxjwind Flink - StreamJob   先看最简单的例子, final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); DataStream<Tuple2<Long, Long>> stream = env.addSource(...); stream .map(new MapFunction<Integer, Integer>(

Flink 1.1 – ResourceManager

Flink resource manager的作用如图,   FlinkResourceManager /** * * <h1>Worker allocation steps</h1> * * <ol> * <li>The resource manager decides to request more workers. This can happen in order * to fill the initial pool, or as a result o

Flink运行时之生成作业图

生成作业图 在分析完了流处理程序生成的流图(StreamGraph)以及批处理程序生成的优化后的计划(OptimizedPlan)之后,下一步就是生成它们面向Flink运行时执行引擎的共同抽象--作业图(JobGraph). 什么是作业图 作业图(JobGraph)是唯一被Flink的数据流引擎所识别的表述作业的数据结构,也正是这一共同的抽象体现了流处理和批处理在运行时的统一. 相比流图(StreamGraph)以及批处理优化计划(OptimizedPlan),JobGraph发生了一些变化,已

阿里蒋晓伟谈流计算和批处理引擎Blink,以及Flink和Spark的异同与优势

首届阿里巴巴在线技术峰会(Alibaba Online Technology Summit),将于7月19日-21日 20:00-21:30 在线举办.本次峰会邀请到阿里集团9位技术大V,分享电商架构.安全.数据处理.数据库.多应用部署.互动技术.Docker持续交付与微服务等一线实战经验,解读最新技术在阿里集团的应用实践. 7月19日晚8点,阿里搜索事业部资深搜索专家蒋晓伟将在线分享<阿里流计算和批处理引擎Blink>,其基于Apache Flink项目并且在API和它上兼容,深度分享阿里为

Flink 原理与实现:内存管理

如今,大数据领域的开源框架(Hadoop,Spark,Storm)都使用的 JVM,当然也包括 Flink.基于 JVM 的数据分析引擎都需要面对将大量数据存到内存中,这就不得不面对 JVM 存在的几个问题: Java 对象存储密度低.一个只包含 boolean 属性的对象占用了16个字节内存:对象头占了8个,boolean 属性占了1个,对齐填充占了7个.而实际上只需要一个bit(1/8字节)就够了. Full GC 会极大地影响性能,尤其是为了处理更大数据而开了很大内存空间的JVM来说,GC