Hive on Spark源码分析（四）—— SparkClilent与SparkClientImpl（下）

Hive on Spark源码分析（一）—— SparkTask
Hive on Spark源码分析（二）—— SparkSession与HiveSparkClient
Hive on Spark源码分析（三）—— SparkClilent与SparkClientImpl（上）
Hive on Spark源码分析（四）—— SparkClilent与SparkClientImpl（下）
Hive on Spark源码分析（五）—— RemoteDriver
Hive on Spark源码分析（六）—— RemoteSparkJobMonitor与JobHandle 

SparkClientImpl提交任务的方法是submit方法，在HiveSparkClient中被调用，提交SparkSession需要提交的任务，其内部其实是调用了内部类ClientProtocol的submit方法：

  
  
  @Override
  public <T extends Serializable> JobHandle<T> submit(Job<T> job) {
    return protocol.submit(job);
  }

我们通过ClientProtocol的继承关系来看一下它到底是什么：

从图上可知，ClientProtocol是继承自io.netty.channel.SimpleChannelInboundHandler，它是负责底层的rpc通信与异步任务执行的，其中定义了submit、run、cancel、endSession这些job相关的方法，以及多个签名不同的handle方法，用以处理针对不同消息类型的rpc请求。

下面首先先看一下submit方法的实现，该方法负责提交SparkClient需要提交的任务，其中JobHandle可以认为是一个job的句柄，用来监控和控制一个正在运行的远程任务，会在后面的文章对JobHandle进行详细解析。

  
  
    <T extends Serializable> JobHandleImpl<T> submit(Job<T> job) {
      //利用java.utils.UUID产生一个jobId
      final String jobId = UUID.randomUUID().toString();
      //promise由EventLoopGroup分配线程进行执行，并封装在JobHandleImpl中,代理很多方法的实现.
      final Promise<T> promise = driverRpc.createPromise();
      //构造JobHandle
      final JobHandleImpl<T> handle = new JobHandleImpl<T>(SparkClientImpl.this, promise, jobId);
      jobs.put(jobId, handle);
      //将jobId和job封装成JobRequest类型的消息,交给driverRpc来发送,最终返回的也是一个promise对象保存异步执行结果
      final io.netty.util.concurrent.Future<Void> rpc = driverRpc.call(new JobRequest(jobId, job));
      LOG.debug("Send JobRequest[{}].", jobId);

这里我们先看一下driverRpc.call方法的实现，其实现实际是调用Rpc类中另一个call方法实现的。首先是检查msg是否为空以及channel是否建立好了

   
   
  public <T> Future<T> call(Object msg, Class<T> retType) {
    Preconditions.checkArgument(msg != null);
    Preconditions.checkState(channel.isActive(), "RPC channel is closed.");

然后为创建一个promise监控当前任务的执行，并产生一个id，通过RpcDispatcher的registerRpc方法进行注册。注册过程就是讲id和promise封装成OutstandingRpc对象添加到rpcs集合中，至于这个集合的作用会在以后分析

    
    
    try {
      final long id = rpcId.getAndIncrement();
      final Promise<T> promise = createPromise();
      //注册client
      dispatcher.registerRpc(id, promise, msg.getClass().getName());

最后一步是将消息msg和消息头MessageHeader写入channel后flush，并未写入操作和flush操作注册监听器。最后返回promise。需要注意的一点是，channel flush后代表消息成功发送到了RemoteDriver端，由RemoteDriver端的driverProtocol处理（在第五篇文章中会讲到），只有 当clientProtocol收到driverProtocol返回的REPLY消息时,rpc(promise)才会被标记为success

    
    
      synchronized (channelLock) {
        //write和writeAndFlush都会返回ChannelFuture,如果
        //id和message的类型封装为消息头MessageHeader,这里消息的类型为CALL
        channel.write(new MessageHeader(id, Rpc.MessageType.CALL)).addListener(listener);
        channel.writeAndFlush(msg).addListener(listener);
      }
      return promise;
    } catch (Exception e) {
      throw Throwables.propagate(e);
    }
  }

其中监听器的定义如下：

     
     
      ChannelFutureListener listener = new ChannelFutureListener() {
          @Override
          public void operationComplete(ChannelFuture cf) {
            //isDone:任务因为正常终止,异常或者取消都会返回true(即只要是非运行状态)
            if (!cf.isSuccess() && !promise.isDone()) {
              LOG.warn("Failed to send RPC, closing connection.", cf.cause());
              promise.setFailure(cf.cause());
              dispatcher.discardRpc(id);
              close();
            }
          }
      };

下面回到SparkClientImpl。接下来先给rpc对象（Promise类型）添加监听器，覆盖operationComplete方法，当rpc执行结束时，如果状态为success，则将job的state变为QUEUED；否则标记rpc执行失败。

   
   
      rpc.addListener(new GenericFutureListener<io.netty.util.concurrent.Future<Void>>() {
        @Override
        public void operationComplete(io.netty.util.concurrent.Future<Void> f) {
          //如果rpc sent成功,jobHandle的状态从sent改为queued
          if (f.isSuccess()) {
            handle.changeState(JobHandle.State.QUEUED);
          } else if (!promise.isDone()) {
            promise.setFailure(f.cause());
          }
        }
      });

再给createPromise返回的promise对象添加监听器，覆盖 operationComplete方法，当promise执行结束时，从job列表中移除相应的job；如果promise被取消，但rpc还没有执行结束，则取消rpc的执行。最后返回job handle

    
    
      promise.addListener(new GenericFutureListener<Promise<T>>() {
        @Override
        public void operationComplete(Promise<T> p) {
          if (jobId != null) {
            //从任务列表里移除这个job
            jobs.remove(jobId);
          }
          if (p.isCancelled() && !rpc.isDone()) {
            rpc.cancel(true);
          }
        }
      });
      return handle;

从上面实现我们可以看出，所谓提交任务最终其实就是基于rpc向远程的rpc发送一个消息。同样地，run、cancel和endSession这几个方法，也是通过调用driverRpc来发送消息，只不过消息类型不同，具体如下：

    
    
    <T extends Serializable> Future<T> run(Job<T> job) {
      @SuppressWarnings("unchecked")
      final io.netty.util.concurrent.Future<T> rpc = (io.netty.util.concurrent.Future<T>)
        //将job封装成SyncJobRequest发送
        driverRpc.call(new SyncJobRequest(job), Serializable.class);
      return rpc;
    }
    void cancel(String jobId) {
      //将jobId封装成CancelJob发送
      driverRpc.call(new CancelJob(jobId));
    }
    Future<?> endSession() {
      //直接发送EndSession消息
      return driverRpc.call(new EndSession());
    }

这些消息类型定义在ClientProtocol的直接基类BaseProtocol中：

    
    
//在RpcDispatcher基础上定义了一系列内部类,代表不同的消息类型(或不同的事件 请求)
abstract class BaseProtocol extends RpcDispatcher {
  protected static class CancelJob implements Serializable {...}
  protected static class EndSession implements Serializable {...}
  protected static class Error implements Serializable {...}
  protected static class JobMetrics implements Serializable {...}
  protected static class JobRequest<T extends Serializable> implements Serializable {...}
  protected static class JobResult<T extends Serializable> implements Serializable {...}
  protected static class JobStarted implements Serializable {..}
  /**
   * Inform the client that a new spark job has been submitted for the client job.
   */
  protected static class JobSubmitted implements Serializable {...}
  protected static class SyncJobRequest<T extends Serializable> implements Serializable {
    final Job<T> job;
    SyncJobRequest(Job<T> job) {
      this.job = job;
    }
    SyncJobRequest() {
      this(null);
    }
  }

其中：

CancelJob只封装了jobId，因为只需要根据一个jobId就可以将相应的jobcancel掉

EndSession为空信息

Error中封装了异常信息cause

JobMetrics中封装了jobId，SparkJobId，stageId，taskId和metrics

JobResult中封装了结果id，结果result，error以及sparkCounter

JobStarted只封装了一个id

JobSubmitted封装了clientJobId和sparkJobId

SyncJobRequest、JobRequest都是对Job的封装，只不过 JobRequest添加了jobId，两种消息在使用时用来封装不同类型的job。

SyncJobRequest仅用来封装SparkClientImpl中定义的几种可以快速执行的任务，具体如下：

     
     
  //添加jar包
  private static class AddJarJob implements Job<Serializable> {...}
  //添加文件
  private static class AddFileJob implements Job<Serializable> {...}
  //获得spark executor数
  private static class GetExecutorCountJob implements Job<Integer> {...}
  //获得spark.default.parallelism
  private static class GetDefaultParallelismJob implements Job<Integer> {...}

最后，SparkClientImpl中还定义了多个签名不同的handle方法，形式如下：

     
     
    private void handle(ChannelHandlerContext ctx, Error msg) {...}
    private void handle(ChannelHandlerContext ctx, JobMetrics msg) {...}
    private void handle(ChannelHandlerContext ctx, JobResult msg) {...}
    private void handle(ChannelHandlerContext ctx, JobStarted msg) {...}
    private void handle(ChannelHandlerContext ctx, JobSubmitted msg) {...}

那么这些方法在什么时候被调用呢？根据前面的继承关系图我们知道，ClientProtocol实际是一个netty中的handler角色，在父类RpcDispatcher的定义中覆盖了SimpleChannelInboundHandler中的channelread0方法。该方法是在收到消息时自动被调用（或者pipeline中前面的handler处理完了，将结果传递到当前handler），我们来看一下 RpcDispatcher中 channelread0方法的具体实现。

该方法的主要内容就是根据收到的消息的消息头（MessageHeader）来判断消息类型，根据不同类型使用不同的方法来处理：

     
     
  @Override
  protected final void channelRead0(ChannelHandlerContext ctx, Object msg) throws Exception {
    if (lastHeader == null) {
      if (!(msg instanceof Rpc.MessageHeader)) {
        LOG.warn("[{}] Expected RPC header, got {} instead.", name(),
            msg != null ? msg.getClass().getName() : null);
        throw new IllegalArgumentException();
      }
      lastHeader = (Rpc.MessageHeader) msg;
    } else {
      //log debug enable is needed
      LOG.debug("[{}] Received RPC message: type={} id={} payload={}", name(),
        lastHeader.type, lastHeader.id, msg != null ? msg.getClass().getName() : null);
      try {
        switch (lastHeader.type) {
        case CALL:
          handleCall(ctx, msg);
          break;
        case REPLY:
          handleReply(ctx, msg, findRpc(lastHeader.id));
          break;
        case ERROR:
          handleError(ctx, msg, findRpc(lastHeader.id));
          break;
        default:
          throw new IllegalArgumentException("Unknown RPC message type: " + lastHeader.type);
        }
      } finally {
        lastHeader = null;
      }
    }
  }

如果messageHeader的类型为REPLY，则根据header中的id找到对应的future，标记为成功并返回，从列表删除future；如果类型为ERROR，则根据header中的id找到相应的future，标记为失败并返回，从列表删除future。

这里重点看一下header类型为CALL的消息的处理。该类型消息由handleCall方法处理，首先查看handlers列表中是否有处理msg类型消息的handler，如果有直接获得；如果没有，则通过反射机制，找到对应类型的已声明的方法，添加到handler列表

     
     
  private void handleCall(ChannelHandlerContext ctx, Object msg) throws Exception {
    //得到相应的handle方法
    Method handler = handlers.get(msg.getClass());
    if (handler == null) {
      handler = getClass().getDeclaredMethod("handle", ChannelHandlerContext.class,
          msg.getClass());
      handler.setAccessible(true);
      handlers.put(msg.getClass(), handler);
    }

然后通过反射机制调用handler方法，如果返回结果不为null，则将返回消息类型置为REPLY（另一端收到后则会调用handleReply方法处理），否则为NullMessage，然后将结果header id 和reply type封装成MessageHeader写入channel，再写入返回结果后flush

      
      
    Rpc.MessageType replyType;
    Object replyPayload;
    try {
      replyPayload = handler.invoke(this, ctx, msg);
      if (replyPayload == null) {
        replyPayload = new Rpc.NullMessage();
      }
      replyType = Rpc.MessageType.REPLY;
    } catch (InvocationTargetException ite) {
      LOG.debug(String.format("[%s] Error in RPC handler.", name()), ite.getCause());
      replyPayload = Throwables.getStackTraceAsString(ite.getCause());
      replyType = Rpc.MessageType.ERROR;
    }
    ctx.channel().write(new Rpc.MessageHeader(lastHeader.id, replyType));
    ctx.channel().writeAndFlush(replyPayload);
  }

如果msg类型为JobResult，那么调用的handler方法则为handle(ChannelHandlerContext ctx, JobResult msg)。

这样我们就知道不同类型的消息是怎样得到不同的handle方法处理的了。至于几个handle方法的具体实现，这里仅以ClientProtocol中的 handle(ChannelHandlerContext ctx, JobStarted msg)为例进行分析。

首先根据msg的id查看jobs列表张是否注册了相应jobHandle，如果有的话，则修改相应job的状态为started，否则输出warn信息

      
      
    private void handle(ChannelHandlerContext ctx, JobStarted msg) {
      JobHandleImpl<?> handle = jobs.get(msg.id);
      if (handle != null) {
        handle.changeState(JobHandle.State.STARTED);
      } else {
        LOG.warn("Received event for unknown job {}", msg.id);
      }
    }

简单总结SparkClient提交任务的过程，就是通过内部类ClientProtocol的submit方法，根据job的类型，封装成不同类型的消息（JobRequest、SyncJobRequest等），然后服务端rpc收到不同类型的消息后，会根据签名通过反射机制调用相应的handle函数来做不同的处理。