瞭解可靠性

本文件將說明 BigQuery 的可靠性功能，例如可用性、耐用性、資料一致性、效能一致性、資料復原，以及錯誤處理注意事項。

本介紹可協助您處理三個主要考量事項：

  • 判斷 BigQuery 是否適合您的工作。
  • 瞭解 BigQuery 可靠度的維度。
  • 找出特定用途的具體可靠度需求。

選取 BigQuery

BigQuery 是全代管的企業資料倉儲，可用於儲存及分析超大型資料集。這項服務可讓您以一致的效能，擷取、儲存、讀取及查詢 MB 到 PB 規模的資料，而且不必管理任何基礎架構。由於 BigQuery 具備強大功能和效能，因此非常適合用於各種解決方案。其中部分已詳細記錄為參考模式。

一般來說，如果工作負載需要擷取及分析大量資料，BigQuery 就非常適合。具體來說，這項功能可有效用於即時和預測資料分析 (搭配串流攝入和 BigQuery ML)、異常偵測，以及其他需要以可預測效能分析大量資料的用途。不過，如果您需要資料庫來支援線上交易處理 (OLTP) 類型的應用程式，建議您考慮其他 Google Cloud 服務，例如 Spanner、Cloud SQL 或 Bigtable，這些服務可能更適合這些用途。

BigQuery 中的可靠度維度

可用性

可用性定義使用者從 BigQuery 讀取資料或寫入資料的能力。BigQuery 的設計可確保這兩項服務的高度可用性，並提供 99.99% 的SLA。這兩項作業都涉及兩個元件：

  • BigQuery 服務
  • 執行特定查詢所需的運算資源

服務的可靠度取決於用於擷取資料的特定 BigQuery API。運算資源的可用性取決於使用者在執行查詢時可用的容量。如要進一步瞭解 BigQuery 的運算基本單位，以及由此產生的運算單元資源經濟，請參閱「瞭解運算單元」。

耐用性

SRE 工作手冊的「Implementing SLOs chapter」一節會討論耐用性，並將其定義為「可成功讀取的資料比例」。

資料一致性

一致性定義了使用者對資料寫入或修改後，如何查詢資料的期望。資料一致性的其中一個層面，就是確保資料擷取的「一次且僅一次」語意。詳情請參閱「重試失敗的工作插入作業」。

效能一致性

一般來說，成效可分為兩個維度。延遲時間是指查詢等長時間資料擷取作業的執行時間。傳送量是用來評估 BigQuery 在特定時間內可處理的資料量。由於 BigQuery 採用多租戶、可水平擴充的設計，因此其傳輸量可擴充至任意資料大小。延遲時間和傳輸量的重要性相對性取決於特定用途。

資料復原

您可以透過以下兩種方式評估服務中斷後復原資料的能力：

  • 復原時間目標 (RTO)。事件發生後，資料無法使用的時間長度。
  • 復原點目標 (RPO)。在事件發生前收集到的資料，可接受的遺失量。

這些考量因素特別適用於可用區或區域發生多日或毀滅性停機的情況。

擬定災難復原計畫

雖然「災難」一詞可能會讓人聯想到自然災害，但本節的範圍是針對特定失敗情形，從個別機器的損失，一直到某個區域的重大損失。前者是 BigQuery 自動處理的日常事件，後者則是客戶可能需要設計架構來處理的事件 (視需求而定)。瞭解災難規劃的範圍是否涵蓋客戶責任，這一點很重要。

BigQuery 提供業界領先的 99.99% 運作時間服務水準協議。這項功能得益於 BigQuery 的區域架構，後者會在兩個不同的區域寫入資料，並配置備用的運算能力。請注意，BigQuery 服務水準協議適用於 us-central1 等區域和美國等多區域。

自動處理情境

由於 BigQuery 是區域服務，因此會自動處理機器或整個區域的損失。事實上，BigQuery 是建立在區域之上，但使用者不必瞭解這項資訊。

機器損失

在 Google 的運作規模下，機器故障是每天都會發生的情況。BigQuery 可自動處理機器故障問題，不會對包含區域造成任何影響。
實際上，查詢的執行作業會拆分為小型工作，這些工作可並行調度至多部機器。系統會自動將工作重新調度至其他機器，以處理機器效能突然中斷或降低的情況。這種做法對於縮短尾延遲時間至關重要。

