Azure Synapse管道Notebook步骤运行耗时异常排查

问题并非直接由Spark Pool计算资源抢占导致。你已经完成独立Spark Pool隔离的对照实验，排除了同池资源争抢的可能性。结合故障出现的时间节点（同事协同修改管道后触发、偶发无报错长耗时），根因属于多人协同引入的配置、共享资源、调度层面的隐性冲突，和计算池本身的算力无关。

• Notebook共享配置被修改：Synapse Notebook的Spark会话参数属于文件级共享配置，如果你同事调整管道时修改了对应Notebook的默认会话配置（比如设置了不合理的Executor规格、过长的会话超时时间、开启了跨作业会话复用），哪怕你使用独立Spark Pool，调用该Notebook时也会继承错误配置，出现会话启动阶段的长时间排队。
• 非计算层共享资源锁冲突：就算计算池完全隔离，只要你和同事的作业共用同一个Linked Service、同一个存储路径、同一个Spark元数据命名空间，就可能出现隐性锁等待——比如一方作业写入ADLS目录时持有排他锁，另一方作业读取同路径就会进入无报错的等待状态；或是双方作业同时操作同名临时表触发元数据锁，这类等待不会抛出显性错误，只会把作业时长拉长到1~2小时，和你遇到的故障特征完全匹配。
• 工作区级调度配额抢占：多个独立Spark Pool同属一个Synapse工作区时，工作区层面的Spark实例总调度配额是共享的。如果你同事的作业占满了工作区总配额，你的作业即使在专属池上，也会卡在实例申请阶段排队，这类排队不会在单个Spark Pool的监控中体现为资源占用，只会表现为管道总时长异常变长。

• 校验并固化Notebook会话配置：打开对应Notebook，通过顶部配置会话面板核对所有Spark参数，重点检查会话空闲超时、Executor规格/数量、动态资源分配、会话复用几个配置项，回滚到单人开发时的正常值。同时在管道的Notebook活动配置中，强制写入固定的会话参数，不要继承Notebook的全局共享配置，避免其他协作者修改参数影响你的作业运行。
• 拆分耗时阶段定位卡点：在监控面板找到长耗时的Notebook运行实例，拆分各阶段耗时：如果耗时集中在会话启动阶段，对应配额/会话配置问题；如果耗时集中在任务执行阶段，进入Spark UI查看具体卡点Stage，重点排查是否存在锁等待、存储IO等待；如果耗时集中在会话销毁阶段，对应会话复用配置错误。
• 隔离非计算层共享资源：检查双方作业是否使用相同的临时表名、临时文件输出路径、Linked Service凭据，给你的作业添加专属的临时路径前缀、临时表名前缀，彻底避免跨作业锁冲突。
• 核对Spark Pool与工作区配额配置：进入Apache Spark池配置页，确认你的专属池开启固定大小预留，关闭不必要的弹性伸缩配置；同时检查工作区层面的Spark实例总配额，确认双方同时运行作业时不会触顶配额上限。
• 增加超时兜底逻辑：给Notebook步骤设置10分钟的超时阈值，触发超时后自动终止异常会话并重跑，避免无意义的长耗时占用资源。

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