Spark Executors通信机制及FetchFailed错误排查咨询

Spark Executors之间的通信其实主要集中在Shuffle阶段——毕竟大部分计算逻辑都是在单个Executor内部完成的，跨Executor的数据交互基本都和Shuffle脱不开关系。具体来说：

• 核心Shuffle通信机制：当Map任务在某个Executor上完成后，会把生成的Shuffle Block写入本地的磁盘（或内存+磁盘混合存储，取决于你的spark.shuffle.spill配置）。之后负责Reduce任务的Executor会主动向Map端的Executor发起拉取请求，这个过程完全基于Netty框架实现的TCP连接，和SSH没有关系。
• 端口与地址管理：每个Executor启动时会绑定一个随机端口（默认是动态分配，范围由系统或Spark配置控制），这个端口会注册到Driver端的BlockManagerMaster组件里。当Reducer需要拉取数据时，Driver会告诉它目标Block所在Executor的IP和端口，Reducer再通过Netty建立连接完成数据拉取。
• 其他跨Executor场景：比如广播变量的分发，是由Driver统一推送给所有Executor，Executor之间不会直接传递广播变量；而像RDD Join这类操作，本质上也是通过Shuffle的拉取机制来完成跨Executor的数据交换。

首先明确：Spark Executors之间的连接用的是TCP协议（基于Netty），完全不需要SSH，所以测试的时候要针对TCP端口来做。下面是具体的排查步骤：

1. 先找到目标Executor的BlockManager端口 #

这个端口是Executor用来接收Shuffle拉取请求的关键端口，获取方式有两种：

• 打开Spark UI的Executors页面，每个Executor条目里都有Block Manager Port字段，直接读取即可。
• 查看目标Executor的日志，搜索关键词BlockManager: Bound to address，日志里会明确显示绑定的IP和端口（比如BlockManager: Bound to address /192.168.1.100, port 34567）。

2. 测试TCP连通性 #

在出现问题的Worker节点上，用以下工具测试：

• telnet：执行telnet <目标ExecutorIP> <BlockManagerPort>，如果能进入telnet交互界面，说明端口连通正常；如果提示Connection refused或者超时，就是端口不通。
• netcat（nc）：执行nc -zv <目标ExecutorIP> <BlockManagerPort>，这个命令会直接输出连通结果，比如Connection to 192.168.1.100 34567 port [tcp/*] succeeded!就是正常的。
• curl（备选）：如果没有telnet或nc，可以试试curl http://<目标ExecutorIP>:<BlockManagerPort>/，如果返回包含BlockManager字样的页面内容，说明端口是开放且可达的。

3. 进一步排查节点不可达的原因 #

如果测试发现端口不通，可能的原因包括：

• 防火墙限制：Worker节点之间的防火墙可能没有开放Executor的动态端口范围（因为默认spark.blockManager.port是随机分配的）。你可以查看这个配置，如果没设置就是随机，需要开放对应的系统端口范围；或者临时固定spark.blockManager.port为某个值，测试是否能连通（生产环境不推荐固定，除非特殊需求）。
• 底层网络问题：先试试ping <目标ExecutorIP>，如果ping不通，说明两个Worker节点之间的底层网络路由有问题，需要找运维排查网络。
• Executor异常退出：目标Executor可能已经因为内存溢出、OOM或者其他原因被kill了，这时候自然会出现节点不可达。去Spark UI的Executors页面看看有没有Executor丢失，或者查看Worker节点的日志确认Executor状态。

内容的提问来源于stack exchange，提问作者Alejandro A