大数据Spark Shuffle三Executor是如何fetch shuffle的数据文件.docx

大数据Spark Shuffle三Executor是如何fetch shuffle的数据文件.docx

《大数据Spark Shuffle三Executor是如何fetch shuffle的数据文件.docx》由会员分享，可在线阅读，更多相关《大数据Spark Shuffle三Executor是如何fetch shuffle的数据文件.docx（14页珍藏版）》请在冰豆网上搜索。

大数据SparkShuffle三Executor是如何fetchshuffle的数据文件

大数据：

SparkShuffle（三）Executor是如何fetchshuffle的数据文件

1.前言

Executor是如何获取到Shuffle的数据文件进行Action的算子的计算呢？

在ResultTask中，Executor通过MapOutPutTracker向Driver获取了ShuffID的Shuffle数据块的结构，整理成以BlockManangerId为Key的结构，这样可以更容易区分究竟是本地的Shuffle还是远端executor的Shuffle

2.Fetch数据

在MapOutputTracker中获取到的BlockID的地址，是以BlockManagerId的seq数组

[plain]viewplaincopy

Seq[（BlockManagerId,Seq[（BlockId,Long）]）]

BlockManagerId结构

[plain]viewplaincopy

classBlockManagerIdprivate（

privatevarexecutorId_:

String,

privatevarhost_:

String,

privatevarport_:

Int,

privatevartopologyInfo_:

Option[String]）

extendsExternalizable

是以ExecutorId，ExecutorHostIP,ExecutorPort标示从哪个Executor获取Shuffle的数据文件，通过Seq[BlockManagerId,Seq（BlockID,Long）]的结构，当前executor很容易区分究竟哪些是本地的数据文件，哪些是远端的数据，本地的数据可以直接本地读取，而需要不通过网络来获取。

2.1读取本Executor文件

如何认为是本地数据？

Spark认为区分是通过相同的ExecutorId来区别的，如果ExecutorId和自己的ExecutorId相同，认为是本地Local，可以直接读取文件。

[plain]viewplaincopy

for（（address,blockInfos）<-blocksByAddress）{

totalBlocks+=blockInfos.size

if（address.executorId==blockManager.blockManagerId.executorId）{

//Filteroutzero-sizedblocks

localBlocks++=blockInfos.filter（_._2!

=0）.map（_._1）

numBlocksToFetch+=localBlocks.size

}

}

这里有两种情况：

同一个Executor会生成多个Task，单个Executor里的Task运行可以直接获取本地文件，不需要通过网络

同一台机器多个Executor，在这种情况下，不同的Executor获取相同机器下的其他的Executor的文件，需要通过网络

2.2读取非本Executor文件

2.2.1构造FetchRequest请求

获取非本Executor的文件，在Spark里会生成一个FetchRequest，为了避免单个Executor的MapId过多发送多个FetchRequest请求，会合并同一个Executor的多个请求，合并的规则由最大的请求参数控制

[plain]viewplaincopy

spark.reducer.maxSizeInFlight

valtargetRequestSize=math.max（maxBytesInFlight/5,1L）

对同一个Executor，如果请求多个Block请求的数据大小未超过targetRequestSize，将会被分配到同一个FetchRequest中，以避免多次FetchRequest的请求

[plain]viewplaincopy

valiterator=blockInfos.iterator

varcurRequestSize=0L

varcurBlocks=newArrayBuffer[（BlockId,Long）]

while（iterator.hasNext）{

val（blockId,size）=iterator.next（）

//Skipemptyblocks

if（size>0）{

curBlocks+=（（blockId,size））

remoteBlocks+=blockId

numBlocksToFetch+=1

curRequestSize+=size

}elseif（size<0）{

thrownewBlockException（blockId,"Negativeblocksize"+size）

}

if（curRequestSize>=targetRequestSize）{

//AddthisFetchRequest

remoteRequests+=newFetchRequest（address,curBlocks）

curBlocks=newArrayBuffer[（BlockId,Long）]

logDebug（s"Creatingfetchrequestof$curRequestSizeat$address"）

curRequestSize=0

}

}

