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