BigQuery 會使用 Reed–Solomon 編碼，以便有效率且持久地儲存資料的區域副本。在極不可能發生的情況下，如果多部機器發生故障導致區域副本遺失，資料也會以相同方式儲存在至少一個其他區域中。在這種情況下，BigQuery 會偵測問題，並建立資料的新區域副本，以便恢復備援機制。

失去可用區

任何特定區域中運算資源的基礎可用性不足以滿足 BigQuery 99.99% 的服務水準協議。因此，BigQuery 會為資料和運算單元提供自動區域備援機制。雖然區域服務中斷的情況不常發生，但仍有可能發生。不過，BigQuery 自動化功能會在嚴重中斷發生後一兩分鐘內，將查詢切換至其他區域。已傳送的查詢可能無法立即復原，但新發出的查詢會復原。這會導致進行中的查詢需要很長的時間才能完成，而新發出的查詢則能快速完成。

即使某個區域無法使用一段較長的時間，也不會發生資料遺失的情況，因為 BigQuery 會同步將資料寫入兩個區域。因此，即使發生區域損失，客戶也不會遇到服務中斷的情況。

故障類型

故障類型分為兩種：軟體故障和硬體故障。

「軟體故障」是指硬體未損壞的操作性缺陷。例如：電源中斷、網路分區或機器當機。一般來說，BigQuery 不會在軟體故障時遺失資料。

「硬體故障」是硬體損壞的操作性缺陷。硬體故障比軟體故障更為嚴重。硬體故障的例子包括水災、恐怖攻擊、地震和颶風造成的損壞。

可用性和耐用性

建立 BigQuery 資料集時，您需要選取資料的儲存位置。這個位置是下列其中一個：

  • 地區：特定地理位置，例如愛荷華州 (us-central1) 或蒙特婁 (northamerica-northeast1)。
  • 多地區：包含兩個以上地理位置的大型地理區域，例如美國 (US) 或歐洲 (EU)。

無論是哪種情況，BigQuery 都會自動將資料副本儲存在所選位置的單一區域內的兩個不同的 Google Cloud 區域中。

除了儲存空間備援機制之外，BigQuery 也會在多個區域中維持備援運算容量。透過結合多個可用區的備援儲存空間和運算資源，BigQuery 可提供高可用性和耐用性。

如果發生機器層級故障，BigQuery 將繼續運作，且幾乎不會出現延遲情況，所有目前執行中的查詢都會繼續處理。在軟性或硬性區域故障的情況下，資料不會遺失。不過，目前執行的查詢可能會失敗，需要重新提交。因停電、變壓器損壞或網路分區等導致的軟體故障，已經過充分測試，且會在幾分鐘內自動緩解。

輕微的地區性故障 (例如整個地區的網路連線中斷) 會導致服務無法使用，直到該地區重新上線為止，但不會導致資料遺失。嚴重的地區性故障，例如災難破壞了整個地區，可能會導致該地區儲存的資料遺失。BigQuery 不會自動在其他地理區域提供資料的備份或副本。您可以建立跨區域資料集副本，強化災難復原策略。

如要進一步瞭解 BigQuery 資料集位置，請參閱「位置注意事項」。

情境：失去區域

在極不可能發生且前所未見的實體區域損失事件中，BigQuery 不會提供耐用性或可用性。這項規則適用於「區域和多區域」設定。因此，在這種情況下，您必須規劃如何維持耐用性和可用性。如果是暫時性資料遺失 (例如網路中斷)，建議您考慮採用 BigQuery 的 99.99% 服務水準協議，以確保資料可用性。

為避免發生區域性災難時資料遺失，您必須將資料備份到其他地理位置。舉例來說，您可以定期將資料快照匯出至位於其他地理區域的 Google Cloud Storage。您可以按照「批次資料處理用途」一節的說明進行操作。
如果是 BigQuery 多區域，請避免將資料備份至多區域範圍內的區域。舉例來說，請勿將美國的資料備份到 us-central1 區域。區域和多區域可能會共用失敗網域，並在災難中共享命運。請改為將資料備份到非美國區域，例如 northamerica-northeast1。如果資料落地規定要求備份必須儲存在美國境內，建議您配對兩個區域，例如 us-central1 和 us-east1。

為避免服務中斷時間過長，您必須在兩個地理位置不同的 BigQuery 位置中，同時備份資料和預留空缺。如上所述，請避免混用區域和多區域，因為在災難發生時，它們可能會共用相同命運。

