如要執行分析資料的即時查詢,同時查詢作業資料,不必建構複雜的管道,可以使用 AlloyDB for PostgreSQL 的 Lakehouse Federation。AlloyDB 透過 bigquery_fdw 擴充功能將查詢路徑導向 BigQuery,藉由 BigLake 外部資料表存取即時資料和開放格式 (例如 Apache Iceberg),省去複雜的 ETL (擷取、轉換、載入) 遷移作業。
Lakehouse Federation 的優點
湖倉聯盟方法具有下列優點:
- 零 ETL:直接查詢分析資料,不必建構或維護複雜的管道。
- 熟悉語法:使用標準 PostgreSQL 語法查詢 BigQuery 資料。
- 即時洞察:存取最新資料和作業資料表。
- 卸載運算作業:透過下推最佳化,使用 BigQuery 分散式引擎執行繁重的工作。
- 授權存取權:為確保只有授權的服務帳戶可以查詢外部資料,請使用 Identity and Access Management (IAM) 集中控管存取權。
用途
Lakehouse Federation 支援下列業務和技術用途:
- 混合式交易和分析處理 (HTAP) 工作負載:您可以同時查詢 AlloyDB 中的即時營運資料,以及 BigQuery 或 Cloud Storage 中的歷來或分析資料,不會影響交易效能。
- 即時洞察,不必使用容易出錯的管道:您可以避免傳統 ETL 程序造成的延遲和失敗模式。即時存取最新的分析資料,根據最新資訊制定業務決策。
- 代理工作流程的資料具體化:您可以將外部分析資料具體化至 AlloyDB,以使用 AlloyDB 資料欄引擎和 AlloyDB AI 功能。您可以在聯合資料中執行高效能向量搜尋、機器學習嵌入,以及進階 AI 驅動的代理式工作流程。
架構和資料流程
下圖顯示使用湖倉聯盟時的資料流和元件互動:
以下說明 AlloyDB 中 Lakehouse Federation 的資料流程程序:
- 提交查詢:您向 AlloyDB 執行個體提交標準 PostgreSQL 查詢。
- 查詢規劃和最佳化:AlloyDB 查詢規劃工具會使用 BigQuery 外部資料包裝函式 (FDW),找出對應至外部 BigQuery 資料集的資料表。
- 下推最佳化:AlloyDB 會將特定篩選器和匯總作業直接下推至 BigQuery,藉此最佳化查詢。確保網路只會傳輸相關的篩選資料列或預先匯總的摘要。
- 執行和擷取:BigQuery 會執行查詢的這部分,直接掃描 BigQuery 內建儲存空間,或讀取儲存在 Cloud Storage 中的 Apache Iceberg 資料表,然後將產生的資料集串流回 AlloyDB。
- 最終處理和回應:AlloyDB 會將外部資料與任何本機作業資料表合併,完成所有剩餘的查詢處理作業,然後將最終結果傳回應用程式。
聯合查詢的資料類型注意事項
使用資料湖倉聯盟從 AlloyDB 查詢外部 BigQuery 資料表時,AlloyDB 查詢規劃工具會將 BigQuery 資料類型解讀為對應的 PostgreSQL 資料類型。瞭解這些對應關係,對於編寫正確的查詢,以及 bigquery_fdw 擴充功能使用的外部資料表定義至關重要。
如果 BigQuery 資料型別沒有直接對應項目,或需要特殊處理,您可能需要在查詢中使用明確的 CAST 函式,或在 BigQuery 中建立檢視區塊,以顯示相容型別的資料。
如需支援的資料類型及其對應的 PostgreSQL 類型清單,請參閱「資料類型對應」。
安全性和存取控管
從 AlloyDB 存取 BigQuery 資料的權限是透過 IAM 管理。您必須將特定 IAM 角色授予 AlloyDB 叢集服務帳戶,藉此定義可查詢的資料集和表格。這有助於確保聯合查詢遵守貴機構的集中式資料治理政策,同時兼顧安全性。詳情請參閱「必要的角色」。
下推式廣告
您可以使用篩選和匯總下推技術,在資料移轉至 AlloyDB 或由 AlloyDB 處理之前,先在 BigQuery 中篩選或匯總資料,藉此加快查詢速度並降低成本。這種做法可盡量減少網路流量和記憶體用量,讓您快速有效率地分析大量資料集,且不會超出資源限制。
篩選器下推式廣告
篩選條件下推 (又稱述詞下推) 是一種最佳化技術,可將資料篩選條件盡可能靠近儲存層,方法是將查詢篩選條件 (使用 WHERE 子句) 從 AlloyDB 下推至 BigQuery。
透過篩選條件下推,您可以使用含有 WHERE 子句的 SQL 查詢,存取遠端資料表中的資料子集。這項資料也可以在區域資料表上具體化,或以區域分割區的形式附加至 PostgreSQL 資料表。
篩選器下推作業支援下列作業:
- 標準比較運算子:
=、<、>、<=、>=、<> - 邏輯運算子:
AND、OR和NOT - 模式比對:
LIKE和NOT LIKE - 空值檢查:
IS NULL和IS NOT NULL - 清單內評估:
IN和NOT IN
匯總下推
匯總下推是一種進階資料庫最佳化功能,可盡可能在儲存層附近執行計算,例如 SUM、COUNT、AVG 或 GROUP BY。這項下推功能會直接在 BigQuery 中評估摘要函式,大幅減少傳回 AlloyDB 的資料列數。
支援的匯總下推作業包括:
SUMCOUNTAVGMINMAX
限制下推式廣告
限制條件下推 (包括 OFFSET 下推) 是一種最佳化技術,可將查詢的 LIMIT 和 OFFSET 子句從 AlloyDB 移至 BigQuery。
這樣一來,BigQuery 只會傳回所要求的特定資料列子集,大幅減少網路流量和查詢延遲。
系統會盡可能自動套用限制下推。請確認符合下列條件:
- 查詢不會在
FETCH FIRST子句中使用WITH TIES選項。 LIMIT和OFFSET運算式是基本常數或可遠端評估的運算式。
BigQuery 費用和帳單
BigQuery 外部資料包裝函式取決於下列項目:
- BigQuery 運算定價
- BigQuery Storage API 定價
詳情請參閱「BigQuery 計價方式」一文。
執行階段專案
在 BigQuery 中,您可以將資料儲存在一個專案中,並在另一個專案中執行查詢。執行查詢並產生運算費用的專案稱為「執行階段專案」 (或帳單專案)。
將執行階段專案與資料儲存專案分開,可將運算費用劃歸特定成本中心、獨立管理配額,以及控管不同工作負載的支出,而不必移動基礎資料。
設定 AlloyDB 存取 BigQuery 資料時,您可以在伺服器層級 (適用於所有相關聯的外部資料表) 或個別資料表層級指定執行階段專案。如未指定執行階段專案,AlloyDB 預設會使用擁有資料的專案。
限制
AlloyDB 和 BigQuery 可能使用不同的預設排序規則,導致兩個系統的資料排序或字串比較結果不同。舉例來說,在排序期間,15、16 和 17 版的預設 PostgreSQL 排序規則處理大小寫的方式,可能與 BigQuery 的預設排序規則不同,後者會根據字串的 Unicode 碼位嚴格評估字串。
如果查詢的任何部分是在 BigQuery 上遠端執行,則排序規則會遵循 BigQuery 的設定。為減少排序規則衝突,建議在 AlloyDB 中使用不含 ICU 的
C.UTF-8排序規則,並在 BigQuery 中使用預設 (空白) 排序規則。從 BigQuery 傳回大量資料的查詢 (下推後) 不會經過最佳化。
建立外部資料表時,AlloyDB 不會主動驗證遠端 BigQuery 資料表是否存在或結構定義。
如果聯合查詢需要讀取大量資料 (例如無法套用篩選條件下推),查詢可能會因 BigQuery API 回應大小限制而失敗。您仍須遵守 BigQuery 的回應大小上限。如要進一步瞭解這些限制,請參閱「配額與限制」。
PostgreSQL 支援更精確的中間運算,而 BigQuery 則嚴格控管小數精確度。這種差異可能會導致複雜計算期間的精確度降低或發生溢位錯誤。詳情請參閱「十進位類型」。
資料庫遷移服務不支援遷移使用
bigquery_fdw擴充功能建立的外部資料表。如要解決這個問題,您可以從遷移工作中排除外部資料表,或在開始遷移前捨棄外部資料表,然後在遷移完成後,於目的地 AlloyDB 叢集重新建立外部資料表。使用
bigquery_fdw擴充功能查詢外部資料表時,BigQuery 會根據 AlloyDB 叢集服務帳戶評估資料存取權。即使資料庫使用者是透過 IAM 資料庫驗證登入,系統也不會根據遠端 BigQuery 資料表檢查個別 IAM 使用者權限。詳情請參閱「將 BigQuery 資料集存取權授予 AlloyDB」。