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