WASB驱动是一个传统的Hadoop文件系统驱动，其开发目的是为了支持FNS(扁平命名空间)Azure存储账户，这些账户不遵循文件-文件夹语法。因此，HDFS文件夹操作由WASB驱动在客户端模拟执行，某些文件夹操作（如重命名和删除）可能导致大量IOP，因为需要在客户端逐个枚举并协调blob的重命名/删除操作。对于其他API也不理想，因为初始路径检查（判断是文件还是文件夹）需要通过多次元数据调用来完成。这些因素导致了性能下降。
为了更好地服务分析用户，微软发布了支持HNS（分层命名空间）的ADLS Gen2，即具备文件-文件夹感知功能的存储账户。ABFS驱动旨在克服WASB的固有缺陷，并建议用户迁移至ABFS驱动。
传统WASB驱动程序的用户面临诸多挑战和限制：1. 他们无法利用最新ABFS驱动程序的优化和优势。2. 在分阶段过渡情况下，如果文件和文件夹同时被传统WASB驱动程序和ABFS驱动程序修改，他们需要处理兼容性问题。3. ABFS驱动程序对FNS和HNS支持的功能存在差异。4. 在某些情况下，他们必须对工作负载进行大量重新工作才能迁移到ABFS驱动程序，该驱动程序仅在启用了HNS的账户上经过全面测试和支持的场景中可用。
我们正在引入一项新功能，使ABFS驱动程序能够通过ABFS方案支持FNS账户（取代WASB驱动程序使用的BlobEndpoint）。该功能将使我们能够使用ABFS驱动程序与存储在GPv2（通用v2）存储账户中的数据进行交互。
通过此功能，仍在使用旧版WASB驱动程序的用户将能够迁移到ABFS驱动程序，而无需对其工作负载进行大量重新工作。不过，他们需要将URI从WASB方案更改为ABFS方案。
一旦ABFS驱动程序构建了支持FNS的能力以迁移WASB用户，WASB驱动程序将在下一个主要版本中被标记为移除。这将消除新用户加入时的任何混淆，因为Azure Storage将只有一个Microsoft驱动程序，迁移用户将获得驱动程序和服务的有SLA保障的支持，而这在WASB上是无法保证的。
我们预计该功能将作为用户转向启用HNS账户并使用ABFS驱动器的垫脚石，这是我们推荐的用于ADLS Gen2大数据分析的解决方案。
此功能不会影响现有使用ADLS Gen2账户（启用了HNS的账户）与ABFS驱动程序的用户。
他们无需对工作负载或配置进行任何更改。他们仍可享受HNS的优势，例如原子操作、细粒度访问控制、可扩展性和性能。
微软继续建议所有大数据与分析用户使用ABFS驱动程序访问Azure Data Lake Gen2（ADLS Gen2），并将在未来持续优化该方案。我们相信，这一新选项将帮助所有用户在规划最终迁移至ADLS Gen2（启用HNS的账户）的同时，立即过渡到受支持的使用场景。
WASB提供的以下认证类型将继续在新的FNS上通过ABFS驱动工作，该驱动配置接受这些SAS类型（类似于WASB）：1. SharedKey 2. Account SAS 3. Service/Container SAS
以下认证类型在WASB驱动中不受支持但在ABFS驱动中受支持，将继续通过ABFS驱动1.0为新FNS提供：1. OAuth 2.0客户端凭据 2. OAuth 2.0：刷新令牌 3. Azure托管身份 4. 自定义OAuth 2.0令牌提供程序
更多详情请参阅ABFS认证。
ABFS驱动程序的某些功能仅适用于使用HNS账户的用户。1. ABFS驱动程序的SAS令牌提供程序插件，支持用户委托SAS和固定SAS。2. 客户端提供的加密密钥（CPK）支持数据流入和流出。