为数据集注入业务上下文：在 Amazon QuickSight 中从传统主题迁移到语义数据集

如果您一直将 Amazon QuickSight 的传统主题与数据集一起管理，您就会知道其中的挑战：两个资产必须保持完美同步，每个资产都有自己的权限、血统和版本控制。列同义词会漂移，计算字段会分叉，数据集中的重命名会静默地破坏传统主题。现在，您可以通过新的数据准备体验中的“数据集富化”功能，将业务上下文直接嵌入数据集本身。列描述、同义词、计算字段、自定义指令和业务规则都与数据共存。数据集富化将业务上下文直接烘焙到数据集中。所有内容（权限、语义、AI 上下文）都与数据一起传播，并自动被基于该数据构建的任何内容继承。一个资产，一个真相源，一个治理点。在本文中，我们将介绍什么是数据集富化，它与传统主题有何不同，并提供三个迁移场景以及逐步指导，以便您能够放心地将业务上下文迁移到数据集层。

主题现在是多数据集语义和推理层，是组合多个数据集、定义关系、编写业务指标和映射业务术语的构造。我们并非引入全新的构造，而是重新调整主题的用途，使其更充分地履行这一角色。将数据集固有的语义下移到它们所属的地方，并将主题提升到拥有跨数据集关系、指标和业务术语的层面，这是主题一直以来的使命。这并非表面上的改变。它建立了一个清晰、前瞻的架构，支持基于共享语义基础的确切 BI 工作流和灵活的 AI 驱动分析。它也为目录集成奠定了框架。

什么是传统主题？传统主题提供了在 Amazon QuickSight 数据集中添加业务上下文的最初方法。它将列同义词、计算字段、命名实体、过滤器和自定义指令存储在一个独立的对象中，该对象位于数据集之上，两者链接但独立管理。今后，我们将现有主题归类为传统主题。新版主题被提升为多数据集语义层，是跨数据集 Q&A 的单一入口点，允许业务用户和 AI 工作流在一个对话中跨多个富化数据集进行查询。数据集富化是实现这一目标的基础：每个数据集必须携带自己的语义上下文，然后主题才能在更高层次上统一它们。

关键区别：传统主题 vs. 数据集富化（新数据准备）

| 方面 | 传统主题 | 数据集富化 | |------|----------|------------| | 元数据位置 | 单独的与传统主题对象，链接到数据集 | 数据集元数据内部 | | 列同义词 | 在传统主题的“列同义词”中定义 | 在列的“附加说明”中定义 | | 业务规则和过滤器 | 带有结构化条件的命名过滤器 | 自定义指令中的基于文本的规则 | | 计算字段 | 传统主题级别的计算（命名表达式） | 计算列（行级转换） | | 命名实体 | 带有同义词的结构化实体对象 | 自定义指令中的文本项（数据集输出选项卡） | | 自定义指令 | 传统主题上的自定义指令字符串 | 自定义指令中的文本项（数据集输出选项卡） | | 治理 | 两个资产需要权限和审计 | 一个资产需要权限和审计 | | 语义类型 | 字段的属性 | 列的属性 | | 聚合级别 | 字段的属性 | 由代理在运行时根据查询处理 |

迁移过程中保持不变的内容 并非所有内容都会改变。在迁移期间，QuickSight 环境的以下方面保持不变：规则数据集不需要迁移。基于规则的逻辑继续像以前一样工作。SPICE 存储和直接查询模式不受影响。无论您使用主题还是数据集富化，数据访问模式保持不变。仪表板和分析不会被重建。它们使用富化数据集。面向用户的 Q&A 交互模型不会改变。用户仍然通过 Amazon Quick Chat 用自然语言提问。这种变化对用户来说是透明的。

为什么将业务上下文迁移到数据集中？ 当业务元数据存在于单独的传统主题对象中时，您需要管理必须保持同步的两个资产。权限、血统和可发现性跨边界分割。数据集富化消除了这个问题：单一真相源。业务上下文与数据一起传播。没有单独的资产会不同步。自动继承。任何构建在富化数据集上的仪表板、分析、传统主题或 AI 驱动的聊天功能都会继承语义上下文，无需额外配置。更简单的治理。一个资产即可管理权限、审计和版本控制。AI 就绪性。数据集对自然语言查询来说变得自描述。Amazon Quick 的聊天体验可以直接从数据集元数据中解析模糊的业务语言，无需单独的主题。