在區域備援設定中，最可靠的架構是執行熱備援，也稱為雙主動。也就是說，工作負載會在主要和次要地區並行執行。雖然成本較高，但可確保次要區域持續進行驗證，並在您需要容錯移轉時正常運作。如果您不太在意區域停機期間的服務可用性，則可將資料備份到其他區域，確保資料耐用性。

情境：意外刪除或資料毀損

憑藉 BigQuery 的多版本並行控制架構，BigQuery 支援時間旅行。有了這項功能，您就能查詢過去七天內任何時間點的資料。這樣一來，您就能在 7 天內自行還原任何誤刪、修改或損毀的資料。時間旅行功能甚至可用於已刪除的資料表。

BigQuery 也支援資料表快照功能。有了這項功能，您就能明確備份同一個區域內的資料，時間範圍超過 7 天的時間旅行視窗。快照純粹是一種中繼資料作業，不會產生額外的儲存空間位元組。雖然這麼做可防止資料意外刪除，但不會提高資料的耐用性。

用途：即時分析

在這個用途中，系統會從端點記錄檔持續擷取串流資料，並將資料擷取至 BigQuery。為避免整個區域的 BigQuery 服務中斷，您必須持續在其他區域複製資料和佈建單元。由於架構會在擷取路徑中使用 Pub/Sub 和 Dataflow，因此在 BigQuery 無法使用時，架構可提供彈性，因此這麼高的備援程度可能不值得付出成本。

假設使用者已將 us-east4 中的 BigQuery 資料設定為每晚匯出，並使用匯出工作將資料匯出至 Cloud Storage，且儲存類別為 us-central1 中的「Archive Storage」。這樣一來，如果 us-east4 發生資料嚴重遺失的情況，就會有可靠的備份。在這種情況下，復原點目標 (RPO) 為 24 小時，因為上次匯出的備份最長可能會延遲 24 小時。復原時間目標 (RTO) 可能需要數天，因為資料必須從 Cloud Storage 備份還原至 us-central1 的 BigQuery。如果要將 BigQuery 佈建在與備份所在區域不同的區域，則必須先將資料移轉至這個區域。另請注意，除非您已預先在復原區域購買備援運算單元，否則可能需要額外等待，才能根據所要求的數量配置所需的 BigQuery 容量。

使用案例：批次資料處理

對於這個用途來說，每日報表必須在固定期限前完成，才能傳送給監管機關，這對業務來說至關重要。透過執行兩個獨立的整個處理管道執行個體，實現備援功能可能值得付出成本。使用兩個獨立的區域 (例如 us-west1 和 us-east4) 可提供地理區隔和兩個獨立的故障網域，以防某個區域長時間無法使用，甚至是永久失去某個區域的情況。

假設我們需要將報表提交一次，就必須調解兩個管道順利完成的預期情況。合理的策略是先從管道中挑選結果，例如在完成時通知 Pub/Sub 主題。或者，您也可以覆寫結果，並重新版本化 Cloud Storage 物件。如果管道在後續完成時寫入損毀的資料，您可以從 Cloud Storage 還原先前由管道寫入的版本，藉此復原。

處理錯誤

以下是處理影響穩定性的錯誤的最佳做法。

重試失敗的 API 要求

BigQuery 的用戶端 (包括用戶端程式庫和合作夥伴工具) 在發出 API 要求時，應使用截斷指數回退。也就是說，如果用戶端收到系統錯誤或配額錯誤，應重試要求的次數上限，但輪詢間隔會隨機增加。

採用這種重試方法，可讓應用程式在發生錯誤時更加穩健。即使在正常運作情況下，您仍可能會遇到萬分之一的要求失敗，如 BigQuery 的 99.99% 可用性 SLA 所述。在異常情況下，這個錯誤率可能會增加，但如果錯誤是隨機分布，指數輪詢策略可以緩解所有情況，除了最嚴重的情況。

如果您遇到要求持續失敗並顯示 5XX 錯誤的情況，請將問題提報給 Google Cloud 支援團隊。請務必清楚說明失敗對業務的影響，以便我們正確分類問題。另一方面，如果要求持續失敗並顯示 4XX 錯誤，您可以透過變更應用程式來解決問題。詳情請參閱錯誤訊息。

指數輪詢邏輯範例

