SparkSQL并行执行多个Job的探索

先来看个现象，下图中一个sql任务居然有多个job并行跑，为什么呢？

不错看到这里是不是有很多疑问，下面我就带着这些疑问，从以下几方面一一解答。

1. 看看Spark的调度框架是否支持并行提交多个job(引用了些其他博主的内容)
2. 讲解SparkSQL的ThriftServer入口，为后面SQL并行提交Job做铺垫
3. 讲解在非自适应与自适应情况下SQL的并行提交Job的机制（原创）

1 并行提交多个job

1.1 是否支持并行提交多个任务

此章节为转载，其余部分为原创

df.write.partitionBy("type", "interval").mode("append").parquet("s3://data")

• 通过partitionBy功能让Spark自动做将数据写入不同的分区路径。
• 对于一个Spark Job，我们总是期望能充分利用所有的cpu-vcore来并行执行，因此通常会将数据repartition成cpu-vcore的个数，即每个cpu-vcore上跑一个Task。而对于写文件的Job，每个Task会写入到自己的一个文件中，最终生成的文件数是由Task个数决定。在下图中，假设集群总共有12个cpu-vcore分配给Executor使用，那么就会有12个Task并行执行写入，最终生成12个文件。
  
• 从充分利用资源的角度来看，这样的设计无疑是最佳的。但是，对于一些实时流处理任务或者周期性的离线任务而言，这样做会产生大量的小文件，会给后续的文件加载和快速查询带来困难。因此，从尽可能产生少量文件的角度出发，需要采用下图所示的写入方式，即在写入前，将数据分配到少量的Partition中，用少量的Task来执行。但是，这样做就会导致有部分cpu-vcore在写入过程中处于闲置状态，造成了资源浪费。

• 显然，在这件事情上，“充分利用资源”和“产生少量文件”两个方向发生了冲突。那么，有没有一个两全之策呢？即既保证产生少量文件，又能把原本闲置的资源利用起来。如下图所示，假设我们能***同时跑多个写入文件的Job，每个Job利用一部分cpu-vcore来执行***，似乎就可以达到这个目的了。带着这样的思路，做一番调研与实践。

• 上述思路可以总结为：通过一个SparkContex并行提交多个Job，由Spark自己来调度资源，实现并行执行。针对这个思路，首先要搞清楚Spark是否支持这么玩，如果支持的话又是怎么支持的。
• 简单梳理下Spark的任务调度机制：

1. SparkContext向DAGScheduler提交一个Job后，会创建一个JobWaiter对象，用于阻塞当前线程，等待Job的执行结果。因此，在一个线程中，Job是顺序执行的。
2. DAGScheduler会根据RDD的依赖关系将一个Job划分为若干个Stage（以Shuffle为界）。因为前后Stage存在数据上的依赖，所以只有父Stage执行完毕才能提交当前Stage。
3. DAGScheduler在提交Stage时，会根据Partition信息生成相应的Task，打包成TaskSet，提交给TaskScheduler。而TaskScheduler收到后，会将TaskSet封装成TaskSetManager，丢到任务队列中等待执行。
4. SchedulerBackend负责Executor状态与资源的管理，当发现有空闲资源时，就会通过TaskScheduler从任务队列中取出相应的TaskSetManager去调度执行。
5. TaskSetManager中的Task最终会分发到Executor中的线程里去执行。
   

• Spark是以TaskSetManager为单元来调度任务的。通常情况下，任务队列中只会有一个TaskSetManager，而通过多线程提交多个Job时，则会有多个TaskSetManager被丢到任务队列中。在有空闲资源的情况下，谁会从队列里被取出来执行就取决于相应的调度策略了。目前，Spark支持FIFO和FAIR两种调度策略。
• 基本可以明确以下两点：

6. Spark支持通过多线程在一个SparkContext上提交多个Job，每个线程里面的Job是顺序执行的，但是不同线程的Job是可以并行执行的，取决当时Executor中是否有充足的cpu-vcore。
7. 任务队列中的TaskSetManager是有序执行，还是轮询执行（可分配权重）取决于采用哪种调度策略。
   可以用多线程方式并行提交Job，示例如下：

var df = spark.read.json("person.json").repartition(55)
// df