AI News HubLIVE
站內改寫4 分鐘閱讀

利用多資料集主題在 Amazon Quick 中構建跨資料集的統一語義層

Amazon Quick Sight 推出多資料集主題(公開預覽),允許使用者在一個主題中新增最多 12 個資料集並定義關係,AI 聊天機器人可自動遍歷關係生成跨資料集查詢,實現統一語義層,簡化分析。

來源AWS Machine Learning Blog作者: Emily Zhu

Amazon Quick 是一項 AI 驅動的統一智慧服務,連線結構化資料和 unstructured 企業內容,使團隊能夠在一個地方進行探索、分析和行動。Amazon Quick Sight 是 Amazon Quick 中的商業智慧(BI)功能,提供互動式儀表板、自然語言查詢、畫素級完美報告、機器學習(ML)驅動的洞察以及嵌入式分析。Quick 中的主題充當語義層,業務使用者可以用自然語言提問並直接從資料中獲得答案。

此前,組織透過建立豐富的資料集並將其與主題一對一關聯來建模語義層。此外,當 Quick Sight 作者構建分析時,一個視覺化只能來源於一個資料集。Quick Sight 將資料集表示為單一扁平表。如果客戶的資料來源包含多個表,Quick Sight 要求客戶透過將源表連線成 Quick Sight 資料準備中的單個表來定義資料集。這種單一非規範化表的方法最初旨在透過避免執行時連線來提供更好的效能。對於簡單資料集(在 Quick Sight 早期階段佔大多數用例)效果良好。如今,我們正在發展這一模型。藉助多資料集主題(公開預覽),您現在可以在單個主題中新增最多 12 個資料集,並定義它們之間的關係。Quick 聊天機器人會在回答問題時自動遍歷這些關係。AI 引擎解釋使用者意圖,識別哪些資料集包含相關列,根據您定義的關係構建適當的 SQL 連線,並返回統一答案。您的資料保持規範化,治理保持集中化,業務使用者無需瞭解底層架構即可獲得更豐富的答案。同一多資料集主題可用於構建分析或使用聊天機器人回答問題。

多資料集主題的工作原理

Quick 中的主題是原始資料和業務使用者之間的語義層。它封裝了後設資料、業務規則、關係和上下文,AI 驅動的自然語言查詢(NLQ)引擎利用這些資訊來解釋自然語言問題並將其轉換為精確的分析查詢。

藉助多資料集主題,這個語義層現在透過明確定義的關係跨越多個資料集。架構包括四個層:

  1. 資料來源:您的規範化資料集從支援的源連線到 Quick Sight。在私有預覽期間,多資料集主題支援 SPICE(超級快速、並行、記憶體計算引擎)資料集。公開預覽擴充套件了對 Amazon Redshift、Amazon Athena、Amazon S3 Tables、Snowflake 和 Databricks 的 Direct Query 支援。目前,您不能在同一主題中混合 SPICE 和 Direct Query 資料集。
  1. 帶有或不帶目錄的資料集豐富:每個資料集獨立地透過語義後設資料進行豐富,從而提高 NLQ 準確性。豐富包括列描述(解釋每個欄位代表的含義)、同義詞(業務使用者可能使用的替代術語)、語義型別(城市、州、貨幣、日期)、計算欄位和欄位排除。NLQ 引擎使用這些後設資料將自然語言術語對映到正確的列。您現在可以在 Quick 中建立豐富的資料集,或使用 AWS Glue 和 Databricks Unity Catalog 的目錄匯入。例如,當使用者詢問“員工人數”時,引擎將定義的同義詞匹配到相應的列。
  1. 多資料集主題:主題作為統一容器,將資料集結合在一起。它包含資料集(預覽中最多 12 個)、關係(資料集對之間定義的連線鍵)、自定義指令(指導 AI 解釋領域特定術語的持久自然語言規則)以及許可權(所有者可修改,檢視者只能提問和使用)。
  1. 消費:業務使用者透過多個介面與主題互動。聊天介面允許使用者用自然語言提問,NLQ 引擎解析問題、識別相關列、構建帶有適當連線的 SQL 並返回答案。分析工作表允許作者使用主題中多個資料集的欄位構建視覺化。跨資料集計算可以建立結合不同資料集度量和維度的計算欄位。

聊天如何處理跨資料集問題

當業務使用者提出跨越多個資料集的自然語言問題時,NLQ 引擎將執行以下步驟:

  1. 意圖解析:引擎透過匹配列名、描述和同義詞來識別哪些列對映到使用者的術語。它確定哪些資料集包含相關的度量和維度。
  1. 關係遍歷:使用定義的連線鍵,引擎確定識別資料集之間的最短連線路徑。它遵循關係圖將事實表連線到必要的維度表。
  1. SQL 生成:引擎構建帶有適當 JOIN 子句、聚合和 GROUP BY 的 SQL 查詢。
  1. 結果呈現:答案以視覺化或表格形式返回,並附有生成的 SQL 供檢查。