指數輪詢邏輯會將每次重試之間的等待時間逐漸增加至最大輪詢時間，藉此重試查詢或要求。例如：

  1. 向 BigQuery 提出要求。

  2. 如果要求失敗，請等待 1 + random_number_milliseconds 秒後再重試要求。

  3. 如果要求失敗，請等待 2 + random_number_milliseconds 秒後再重試要求。

  4. 如果要求失敗，請等待 4 + random_number_milliseconds 秒後再重試要求。

  5. 依此類推，時間上限為 (maximum_backoff)。

  6. 繼續等待及重試，直到重試次數達特定上限，但不再增加每次重試之間的等待時間。

注意事項：

  • 等待時間為 min(((2^n)+random_number_milliseconds), maximum_backoff)，n 會在每次疊代 (要求) 時增加 1。

  • random_number_milliseconds 是小於或等於 1000 的隨機毫秒數。這種隨機化設定有助於避免多個用戶端在同步處理並同時重試的情況，導致同步傳送每一波要求。random_number_milliseconds 的值會在每次重試要求後重新計算。

  • 輪詢時間上限 (maximum_backoff) 通常為 32 或 64 秒。maximum_backoff 的適當值視用途而定。

用戶端在達到輪詢持續時間上限後，可以繼續重試。但接下來的重試工作就不需繼續增加輪詢時間。舉例來說，如果用戶端使用的最大輪詢時間為 64 秒，達到這個值之後，用戶端就可以繼續每 64 秒重試一次。到了特定時間點後，用戶端應停止無限重試。

重試之間的等待時間和重試次數，取決於您的用途和網路狀況。

重試失敗的工作插入作業

如果應用程式需要確切一次插入語意，則在插入工作時，還需要考量其他事項。如何實現「僅限一次」語意取決於您指定的 WriteDisposition。寫入處置會告訴 BigQuery 在遇到資料表中的現有資料時應採取哪種做法：失敗、覆寫或附加。

使用 WRITE_EMPTY 或 WRITE_TRUNCATE 處置時，只要重試所有失敗的工作插入或執行作業，即可達成這項目標。這是因為工作擷取的所有資料列都會以原子寫入資料表。

使用 WRITE_APPEND 處置時，用戶端需要指定工作 ID，以防重試時再次附加相同的資料。這是因為 BigQuery 會拒絕嘗試使用先前工作 ID 的工作建立要求。這可為任何給定的作業 ID 實現「僅限一次」語意。在 BigQuery 確認先前的所有嘗試都失敗後，您就可以透過使用新的可預測工作 ID 來重試，以便達到「一次一事」的效果。

在某些情況下，API 用戶端或 HTTP 用戶端可能不會收到工作插入作業的確認訊息，原因可能是暫時性問題或網路中斷。重試插入作業時，該要求會失敗，並傳回 status=ALREADY_EXISTS (code=409 和 reason="duplicate")。您可以呼叫 jobs.get 來擷取現有的工作狀態。現有工作的狀態為 retrieved 後，呼叫端可以決定是否應建立具有新 JOB ID 的新工作。

用途和可靠性需求

BigQuery 可能是各種架構的重要元件。視用途和部署的架構而定，您可能需要滿足各種可用性、效能或其他可靠性要求。為了配合本指南的目的，我們將選取兩個主要用途和架構進行詳細討論。

即時分析

第一個範例是事件資料處理管道。在這個範例中，我們使用 Pub/Sub 擷取端點的記錄事件。接著，串流 Dataflow 管道會對資料執行一些作業，然後再使用 Storage Write API 將資料寫入 BigQuery。接著，系統會使用這些資料進行臨時查詢，例如重建可能導致特定端點結果的事件序列，以及提供近乎即時的資訊主頁，以便透過視覺化資料來偵測趨勢和模式。

這個範例需要您考量可靠性的多個面向。由於端對端資料更新間隔要求相當嚴格，因此攝入程序的延遲時間至關重要。資料寫入 BigQuery 後，可靠性的定義是指使用者能夠以一致且可預測的延遲時間發出臨時查詢，並確保使用資料的資訊主頁反映最新可用的資訊。

批次資料處理

第二個範例是金融服務業的法規遵循批次處理架構。其中一個重要規定是，必須在固定的每晚截止時間前，向監管機構提交每日報表。只要產生報表的每晚批次程序在期限前完成，就會被視為足夠快速。

資料必須在 BigQuery 中提供，並與其他資料來源彙整，以便製作資訊主頁、進行分析，並最終產生 PDF 報表。這些報表必須準時且正確地提交，這是重要的業務需求。因此，確保資料擷取和產生報表的可靠性，並以一致的時間範圍內，以符合必要期限，是關鍵所在。