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