持續性 materialized view

本文將概略說明持續性 materialized view 和常見用途。閱讀本頁之前，請先熟悉 Bigtable 總覽。

在 Bigtable 中，持續性 materialized view 是持續、全代管背景程序的結果。這項程序會使用您提供的 SQL 查詢，建立及維護預先運算的資料表，Bigtable 會隨著來源資料變更，逐步更新資料表。SQL 查詢可以包含基礎 Bigtable 資料表的匯總和轉換。

持續性 materialized view 中的資料包括：

  • 從來源資料表中的資料衍生出的匯總或轉換值
  • 定義分組鍵的未匯總值

使用持續性 materialized view，即可在擷取資料時預先匯總。另外，持續性 materialized view 的結構定義與其來源資料表不同，會以最適合查詢的結構呈現來源資料表內容，查詢模式不同於來源資料表使用的查詢。

以下是 Bigtable 持續性 materialized view 的主要特性：

  • 免維護：持續性 materialized view 會在背景預先運算。來源資料表的資料變更 (包括更新和刪除) 會在背景自動傳播至連續 materialized view，使用者不需採取任何動作。
  • SQL 開發模式：持續性 materialized view 是以 GoogleSQL for Bigtable 查詢為基礎，包括 SQL 函式、篩選器和匯總。雖然函式預設為確定性，但在有限的用途中，您可以選擇加入使用一組精選的非確定性函式。
  • 與垃圾收集同步：連續 materialized view 會與來源資料表的垃圾收集政策保持同步，並在資料表資料過期或刪除時自動更新。
  • 讀取和寫入延遲時間不受影響：如果執行個體的叢集已充分佈建或使用自動調度資源功能，連續 materialized view 對來源資料表的效能影響極小。
  • 最終一致：持續性 materialized view 會在背景中運算。持續增補的 materialized view 更新作業可能會延遲，但持續增補的 materialized view 結果會始終保持一致。

您用來定義連續 materialized view 的資料列索引鍵、資料欄限定詞和資料欄值，都會視為服務資料。因此，請勿使用包含私密資訊的資料列索引鍵、資料欄限定詞或資料欄值，建立連續 materialized view。如要瞭解服務資料的處理方式，請參閱《Google Cloud 隱私權聲明》。

您可以使用 Google Cloud CLI、 Google Cloud 控制台中的 Bigtable Studio 查詢編輯器，或 Java 和 Go 適用的 Bigtable 用戶端程式庫，建立連續 materialized view。

您可以使用下列方式，從持續性 materialized view 讀取資料：

  • Bigtable Studio 查詢編輯器
  • 支援 SQL 查詢的 Bigtable 用戶端程式庫
  • 使用 Java 和 Go 的 Bigtable 用戶端程式庫發出 ReadRows API 呼叫

詳情請參閱「從連續 materialized view 讀取資料」。

持續性 materialized view 的使用時機

持續增補的 materialized view 可讓您使用 SQL 定義 Bigtable 資料的新表示法。建立後，持續性 materialized view 會持續自動將來源資料表的資料，重組為 SQL 查詢定義的格式。接著，您不必查詢資料表，也不必在讀取資料後轉換或匯總資料，而是可以直接查詢持續性 materialized view。

持續性 materialized view 可提高下列用途的查詢效能：

  • 資料預先匯總：您可以使用連續 materialized view，匯總各資料列的傳入資料。這可讓您快速擷取匯總和匯總資料，例如資訊主頁的指標。
  • 自動化 lambda 和 kappa 架構：如果應用程式需要混合即時串流管道資料和包含歷來資料的批次管道資料，請使用連續 materialized view。這些檢視畫面會隨著時間更新，反映基礎資料的變更，讓您查看所有資料來源，而不需額外的串流處理工具或自訂 ETL 工作。
  • 次要存取模式：持續性 materialized view 會建立資料的替代表示法。這種表示法可針對查詢進行最佳化，其查詢模式與您在來源資料表查詢中使用的模式不同。因此，持續性 materialized view 是強大的工具，可有效為資料建立非同步次要索引。如要進一步瞭解這些模式，請參閱「建立非同步次要索引」。

如要比較持續性 materialized view 與其他類型的 Bigtable view，請參閱「資料表和 view」。

計數器使用時機

另一種預先匯總資料的方法，是使用匯總儲存格建立分散式計數器。

寫入匯總儲存格的資料，可立即從寫入的叢集讀取。系統會在資料寫入後處理連續 materialized view，最終與來源資料表保持一致。

在下列情況下，請使用計數器，而非持續性 materialized view：

  • 不需篩選，也不必跨資料列的匯總。
  • 如果需要立即從寫入的叢集讀取寫入內容。

