外表（有时称为“联合表”），是使用 Unity Catalog 作为外部目录的一部分注册的表。 外部表包含由外部系统管理的数据和元数据，Unity Catalog添加数据治理功能以管理并查询这些表。
Azure Databricks 支持注册外表的以下方法：
- 查询联合 使用安全的 JDBC 连接来联合到外部数据系统，例如 PostgreSQL 和 MySQL。
- 目录联合将外部目录（例如 Hive Metastore、AWS Glue 或 Snowflake Horizon Catalog）连接起来，使得可以直接在文件存储中查询数据。
重要
外部目录中的所有表都是外部数据表，外部数据表必须存储于外部数据目录。
为了保持与旧版 Apache Spark 和 Azure Databricks 工作负载的向后兼容性，联合 Hive 元存储中的外部表将从 Hive 元存储返回元数据，包括该表是 Hive 管理表还是 Hive 外部表。
为什么要使用外表？
在将 Azure Databricks 与现有数据系统集成或从旧系统迁移时，外部表提供了灵活性。
许多外部表作为临时解决方案，用于直接访问 Azure Databricks 未管理的数据，因为它们提供了快速解决方案，而无需对上游 ETL 流程和工作流进行数据迁移或代码重构。 Databricks 建议将驱动生产工作负载或频繁查询的数据集迁移到 Unity Catalog 托管表，因为托管表提供最佳性能，同时拥有诸多内置优化。
查询联合提供了一种补充解决方案，用于从 Lakeflow Connect 不支持的外部数据系统加载数据。 Databricks 建议使用具体化视图将外表复制到 Unity Catalog。 请参阅 使用物化视图从外表加载数据。
创建或写入外表
如果你拥有足够的权限，并且工作区已配置了内部联合 Hive 元存储，则可以创建或写入由内部联合 Hive 元存储支持的外表。 外部联合 Hive 元存储以及 Lakehouse Federation 支持的所有外表都是只读的。
Azure Databricks 不管理向外表写入的元数据、数据或语义。 外部表可能由符合 ACID 的格式（如 Delta Lake 或 Apache Iceberg）提供支持，但外部表不提供 Unity 目录托管表的事务保证。
大多数 Azure Databricks 的优化措施，包括查询性能、写入速度增强、数据跳过以及仅元数据查询，都需要使用 Unity Catalog。 Databricks 建议使用最新的 Databricks Runtime 版本比较外表和 Unity Catalog 托管表之间的读取和写入查询性能，以评估延迟和成本差异。 请参阅 Azure Databricks for Delta Lake 和 Apache Iceberg 中的 Unity 目录托管表。