读取不存在的Azure存储路径时不同集群类型的行为差异问询

现象描述 #

读取Azure存储容器中不存在的路径时，不同Databricks集群类型表现出明显差异：

• no-isolation-shared/Personal集群：执行读取语句时直接抛出路径不存在的错误
• Standard（曾用名shared）集群：会返回一个无Schema、无内容的DataFrame，仅在调用display()、count()等Action类方法时才会触发路径不存在的错误

差异原因解析 #

这种差异并非单纯由Spark延迟求值导致，而是Databricks针对不同集群的定位，在存储客户端元数据校验时机上做了不同设计：

1. 隔离型集群（no-isolation-shared/Personal）的即时校验
   这类集群面向单用户隔离场景，优先级是操作的准确性与即时反馈。初始化Azure存储客户端时，默认开启了即时元数据校验：当执行spark.read相关代码时，客户端会立刻向Azure存储发起请求，校验目标路径的存在性与访问权限。一旦路径不存在，直接抛出错误，不会进入Spark的延迟执行流程。

2. 共享型集群（Standard）的延迟校验
   Standard集群是多用户共享的资源池，核心目标是提升资源利用率、减少不必要的存储交互。因此默认采用延迟元数据校验：执行spark.read时，仅会构建DataFrame的逻辑执行计划，不会立即触发Azure存储的元数据查询。只有当触发Action类操作（触发实际计算的操作）时，才会真正访问存储系统，此时才会发现路径不存在并抛出错误。

简单来说，隔离型集群提前做了校验，而共享集群把校验延迟到了实际计算触发时，这才是两种集群行为差异的核心原因。

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