Azure ML中DatabricksStep使用PipelineParameter传递参数失效问题咨询

你的问题核心是PipelineParameter传递到Databricks笔记本时始终使用默认值，无法被运行时传入的参数覆盖，我来帮你拆解可能的原因和修复方法：

1. 先确认笔记本的参数读取逻辑 #

你在笔记本里用dbutils.widgets.text("StartDate", "", "StartDate(YYYY-MM-DD)")创建了参数控件，但要确保后续代码是主动读取这个参数的值，而不是误用到了控件的默认值。

请在笔记本中添加明确的参数读取代码，验证实际接收到的值：

# 创建参数控件后，一定要主动获取传入的值
start_date = dbutils.widgets.get("StartDate")
print(f"Databricks notebook received StartDate: {start_date}")

这一步可以帮你排除“笔记本内部没正确读取参数”的可能性。

2. 检查已发布管道的运行参数传递方式 #

你定义PipelineParameter的语法是正确的，但很容易忽略：发布管道后，必须在启动运行时明确传递参数值，而不是只在创建管道阶段定义参数。

如果通过AML UI运行： #

• 进入已发布管道页面，点击「创建运行」
• 在弹出的参数配置面板中，找到StartDate参数，手动输入你想要的2021-01-19，再启动运行（注意参数名大小写必须和PipelineParameter的name完全一致）

如果通过代码运行： #

from azureml.pipeline.core import PublishedPipeline

# 获取已发布的管道
published_pipeline = PublishedPipeline.get(workspace=your_workspace, id="<你的管道ID>")
# 启动运行时必须显式传入参数
pipeline_run = your_experiment.submit(
    published_pipeline,
    parameters={"StartDate": "2021-01-19"}
)

3. 排除运行复用的影响 #

你设置了allow_reuse=False，这一点是正确的——它会强制每次运行重新执行步骤，不会复用之前带默认参数的运行结果，所以复用旧运行的问题可以排除。

4. 快速定位问题的测试方法 #

为了快速区分是参数传递环节的问题，还是笔记本逻辑的问题，你可以先临时移除PipelineParameter，直接给notebook_params传固定值测试：

data_loading_step = DatabricksStep(
    name="Data Loading",
    existing_cluster_id=db_cluster_id,
    notebook_path=data_loading_path,
    run_name="Loading raw data",
    notebook_params={
        'StartDate': '2021-01-19',  # 直接传固定值
    },
    compute_target=dbricks_compute,
    instance_pool_id=instance_pool_id,
    num_workers=num_workers,
    allow_reuse=False
)

如果笔记本能接收到2021-01-19，说明问题出在PipelineParameter的运行时传递环节，回到步骤2确认参数传递的正确性即可。

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