多Spark内核Jupyter Notebook集群共享与资源影响咨询

基础作业调度规则 #

基于SparkMagic这类Spark内核的Jupyter Notebook，本质是连接到EMR集群的瘦客户端，本身不承载实际的计算逻辑：

• 所有连接到同一EMR集群的Notebook，均可直接向集群的资源管理器（EMR默认使用YARN）提交Spark作业，不存在强制串行执行的限制
• 集群会按照配置的资源调度策略，把所有Worker节点的CPU、内存、磁盘存储容量拆分为独立的资源容器，分配给每个Notebook启动的独立Spark应用
• 当所有Notebook提交的作业申请的总资源量未超过集群总容量时，多个作业可完全并行调度运行；当总需求超出集群容量时，超出部分的作业会进入等待队列，直到有其他作业释放资源后再启动

闲置Notebook的资源占用影响 #

针对挂着Notebook、缓存大RDD未释放的场景，会明确影响其他用户的作业效率，核心原因是Spark对应用持有的资源没有自动回收机制：

• 只要Notebook对应的Spark应用没有被主动终止（没有执行spark.stop()、没有断开内核连接触发应用注销），这个应用一开始申请到的固定资源配额就会一直被占用，哪怕根本没有跑新代码，也不会自动把资源还给集群公共池
• 不管是存在executor内存还是本地磁盘的RDD缓存块，只要所属的Spark应用还没注销，这些占了内存、磁盘的块就不会被自动清理——哪怕这些RDD存了之后再也没被读过
• 这些被长期占着的资源，直接从集群总容量里扣除，结果就是其他用户能拿到的资源变少：轻则把其他作业的executor内存配额压得很低、Task排队等调度的时间变长，重则碰到磁盘满、内存不够的情况，导致其他作业的Shuffle失败、整体运行卡顿

AWS EMR + SageMaker 场景的实际表现 #

结合美国区域常见的SageMaker连接EMR的部署配置，几个和通用机制不一样的细节要注意：

• 默认配置下，所有从SageMaker连过来的SparkMagic Notebook，启动的Spark应用都会跑在同一个YARN默认队列里，没做专门的资源队列隔离的话，任何一个用户的闲置Notebook占的缓存资源，都是直接从公共池里扣的，不会因为是跨用户的会话就自动隔离
• EMR默认开启的Spark动态资源分配，不是万能的：它只会回收“既没有存任何RDD缓存块、也没在跑Task”的空executor，只要executor上存了这个Notebook的缓存RDD，哪怕长期闲置，也不会被回收给其他用户使用
• 就算EMR开了资源抢占功能，资源紧张的时候系统会强行回收闲置应用的部分executor，但这会把缓存的RDD直接弄丢，等对应的用户回来再跑单元格要用这个缓存时，就得全量重算一遍，反而更浪费集群资源

核心结论：连在同一个集群上的所有Spark Notebook，完全可以同时提交作业，不需要串行排队等别人跑完再跑；但集群的总资源是固定的，大家按申请量拆分资源。只要一个Notebook没关、还存了大体积的缓存RDD，就会一直占着对应的内存、磁盘、计算配额，实打实拖慢其他用户的作业速度。

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