使用具體化檢視表

本文件將進一步說明實體檢視表及其使用方式。閱讀本文前，請先熟悉資料視圖簡介和建立資料視圖。

查詢具體化檢視表

您可以直接查詢具象化檢視畫面，方法與查詢一般資料表或標準檢視畫面相同。針對已實作的檢視表執行的查詢，一律會與針對檢視表基本資料表執行的查詢一致，即使這些資料表自上次更新已實作的檢視表後有所變更，也一樣。查詢不會自動觸發已實作的重新整理作業。

必要的角色

如要取得查詢具現檢視表所需的權限，請要求管理員為您授予具現檢視表和具現檢視表本身的 BigQuery 資料檢視者 (roles/bigquery.dataViewer) 身分與存取權管理角色。如要進一步瞭解如何授予角色，請參閱「管理專案、資料夾和機構的存取權」。

這個預先定義的角色具備查詢具象化檢視畫面所需的權限。如要查看確切的必要權限，請展開「必要權限」部分：

所需權限

您必須具備下列權限，才能查詢具象化檢視表：

  • bigquery.tables.get
  • bigquery.tables.getData

您或許還可透過自訂角色或其他預先定義的角色取得這些權限。

查詢必須具備這些權限，才能享有智慧調整的優勢。

如要進一步瞭解 BigQuery 中的身分與存取權管理角色，請參閱「身分與存取權管理簡介」。

分批更新

當 BigQuery 將快取檢視的資料與新資料結合，以便在繼續使用具體化檢視的同時提供一致的查詢結果時，就會發生遞增更新。對於單一資料表的具體化檢視表，如果自上次重新整理後，基礎資料表未變更，或只新增資料，就有可能發生這種情況。對於 JOIN 檢視畫面，只有 JOIN 左側的資料表可以附加資料。如果 JOIN 右側的其中一個資料表已變更，則無法逐步更新檢視畫面。

如果基礎資料表自上次重新整理後有更新或刪除作業，或是 JOIN 右側的已實現檢視畫面基礎資料表有所變更，則 BigQuery 不會使用增量更新，而是自動還原為原始查詢。如要進一步瞭解彙整和物化檢視表，請參閱「彙整」一文。以下是可能導致更新或刪除作業的 Google Cloud 主控台、bq 指令列工具和 API 動作範例：

  • 資料操縱語言 (DML) UPDATE、MERGE 或 DELETE 陳述式
  • 截斷
  • 分區有效期限

下列中繼資料作業也會防止物化檢視畫面以漸增方式更新：

  • 變更分區到期時間
  • 更新或捨棄資料欄

如果具體化檢視表無法以漸進方式更新，則查詢不會使用其快取資料，除非檢視表已自動或手動重新整理。如要進一步瞭解為何工作未使用具象化檢視資料，請參閱「瞭解具象化檢視表遭拒的原因」。此外，如果基礎資料表累積未處理的變更時間超過資料表的時間回溯間隔，則無法以漸進方式更新已具體化的檢視畫面。

分區對齊

如果已為具象化檢視建立分區，BigQuery 會確保其分區與基礎資料表的分區欄位保持一致。「Aligned」表示基本資料表的特定分區提供的資料，會納入物化檢視畫面的相同分區。舉例來說，主資料表分區 20220101 的資料列只會提供 materialized view 的分區 20220101。

當具體化檢視畫面經過分割後，每個個別分割區都會獨立發生「增量更新」中所述的行為。舉例來說，如果在基礎資料表的一個分區中刪除資料，BigQuery 仍可使用具體化檢視表的其他分區，而不需要重新整理整個具體化檢視表。

內部彙整功能的具體化檢視表只能與其中一個基礎資料表對齊。如果其中一個未對齊的基礎資料表發生變更，就會影響整個檢視畫面。

智慧微調

BigQuery 會自動重寫查詢，盡可能使用已實作的檢視畫面。自動重寫功能可提高查詢效能並降低成本，且不會變更查詢結果。查詢不會自動觸發物化重新整理作業。如要使用智慧調整功能重寫查詢，實體資料檢視必須符合下列條件：

  • 與其中一個基礎資料表或查詢執行所在的專案屬於同一專案。
  • 使用與查詢相同的一組基礎資料表。
  • 納入要讀取的所有資料欄。
  • 包含所有要讀取的資料列。

智慧調整功能不支援下列項目：

智慧微調範例

請參考以下具體化檢視表查詢範例：

SELECT
  store_id,
  CAST(sold_datetime AS DATE) AS sold_date
  SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
  CAST(sold_datetime AS DATE) >= '2021-01-01' AND
  promo_id IS NOT NULL
GROUP BY 1, 2

以下範例顯示查詢，以及為何這些查詢會或不會自動使用此檢視畫面重寫：

查詢 重寫？ 原因
SELECT
SUM(net_paid) AS sum_paid,
SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id IS NOT NULL 		否 檢視畫面必須包含要讀取的所有資料欄。檢視畫面不包含「SUM(net_paid)」。
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id IS NOT NULL 		是
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id IS NOT NULL AND
customer_id = 12345 		否 檢視畫面必須包含要讀取的所有資料欄。這個檢視畫面不包含「customer」。
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
sold_datetime= '2021-01-01' AND
promo_id IS NOT NULL
 否 檢視畫面必須包含要讀取的所有資料欄。「sold_datetime」不是輸出內容 (但「CAST(sold_datetime AS DATE)」是)。
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id IS NOT NULL AND
store_id = 12345		 是
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id = 12345 		否 檢視畫面必須包含所有要讀取的資料列。由於「promo_id」不是輸出項目，因此無法將更嚴格的篩選器套用至檢視畫面。
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE CAST(sold_datetime AS DATE) >= '2020-01-01'
 否 檢視畫面必須包含所有要讀取的資料列。資料檢視篩選器篩選 2021 年以後的日期，但查詢會讀取 2020 年的日期。
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2022-01-01' AND
promo_id IS NOT NULL 		是

