使用反向 ETL 將資料從 BigQuery 載入 Spanner Graph

本文說明如何使用反向擷取、轉換及載入 (ETL) 管道,將圖形資料從 BigQuery 移至 Spanner Graph,並持續同步處理。涵蓋下列重要層面:

如要使用反向 ETL 將資料從 BigQuery 匯出至 Spanner,請參閱「將資料匯出至 Spanner」。

BigQuery 是分析處理平台,可大規模執行複雜的資料操作,而 Spanner 則經過最佳化,適用於需要高 QPS 和低服務延遲時間的用途。Spanner Graph 和 BigQuery 可有效整合,在 BigQuery 分析管道中準備圖形資料,讓 Spanner 服務低延遲圖形遍歷。

事前準備

  1. 建立 Spanner 執行個體,並在其中建立包含圖形資料的資料庫。詳情請參閱「設定及查詢 Spanner Graph」。

  2. 在 BigQuery 中,建立 Enterprise 或 Enterprise Plus 層級的 Slot 預留。將資料匯出至 Spanner 圖表時,您可以減少 BigQuery 運算費用。如要這麼做,請將基準運算單元容量設為零,並啟用自動調度資源

  3. 授予身分與存取權管理 (IAM) 角色,讓使用者擁有執行本文各項工作所需的權限。

必要的角色

如要取得將 BigQuery 圖形資料匯出至 Spanner Graph 所需的權限,請要求管理員在專案中授予您下列 IAM 角色:

如要進一步瞭解如何授予角色,請參閱「管理專案、資料夾和組織的存取權」。

您或許也能透過自訂角色或其他預先定義的角色,取得必要權限。

反向 ETL 用途

以下是幾個範例用途。在 BigQuery 中分析及處理資料後,您可以使用反向 ETL 將資料移至 Spanner Graph。

資料匯總和摘要 - 使用 BigQuery 計算細微資料的匯總,讓資料更適合用於作業用途。

資料轉換和擴充:使用 BigQuery 清理及標準化從不同資料來源收到的資料。

資料篩選和選取 - 使用 BigQuery 篩選大型資料集,以供分析。舉例來說,您可以篩除即時應用程式不需要的資料。

特徵預先處理和工程 - 在 BigQuery 中,使用 ML.TRANSFORM 函式轉換資料,或使用 ML.FEATURE_CROSS 函式建立輸入特徵的特徵交叉。接著,使用反向 ETL 將產生的資料移至 Spanner Graph。

瞭解反向 ETL 管道

資料會透過反向 ETL 管道,分兩步驟從 BigQuery 移至 Spanner 圖表:

  1. BigQuery 會使用指派給管道工作的時段,擷取及轉換來源資料。

  2. BigQuery 反向 ETL 管道會使用 Spanner API,將資料載入已佈建的 Spanner 執行個體。

下圖顯示反向 ETL 管道的步驟:

這張圖表顯示資料從 BigQuery 移至 Spanner Graph 時,反向 ETL 管道的三個主要步驟。

圖 1. BigQuery 反向 ETL 管道程序

管理圖形資料變更

您可以使用反向 ETL 執行下列操作:

  • 將圖形資料集從 BigQuery 載入 Spanner Graph。

  • 與 BigQuery 資料集持續更新的資料同步。

您可以使用 SQL 查詢設定反向 ETL 管道,指定來源資料和要套用的轉換。管道會使用 upsert 作業,將符合 SELECT 陳述式 WHERE 子句的所有資料載入 Spanner。upsert 作業等同於 INSERT OR UPDATE 陳述式。這項作業會在儲存圖形資料的資料表中插入新資料列,並更新現有資料列。管道會根據 Spanner 資料表主鍵,建立及更新資料列。

插入及更新具有載入順序依附元件的資料表資料

Spanner Graph 結構定義設計最佳做法建議使用交錯資料表和外鍵。如果您使用交錯資料表或強制執行的外部鍵,就必須依特定順序載入節點和邊緣資料。這可確保您建立參照資料列前,參照資料列已存在。詳情請參閱「建立交錯式資料表」。

以下範例圖形輸入資料表結構定義使用交錯式資料表和外部鍵限制,建立人員與帳戶之間的關係模型:

CREATE TABLE Person (
  id    INT64 NOT NULL,
  name  STRING(MAX)
) PRIMARY KEY (id);

