如果您一直將 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 行為後，再移除傳統主題。