数据建模
本文介绍有关 Azure Databricks 上的数据建模的考虑、注意事项和建议。 它面向正在设置新表或编写 ETL 工作负荷的用户，重点是了解影响将原始数据转换为新数据模型的 Azure Databricks 行为。 数据建模决策取决于组织和工作负荷使用表的方式。 选择的数据模型会影响查询性能、计算成本和存储成本。 本文还包括使用 Azure Databricks 进行数据库设计的基础概念介绍。
重要
本文仅适用于 Delta Lake 支持的表，其中包括所有 Unity Catalog 托管的表。
可以使用 Azure Databricks 来查询其他外部数据源，包括向 Lakehouse Federation 注册的表。 每个外部数据源都有不同的限制、语义和事务保证。 请参阅查询数据。
使用 Azure Databricks 构建的 Lakehouse 与其他企业数据仓库系统共享许多组件和概念。 在设计数据模型时，请考虑以下概念和功能。
Azure Databricks 将事务范围限定为各个表。 这意味着 Azure Databricks 不支持多表语句（也称为多语句事务）。
对于数据建模工作负荷，这意味着当引入源记录需要将行插入或更新到两个或多个表中时，必须执行多个独立事务。 每个事务的成功或失败可以独立于其他事务，下游查询需要容忍由于事务失败或延迟而导致的状态不匹配。
主键和外键仅供参考，不会被强制执行。 此模型在许多企业基于云的数据库系统中很常见，但与许多传统的关系数据库系统不同。 请参阅 Azure Databricks 上的约束。
在任何数据库设计中，联接都可能带来处理瓶颈。 在 Azure Databricks 上处理数据时，查询优化器会寻求优化联接计划，但当单个查询必须联接来自多个表的结果时，查询优化器可能会遇到困难。 当筛选参数位于另一个表的字段上时，优化器也可能无法跳过表中的记录，这可能会导致全表扫描。
Azure Databricks 支持使用半结构化数据源（包括 JSON、Avro 和 ProtoBuff），并将复杂数据存储为结构、JSON 字符串以及映射和数组。 请参阅对半结构化数据建模。
Azure Databricks 可以很好地处理任何数据模型。 如果有需要从 Azure Databricks 查询或迁移到 Azure Databricks 的现有数据模型，则应在重新架构数据之前评估性能。
如果要构建新的 Lakehouse 或向现有环境添加数据集，Azure Databricks 建议不要使用高度规范化的模型，例如第三范式 (3NF)。
星型架构或雪花架构等模型在 Azure Databricks 上表现良好，因为标准查询中存在的联接较少，需要保持同步的键也较少。此外，在单个表中包含更多数据字段可以让查询优化器使用文件级统计信息跳过大量数据。 有关跳过数据的详细信息，请参阅 Delta Lake 的数据跳过。