使用EMR Notebooks+PySpark/Livy执行Join时遇400会话未激活错误

嘿，我之前在EMR上用Livy+PySpark处理大数据量Join的时候也踩过这个「Session isn't active」的坑，哪怕已经把超时设到5小时还是会出问题。咱们来一步步拆解可能的原因和解决办法：

1. 先确认Livy会话的真实状态 #

首先别光看报错，手动查一下会话到底是不是真的超时了：

• 登录EMR主节点，执行这条命令（忽略自签证书的话加-k）：

  curl -k https://172.31.12.103:18888/sessions/5
  

  看看返回的state字段，如果是dead或者shutting down，大概率不是单纯的超时，而是会话因为资源问题被强制终止了。

2. 排查Join操作引发的资源耗尽 #

200万行的Parquet本身不算超大，但Join操作很容易触发Shuffle，如果资源配置不合理，直接会把Executor搞崩，进而导致Livy会话挂掉：

• 去EMR控制台的「YARN ResourceManager」界面，或者主节点的/var/log/yarn/目录下看日志，找有没有OutOfMemoryError的记录——这是最常见的原因。
• 临时调整Spark的资源参数，给Join操作足够的缓冲：

  # 调大Executor和Driver内存
  spark.conf.set("spark.executor.memory", "8g")
  spark.conf.set("spark.driver.memory", "4g")
  # 调整Shuffle分区数，避免单分区数据量过载
  spark.conf.set("spark.sql.shuffle.partitions", "200")
  

• 先对要Join的DataFrame做精简：只保留需要的列，提前过滤掉无关的行，减少Shuffle的数据量。

3. 检查Livy的完整配置，别只盯超时时间 #

很多人只改了livy.server.session.timeout，但还有几个关键参数会影响会话存活：

• livy.server.session.max-idle：这个是会话空闲多久会被回收，默认可能很短，得改成和超时时间一致，比如5h。
• livy.executor.instances和livy.executor.memory：确保Livy启动的Executor有足够资源，避免被YARN强制杀掉。
• 如果是EMR集群，创建的时候可以在「集群配置」的livy-conf分类里批量设置：

  livy.server.session.timeout=5h
  livy.server.session.max-idle=5h
  livy.executor.memory=8g
  

4. 重启Livy服务和会话试试 #

如果以上排查都没发现问题，可能是Livy服务本身有残留的异常：

• 登录EMR主节点，执行：

  sudo stop livy-server
  sudo start livy-server
  

• 然后关闭当前的EMR Notebook会话，重新开一个新的再执行Join——旧会话可能已经有隐性的资源泄漏了。

5. 可选：换成EMR Studio（更稳定的替代方案） #

如果经常碰到Livy会话的问题，EMR Studio比传统的EMR Notebooks对Livy的管理更靠谱，它直接连接集群的Spark环境，减少中间层的会话问题，处理大数据操作时稳定性会好很多。

你遇到的具体错误信息：从https://172.31.12.103:18888/sessions/5/statements/20返回无效状态码‘400’，错误负载："requirement failed: Session isn't active."

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