Spark Streaming揭秘 Day7
再探Job Scheduler
今天，我们对Job Scheduler再进一步深入一下，对一些更加细节的源码进行分析。
Job Scheduler启动
在Job Scheduler的启动代码中，我们发现其采用了新建Thread的方式来启动代码
在更早的Spark版本中，并没有采用这种方式，为啥要这么多做？
从注释中，很明确的指出了，这么做的原因主要是对于变量的隔离
通过启动线程，可以使运行和用户处理线程没有关系，从而避免用户线程中变量设置的干扰
从变量定义可以看到，使用了ThreadLocal，从而保证了变量是私有的
线程池
根据前面几篇的描述，我们知道在Job Scheduler中运行Job是采用了线程池的方式，下面是线程池jobExecutor的具体定义
我们发现，线程池的默认大小是1，这个是由SparkStreaming默认的特性决定了，也就是说在默认情况下，Batch Duration之间的Job会发生等待。
但是，当有Batch Duration需要有多个Output操作的话，我们可以提高并行度，提高性能。
Job运行的什么？
进一步深入线程池，我们发现其最终是调用了job的run方法来运行
Job的run方法中，只是触发了对func的执行，那么func是从哪里来的呢。
func是在DStream中产生的，关键就是如下generateJob方法：
往上追溯，其调用在graph中，是针对outputStream。
进入一个具体的方法，我们发现，这个就是我们的业务逻辑代码。
从而我们知道，每个Job实际运行的就是在outputStream中定义的业务方法。
下面问题又来了，只是outputStream调用的话，其他DStream的逻辑又是如何处理？卖个关子，我们明天再谈。
小结
Dstream在RDD基础上加了一层薄薄的时间的封装，JobScheduler的作用是从时间维度去调用空间维度，时空结合之后就变成物理级别的了，变成了我们具体的业务处理。
欲知后事如何，且听下回分解
DT大数据每天晚上20：00YY频道现场授课频道68917580