创建Azure Unity Catalog时为何需Azure Databricks Connector而非服务主体？

你提到的服务主体确实能实现Azure存储账户的身份验证，但Unity Catalog的核心是统一数据治理，而非单纯的权限打通，第三方连接器（Azure Databricks Connector）的价值正是填补服务主体在治理能力上的空白，具体原因如下：

• 统一元数据映射：Unity Catalog需要将存储账户中的物理数据（比如ADLS Gen2的文件路径）转化为Catalog、Schema、Table这类逻辑数据对象，让你可以用SQL直接访问数据，无需每次拼接存储路径。服务主体仅能完成身份验证，无法实现物理存储与逻辑元数据的绑定管理。

• 细粒度权限联动：Unity Catalog的权限管控基于逻辑对象（如表、视图），而非存储账户的文件/Blob权限。连接器会自动将逻辑对象的权限（如SELECT、INSERT）映射为底层存储的访问权限，无需手动在存储账户中配置大量ACL规则。服务主体做不到这种权限的自动同步与精细化关联。

• 跨存储统一体验：如果你的数据分布在不同存储服务（甚至跨云），连接器提供了标准化的访问接口，无论底层是ADLS、S3还是GCS，在Unity Catalog中都能以一致的逻辑模型操作数据。服务主体仅与单个Azure存储账户绑定，无法提供这种跨环境的统一访问能力。

• 完整审计链路：Unity Catalog的审计日志会记录对逻辑数据对象的操作，连接器负责将这些操作与底层存储的访问行为关联，确保审计数据覆盖从逻辑操作到物理访问的全链路。单纯使用服务主体的话，审计仅能到存储层面，无法关联到具体的表或用户操作。

需要明确的是：服务主体是连接器工作的基础——连接器依赖服务主体完成与存储账户的身份验证，但连接器的核心价值是在服务主体的基础上，提供Unity Catalog所需的元数据管理、权限映射等治理能力，而非替代服务主体。

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