Amazon Quick Sight 多数据集关系的数据建模最佳实践

商业智能分析师在每个分析项目开始时都会面临同样的挑战：回答一个业务问题所需的数据分散在多个表中。销售交易在一个地方，客户人口统计和产品属性在另一个地方，而退货、预测和运营指标则位于其他表格中。

在此之前，在 Amazon Quick Sight 中组合这些表需要预先将所有内容连接成宽泛的反范式数据集，然后才能开始分析。这种方法可行，但它强制在前期做出数据建模决策，在不同粒度上复制度量，引入维护开销，并且通常为几乎每个报表场景生成不同的数据集。

今天，我们很高兴地宣布推出 Amazon Quick Sight 的多数据集关系。这项新功能允许您定义 Quick Sight 数据集之间的逻辑关系，并在查询时执行运行时连接。您无需提前扁平化表格，而是将每个表保留为自己的 Quick Sight 数据集，并在 Quick Sight 主题中声明这些数据集如何相互关联。随后，Quick Sight 会为可视化、计算字段、过滤器或自然语言问答精确地组装所需的连接。

这种范式转变带来了几个关键优势：

• 减少前期数据准备：定义一次关系，Quick Sight 仅在分析时连接相关表。
• 保持原生粒度：每个数据集保持自身的细节级别，避免跨粒度度量重复。
• 跨分析重用：一个包含定义关系的主题可以服务于多个分析用例，无需重建数据集。
• 简化治理：在单个数据集级别管理权限、转换和业务逻辑。
• 独立刷新计划：根据数据波动性，按不同节奏（每小时、每天、每月）摄取每个表的数据。
• 运行时行级安全：在运行时连接期间强制执行行级安全规则，因此数据访问策略跨数据集一致应用。

在本文中，我们涵盖数据建模概念、支持的模式以及在 Quick Sight 中设计多数据集数据模型的最佳实践。有关每种模式模式的深入探讨（含 SQL 示例和高级变通方法），请参阅本系列的第二篇文章：《Amazon Quick Sight 多数据集关系的数据建模模式》。

为什么选择运行时、基于关系的模型？

传统的单数据集模型有三个反复出现的成本：

• 前期准备：在了解所有问题之前，您必须决定连接形状，通常将逻辑推入自定义 SQL 或数据库视图。
• 度量重复：当将事实表连接到更高粒度的维度时，“一”侧的度量会在“多”侧复制，除非仔细去重，否则会夸大求和。
• 数据集蔓延：每个分析场景往往会产生自己的专用扁平数据集，从而增加维护工作。

基于关系的模型解决了所有这三个问题。您只需建模一次表，将每个表保留在其原生细节级别，并让引擎仅引入特定可视化实际需要的表。

理解架构

多数据集关系依赖于两个不同的建模层。理解它们的区别有助于您决定每部分逻辑属于何处。

两层：逻辑层和物理层

• 物理层——在数据集内部。单个 Quick Sight 数据集是您通过连接、联合、SQL 和转换将物理表合并为一个扁平结果的地方。将其视为组合共享相同粒度且始终属于一起的表。
• 逻辑层——跨主题中的数据集。每个数据集充当一个逻辑表。在主题中，您将这些逻辑表相互关联。它们不会合并，而是保持独立并保持自己的粒度。仅当可视化、计算、过滤器或聊天问题需要来自多个数据集的字段时，Quick Sight 才会组合它们。

概念 Quick Sight 实现 逻辑表 Quick Sight 数据集（可包含内部连接、转换、计算字段） 关系 在 Quick Sight 主题中定义，通过匹配键列 运行时连接 在查询时执行，当可视化或计算引用多个数据集的字段时 数据模型 Quick Sight 主题——作为数据集+关系的容器

工作原理

1. 创建单个数据集。每个数据集代表一个逻辑实体，例如销售事实、客户维度或产品维度。
2. 创建主题。主题充当您的语义逻辑数据模型容器。
3. 定义关系。指定哪些列链接数据集。
4. 分析。在分析工作表中，从多个数据集拖放字段，Quick Sight 执行运行时内连接。
5. 聊天（问答）。询问跨数据集自然语言问题，Quick Sight 使用关系生成跨数据集查询。

