Spark Streaming揭秘 Day30
集群模式下SparkStreaming日志分析
今天通过集群运行模式观察、研究和透彻的刨析SparkStreaming的日志和web监控台。
Day28已经分析过local模式下的日志，集群模式会比较类似，这次主要是对集群模式在的web监控台，进行统一的深度刨析。
我们从wordcount程序开始，代码如下，为了展示出SparkStreaming在集群中的运行，Batch Duration设置为5分钟。
系统作业
为了观察持续运行的情况，我们运行了10分钟，一共产生了6个Job，Job0和Job1是框架产生的系统Job。
首先我们会看见一个Job0，这个是SparkStreaming启动时进行自检的dummy Job，前面课程曾经介绍过，目标是为了资源的平衡和最大化。
Job1一直处于active状态，其内部是一个Receiver，为了启动Receiver进行数据接收而产生的，我们发现这个Job只运行在一台机器上。
无数据处理作业
下面看下Streaming专有的控制台。我们进行了多个Batch的处理，其中第一个Batch没有数据，而第二个Batch有数据，我们发现就算没有数据，因为也会执行一个action，所以也会有处理时间。
首先是Batch1，其中并没有数据发生，这个Batch由Job2和Job3组成。
我们进入Job2，里面有2个Stage，里面虽然触发了一个action，但是因为没数据，所以啥也没干，只是走了一个形式。
我们会发现第一个Stage中没有Task运行。
第二个Stage，是只有一个Task在worker2运行，进行reduce操作。
有数据处理作业
从日志看，发现在输入读入时，在2个worker上进行数据存入，有两个是因为存储级别默认为MEMORY_AND_DISK_SER_2，有备份机制。
有数据输入Batch2由Job4和Job5组成。
我们看下Job4，第一个Stage不再跳过，这个时候，就有具体的数据处理了
第一个Stage，运行在worker4的机器上，和receiver在一起。而且数据是在内存中(NODE_LOCAL)。主要进行了Shuffle write，写入了4条数据。
第二个Stage，在worker4上运行，shuffle read了3个record。
Job5中，也是运行在worker4上，shuffle read了1个record。
在这里，我们发现了一个现象：从web控制台来看，一个Batch Duration产生2个Job，共同完成了这个Batch中全部record的处理，分了2个Job来shuffle read数据。
多Job机制再研究
从上述描述，我们看到一个print函数会由多个Job协作完成，这个是不是偶发现象，我们做个实验。
把代码中分区数调为8，重新运行程序：
这个时候，我们发现同时运行的Job变成了3个，3个Job一共运行了8个Task！！！
这个是spark1.6的新特性，框架在做作业调度的时候，为了更大化的利用集群的资源，把我们的task分发成不同的Job，每个Job负责一部分的Task。启动多个Job，好处是可以支持无限的自动重启提高可靠性。
这个处理代价不是太大，原因是在SparkStreaming角度讲只是封装了Runnable对象，是一种轻量级的处理。具体实现看，在JobGenerator中，在产生Jobset提交到JobScheduler的时候，会根据并行度等规则，把Job分成了不同的子Job。这个子Job的拆分，我们下节课来分析。
欲知后事如何，且听下回分解!
DT大数据每天晚上20：00YY频道现场授课频道68917580