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