瞭解可靠性

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

這份簡介將協助您解決三項主要考量：

  • 判斷 BigQuery 是否適合您的工作。
  • 瞭解 BigQuery 可靠性的各個層面。
  • 針對特定用途找出具體的可靠性需求。

選取 BigQuery

BigQuery 是全代管的企業資料倉儲，可儲存及分析大量資料集。您可以使用此服務擷取、儲存、讀取及查詢 MB 到 PB 規模的資料，享有穩定的效能，不必管理任何基礎架構。BigQuery 效能強大，因此非常適合用於各種解決方案。其中有些已詳細記錄為參考模式。

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

BigQuery 的可靠性層面

可用性

可用性是指使用者從 BigQuery 讀取或寫入資料的能力。BigQuery 的設計宗旨是確保這兩者都具有高可用性，並提供 99.99% 的服務水準協議。這兩項作業都涉及兩個元件：

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

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

耐用性

如要瞭解耐久性，請參閱 SRE 工作手冊的「實作 SLO」一章，其中將耐久性定義為「可成功讀取的資料比例」。

資料一致性

一致性定義使用者對資料的期望，也就是資料寫入或修改後，查詢資料的方式。資料一致性的一環是確保資料擷取作業的「只執行一次」語意。詳情請參閱「重試插入失敗的工作」。

效能一致性

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

資料復原

評估系統在服務中斷後復原資料能力的方式有兩種：

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

萬一可用區或區域發生多日或破壞性中斷，這些考量因素就特別重要。

擬定災難復原計畫

雖然「災害」一詞可能會讓人聯想到天災，但本節的範圍涵蓋特定故障，從單一機器的損失，到區域的災難性損失都有。前者是 BigQuery 自動處理的日常事件，後者則需要客戶設計架構來處理 (如有需要)。瞭解災難規劃在何種範圍內會轉移至客戶責任，這點非常重要。

BigQuery 提供業界領先的運作時間服務水準協議，保證 99.99% 的運作時間。BigQuery 的區域架構會在兩個不同區域寫入資料，並提供備援運算容量，因此能確保資料可用性。請務必注意，BigQuery 的服務等級協議 (SLA) 適用於區域 (例如 us-central1) 和多區域 (例如 US)。

自動處理情境

由於 BigQuery 是區域服務，因此 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 資料，並使用擷取工作，每晚將資料匯出至 us-central1 中 Archive Storage 類別下的 Cloud 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 要求時，應使用截斷指數輪詢。也就是說，如果用戶端收到系統錯誤或配額錯誤，應重試要求最多幾次，但輪詢間隔應隨機增加。

採用這種重試方法後，應用程式在發生錯誤時會更加穩定可靠。即使在正常運作條件下，您仍可預期每 10, 000 個要求中，會有一個要求失敗，如 BigQuery 的可用性 99.99% 服務水準協議所述。在異常情況下，這個錯誤率可能會提高，但如果錯誤是隨機分布，指數輪詢策略可以減輕所有情況，最嚴重的情況除外。

如果要求持續失敗並出現 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 都會達到「最多一次」的語意。確認先前所有嘗試都失敗後，您可以使用新的可預測工作 ID 重試，即可達到「只執行一次」的效果。

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

用途和可靠性需求

BigQuery 可能是各種架構的重要元件。視用途和部署的架構而定，您可能需要滿足各種可用性、效能或其他穩定性需求。在本指南中，我們將選取兩個主要用途和架構，並詳細說明。

即時分析

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

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

批次資料處理

第二個例子是批次處理架構，以金融服務業的法規遵循為基礎。其中一項重要需求是每天在固定夜間截止時間前，向監管機構提交報告。只要在期限前完成產生報表的夜間批次程序，即視為速度夠快。

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