【Spark2运算效率】第六节 影响生产集群运算效率的原因之网络IO

前言

在磁盘IO速率和网络接口IO传输速率匹配的情况下，更快的网络IO能够极大提升Spark程序Shuffle过程中Executor交换数据的速度，认识到这一点，网络IO对于集群效率的影响不言而喻，主机间可用带宽越高就意味着Spark程序数据交换速度越快；

问题概述

在前言中，我着重强调了主机间的可用带宽越高，Spark程序数据交换速度越快，而不是机房环境的整体网络带宽。对于整个集群的调度来说，机房带宽越高，集群整体的数据交换速度越快。而对于单个Job来说，其Executor间的数据交换速度取决于程序执行时，主机间的空闲网络带宽。

明白了上面我所说的，结合流程图，就不难让我们想到，在操作广播变量，或者是数据落地的时候（ETL开发中经常涉及中间表落地），这些涉及了网络传输的操作，这些操作的执行速率与程序执行时的可用带宽富裕程度是休戚相关的。
当你发现平时执行很流畅的Job在某一天突然某卡在了某一个task上，就要关注此时集群的带宽使用情况了。

案例

启动两个Job（Spark SQL写的逻辑）对一张带有两个分区字段的大表执行相同的操作，但是采用不一样的写法，一个用到了分区，另一个其实用不到分区（这也是开发人员容易陷入的一个误区，有时候你以为你你使用了分区机制，但其实没有），两个Job启动后，可以看到各自申请了300核及1.8T左右的内存：

其中，没有用到分区的Job，按部就班地执行，先是读数据，读完了之后，要进行join操作，这时候涉及shuffle，要走网络：

几百G的数据要在Executor间进行交换，这时候集群的网络IO也起来了：

可见万兆网IO已经打满，而另一个Job执行到一处涉及830.7KB数据交互的task也卡住了：

最终这830.7KB的数据交互了7.4分钟（按逻辑这个地方是一个广播表，先发送到Driver，再由Driver推到下游Executor，供Executor内的task共享）：

结语

当集群的网络IO被打满后，即使我们拿到了数以百计的核、数以T计的内存，在传输数百KB的数据时仍会因为传输等待而使得执行过程变得效率低下，要规避集群网络IO被打满，除了要谨慎使用广播变量外，对于所传输的数据分区也要进行控制，过多的分区意味着分发过程的复杂，也会造成集群网络IO的浪费。
其实一个集群拥有的资源不止是内存、磁盘和内核，网络IO、磁盘IO也应该作为一种动态指标纳入对集群执行效率高低的判断因素之中。

跳转

目录