//Addinthefinalrequest

if（curBlocks.nonEmpty）{

remoteRequests+=newFetchRequest（address,curBlocks）

}

多个FetchRequest会被随机化后放入队列Queue中，每个Executor从Driver端获取的ShuffID对应的BlockManagerID所管理的BlockID的状态是相同的顺序，如果不对FetchRequest进行随机化，那么非常有可能存在多个Executor同时向同一个Executor获取发送FetchRequest的情况，从而导致Executor的负载增高，为了均衡每个Executor的数据获取，随机化FetchRequest是非常有必要的。

2.2.1发送FetchRequest

FetchRequest并不是并行提交的，对同一个Task来说，在Executor的做combine的时候是一个一个的BlockID块合并的，而Task本身就是一个线程运行的，所以不需要设计FetchRequest成并行提交，当一个BlockID完成计算后，才需要判断是否需要进行下一个FetchRequest请求，因为FetchRequest是多个Block提交的，为了控制Executor获取多个BlockID的shuffle数据的带宽，在提交FetchRequest的时候控制了请求的频率

在满足下面以下条件下，才允许提交下个FetchRequest

当正在请求的所有BlockId的内容和下一个FetchRequest的请求内容之和小于maxBytesInFlight的时候，才能进行下一个FetchRequest的请求

当正在请求的数量小于所设置的最大的允许请求数量的时候，才能进行下一个FetchRequest的请求，控制参数如下：

[plain]viewplaincopy

spark.reducer.maxReqsInFlight

2.2.2完整的FetchRequest流程

ExecutorA通过ExternalShuffleClient进行fetchBlocks的操作，如果配置了

[plain]viewplaincopy

io.maxRetries

最大重试参数的话，将启动一个能重试RetryingBlockFetcher的获取器

初始化TransportClient，OneForOneBlockFetcher获取器

在OneForOneBlockFetcher里首先向另一个ExecutorB发送了OpenBlocks的询问请求，里面告知ExecutorID,APPID和BlockID的集合

ExecutorB获取到BlockIDs，后通过BlockManager获取相关的BlockID的文件（通过mapid,reduceid获取相关的索引和数据文件），构建FileSegmentManagedBuffer

通过StreamManager（OneForOneStreamManager）registerStream生成streamId，和StreamState（多个ManagedBuffer，AppID）的缓存

返回所生成的StreamId

ExecutorB返回给StreamHandle的消息，里面包含了StreamId和Chunk的数量，这里chunk的数量其实就是Block的数量

ExecutorA获取到StreamHandle的消息，一个一个的发送ChunkFetchRequest里面包含了StreamId,Chunkindex，去真实的获取ExecutorB的shuffle数据文件

ExecutorB通过传递的ChunkFetchRequest消息获取到StreamId,Chunkindex,通过缓存获取到对应的FileSgementManagedBuffer，返回chunkFetchSuccess消息，里面包含着streamID,和FileSegmentManagedBuffer

在步骤3-6步骤里是堵塞在Task线程里，而步骤7一个一个发送ChunkFetchRequest后，并不堵塞等待返回结果，结果是通过回调函数来实现的，在调用前注册了一个回调函数

[plain]viewplaincopy

client.fetchChunk（streamHandle.streamId,i,chunkCallback）;

privateclassChunkCallbackimplementsChunkReceivedCallback{

@Override

publicvoidonSuccess（intchunkIndex,ManagedBufferbuffer）{

//Onreceiptofachunk,passitupwardsasablock.

listener.onBlockFetchSuccess（blockIds[chunkIndex],buffer）;

}

@Override

publicvoidonFailure（intchunkIndex,Throwablee）{

//Onreceiptofafailure,faileveryblockfromchunkIndexonwards.

String[]remainingBlockIds=Arrays.copyOfRange（blockIds,chunkIndex,blockIds.length）;

failRemainingBlocks（remainingBlockIds,e）;

}

}