CREATE TABLE Account (
  id           INT64 NOT NULL,
  create_time  TIMESTAMP,
  is_blocked   BOOL,
  type        STRING(MAX)
) PRIMARY KEY (id);

CREATE TABLE PersonOwnAccount (
  id           INT64 NOT NULL,
  account_id   INT64 NOT NULL,
  create_time  TIMESTAMP,
  CONSTRAINT FK_Account FOREIGN KEY (account_id) REFERENCES Account (id)
) PRIMARY KEY (id, account_id),
  INTERLEAVE IN PARENT Person ON DELETE CASCADE;

CREATE PROPERTY GRAPH FinGraph
  NODE TABLES (
    Person,
    Account
  )
  EDGE TABLES (
    PersonOwnAccount
      SOURCE KEY (id) REFERENCES Person
      DESTINATION KEY (account_id) REFERENCES Account
      LABEL Owns
  );

在這個範例結構定義中,PersonOwnAccountPerson 中的交錯資料表。在 PersonOwnAccount 資料表中的元素之前,載入 Person 資料表中的元素。此外,PersonOwnAccount 上的外鍵限制可確保 Account (邊緣關係目標) 中存在相符的資料列。因此,請先載入 Account 資料表,再載入 PersonOwnAccount 資料表。以下清單概略說明這個結構定義的載入順序依附元件:

請按照下列步驟載入資料:

  1. PersonOwnAccount 前載入 Person
  2. PersonOwnAccount 前載入 Account

Spanner 會強制執行範例結構定義中的參照完整性限制。如果管道嘗試在 PersonOwnAccount 資料表中建立資料列,但 Person 資料表或 Account 資料表中沒有相符的資料列,Spanner 就會傳回錯誤。管道隨即失敗。

這個反向 ETL 管道範例會使用 BigQuery 中的 EXPORTDATA 陳述式,從資料集中的 PersonAccountPersonOwnAccount 資料表匯出資料,以符合載入順序的依附元件:

BEGIN
EXPORT DATA OPTIONS (
    uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
    format='CLOUD_SPANNER',
    spanner_options="""{
      "table": "Person",
      "priority": "HIGH",
      "tag" : "graph_data_load_person"
    }"""
  ) AS
  SELECT
    id,
    name
  FROM
    DATASET_NAME.Person;

EXPORT DATA OPTIONS (
  uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
  format='CLOUD_SPANNER',
  spanner_options="""{
    "table": "Account",
    "priority": "HIGH",
    "tag" : "graph_data_load_account"
  }"""
) AS
SELECT
  id,
  create_time,
  is_blocked,
  type
FROM
  DATASET_NAME.Account;

EXPORT DATA OPTIONS (
  uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
  format='CLOUD_SPANNER',
  spanner_options="""{
    "table": "PersonOwnAccount",
    "priority": "HIGH",
    "tag" : "graph_data_load_person_own_account"
  }"""
) AS
SELECT
  id,
  account_id,
  create_time
FROM
  DATASET_NAME.PersonOwnAccount;
END;

同步處理資料

如要將 BigQuery 與 Spanner 圖表同步處理,請使用反向 ETL 管道。您可以設定管道執行下列其中一項操作:

  • 將 BigQuery 來源中的任何插入和更新作業套用至 Spanner Graph 目標資料表。您可以將結構定義元素新增至目標資料表,以邏輯方式傳達刪除作業,並依排程移除目標資料表資料列。

  • 使用可套用插入和更新作業,並識別刪除作業的時間序列函式。

參照完整性限制

與 Spanner 不同,BigQuery 不會強制執行主鍵和外鍵限制。如果 BigQuery 資料不符合您在 Spanner 資料表上建立的限制,反向 ETL 管道在載入該資料時可能會失敗。

反向 ETL 會自動將資料分組為批次,且批次不會超過每次提交的突變次數上限,並以任意順序將批次原子地套用至 Spanner 資料表。如果批次包含的資料未通過參照完整性檢查,Spanner 就不會載入該批次。這類失敗的例子包括:交錯的子項資料列缺少父項資料列,或是強制執行的外部鍵資料欄在參照的資料欄中沒有相符的值。如果批次未通過檢查,管道就會因錯誤而失敗,並停止載入批次。

瞭解參照完整性限制錯誤

以下範例顯示您可能會遇到的參照完整性限制錯誤:

解決外來鍵限制錯誤
  • 錯誤:「Foreign key constraint FK_Account is violated on table PersonOwnAccount. 找不到「Account(id)」中的參照值

  • 原因:由於缺少 Account 資料表中與 FK_Account 外鍵相符的資料列,因此無法將資料列插入 PersonOwnAccount 資料表。