如要執行下列操作，請使用持續增補的 materialized view：

  • 為匯總查詢產生不同的金鑰。
  • 查看基礎資料表的變更如何反映在匯總中。
  • 自動合併多列資料。

如要執行下列操作，請結合使用計數器和持續性 materialized view：

  • 在匯總儲存格中擷取新指標，但保留這些指標的歷來匯總資料。
  • 在持續性 materialized view 中合併指標。

資源佈建和效能

持續性 materialized view 的後續處理作業會以低優先順序的背景工作執行。因此，只要叢集大小適當，對應用程式效能和來源資料表的讀寫延遲影響極小。

為確保連續 materialized view 中的資料保持最新狀態，最佳做法是為包含連續 materialized view 的執行個體中的叢集啟用自動調度資源功能。自動調度資源功能會自動新增足夠的節點來處理處理負擔，並在不再需要時移除這些節點。這有助於確保在執行持續執行的 SQL 查詢時，有足夠的運算能力。自動調度資源功能也能確保您有足夠的節點，可處理連續 materialized view 的儲存空間需求。

持續增補的 materialized view 會計入每個執行個體 1,000 個資料表的限制。

在現有資料表建立持續性 materialized view

為現有資料表建立連續 materialized view 時，Bigtable 會啟動一次性程序，將現有資料表的資料填入檢視表。這項程序稱為「初始母體」。初始母體所需的時間取決於資料表的大小和查詢的複雜度。根據預設，您無法在初始母體期間查詢檢視表。不過，如果您的用途可以容許不完整的資料 (例如在應用程式開發期間)，則可在填入完成前，使用 allow_incomplete_view 查詢提示查詢檢視表。在這段期間，如果檢視表執行匯總，傳回的匯總結果可能只會反映部分資料。詳情請參閱「在初始母體期間讀取資料」。

這項初始母體會以低優先順序的背景工作執行，盡可能減少對叢集效能的影響。如果是大型資料表，您可以暫時在叢集中新增更多節點，加快建立檢視表。

下圖顯示建立連續 materialized view 的程序：

在 Bigtable 建立持續性 materialized view 的程序。
圖 1. 在 Bigtable 建立持續性 materialized view 的程序 (點選即可放大)。

舉例來說，假設來源資料表包含索引鍵符合 advertiser_id#region#ad_id 模式的資料列，以及一個資料欄系列 data，其中包含 spend_usd 資料欄限定詞，並以數值資料代表廣告支出：

資料列索引鍵 data:spend_usd
adv1#us-east#ad1 100
adv1#us-west#ad2 150
adv2#us-east#ad3 200

如果使用下列查詢定義這個資料表的連續 materialized view，在 175 個節點的叢集上，1 TB 資料的初始母體大約會在三小時內完成。

SELECT
          SPLIT(_key, "#")[SAFE_OFFSET(0)] AS advertiser_id,
          count(*) AS count,
          sum(cast(cast(data['spend_usd'] as string) as int64)) as sum_spend
        FROM `$0`
        GROUP BY advertiser_id

由於 Bigtable 會線性擴充，因此假設資料形狀相似，175 個節點的叢集處理 2 TB 的資料約需 6 小時，處理 10 TB 的資料約需 30 小時。如要縮短初始母體所需的時間，您可以暫時在叢集中新增更多節點，或者，如果您使用自動調度資源，則可以暫時增加節點數量上限。

非確定性 SQL 函式

根據預設，連續 materialized view 僅支援確定性函式，確保執行個體中所有叢集的結果一致。不過，您可以選擇加入使用非確定性函式 (例如 CLUSTER_ATTRIBUTE())，依處理資料的叢集篩選資料。詳情請參閱「非確定性查詢」。

如要使用這些函式，您必須在建立連續 materialized view 時，確認可能存在語意差異。詳情請參閱「建立連續 materialized view」。

儲存空間

Bigtable 會為每個持續性 materialized view 儲存下列內容：

  • 持續性 materialized view 中的資料
  • 中繼儲存空間

與任何 Bigtable 資料表一樣，持續 materialized view 存在於包含該檢視表的所有叢集中。執行個體中的叢集必須有足夠的節點，才能儲存來源資料表，以及以該資料表為基礎的任何連續 materialized view。自動調度資源功能可讓叢集隨著儲存空間需求變化，擴充或縮減大小。

雖然持續性 materialized view 的儲存空間與來源資料表不同，但必須在與來源資料表相同的執行個體中建立。

持續性 materialized view 儲存空間

持續增補的 materialized view 包含 SQL 查詢產生的資料，而該查詢是持續增補的 materialized view 的基礎。也就是說，其中包含 SQL 查詢中匯總子句定義的匯總值，以及定義分組索引鍵的未匯總值。

