Spark定制班第6课：Spark Streaming源码解读之Job动态生成和深度思考
本期内容：
1 Spark Streaming Job生成深度思考
2 Spark Streaming Job生成源码解析
1 Spark Streaming Job生成深度思考
前面的课程中已经讲了，Spark Streaming的Job是通过JobGenerator生成。这里说的Job和Spark Core中的Job不是一回事。Spark Streaming中的Job相当于Java中线程要处理的Runnable的业务逻辑的封装。Spark Core上的Job是一个运行的作业。
JobGenerator会利用DStream来生成Job。从流程上看，DStream一般分三种类型：
1、输入的DStreams。
2、输出的DStreams，是一个逻辑级别的Action，它是SparkStreaming框架提出的，它的底层还是会被翻译成物理级别的Action。所谓物理级别的Action是RDD的Action。
3、中间的业务处理的通过Transformation（转换）产生的DStream。也就是业务处理逻辑的中间过程。
产生DStream也可以说有两类：一类是根据数据源产生DStream，另一类是通过前面的DStream转换后生成DStream。
所以说，JobGenerator是根据DStream的依赖关系，或者说根据DStreamGraph来产生Job。
当然从时间维度上讲，JobGenarator会不断地产生Job。我们做连续不断的大数据任务时，如果不采用流式处理，一般会用定时任务。其实我们也是变相地在做流处理。不管是定时1分钟、1小时，甚至是1天，都类似在做流处理。应该更深刻的理解此前说过的一句话吧：一切没有经过流处理或近似流处理的数据，都将是没有价值的数据。原来的定时任务实际上是在做变相的流处理。我们相信，一切处理终将会被流处理完全统一。
2 Spark Streaming Job生成源码解析
其实，Spark Streaming的流处理实际上就是以时间作为触发器的。这和基于事件触发的Storm不同。
看看Spark Streaming应用程序代码的最开始的共同之处：定义SparkStreamingContext。给个例子：
val ssc = new StreamingContext(conf, Seconds(5))
这个5秒钟的Batch Duration（批处理时间间隔）就是用来设置定时器的时间长度。
系统翻译基于DStream的依赖关系，成为了RDD之间的依赖关系，而最后的处理是一个action，但由于这个处理是定义在一个方法中，而此方法没有被马上调用，也就没有马上执行。这是为了便于管理，要形成队列来依次处理。
Spark Streaming应用程序代码的最后面的共同之处：运行SparkStreamingContext的start()：
ssc.start()
这里才是真正启动流处理执行的地方。启动SparkStreamingContext，会启动JobScheduler。
Spark Streaming作业的三大核心是：
1. JobGenerator：负责Job的生成。
2. ReceiverTracker：负责数据的接收。
3. JobScheduler：负责Job的调度执行。
JobGenerator、ReceiverTracker其实是在