Spark定制班第6课：Spark Streaming源码解读之Job动态生成和深度思考



Spark Streaming Job动态生成三大核心

• JobGenerator：负责Job生成
• JobSheduler：负责Job调度
• ReceiverTracker：获取元数据

JobGenerator在构造的时候有一个核心的参数是jobScheduler，jobScheduler是整个Job（作业）的生成和提交给集群的核心，JobGenerator会基于DStream生成Job。这里面的Job就相当于Java中线程要处理的Runnable里面的业务逻辑封装。Spark的Job就是运行的一个作业。

最后来思考一个问题：DStreamGraph将逻辑级别的输入数据翻译成物理级别的RDD Graph，最后一个操作是RDD的action操作，是否会立即触发Job？

• action触发Job，这个时候作为Runnable接口封装，他会定义一个方法，这个方法里面是基于DStream的依赖关系生成的RDD。翻译的时候是将DStream的依赖关系翻译成RDD的依赖关系，由于DStream的依赖关系最后一个是action级别的，翻译成RDD的时候，RDD的最后一 个操作也应该是action级别的，如果翻译的时候直接执行的话，就直接生成了Job，就没有所谓的队列，所以会将翻译的事件放到一个函数中或者一个方法fun() 中，因此，如果这个函数没有指定的action触发Job是执行不了的。
• Spark Streaming根据时间不断的去管理我们的生成的Job，所以这个时候我们每个Job又有action级别的操作，这个action操作是对DStream进行逻辑级别的操作，他生成每个Job放到队列的时候，他一定会被翻译为RDD的操作，那基于RDD操作的最后一个一定是action级别的，如果翻译的话直接就是触发action的话整个Spark Streaming的Job就不受管理了。因此我们既要保证他的翻译，又要保证对他的管理，把DStream之间的依赖关系转变为RDD之间的依赖关系， 最后一个DStream使得action的操作，翻译成一个RDD之间的action操作，整个翻译后的内容他是一块内容，他这一块内容是放在一个函数体中的，这个函数体，他有函数的定义，这个函数由于只是定义还没有执行，所以他里面的RDD的action不会执行，不会触发Job，当我们的 JobScheduler要调度Job的时候，转过来在线程池中拿出一条线程执行刚才的封装的方法。