解決缺少父項列的錯誤
  • 錯誤:「資料表 PersonOwnAccount 中資料列 [15,1] 的父項資料列遺失」

  • 原因:插入 PersonOwnAccount (id: 15account_id: 1) 的資料列失敗,因為 Person 資料表 (id: 15) 中缺少父項資料列。

如要降低參照完整性錯誤的風險,請考慮下列選項。每個選項都有取捨之處。

  • 放寬限制,允許 Spanner 圖表載入資料。
  • 在管道中新增邏輯,略過違反參照完整性限制的資料列。

放寬參照完整性

如要避免載入資料時發生參照完整性錯誤,其中一個方法是放寬限制,讓 Spanner 不會強制執行參照完整性。

  • 您可以使用 INTERLEAVE IN 子句建立交錯資料表,以使用相同的實體列交錯特徵。如果您使用 INTERLEAVE IN 而非 INTERLEAVE IN PARENT,Spanner 不會強制執行參照完整性,但查詢會受益於相關資料表的共置。

  • 您可以使用 NOT ENFORCED 選項建立資訊外鍵NOT ENFORCED 選項可提供查詢最佳化優勢。不過,Spanner 不會強制執行參照完整性。

舉例來說,如要建立沒有參照完整性檢查的邊緣輸入資料表,可以使用下列 DDL:

CREATE TABLE PersonOwnAccount (
  id          INT64 NOT NULL,
  account_id  INT64 NOT NULL,
  create_time TIMESTAMP,
  CONSTRAINT FK_Account FOREIGN KEY (account_id) REFERENCES Account (id) NOT ENFORCED
) PRIMARY KEY (id, account_id),
INTERLEAVE IN Person;

在反向 ETL 管道中遵守參照完整性

為確保管道只會載入符合參照完整性檢查的資料列,請只納入 PersonOwnAccount 資料列,且這些資料列在 PersonAccount 資料表中必須有相符的資料列。接著保留載入順序,讓 Spanner 在參照這些資料列的 PersonOwnAccount 資料列之前,先載入 PersonAccount 資料列。

EXPORT DATA OPTIONS (
  uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
  format='CLOUD_SPANNER',
    spanner_options="""{
      "table": "PersonOwnAccount",
      "priority": "HIGH",
      "tag" : "graph_data_load_person_own_account"
    }"""
  ) AS
  SELECT
    poa.id,
    poa.account_id,
    poa.create_time
  FROM `PROJECT_ID.DATASET_NAME.PersonOwnAccount` poa
    JOIN `PROJECT_ID.DATASET_NAME.Person` p ON (poa.id = p.id)
    JOIN `PROJECT_ID.DATASET_NAME.Account` a ON (poa.account_id = a.id)
  WHERE poa.id = p.id
    AND poa.account_id = a.id;

刪除圖表元素

反向 ETL 管道會使用 upsert 作業。由於 upsert 作業等同於 INSERT OR UPDATE 陳述式,管道只能同步處理執行階段來源資料中存在的資料列。也就是說,管道會排除已刪除的資料列。如果您從 BigQuery 刪除資料,反向 ETL 管道無法直接從 Spanner Graph 移除相同資料。

您可以透過下列任一方式,處理 BigQuery 來源資料表中的刪除作業:

在來源中執行邏輯刪除或虛刪除

如要以邏輯方式標記待刪除的資料列,請在 BigQuery 中使用已刪除的旗標。接著在目標 Spanner 資料表中建立資料欄,以便傳播標記。反向 ETL 套用管道更新時,請刪除 Spanner 中含有這個標記的資料列。您可以使用分區 DML 找出並明確刪除這類資料列。或者,您也可以設定存留時間 (TTL) 欄位,並根據刪除旗標欄位中的日期,間接刪除資料列。編寫 Spanner 查詢,排除這些邏輯上已刪除的資料列。這樣才能確保 Spanner 會在排定刪除時間前,從結果中排除這些資料列。反向 ETL 管道執行完畢後,Spanner 會在資料列中反映邏輯刪除作業。接著,您就可以從 BigQuery 刪除資料列。

這個範例會在 Spanner 的 PersonOwnAccount 資料表中新增 is_deleted 資料欄。然後新增取決於 is_deleted 值的 expired_ts_generated 資料欄。由於產生資料欄中的日期早於 DELETION POLICY 閾值,存留時間政策會排定刪除受影響的資料列。