当前版本说明：在当前版本中，关系使用内连接语义。行必须在两个数据集中都有匹配键才能出现在结果中。

数据建模概念

在设计关系之前，回顾维度建模的核心构建块会有所帮助。

维度建模

• 事实表——包含定量、可测量的数据（收入、数量、成本），具有特定粒度。事实表通常窄而高。
• 维度表——包含描述性属性（客户姓名、产品类别、商店位置），提供上下文。维度表通常宽而短。

模式 描述 使用时机 星型模式 单个事实表被维度表包围，所有直接连接 简单、快速查询；推荐默认 雪花模式 星型模式，但维度表规范化（分解） 减少大型维度中的冗余 星系/星座模式 多个事实表共享一致的维度 跨流程分析（销售 vs 退货）

星型、雪花和星系/星座模式

维度中的层次类型

• 平衡（固定深度）：每个分支具有相同数量的级别（年>季>月>日）
• 参差不齐（可变深度）：分支具有不同深度，某些级别被跳过（国家>州>城市，有些没有州）
• 递归（自引用）：表通过父-子键引用自身（员工>经理，组织图）
• 拆分（并行）：实体属于多个独立层次结构（产品有品牌和类别层次结构）

最佳实践

以下实践帮助您构建一个随着增长保持高性能和可维护性的多数据集模型。

1. 从星型模式开始：星型模式是推荐的基础：中央事实表作为核心数据集，维度表向外辐射。星型模式最大限度地减少了连接复杂性，并最大限度地提高了查询性能。

1. 将数据集设计为逻辑表：一个数据集 = 一个业务概念（客户、产品、订单）。在可行的情况下，将雪花链预先连接到单个维度数据集中。包含代理键以实现干净连接。使用描述、同义词和语义类型进行丰富。

1. 定义清晰的连接键：尽可能使用整数代理键（更快的连接，更小的存储）。确认关系两侧的数据类型匹配。从连接键列中移除空值（空值在内连接中从不匹配）。验证参照完整性。事实表中的每个外键应存在于维度中。

1. 刻意管理粒度：与同一事实相关的所有数据集应在兼容的粒度上可连接。如果维度粒度较粗，则聚合事实以匹配。对于多事实模型，确保共享维度具有单一、一致的粒度。

1. 为AI和自然语言准确性丰富元数据：多数据集主题驱动Quick Sight的自然语言界面。丰富的元数据极大地提高了准确性。添加字段描述解释业务含义。添加同义词（例如收入→销售额、收入、总金额）。设置语义类型（城市、货币、日期等）。添加业务规则的自定义指令。排除用户不需要的内部/技术列。

1. 小心处理多事实场景：确认共享维度在所有事实上具有一致的粒度。明确哪些关系存在，避免创建不必要的连接。测试跨事实计算以验证正确的聚合。

1. 规划增长：从聚焦模型开始（1个事实+关键维度）。逐步添加数据集。通过保持数据集和关系图来记录数据模型。使用命名约定：FACT_*、DIM_*、BRIDGE_*。

决策框架：何时使用多数据集 vs 预连接

场景 推荐方法 少于5个表且只有1个事实表的简单分析 单个预连接数据集（传统） 多个分析师询问不同事实表上的不同问题 多数据集关系 需要外连接行为 单个预连接数据集（或等待未来版本） 自然语言或聊天驱动的探索 使用数据集和主题丰富的多数据集关系 多对多无桥接表 多数据集关系 角色扮演维度 多数据集关系（每个角色有单独数据集）

入门 要开始使用，请阅读《在 Amazon Quick Sight 中跨数据集构建统一语义层》。

下一部分：模式模式和高级变通方法

到目前为止，我们已经介绍了维度建模的基础概念，包括星型、雪花和星系（星座）模式。我们还介绍了设计清晰连接键、管理粒度、丰富元数据和规划增长的一般最佳实践。

在第二部分中，我们从理论转向实践。我们将详细讲解每种模式模式，包括具体的表结构和示例SQL查询。我们还将展示如何处理受支持的场景，如角色扮演维度和不同粒度的多事实模型。并解释本机不支持的模式（包括循环连接、递归层次和参差不齐层次）的变通方法。

阅读第二部分：《Amazon Quick Sight 多数据集关系的数据建模模式》