Databricks中Spark读ABFSS报403但dbutils正常的问题排查

1. 核对Spark代理配置的完整性 #

dbutils与Spark的代理配置相互独立，即便修复了dbutils的代理，Spark可能未同步生效：

• 执行spark.conf.get("spark.driver.proxyHost")和spark.conf.get("spark.driver.proxyPort")，确认参数与修复dbutils时使用的代理一致
• 若为集群级代理，检查集群Spark配置是否添加了全套代理参数：
  • spark.driver.proxyHost
  • spark.driver.proxyPort
  • spark.executor.proxyHost
  • spark.executor.proxyPort
• 若代理需要认证，确认是否配置了spark.driver.proxyUser和spark.driver.proxyPassword——dbutils可能自动继承了系统级认证信息，但Spark不会默认同步

2. 排查认证机制的差异 #

dbutils与Spark访问ADLS/Blob的认证逻辑可能不同：

• 若使用服务主体认证，检查Spark配置中spark.azure.storage.account.key.myhost.com、spark.azure.storage.account.oauth2.client.id.myhost.com等参数是否正确配置。dbutils可能用了集群默认MSI认证，但Spark读Delta时未加载对应权限配置
• 执行spark.conf.get("spark.azure.storage.account.*myhost.com*")查看所有存储账户相关配置，确认无关键参数遗漏
• 若使用MSI认证，核实集群executor的MSI权限：dbutils运行在driver节点，可能使用Notebook用户的MSI；而Spark读数据时会调用executor节点的MSI，后者可能未被授予目标容器的读取权限

3. 检查Delta Lake特定问题 #

• 确认路径完全一致：dbutils.fs.ls与spark.read.load的路径需完全匹配，注意ADLS/Blob路径大小写敏感
• 测试Delta日志目录权限：执行dbutils.fs.ls("abfss://myname@myhost.com/mytable/_delta_log/")，若此操作也报403，说明核心权限问题在Delta元数据目录
• 排查Delta专属配置：比如spark.databricks.delta.storage.checkpointPath等参数是否错误修改了存储访问路径

4. 验证网络路径的一致性 #

• 虽然测试了443端口，但Spark executor的网络路径可能与driver不同：dbutils仅在driver节点运行，而Spark读数据时会让executor直接访问存储。需确认executor节点的代理配置正确，且能连通存储账户端点
• 检查存储账户防火墙规则：确保集群所有节点（含executor）的IP都在允许列表中，避免仅开放了driver节点IP
• 用SQL方式测试：执行spark.sql("SELECT * FROM delta.abfss://myname@myhost.com/mytable/ LIMIT 1")，排除DataFrame API的特定问题

5. 确认配置优先级 #

• 若在Notebook中临时设置Spark配置，可能未覆盖集群级默认配置，或被SparkSession初始化时的高优先级配置覆盖
• 尝试将代理、存储认证配置添加到集群启动参数中，确保配置在整个Spark应用生命周期内生效

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