Spark Streaming揭秘 Day30 集群模式下SparkStreaming日志分析

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