重要
DBFS 根和 DBFS 挂载点均已弃用，Databricks 不推荐使用这些功能。 无需访问这些功能即可预配新帐户。 Databricks 建议改用 Unity 目录 卷、 外部位置或 工作区文件 。
Unity Catalog 引入了许多新配置和理念，这些在数据治理上的方法与 DBFS 完全不同。 本文概述了有关使用 Unity 目录外部位置和 DBFS 的几个最佳做法。
对于启用了 Unity Catalog 的 Azure Databricks 工作区中的大多数用例，Databricks 不建议使用 DBFS 和挂载的云对象存储。 本文介绍应使用已装载的云对象存储的几种方案。 请注意，Databricks 不建议将 DBFS 根目录与 Unity 目录结合使用，除非必须将存储在其中的文件或数据迁移到 Unity 目录中。
如何在已启用 Unity 目录的工作区中使用 DBFS？
对hive_metastore表执行的操作使用旧数据访问模式，这些模式可能包括由DBFS管理的数据和存储凭据。 工作区范围内的 hive_metastore 托管表存储在 DBFS 根目录中。
DBFS 如何在专用访问模式下工作（以前是单用户访问模式）？
使用专用访问模式配置的计算资源对 DBFS 具有完全访问权限，包括 DBFS 根目录中的所有文件和已装载的数据。
DBFS 如何在标准访问模式（以前共享访问模式）中工作？
标准访问模式将 Unity 目录数据管理与 Azure Databricks 旧表 ACL 相结合。 只有具有显式授予权限的用户才能访问在 hive_metastore 中的数据。
要直接使用 DBFS 与文件交互，必须已获得 ANY FILE 权限。 由于 ANY FILE 允许用户绕过旧表的 ACLs 并访问 DBFS 管理的所有数据，因此 Databricks 建议在授予此权限时要谨慎。
不要将 DBFS 与 Unity 目录外部位置配合使用
Unity Catalog 通过使用完整的云 URI 路径来识别托管对象存储目录上的权限，从而保证对外部位置数据访问的安全性。 DBFS 装载使用完全不同的数据访问模型，该模型完全绕过 Unity 目录。 Databricks 建议不要在 DBFS 装载和 UC 外部卷之间重复使用云对象存储卷，包括在工作区或帐户之间共享数据时。
保护 Unity Catalog 管理的存储
Unity Catalog 使用托管存储位置来存储托管表和卷的数据文件。
Databricks 建议对托管存储位置执行以下操作：
- 使用新的存储帐户或存储桶。
- 为 Unity 目录定义自定义标识策略。
- 限制对由 Unity 目录管理的 Azure Databricks 的所有访问。
- 限制对为 Unity 目录创建的标识访问策略的所有访问。
将现有数据添加到外部存储位置
可以使用外部位置将现有存储帐户加载到 Unity 目录中。 为了获得最大的安全性，Databricks 建议仅在撤销所有其他存储凭据和访问模式后将存储帐户加载到外部位置。
不应把用作 DBFS 根目录的存储帐户作为 Unity Catalog 中的外部位置加载。
Unity Catalog 文件系统访问将忽略集群配置
Unity 目录不遵循文件系统设置的群集配置。 这意味着使用 Unity 目录访问数据时，使用云对象存储配置自定义行为的 Hadoop 文件系统设置不起作用。
关于多个路径访问的限制
虽然通常可以将 Unity 目录和 DBFS 一起使用，但不能使用不同访问方法在同一命令或笔记本单元中引用相同或共享父/子关系的路径。
例如，如果在foo的位置hive_metastore定义了外部表a/b/c，并且在 Unity 目录中定义了外部位置a/b/，则以下代码将引发错误：
spark.read.table("foo").filter("id IS NOT NULL").write.mode("overwrite").save("a/b/c")
如果此逻辑分为两个单元格，则不会出现此错误：
df = spark.read.table("foo").filter("id IS NOT NULL")
df.write.mode("overwrite").save("a/b/c")