中繼儲存空間

為支援連續 materialized view 與來源資料表的同步處理，Bigtable 會使用中繼儲存空間，儲存需要用來對連續 materialized view 進行增量更新的資料副本。

中繼儲存空間中的資料量，大致相當於來源資料表中掃描的資料量，用於產生定義連續 materialized view 的 SQL 查詢結果。舉例來說，如果查詢會匯總整個資料表的資料，Bigtable 會將相當於整個資料表的資料保留在中繼儲存空間。如果依據特定資料列索引鍵範圍或資料欄的查詢建立連續 materialized view，則只有這些資料列或資料欄會保留在中間儲存空間。

中繼儲存空間會在連續 materialized view 的生命週期內保留，有效支援 view 的增量更新，並將來源資料表的刪除作業傳播至連續 materialized view。您無法讀取中繼儲存空間中的資料。如要深入瞭解中繼儲存空間用量，請參閱「持續性 materialized view 指標」。

複製

在使用複製功能的執行個體中，持續性 materialized view 的複製方式與資料表不同。而是由執行個體中的每個叢集，使用來源資料表的副本，獨立處理連續 materialized view。舉例來說，這表示寫入叢集 A 來源資料表的資料會複製到叢集 B 的資料表，然後複製到叢集 B 的連續 materialized view。

費用

使用持續性 materialized view 時，不會產生個別資源費用。不過，建立及同步處理持續性 materialized view 需要處理和儲存空間，因此會按照標準費率收費。建立持續性 materialized view 時，下列項目會增加：

  • 儲存空間：系統會根據儲存在連續 materialized view 的資料量和中繼儲存空間向您收費。詳情請參閱「儲存空間」。
  • 運算：來源資料表和連續 materialized view 的持續同步作業需要 CPU 處理，叢集可能需要更多節點來處理額外的背景工作。

同時，您可能會發現來源資料表的處理作業減少，例如不再對資料進行範圍掃描，以執行重複運算和其他效率較低的查詢。您也可能不需要執行 Dataflow 或 Spark 等管道工作，來匯總來源資料並寫回 Bigtable。

如要進一步瞭解定價，請參閱「Bigtable 定價」。如要瞭解哪些指標可協助您監控連續 materialized view 的用量，請參閱「指標」。

指標

持續性 materialized view 會向 Cloud Logging 回報多項重要指標，您可以使用這些指標監控持續性 materialized view。

指標 說明
materialized_view/max_delay 持續性 materialized view 的處理延遲時間上限
materialized_view/storage 連續 materialized view 儲存空間使用的資料量，以位元組為單位
materialized_view/intermediate_storage 連續 materialized view 的中繼處理作業使用的資料量，以位元組為單位
table/materialized_view_intermediate_storage 這個資料表定義的持續性 materialized view，其中間處理作業使用的資料量
materialized_view/user_errors 連續 materialized view 的使用者資料錯誤數量。使用者錯誤導致資料無法傳播至檢視畫面。
materialized_view/system_errors 持續性 materialized view 的系統錯誤數量

您也可以使用許多 Bigtable 資料表指標監控連續 materialized view，只要將資料表 ID 替換為連續 materialized view ID 即可。具體來說，CPU 指標的細目中包含連續 materialized view，可協助您瞭解其影響。使用 Data API 的 ReadRows 方法讀取連續 materialized view 時，系統會產生每秒要求數、延遲時間和處理量的 Bigtable 指標。詳情請參閱「指標」。

如要開始使用 Cloud Logging，請參閱「查詢和查看記錄檔總覽」。

限制

  • 每個執行個體最多可建立 50 個持續性 materialized view。
  • 每個資料表最多可建立 5 個持續性 materialized view。如有需要，您可以與 Cloud Customer Care 聯絡，要求提高這項限制。
  • 建立檢視表時，如果未指定 _key，來源資料表中所選資料欄不得為 NULL。詳情請參閱「由 GROUP BY 或 ORDER BY 子句定義的資料列索引鍵」。
  • 您無法修改定義持續 materialized view 的 SQL 查詢。您必須刪除連續 materialized view，並建立新的檢視表，然後套用變更。
  • 您無法為其他持續性 materialized view 或邏輯檢視表建立持續性 materialized view。
  • 定義持續性 materialized view 的查詢無法使用 SELECT *。
  • 您無法為連續 materialized view 設定垃圾收集政策。所有資料保留作業均受來源資料表的垃圾收集政策規範，來源的垃圾收集作業會自動反映在連續 materialized view 中。
  • 如果資料表的時間戳記精細程度設為微秒，就無法建立持續性 materialized view。

後續步驟