关于spark streaming中的任务有如下几个概念：
batch
job
stage
task
job的并行度复杂些，由两个配置决定：
spark.scheduler.mode(fifo/fair)
spark.streaming.concurrentjobs
我们知道一个batch可能会有多个action执行，比如你注册了多个kafka数据流，每个action都会产生一个job,所以一个batch有可能是一批job,也就是jobset的概念，这些job由jobexecutor依次提交执行,而jobexecutor是一个默认池子大小为1的线程池，所以只能执行完一个job再执行另外一个job。这里说的池子，他的大小就是由<b>spark.streaming.concurrentjobs </b>控制的。
concurrentjobs 其实决定了向spark core提交job的并行度。提交一个job，必须等这个执行完了，才会提交第二个。假设我们把它设置为2，则会并发的把job提交给spark core，spark 有自己的机制决定如何运行这两个job,这个机制其实就是fifo或者fair（决定了资源的分配规则）。默认是fifo,也就是先进先出，你把concurrentjobs设置为2，但是如果底层是fifo,那么会优先执行先提交的job,虽然如此，如果资源够两个job运行，还是会并行运行两个job。
我们搞个例子来论证下上面的结论：
<a href="https://github.com/allwefantasy/spark-ml-example/blob/master/src/main/java/exmaple/jobtest.scala" target="_blank"><b>源码github地址</b></a>
上面的testinputstream的签名如下：
所以testinputstream其实就是我mock的一个数据源，最后numpartitions表示的是分区数。这里，我们把concurrentjobs设置为2，意味着taskscheduler接受到了两个job,然后setmaster[local(2)]表示只可以并发执行两个task。
因为input,input1每个batch至少都有3个元素，每个元素需要运行5秒，所以有一个task需要运行两个元素，那么第一次input1需要运行10秒。input1在运行五秒后，空出了一个线程，这个时候input的job开始运行，到第十秒的时候，input1完成，input开始运行也已经完成一个元素的计算，这个时候启动另外两个元素运行。所以input1花了10秒，input花了15秒，但是因为input被延时了五秒才得以运行，所以input1其实相当于花了20秒。
这里你会好奇，为啥我先声明的input,接着再申明的input1,但是input1却先运行呢？因为这两个数据源对应的job是被并发提交的，有一定的随机性。如果你多启动几次，你会发现input对应job id有可能是0，也有可能是1。
还有两点值的注意的是：
job id的产生是在job提交的时候才产生，而不是job在产生的时候生成的。
job被提交后会直接进入scheduler的pool,在scheduler给你分配资源的时候，虽然说fifo是先按job id 小的优先处理，但是job id大的先进来，在分配资源的时候，小的还没进来呢，所以job id 大的可能被优先执行了。
上面的流程解说解释的是下面这张图：
接着呢，input2在剩下两条记录处理的10秒过程中，其实第二个周期已经开始了，input的任务又得以开始运行，这个时候因为只有一个线程可以用，所以运行了两个元素，input1处理完成，空出线程，第二个周期的input1继续调度，input的剩下的一个元素也继续运行，最后input,input1都花了15秒。
有点绕，如果大家迷惑，可以把代码贴在自己的ide上运行一下，然后观察他们的交错时间。
如果我们再做个调整：
你会发现，不同batch的job其实也可以并行运行的，这里需要有几个条件：
有延时发生了，batch无法在本batch完成
concurrentjobs > 1
如果scheduler mode 是fifo则需要某个job无法一直消耗掉所有资源
mode是fair则尽力保证你的job是并行运行的，毫无疑问是可以并行的。
回到我们的标题，不同batch的job有可能会同时在运行么，只要满足我前面提到的三个条件，就有可能。