ALTER TABLE PersonOwnAccount
  ADD COLUMN is_deleted BOOL DEFAULT (FALSE);

ALTER TABLE PersonOwnAccount ADD COLUMN
  expired_ts_generated TIMESTAMP AS (IF(is_deleted,
    TIMESTAMP("1970-01-01 00:00:00+00"),
    TIMESTAMP("9999-01-01 00:00:00+00"))) STORED HIDDEN;

ALTER TABLE PersonOwnAccount
  ADD ROW DELETION POLICY (OLDER_THAN(expired_ts_generated, INTERVAL 0 DAY));

使用 BigQuery 變更記錄進行 INSERT、UPDATE 和邏輯刪除

您可以使用 BigQuery 資料表的變更記錄,追蹤資料表的變更。使用 GoogleSQL CHANGES 函式,找出特定時間間隔內變更的資料列。然後,使用已刪除的資料列資訊搭配反向 ETL 管道。您可以設定管道,在 Spanner 資料表中設定指標,例如刪除標記或到期日。這個指標會標記 Spanner 資料表中待刪除的資料列。

使用 CHANGES 時間序列函式的結果,決定要將來源資料表中的哪些資料列納入反向 ETL 管道的載入作業。

如果來源資料表中有資料列,管道會將這些資料列納入 _CHANGE_TYPE,做為 INSERTUPDATE 插入/更新。來源資料表中的目前資料列提供最新資料。

使用_CHANGE_TYPE做為DELETE的資料列,在來源資料表中具有現有資料列,即可在 Spanner 資料表中設定指標,例如已刪除的標記或資料列到期日。

匯出查詢必須考量 BigQuery 中的插入和刪除順序。舉例來說,假設系統在 T1 時間刪除資料列,並在稍後的 T2 時間插入新資料列。如果兩者都對應至相同的 Spanner 資料表列,匯出作業必須保留這些事件的影響,並按照原始順序排列。

如果已設定,delete 指標會標記 Spanner 資料表中的資料列,以供刪除。

舉例來說,您可以在 Spanner 輸入資料表中新增資料欄,儲存每個資料列的到期日。然後,建立使用這些到期日的刪除政策。

以下範例說明如何新增資料欄,用來儲存資料表列的到期日。

ALTER TABLE PersonOwnAccount ADD COLUMN expired_ts TIMESTAMP;

ALTER TABLE PersonOwnAccount
  ADD ROW DELETION POLICY (OLDER_THAN(expired_ts, INTERVAL 1 DAY));

如要在 BigQuery 資料表上使用 CHANGES 函式,請將資料表的 enable_change_history 選項設為 TRUE

ALTER TABLE `PROJECT_ID.DATASET_NAME.PersonOwnAccount`
  SET OPTIONS (enable_change_history=TRUE);

以下範例說明如何使用反向 ETL 更新新的或已變更的資料列,並為標示為刪除的資料列設定到期日。與 PersonOwnAccount 資料表進行左側聯結,可讓查詢取得每個資料列目前狀態的相關資訊。

EXPORT DATA OPTIONS (
  uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
    format='CLOUD_SPANNER',
    spanner_options="""{
      "table": "PersonOwnAccount",
      "priority": "HIGH",
      "tag" : "graph_data_delete_via_reverse_etl"
    }"""
  ) AS
SELECT
  DISTINCT
   IF (changes._CHANGE_TYPE = 'DELETE', changes.id, poa.id) AS id,
   IF (changes._CHANGE_TYPE = 'DELETE', changes.account_id, poa.account_id) AS account_id,
   IF (changes._CHANGE_TYPE = 'DELETE', changes.create_time, poa.create_time) AS create_time,
   IF (changes._CHANGE_TYPE = 'DELETE', changes._CHANGE_TIMESTAMP, NULL) AS expired_ts
FROM
  CHANGES(TABLE `PROJECT_ID.DATASET_NAME.PersonOwnAccount`,
    TIMESTAMP_TRUNC(TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY), DAY),
    TIMESTAMP_TRUNC(CURRENT_TIMESTAMP(), DAY)) changes
LEFT JOIN `PROJECT_ID.DATASET_NAME.PersonOwnAccount` poa
  ON (poa.id = changes.id
  AND poa.account_id = changes.account_id)