此過程透明,使用者可以檢視生成的 SQL 以驗證使用了正確的資料集和連線。豐富後設資料和自定義指令越詳細,引擎解釋模糊問題的準確性就越高。

工作示例:按客戶細分和門店區域顯示總銷售額

考慮問題:“按客戶細分和門店區域顯示總銷售額。”

步驟 1 – 意圖解析:引擎對映“總銷售額” → SUM(SALES_FACT.SALE_AMOUNT),“客戶細分” → CUSTOMER_DIM.SEGMENT(透過同義詞“細分”匹配),“門店區域” → STORE_DIM.REGION(透過同義詞“區域”匹配)。

步驟 2 – 關係遍歷:引擎識別回答此問題需要三個資料集:SALES_FACT、CUSTOMER_DIM 和 STORE_DIM。使用定義的關係:SALES_FACT.CUSTOMER_ID → CUSTOMER_DIM.CUSTOMER_ID;SALES_FACT.STORE_ID → STORE_DIM.STORE_ID。它構建了一條透過 SALES_FACT 作為中心的兩跳連線路徑。

步驟 3 – SQL 生成:引擎產生:SELECT c.SEGMENT AS customer_segment, s.REGION AS store_region, SUM(f.SALE_AMOUNT) AS total_sales FROM SALES_FACT f JOIN CUSTOMER_DIM c ON f.CUSTOMER_ID = c.CUSTOMER_ID JOIN STORE_DIM s ON f.STORE_ID = s.STORE_ID GROUP BY c.SEGMENT, s.REGION ORDER BY total_sales DESC。

步驟 4 – 結果呈現:答案以視覺化或表格形式呈現,使用者可以使用解釋功能檢查生成的 SQL。

功能可用性

多資料集主題正在逐步推出。下表總結了 Quick Sight BI 視覺化構建的功能可用性。對於在 Quick 聊天機器人中使用主題,沒有此類限制。

解決方案概述

在本演練中,我們為 AnyCompany 的零售分析場景構建一個多資料集主題。該場景使用五個資料集,建模為星型模式。資料集包括:SALES_FACT(交易級銷售資料)、RETURN_FACT(產品退貨記錄)、CUSTOMER_DIM(客戶屬性)、PRODUCT_DIM(產品目錄)、STORE_DIM(門店位置)。

前提條件:擁有啟用 Amazon Quick Enterprise Edition 的 AWS 賬戶,具有作者或管理員角色,代表星型模式的資料集(事實表和維度表)載入到 SPICE 或可透過受支援的 Direct Query 源訪問,具有建立主題和管理資料集的許可權,熟悉基本資料建模概念。

建立並豐富每個資料集

豐富化彌合了技術列名與業務使用者實際談論資料之間的差距。透過新增描述、同義詞和語義型別,您教會 NLQ 引擎您組織的詞彙。這項投資會在使用者提出的每個問題上得到回報。它是使多資料集主題準確而不僅僅是功能性的基礎。

對於每個資料集:從 Quick 控制台左側窗格中,在 Quick Sight 下選擇“資料”,選擇一個資料集並選擇“編輯”,選擇“輸出”選項卡,為每個列新增描述、同義詞和語義型別。排除內部或未使用的欄位,如代理鍵、審計時間戳和 ETL 標誌。選擇“儲存併發布”。示例豐富化表格展示了 STORE_DIM 資料集的列描述、同義詞和語義型別。

建立包含多個資料集的主題

豐富資料集後,建立一個主題將它們組合成單個語義層。從 Quick 控制台左側窗格中,在 Quick Sight 下選擇“資料”,導航到“主題”選項卡並選擇“建立主題”。輸入主題名稱和描述,選擇“新增資料集”,選擇所有相關資料集。定義關係:上傳 JSON 檔案指定資料集之間的連線鍵。新增自定義指令處理領域特定術語。設定許可權。然後儲存主題。

使用主題進行聊天和分析

建立主題後,業務使用者可以透過聊天或分析使用它。在聊天中,使用者可以直接提問,引擎會返回基於多個資料集的答案。在分析中,作者可以構建使用主題中多個資料集欄位的視覺化。跨資料集計算允許建立跨資料集的度量。

總之,多資料集主題透過將多個資料集統一在一個語義層下,簡化了跨資料集的分析,使業務使用者能夠以自然語言獲得更豐富的洞察,同時保持資料的規範化和治理的集中化。