PAYATHON 2026

Microsoft Fabric Spark Pool 启动慢且未按预期复用，如何配置？

数据阿明

结论

优先检查工作区是否启用了面向 Pipeline 的 High concurrency，再确认后续 Notebook 是否满足会话共享条件。sessionTag 需要配合该功能才能复用会话；仅设置相同标签和 20 分钟 timeout，不能保证下一次 Pipeline 运行直接使用已有会话。

在禁用 Starter Pools 的私有网络环境中，按需创建 Spark 集群可能需要数分钟。Microsoft 文档列出的 Private Links/Managed VNets 场景启动耗时约为 2 至 5 分钟，与这里的 3 至 5 分钟相符。不过，这还不足以证明每次等待都由集群创建引起。Spark compute 说明

先区分两种 timeout

提供的 JSON 包含以下设置：

"policy": {
  "timeout": "0.00:10:00",
  "retry": 0,
  "retryIntervalInSeconds": 30,
  "secureOutput": false,
  "secureInput": false
}

0.00:10:00 表示 10 分钟，控制 Notebook activity 的运行超时。它不设置 Spark 会话的空闲保留时间，也不负责让集群保持预热。Activity Policy 定义

如果所说的 20 分钟来自工作区 Jobs 下的 Spark session timeout，官方将其描述为交互式 Notebook 会话的过期时间。这不能说明 Pipeline 活动完成后，同一个会话一定会继续保留 20 分钟，供下一次运行复用。工作区 Spark 设置

由于当前材料没有实际截图，无法确定这个 20 分钟设置在什么位置，也就暂时不能判断 timeout 是否未生效。

启用 Pipeline 会话共享

请工作区管理员检查以下设置：

  1. 打开 Workspace settings。
  2. 进入 Data Engineering/Science → Spark settings → High concurrency。
  3. 启用 For pipeline running multiple notebooks。
  4. 保存后重新运行测试。

选项名称虽然包含 multiple notebooks，测试单个 Notebook 并在之后再次运行时，也需要先确认该功能已开启。官方要求启用这个选项后才能使用 Pipeline 的 sessionTag。Notebook activity 设置

接着检查预热 Notebook 与下游 Notebook 的运行身份、工作区、默认 Lakehouse、Spark compute 配置和库依赖是否一致。相同标签只是匹配条件之一；即使标签相同，配置不兼容时仍会创建独立会话。Pipeline 会话共享条件

验证 sessionTag 和预热效果

现有标签表达式是：

@replace(pipeline().DataFactory,'-', '_')

仅凭这段 JSON，无法确认每次运行时实际解析出的标签值。排查时，可以先在 Notebook activity 的 Session tag 输入框中使用固定字符串，例如：

spark_warmup_test

给预热和下游活动设置相同标签并固定其他配置，先测试同一次 Pipeline 内连续运行两个 Notebook，再测试短时间内重新运行 Pipeline，分别观察同次运行和跨次运行是否发生共享。

原来的 print(...) 可以用于观察活动启动耗时，但它没有执行 Spark 数据处理，不能衡量 Spark 作业性能，也不能证明下游已复用会话。测试时可临时加入：

print("Spark application ID:", spark.sparkContext.applicationId)
print("Spark action result:", spark.range(1).count())

这段代码会执行一个很小的 Spark action。结合 Spark Monitoring 中的会话信息和 application ID，可以检查第二个 Notebook 是否加入同一个 Spark application。代码仅用于验证，不会强制平台延长会话生命周期。

如果首次运行较慢，后续成功共享会话后明显变快，说明复用路径有效。复用已经运行的会话可以加速后续运行，但仍需承担第一次冷启动的成本。High concurrency 工作方式

首次启动也需要更快时怎么办？

如果工作区提供 Custom live pools，可以核对当前容量及私有网络配置是否适用。该功能通过配置时间窗口提前准备集群，适合有固定调度时间的 Notebook 工作负载。

它需要付费 Fabric capacity，且只有预热完成、存在可用集群等条件满足时才能获得较快启动。预热窗口之外或预热集群耗尽时，仍可能回退到按需创建。保留已分配集群也会产生相应计费。普通 Custom Pool 不会因为名字或最小节点数设置就自动获得相同的预热能力。Custom live pools 说明

仍然每次等待 3 至 5 分钟时，如何继续排查？

把总耗时拆开记录，包括活动提交后的等待、集群和会话初始化、库安装以及代码执行。重点核对：

  • 第二次提交时，第一次的会话是否仍然存活；如果已经停止，是否有停止原因。
  • 两次运行的实际身份、标签值、Environment、默认 Lakehouse 和 compute 配置是否一致。
  • 是否存在容量等待或初始化阶段的错误。
  • 是否有额外依赖安装增加启动时间。

当前测试只有一条 print(...)，应先解决启动和复用问题。现有测试没有相应的计算负载，无法据此判断是否需要增加 executors 或调整分区。

如果确认配置匹配、可共享会话仍然存活，后续运行却持续创建新会话，可以携带 Pipeline run ID、Spark application ID、时间线和配置记录提交支持请求，进一步判断是否存在平台异常。

备注：内容仅供参考。