如何在Azure Data Factory V2中运行带依赖的PySpark作业

我帮你梳理下这个问题的解决思路，毕竟本地spark-submit能跑通，但ADF配置后出问题，大概率是路径配置或者ADF活动参数使用方式不对。

首先，你之前在sparkConfig里设置spark.submit.pyFiles的方式虽然可行，但ADF的HDInsightSpark活动其实提供了更直接的pyFiles属性来管理依赖，这个方式更可靠，也符合ADF的设计规范。

调整后的ADF活动配置 #

这里是修改后的配置，重点改动了typeProperties部分，添加了专门的pyFiles字段来指定egg依赖：

{
  "name": "dimension",
  "properties": {
    "activities": [
      {
        "name": "Spark1",
        "type": "HDInsightSpark",
        "policy": {
          "timeout": "7.00:00:00",
          "retry": 0,
          "retryIntervalInSeconds": 30,
          "secureOutput": false
        },
        "typeProperties": {
          "rootPath": "adfspark",
          "entryFilePath": "main.py",
          "getDebugInfo": "Always",
          // 新增pyFiles字段，指定依赖的egg文件路径
          "pyFiles": [
            "pyFiles/0.3-py3.6.egg"
          ],
          "sparkJobLinkedService": {
            "referenceName": "AzureStorageLinkedService",
            "type": "LinkedServiceReference"
          }
        },
        "linkedServiceName": {
          "referenceName": "hdinsightlinkedService",
          "type": "LinkedServiceReference"
        }
      }
    ]
  }
}

关键配置说明 #

• pyFiles字段：这是ADF HDInsightSpark活动专门用来声明Python依赖（egg、zip、py文件）的参数，接收一个数组。这里用相对路径pyFiles/0.3-py3.6.egg是因为你的rootPath已经设为adfspark，所以这个路径对应存储容器里的adfspark/pyFiles/0.3-py3.6.egg，和你实际的文件存储位置匹配。
• 路径替代方案：如果你想用完整的wasb路径也可以，格式是wasb://adfspark@<你的存储账户名>.blob.core.windows.net/pyFiles/0.3-py3.6.egg，把<你的存储账户名>替换成实际名称即可。
• 移除冲突配置：建议删掉之前的spark.submit.pyFiles配置，避免和pyFiles字段产生冲突。

额外验证步骤 #

• 检查LinkedService权限：确保AzureStorageLinkedService有访问该存储容器的权限（比如使用账户密钥或者托管标识，且权限足够读取文件）。
• 调试日志排查：因为你已经设置了getDebugInfo": "Always"，运行后可以在ADF活动的输出中找到日志链接，查看是否有“找不到依赖文件”之类的错误信息，方便快速定位问题。
• 分布式执行准备：如果后续要分布式执行，只要依赖文件在HDInsight集群能访问的存储（默认存储或附加存储）中，ADF会自动把依赖分发到各个节点，不需要额外配置，确保路径正确即可。

为什么之前的配置可能失效？ #

之前在sparkConfig里设置spark.submit.pyFiles时，可能因为ADF对相对路径的解析逻辑和本地spark-submit不同，导致集群找不到依赖文件。而用ADF原生的pyFiles字段，系统会自动处理路径映射和文件分发，可靠性更高。

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