Spark Streaming写入HBase遇Connection reset by peer问题求助（动态分配开启时触发）

我之前也碰到过几乎一模一样的场景——开了Spark动态分配就触发HBase连接重置，关了或者写HDFS就完全正常。结合你的排查方向，咱们从根源和实操方案来拆解：

问题核心原因 #

Spark动态分配会自动销毁空闲Executor，但HBase的Connection是绑定到特定网络会话的线程安全对象，一旦Executor被回收，对应的HBase连接不会主动向ZK发送断开信号，ZK会因为检测到无效连接主动重置，就抛出了java.io.IOException: Connection reset by peer。

具体解决步骤 #

1. 重构HBase连接的创建逻辑（最关键）

绝对不要在Driver端创建HBase Connection再序列化到Executor——HBase Connection根本不支持序列化。要在每个Executor内部懒加载单例连接，并确保Executor销毁时主动关闭：

object HBaseConnManager {
  private var conn: Connection = _
  private val lock = new Object()

  def getConn(hbaseConf: Configuration): Connection = {
    lock.synchronized {
      if (conn == null || conn.isClosed) {
        conn = ConnectionFactory.createConnection(hbaseConf)
        // 给Executor加 shutdown hook，退出时强制关闭连接
        sys.addShutdownHook {
          if (conn != null && !conn.isClosed) {
            conn.close()
          }
        }
      }
    }
    conn
  }
}

在你的Spark Streaming算子里，调用这个工具类获取连接，确保每个Executor有独立的、可被清理的HBase连接。

2. 调整Spark动态分配参数，减少Executor频繁销毁

默认的动态分配参数太激进，容易导致Executor刚创建就被回收，试试调整这些配置：

• spark.dynamicAllocation.minExecutors：设置为你业务稳定运行时的最小Executor数（比如5），避免频繁销毁重建
• spark.dynamicAllocation.executorIdleTimeout：从默认60s改成300s，延长空闲Executor的存活时间
• spark.dynamicAllocation.cachedExecutorIdleTimeout：如果有RDD缓存，把这个值调得更大（比如600s），防止缓存Executor被误回收

3. 优化HBase客户端与ZK的适配配置

在Spark配置或HBase配置中添加这些参数，增强连接稳定性：

• hbase.client.retries.number：从默认3改成8，增加重试次数
• hbase.rpc.timeout：从默认60s改成120s，延长RPC超时时间
• hbase.zookeeper.session.timeout：设置为90s以上，和Spark的网络超时对齐
• hbase.zookeeper.maxClientCnxns：把ZK的单客户端连接数限制从默认60改成200，避免动态分配时连接数超限

4. 验证Executor回收时的资源清理

开启Spark的调试日志，查看Executor销毁时的资源释放情况：

log4j.logger.org.apache.spark.scheduler.cluster=DEBUG

如果日志里看不到HBase连接关闭的记录，可以通过Spark的SparkListener监听onExecutorUnregistered事件，在回调里手动触发HBase连接的关闭逻辑。

总结 #

这个问题本质是动态分配的Executor生命周期不稳定和HBase连接的强会话绑定之间的冲突。从连接管理、动态分配参数、HBase/ZK配置这三个方向入手，基本能解决问题。

内容的提问来源于stack exchange，提问作者feus.tigris