在这里的listener就是前面fetchBlocks里注入的BlockFetchingListener

[plain]viewplaincopy

newBlockFetchingListener{

overridedefonBlockFetchSuccess（blockId:

String,buf:

ManagedBuffer）:

Unit={

//Onlyaddthebuffertoresultsqueueiftheiteratorisnotzombie,

//i.e.cleanup（）hasnotbeencalledyet.

ShuffleBlockFetcherIterator.this.synchronized{

if（!

isZombie）{

//Incrementtherefcountbecauseweneedtopassthistoadifferentthread.

//Thisneedstobereleasedafteruse.

retain（）

remainingBlocks-=blockId

results.put（newSuccessFetchResult（BlockId（blockId）,address,sizeMap（blockId）,buf,

remainingBlocks.isEmpty））

logDebug（"remainingBlocks:

"+remainingBlocks）

}

}

logTrace（"Gotremoteblock"+blockId+"after"+Utils.getUsedTimeMs（startTime））

}

overridedefonBlockFetchFailure（blockId:

String,e:

Throwable）:

Unit={

logError（s"Failedtogetblock（s）from${req.address.host}:

${req.address.port}",e）

results.put（newFailureFetchResult（BlockId（blockId）,address,e））

}

}

如果获取成功将封装SuccessFetchResult里面保存着blockId，地址，数据大小，以及ManagedBuffer，并保存到results的queue中

2.2.3Fetch迭代获取数据文件

Executor在BlockStoreShuffeReader的read函数中构建ShuffleBlockFetcherIterator，ShuffleBlockFetcherIterator是个InputStream的迭代器，每个BlockID生成一个InputStream，在设计里并没有区分是本地的还是远端的，每一次迭代都是从堵塞的Queue里获取到BlockID的ManagerBuffer，通过调用ManagerBuffer.createInputStream获取每个InputStream，进行读取并且反序列话，进行KV的combine.

如何判断所有的BlockID已经读取完了？

[plain]viewplaincopy

overridedefhasNext:

Boolean=numBlocksProcessed

在hasNext里判断当前的是否已经达到需要读取的block数量了，每一次读取下一个block的时候都会在numBlocksProcessed+1，在读取失败的情况下会直接抛出异常。

3.Fetch交互协议

在前面的博客里描述了很多交互协议都使用了Java的原生态的反序列化，但在上文描述的Fetch协议中，是Spark单独定义的一套协议标准，自己实现encoder和decoder

ChunkFetchRequest,ChunkFetchSuccess,RpcRequest,RpcResponse....这些都是直接使用Java进行封装，在Network-Commmon的包里，所有的消息最后都实现了基本的接口。

3.1MessageEncoder

[java]viewplaincopy

publicinterfaceMessageextendsEncodable{}

而核心的是Encodable，有点类似Java的Serializable接口，需要自己实现Encoder和Decoder的方法

[java]viewplaincopy

publicinterfaceEncodable{

/**Numberofbytesoftheencodedformofthisobject.*/

intencodedLength（）;

/**

*SerializesthisobjectbywritingintothegivenByteBuf.

*ThismethodmustwriteexactlyencodedLength（）bytes.

*/

voidencode（ByteBufbuf）;

}

核心的序列话的encode的入参数是ByteBuf很符合Netty里的NIO所暴露出的接口，同时也要注意这是Netty的ByteBuf和Netty是耦合了

如何让Netty调用Encodableencode方法呢？

在Netty里暴露出的类MessageToMessageEncoder，里暴露encode的抽象方法，这是一个可以允许对传递的消息进行一次自定义的编码

[java]viewplaincopy

MessageToMessageEncoderprotectedabstractvoidencode（ChannelHandlerContextparamChannelHandlerContext,IparamI,List