瞭解查詢是否已重寫

如要瞭解智慧調校是否已將查詢改寫為使用具象化檢視畫面，請檢查查詢計畫。如果查詢已重寫，則查詢計畫會包含 READ my_materialized_view 步驟，其中 my_materialized_view 是所用物化檢視表的名稱。如要瞭解查詢未使用具體化檢視表的原因，請參閱「瞭解具體化檢視表遭拒的原因」。

瞭解具體化檢視表遭拒的原因

如果您已為具象化檢視畫面停用自動重新整理功能，且資料表有未處理的變更，則查詢可能會在幾天內加快，但之後會開始回復原始查詢，導致處理速度變慢。如要充分運用已具象化檢視畫面，請啟用自動重新整理功能或定期手動重新整理，並監控已具象化檢視畫面重新整理作業，確認作業成功。

如要瞭解具體化檢視表遭拒絕的原因，請依據您使用的查詢類型採取下列步驟：

  • 直接查詢具體化檢視表
  • 間接查詢 (智慧調整可能會選擇使用具體化檢視表)

下列各節將說明如何瞭解為何會拒絕實體化檢視畫面。

直接查詢具體化檢視表

在某些情況下，對具體化檢視畫面執行直接查詢可能不會使用快取資料。您可以透過下列步驟瞭解為何未使用已實作的檢視資料：

  1. 請按照「監控具體化檢視表使用情形」一文中的步驟操作，並在查詢的 materialized_view_statistics 欄位中找出目標具體化檢視表。
  2. 如果統計資料中出現 chosen，且其值為 TRUE，則查詢會使用具象化檢視畫面。
  3. 請查看 rejected_reason 欄位，瞭解後續步驟。在大多數情況下，您可以手動重新整理具象化檢視畫面，或等待下次自動重新整理。

使用智慧微調功能進行查詢

  1. 請按照「監控已具象化檢視畫面使用情形」中的步驟操作，並在查詢的 materialized_view_statistics 中找出目標已具象化檢視畫面。
  2. 請查看 rejected_reason 瞭解後續步驟。舉例來說，如果 rejected_reason 值為 COST，智慧調整就會找出更有效率的費用和成效資料來源。
  3. 如果沒有具體化檢視表，請嘗試直接查詢具體化檢視表，並按照「直接查詢具體化檢視表」中的步驟操作。
  4. 如果直接查詢未使用經過物化處理的檢視表，則經過物化處理的檢視表形狀與查詢不符。如要進一步瞭解智慧型調整功能，以及如何使用具象化檢視圖重新撰寫查詢，請參閱「智慧型調整功能範例」。

常見問題

何時該使用排程查詢，而非具體化檢視表？

排程查詢是定期執行任意複雜計算的方便方法。每次執行查詢時，查詢都會完整執行，不會從先前的結果中獲得任何好處，而且您必須為查詢支付完整的運算成本。如果您不需要最新資料，而且較不在意資料過時，建議使用排程查詢。

當您需要重複運用先前運算的結果，在查詢最新資料時減少延遲情形與費用時，具體化檢視表最適合用於此類情況。您可以將具體化檢視表當作偽索引使用，加快對基礎資料表的查詢速度，而無需更新任何現有的工作流程。--max_staleness 選項可讓您為具象化檢視畫面定義可接受的過時程度，在處理大量經常變更的資料集時，提供持續的高效能和受控成本。

一般來說，如果您不執行任意複雜的計算，請盡可能使用已實作的檢視畫面。

針對具體化檢視表執行的部分查詢，其速度會比針對手動具體化資料表執行相同查詢的速度慢。為什麼會這樣？

一般來說，對具體化檢視表執行的查詢，不一定比對等具體化資料表執行的查詢效能佳。這是因為實體檢視區塊一律會傳回最新結果，且必須考量自上次檢視區塊重新整理後，其基礎資料表的變更情形。

請考慮以下情境：

CREATE MATERIALIZED VIEW my_dataset.my_mv AS
SELECT date, customer_id, region, SUM(net_paid) as total_paid
FROM my_dataset.sales
GROUP BY 1, 2, 3;

CREATE TABLE my_dataset.my_materialized_table AS
SELECT date, customer_id, region, SUM(net_paid) as total_paid
FROM my_dataset.sales
GROUP BY 1, 2, 3;

例如以下查詢：

  SELECT * FROM my_dataset.my_mv LIMIT 10
 通常比這項查詢執行得慢得多：
  SELECT * FROM my_dataset.my_materialized_table LIMIT 10
 為了提供一致的最新結果，BigQuery 必須查詢基礎資料表中的新資料列，並將這些資料列合併至具體化視圖，然後才能套用「LIMIT 10」述詞。因此，即使已完全更新唯讀檢視畫面，系統仍會持續發生效能緩慢的問題。

另一方面，對具體化檢視表進行匯總的速度通常與對具體化資料表的查詢一樣快。例如：

  SELECT SUM(total_paid) FROM my_dataset.my_mv WHERE date > '2020-12-01'
 應如下所示： 
  SELECT SUM(total_paid) FROM my_dataset.my_materialized_table WHERE date > '2020-12-01'