数据集富化中数据集定义的变更 新的数据准备体验在数据集上引入了 semantic_model_configuration。它有两个层次：

列级元数据（在 TableMap 内）：

• 描述：字段的含义。
• 附加说明：用户可能使用的同义词和替代名称。

数据集级元数据（在 SemanticMetadata 内）：

• 描述：数据集的总体摘要。
• 自定义指令：业务逻辑、公式、命名实体和规则。

从传统主题字段到数据集富化的映射：

| 传统主题字段 | 数据集 SemanticModel 目标 | |--------------|---------------------------| | ColumnDescription | ColumnProperties.Description.Text | | ColumnSynonyms[] | ColumnProperties.AdditionalNotes.Text（逗号连接） | | CalculatedFields.Expression | DataPrepConfiguration → CreateColumnsStep | | NamedEntities.EntityName + EntityDescription + Definition | CustomInstructions.InlineCustomInstruction.InstructionText（格式：“实体名称：定义（字段：…）（同义词：…）”） | | Filters | CustomInstructions.InlineCustomInstruction.InstructionText（格式：“业务规则 – 名称：输出列名称 IN [值]”） | | CustomInstructionsString | CustomInstructions.InlineCustomInstruction.InstructionText |

解决方案概述 迁移是一个四步过程。您识别目标数据集，定位源传统主题，并运行一个 Python 脚本，该脚本提取传统主题的元数据，并通过 QuickSight API 将其写入数据集的 SemanticModelConfiguration。该脚本一次处理列描述、同义词、计算字段、命名实体、过滤器和自定义指令。无需手动 UI 操作。

前提条件 在开始之前，请确保您已具备以下条件：AWS CLI v2（2.34.50 或更高版本）已安装并配置了有效凭证。运行 aws sts get-caller-identity 确认会话处于活动状态。Python 3.6 或更高版本。Amazon QuickSight 企业版，并启用 Q 功能。目标数据集使用新的数据准备体验（DataPrepConfiguration，而非 LogicalTableMap），且所有 InputColumns 上都有列 ID。一个现有的传统主题（源），包含列、描述、同义词，以及可选的复杂字段、实体和过滤器。IAM 权限：quicksight:DescribeDataSet、quicksight:UpdateDataSet、quicksight:DescribeTopic。

迁移场景 正确的方法取决于您当前的设置。我们涵盖三种场景，从最简单到最复杂。

场景 1：传统数据集，无传统主题 您的数据集是使用经典 QuickSight 体验构建的，没有任何语义层。用户看到原始列名。当有人在 Amazon Quick Chat 中输入自然语言问题时，系统没有任何上下文。传统数据集（使用 LogicalTableMap）不支持数据集富化。目前没有就地升级路径。您可以选择使用数据集 Q&A 功能直接查询数据集。

场景 2：传统主题与传统数据集 一个主题位于传统数据集之上，提供用户依赖的语义层。但底层数据集没有富化，仍使用 LogicalTableMap。与传统数据集一样，它不支持 SemanticModelConfiguration。前进的道路是创建一个使用新数据准备体验的新数据集，将传统主题元数据迁移到其中作为数据集富化，验证结果，然后切换。或者，您可以使用传统数据集的数据集 Q&A 功能。

场景 3：传统主题与新数据准备数据集 当前状态：您已经为数据集使用了新的数据准备体验。它具有 DataPrepConfiguration，但传统主题仍然叠加在顶层提供语义上下文。数据集结构本身就支持富化，但尚未应用。这是唯一支持直接就地迁移的场景。因为数据集使用 DataPrepConfiguration，您可以直接将 SemanticModelConfiguration 传递给 update-data-set API。这意味着您可以迁移列描述和同义词、计算字段、命名实体、过滤器和自定义指令。在迁移期间保持传统主题激活，两者可以暂时共存。验证富化数据集的 Q&A 行为后，再移除传统主题。