WHERE (changes._CHANGE_TYPE = 'DELETE'
   AND poa.id IS NULL)
   OR (changes._CHANGE_TYPE IN ( 'UPDATE', 'INSERT')
   AND poa.id IS NOT NULL );

範例查詢會搭配來源資料表使用 LEFT JOIN,以保留順序。這項聯結可確保系統忽略在查詢變更記錄間隔內刪除並重新建立的資料列,DELETE變更記錄。管道會保留有效的新資料列。

刪除資料列時,管道會使用 _CHANGE_TIMESTAMP 欄中的 DELETE 時間戳記,在對應的 Spanner 圖表資料列中填入 expired_ts 欄。Spanner 中的資料列刪除政策 (存留時間政策) 會刪除 expired_ts 值超過一天的所有資料列。

為確保系統可靠性,請協調管道排程、變更回溯時間範圍和 Spanner TTL 政策。排定每天執行管道。Spanner TTL 政策的存留時間必須長於這個執行間隔。這樣可避免管道重新處理 Spanner 存留時間政策已移除的資料列,先前發生的 DELETE 事件。

這個範例顯示每日查詢的 start_timestampend_timestamp 間隔,可擷取前一個世界標準時間當天的所有 BigQuery 資料表變更。由於這是批次查詢,且 CHANGES 函式有相關限制,因此 end_timestamp 必須比目前時間早至少 10 分鐘。因此,請安排這項查詢在世界標準時間午夜後至少 10 分鐘執行。詳情請參閱 CHANGES 說明文件

搭配上次顯示時間戳記使用存留時間資料欄

反向 ETL 管道會將 last_seen_ts 欄設為 Spanner 資料表中每個資料列的目前時間戳記。刪除 BigQuery 資料列時,Spanner 不會更新對應的資料列,且 last_seen_ts 欄不會變更。然後,Spanner 會根據定義的門檻,使用存留時間政策或分區 DML 移除 last_seen_ts 過時的資料列。在排定刪除作業前,Spanner 查詢可以篩除 last_seen_ts 較舊的資料列。如果圖形資料定期更新,且缺少更新表示資料過時而需要刪除,這個方法就非常有效。

執行全面重新整理

從 BigQuery 載入資料前,您可以刪除 Spanner 資料表,以反映來源資料表中的刪除作業。這樣一來,管道在下次執行時,就不會將從來源 BigQuery 資料表刪除的資料列載入至 Spanner。這可能是最容易實作的選項。不過,請考量完整重新載入圖表資料所需的時間。

維護排定的批次反向 ETL 管道

反向 ETL 管道首次執行時,會將 BigQuery 中的資料大量載入 Spanner Graph,但現實世界中的資料會持續變動。資料集會變更,管道也會隨著時間新增或移除圖表元素。管道會發掘新節點並新增邊緣關係,或由 AI 推論生成這些關係。

為確保 Spanner 圖形資料庫保持最新狀態,請使用下列任一選項排定 BigQuery pipeline 協調作業的時程和順序:

BigQuery Pipelines 可讓您在 BigQuery 中開發、測試、版本管控及部署複雜的 SQL 資料轉換工作流程。您可以定義管道中查詢之間的關係,系統會以原生方式處理順序依附元件。Dataform 會建構依附性樹狀結構,並以正確順序執行查詢。這可確保上游相依工作完成後,下游工作才會開始。

Cloud Scheduler 叫用的工作流程,可提供實用且彈性的解決方案,用於協調一連串的Google Cloud 服務,包括 BigQuery 查詢。將工作流程定義為一系列步驟,每個步驟都會執行 BigQuery 工作。您可以使用 Cloud Scheduler,按照定義的時間表叫用這些工作流程。使用工作流程定義管理依附元件,指定執行順序、實作條件邏輯、處理錯誤,以及將輸出內容從一個查詢傳遞至另一個查詢。

已排定時程的查詢 (又稱 BigQuery 移轉工作) 可讓您定期執行 SQL 陳述式。排程查詢無法提供完善的錯誤處理或動態依附關係管理功能。

使用 BigQuery 持續查詢執行反向 ETL

BigQuery 持續查詢功能可讓您近乎即時地執行 BigQuery 作業。結合 EXPORT DATA 和持續查詢,即可採用替代方法執行反向 ETL 管道,避免排定批次工作。

持續查詢是長時間執行的查詢,會監控來源 BigQuery 資料表中的新資料列。BigQuery 偵測到資料表新增資料列時,會將查詢結果串流至 EXPORT DATA 作業。

