AzureML并行处理作业SAS令牌过期问题咨询与解决方案

1. 关于SAS令牌过期的判断是否正确？ #

正确。你的场景完全符合SAS令牌过期的特征：

• 小文件作业（10分钟）在令牌有效期内完成，无报错；
• 大文件作业（3.5小时）超过AzureML默认SAS令牌有效期（通常为3小时），在写入阶段触发403错误，日志明确提示无法获取SAS令牌；
• 并行组件output_action=summary_only需要显式写入文件，此时依赖的SAS令牌已过期，导致存储API调用失败。

2. 能否延长SAS令牌过期时间？ #

可以。AzureML支持调整SAS令牌的有效期，具体可通过以下方式实现：

• 通过SDK提交作业时配置：在定义作业的输入/输出数据引用时，指定token_expiration参数设置更长的有效期（例如设置为4小时或更久）。示例代码：

  from azureml.core import Dataset
  
  input_dataset = Dataset.File.from_files(path="azureml://datastores/<your_datastore>/paths/<folder_path>")
  input_with_longer_token = input_dataset.as_named_input("input_data").with_token_expiration("4h")
  

• 修改数据存储配置：在AzureML工作室或SDK中，修改目标数据存储的SAS令牌有效期设置，将默认时长调整为覆盖作业最长运行时间。

3. 无法延长令牌时的替代方案 #

如果因权限或平台限制无法调整令牌时长，可采用以下方案：

• 拆分大任务：将3.5小时的作业拆分为多个子任务，每个子任务运行时间控制在令牌有效期内，完成后独立写入输出，最后合并结果；
• 使用托管身份访问存储：为计算集群或作业启用托管身份，给身份分配Blob存储的Storage Blob Data Contributor角色，替代SAS令牌访问。这种方式无令牌过期问题，更安全稳定；
• 本地临时存储缓存：先将处理后的文件写入计算节点的本地临时存储（如$AZ_BATCH_TASK_WORKING_DIR），待所有处理完成后，一次性上传到Blob存储，减少中间存储访问的令牌依赖；
• 调整并行组件输出策略：若业务允许，将output_action改为upload_files或append_row，利用AzureML内置的输出管理机制，避免显式写入时的令牌过期问题。

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