Spark Streaming揭秘 Day7 再探Job Scheduler

Spark Streaming揭秘 Day7

再探Job Scheduler

今天,我们对Job Scheduler再进一步深入一下,对一些更加细节的源码进行分析。

Job Scheduler启动

在Job Scheduler的启动代码中,我们发现其采用了新建Thread的方式来启动代码
Snip20160514_10

在更早的Spark版本中,并没有采用这种方式,为啥要这么多做?
从注释中,很明确的指出了,这么做的原因主要是对于变量的隔离
通过启动线程,可以使运行和用户处理线程没有关系,从而避免用户线程中变量设置的干扰

从变量定义可以看到,使用了ThreadLocal,从而保证了变量是私有的
Snip20160514_11

线程池

根据前面几篇的描述,我们知道在Job Scheduler中运行Job是采用了线程池的方式,下面是线程池jobExecutor的具体定义
Snip20160514_12
我们发现,线程池的默认大小是1,这个是由SparkStreaming默认的特性决定了,也就是说在默认情况下,Batch Duration之间的Job会发生等待。
但是,当有Batch Duration需要有多个Output操作的话,我们可以提高并行度,提高性能。

Job运行的什么?

进一步深入线程池,我们发现其最终是调用了job的run方法来运行
Snip20160514_13

Job的run方法中,只是触发了对func的执行,那么func是从哪里来的呢。
Snip20160514_15

func是在DStream中产生的,关键就是如下generateJob方法:
Snip20160514_16

往上追溯,其调用在graph中,是针对outputStream。

Snip20160514_19

进入一个具体的方法,我们发现,这个就是我们的业务逻辑代码。
Snip20160514_17

从而我们知道,每个Job实际运行的就是在outputStream中定义的业务方法。

下面问题又来了,只是outputStream调用的话,其他DStream的逻辑又是如何处理?卖个关子,我们明天再谈。

小结

Dstream在RDD基础上加了一层薄薄的时间的封装,JobScheduler的作用是从时间维度去调用空间维度,时空结合之后就变成物理级别的了,变成了我们具体的业务处理。

欲知后事如何,且听下回分解

DT大数据每天晚上20:00YY频道现场授课频道68917580

posted @ 2016-05-14 23:02  哎哟慰  阅读(638)  评论(0编辑  收藏  举报