此方法具備下列優點。

  • 近乎即時的資料同步:BigQuery 中的新資料列會以最短延遲時間反映在 Spanner 中。

  • 減少批次處理負擔:持續查詢可免除定期批次工作,進而減少運算負擔。

  • 事件驅動更新:根據 BigQuery 的實際變更更新 Spanner 資料。

持續查詢管道需要指派具有 job_type 的時段預留項目 CONTINUOUS。請在專案或資料夾層級,或機構層級指派這項角色。

建立持續查詢,將資料從 BigQuery 反向 ETL 至 Spanner

設定 APPENDS 函式的 start_timestamp 參數,從批次載入作業停止的位置開始處理資料。這項函式會擷取特定時間範圍內建立的所有資料列。在下列範例中,管道任意將起點設為 CURRENT_TIME 前 10 分鐘。這個時間戳記必須在 BigQuery 時間回溯視窗內。

啟動連續查詢管道的方法有幾種,包括:

  1. 在 BigQuery Studio 中,依序選取「更多」和「選擇查詢模式」下方的「持續查詢」

  2. 使用 bq CLI 並提供 --continuous=true 選項。

EXPORT DATA OPTIONS ( uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
  format="CLOUD_SPANNER",
  spanner_options="""{
      "table": "PersonOwnAccount",
      "priority": "HIGH",
      "tag": "reverse-etl-continuous",
      "change_timestamp_column": "create_time"
   }"""
)
AS SELECT id, account_id, _CHANGE_TIMESTAMP as create_time
  FROM
APPENDS(TABLE `PROJECT_ID.DATASET_NAME.PersonOwnAccount`,
  CURRENT_TIMESTAMP() - INTERVAL 10 MINUTE )

無法保證載入順序

Spanner 圖表資料包含多個輸入資料表。如果資料表有參照完整性限制,您必須遵守嚴格的載入順序。不過,並行的持續查詢無法控制 Spanner 新增資料列的順序。因此,使用連續查詢載入 Spanner Graph 資料時,只能用於參考完整性限制較寬鬆的圖形結構定義。

與現有管道整合

持續查詢可輔助現有的排定批次工作。舉例來說,您可以透過持續查詢功能近乎即時地提供最新資料,或者也可選擇排程工作,完整同步或比對資料。

使用 BigQuery 連續查詢建構即時且最新的反向 ETL 管道,在 BigQuery 和 Spanner Graph 之間同步資料。

持續查詢注意事項

  • 費用:持續查詢會產生持續執行查詢和串流資料的費用。

  • 錯誤處理:如果遇到任何資料庫錯誤 (例如主鍵重複或違反參照完整性),系統就會取消連續查詢管道。如果管道失敗,您必須先手動修正來源 BigQuery 資料表中的資料,才能重新啟動查詢。

  • 未處理的刪除和更新APPENDS 函式只會擷取插入內容。不會擷取刪除或更新的內容。

遵循反向 ETL 最佳做法

如要獲得最佳成效,請採取下列做法。

  • 選擇策略,避免載入邊緣資料時發生參照完整性錯誤。

  • 設計整體資料管道,避免出現懸空邊緣。懸空邊緣可能會影響 Spanner Graph 查詢效率和圖形結構完整性。詳情請參閱「防止懸空邊緣」。

  • 按照 Spanner 匯出最佳化建議操作。

  • 如果載入大量資料,建議將管道分成多個較小的管道,以免達到預設的六小時 BigQuery 查詢執行時間配額。詳情請參閱「BigQuery 查詢工作限制」。

  • 如要載入大量資料,請在完成初始大量資料載入後,新增索引和外鍵限制。因為外鍵限制需要額外的讀取作業進行驗證,索引則需要額外的寫入作業,因此這項做法可提升資料載入效能。這些作業會增加交易參與者人數,可能導致資料載入程序變慢。

  • 在 Spanner 中啟用自動調度資源功能,加快將資料載入執行個體的速度。然後,在 BigQuery EXPORT DATA 指令的 spanner_options 區段中,將 Spanner priority 參數設為 HIGH。詳情請參閱「Spanner 自動調度總覽」、「使用 spanner_options 選項設定匯出作業」和「RequestOptions.priority」。

  • 如要載入大量資料,請建立分割點,預先分割資料庫。這項作業會為 Spanner 準備好因應更高的輸送量。

  • 在管道定義中,設定資料載入的 Spanner 要求優先順序

後續步驟