商業智能分析師在每個分析項目開始時都會面臨同樣的挑戰：回答一個業務問題所需的數據分散在多個表中。銷售交易在一個地方，客户人口統計和產品屬性在另一個地方，而退貨、預測和運營指標則位於其他表格中。
在此之前，在 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 主題——作為數據集+關係的容器
工作原理
- 創建單個數據集。每個數據集代表一個邏輯實體，例如銷售事實、客户維度或產品維度。
- 創建主題。主題充當您的語義邏輯數據模型容器。
- 定義關係。指定哪些列鏈接數據集。
- 分析。在分析工作表中，從多個數據集拖放字段，Quick Sight 執行運行時內連接。
- 聊天（問答）。詢問跨數據集自然語言問題，Quick Sight 使用關係生成跨數據集查詢。
當前版本説明：在當前版本中，關係使用內連接語義。行必須在兩個數據集中都有匹配鍵才能出現在結果中。
數據建模概念
在設計關係之前，回顧維度建模的核心構建塊會有所幫助。
維度建模
- 事實表——包含定量、可測量的數據（收入、數量、成本），具有特定粒度。事實表通常窄而高。
- 維度表——包含描述性屬性（客户姓名、產品類別、商店位置），提供上下文。維度表通常寬而短。
模式 描述 使用時機 星型模式 單個事實表被維度表包圍，所有直接連接 簡單、快速查詢；推薦默認 雪花模式 星型模式，但維度表規範化（分解） 減少大型維度中的冗餘 星系/星座模式 多個事實表共享一致的維度 跨流程分析（銷售 vs 退貨）
星型、雪花和星系/星座模式
維度中的層次類型
- 平衡（固定深度）：每個分支具有相同數量的級別（年>季>月>日）
- 參差不齊（可變深度）：分支具有不同深度，某些級別被跳過（國家>州>城市，有些沒有州）
- 遞歸（自引用）：表通過父-子鍵引用自身（員工>經理，組織圖）
- 拆分（並行）：實體屬於多個獨立層次結構（產品有品牌和類別層次結構）
最佳實踐
以下實踐幫助您構建一個隨着增長保持高性能和可維護性的多數據集模型。
- 從星型模式開始：星型模式是推薦的基礎：中央事實表作為核心數據集，維度表向外輻射。星型模式最大限度地減少了連接複雜性，並最大限度地提高了查詢性能。
- 將數據集設計為邏輯表：一個數據集 = 一個業務概念（客户、產品、訂單）。在可行的情況下，將雪花鏈預先連接到單個維度數據集中。包含代理鍵以實現乾淨連接。使用描述、同義詞和語義類型進行豐富。
- 定義清晰的連接鍵：儘可能使用整數代理鍵（更快的連接，更小的存儲）。確認關係兩側的數據類型匹配。從連接鍵列中移除空值（空值在內連接中從不匹配）。驗證參照完整性。事實表中的每個外鍵應存在於維度中。
- 刻意管理粒度：與同一事實相關的所有數據集應在兼容的粒度上可連接。如果維度粒度較粗，則聚合事實以匹配。對於多事實模型，確保共享維度具有單一、一致的粒度。
- 為AI和自然語言準確性豐富元數據：多數據集主題驅動Quick Sight的自然語言界面。豐富的元數據極大地提高了準確性。添加字段描述解釋業務含義。添加同義詞（例如收入→銷售額、收入、總金額）。設置語義類型（城市、貨幣、日期等）。添加業務規則的自定義指令。排除用户不需要的內部/技術列。
- 小心處理多事實場景：確認共享維度在所有事實上具有一致的粒度。明確哪些關係存在，避免創建不必要的連接。測試跨事實計算以驗證正確的聚合。
- 規劃增長：從聚焦模型開始（1個事實+關鍵維度）。逐步添加數據集。通過保持數據集和關係圖來記錄數據模型。使用命名約定：FACT_*、DIM_*、BRIDGE_*。
決策框架：何時使用多數據集 vs 預連接
場景 推薦方法 少於5個表且只有1個事實表的簡單分析 單個預連接數據集（傳統） 多個分析師詢問不同事實表上的不同問題 多數據集關係 需要外連接行為 單個預連接數據集（或等待未來版本） 自然語言或聊天驅動的探索 使用數據集和主題豐富的多數據集關係 多對多無橋接表 多數據集關係 角色扮演維度 多數據集關係（每個角色有單獨數據集）
入門 要開始使用，請閲讀《在 Amazon Quick Sight 中跨數據集構建統一語義層》。
下一部分：模式模式和高級變通方法
到目前為止，我們已經介紹了維度建模的基礎概念，包括星型、雪花和星系（星座）模式。我們還介紹了設計清晰連接鍵、管理粒度、豐富元數據和規劃增長的一般最佳實踐。
在第二部分中，我們從理論轉向實踐。我們將詳細講解每種模式模式，包括具體的表結構和示例SQL查詢。我們還將展示如何處理受支持的場景，如角色扮演維度和不同粒度的多事實模型。並解釋本機不支持的模式（包括循環連接、遞歸層次和參差不齊層次）的變通方法。
閲讀第二部分：《Amazon Quick Sight 多數據集關係的數據建模模式》