災難復原用途：位置受限的資料分析應用程式

Last reviewed 2024-07-20 UTC

本文是系列文章之一，旨在探討災難復原 (DR) Google Cloud。本文說明如何將「為位置受限的工作負載建立災難復原架構」一文中的位置限制，套用至資料分析應用程式。具體來說，本文說明資料分析平台中使用的元件如何納入 DR 架構，以符合應用程式或資料可能受限的地域限制。

本系列文章包含以下部分：

本文適用對象為系統架構師和 IT 經理。本教學課程假設您具備下列知識和技能：

資料分析平台的地域性規定

資料分析平台通常是複雜的多層級應用程式，會儲存靜態資料。這些應用程式會產生事件，並在您的 Analytics 系統中處理及儲存。應用程式本身和系統中儲存的資料都可能受到當地法規的約束。這些法規不僅因國家/地區而異，也因產業別而有所不同。因此，在開始設計 DR 架構之前，您應清楚瞭解資料所在地規定。

請回答下列兩個問題，判斷資料分析平台是否符合任何地域性規定：

  • 您的應用程式是否需要部署至特定區域？
  • 您的靜態資料是否僅限於特定區域？

如果兩題的答案都是「否」，表示您的資料分析平台沒有任何地區專屬規定。由於您的平台沒有地域性需求，請按照「災難復原規劃指南」中的規定，為符合規定的服務和產品制定災難復原指南。

不過，如果對任一問題的答案為「是」，您的應用程式就會受到地區限制。由於您的數據分析平台受到地域限制，因此您必須提出以下問題：您是否能使用加密技術，減輕靜態資料需求？

如果您可以使用加密技術，可以採用 Cloud External Key Manager 和 Cloud Key Management Service 的多區域和雙區域服務。接著，您也可以按照「資料的災難復原情境」一文所述的標準高可用性和災難復原 (HA/DR) 技術操作。

如果無法使用加密技術，則必須使用自訂解決方案或合作夥伴產品來規劃 DR。如要進一步瞭解如何解決災難復原情境的位置限制，請參閱「為位置受限的工作負載建立災難復原架構」。

資料分析平台中的元件

瞭解地區性需求後，下一個步驟是瞭解資料分析平台使用的元件。資料分析平台的常見元件包括資料庫、資料湖泊、處理管道和資料倉儲，如下所列：

  • Google Cloud 提供一系列資料庫服務， 可滿足各種用途。

  • 資料湖泊、資料倉儲和處理管道的定義可能略有不同。本文使用一組參照 Google Cloud 服務的定義：

    • 資料湖泊是可擴充且安全的平台，可從多個系統擷取及儲存資料。典型的資料湖泊可能會使用 Cloud Storage 做為中央儲存空間。
    • 處理管道是端對端程序，可從一或多個系統擷取資料或事件、轉換資料或事件，然後載入至其他系統。管道可以遵循擷取、轉換和載入 (ETL) 或擷取、載入和轉換 (ELT) 程序。通常，載入處理後資料的系統是資料倉儲。Pub/Sub、Dataflow 和 Dataproc 是處理管道的常用元件。
    • 資料倉儲是一種企業系統，可用於分析及製作資料報表，這些資料通常來自作業資料庫。BigQuery 是在 Google Cloud上執行的常用資料倉儲系統。

實際的 DR 實作方式會因地區性需求和使用的資料分析元件而異。以下各節將透過兩個應用實例，說明這項變化。

批次用途：週期性 ETL 工作

第一個用途說明批次程序，其中零售平台會定期從各家商店收集銷售事件做為檔案，然後將檔案寫入 Cloud Storage 值區。下圖說明這項零售商批次作業的資料分析架構。

涉及銷售點資料的批次用途架構圖。

此架構包含下列階段和元件：

  • 擷取階段是指商店將銷售點 (POS) 資料傳送至 Cloud Storage。系統會處理這些擷取的資料。
  • 自動化調度管理階段會使用 Cloud Composer，自動化調度管理端對端批次管道。
  • 處理階段會在 Dataproc 叢集上執行 Apache Spark 工作。Apache Spark 工作會對擷取的資料執行 ETL 程序。這項 ETL 程序會提供業務指標。
  • 資料湖泊階段會取得處理後的資料，並將資訊儲存在下列元件中：
    • 處理後的資料通常會以 Cloud Storage 資料欄式格式 (例如 Parquet 和 ORC) 儲存，因為這些格式可有效率地儲存資料，並加快分析工作負載的存取速度。
    • 程序資料的中繼資料 (例如資料庫、資料表、資料欄和分割區) 會儲存在 Dataproc Metastore 提供的 Hive 中繼存放區服務中。

在受地域限制的情況下，可能難以提供冗餘的處理和協調容量，以維持可用性。由於資料是批次處理，因此在解決災害情境後，可以重新建立處理和協調管道，並重新啟動批次工作。因此，災難復原的重點在於復原實際資料：擷取的 POS 資料、儲存在資料湖泊中的已處理資料，以及儲存在資料湖泊中的中繼資料。

擷取至 Cloud Storage

首先，請考慮用於從 POS 系統擷取資料的 Cloud Storage bucket 的地域性需求。考慮下列選項時，請使用這項地區資訊：

  • 如果當地法規允許靜態資料存放在多區域或雙區域位置，請在建立 Cloud Storage bucket 時選擇對應的位置類型。您選擇的位置類型會定義用於複製靜態資料的 Google Cloud 區域。如果其中一個區域發生中斷，您仍可存取多區域或雙區域值區中的資料。
  • Cloud Storage 也支援客戶管理加密金鑰 (CMEK) 和客戶提供的加密金鑰 (CSEK)。如果您使用 CMEK 或 CSEK 管理金鑰，部分地區規則允許將靜態資料儲存在多個位置。如果您的地域性規則允許使用 CMEK 或 CSEK，您可以設計 DR 架構，使用 Cloud Storage 地區。
  • 您所在地區的規定可能不允許使用任一位置類型或加密金鑰管理。如果無法使用位置類型或加密金鑰管理功能，可以透過 gcloud storage rsync 指令將資料同步到其他位置，例如本機儲存空間或其他雲端供應商的儲存空間解決方案。

如果發生災害，Cloud Storage 值區中擷取的 POS 資料可能包含尚未處理及匯入資料湖的資料。或者，POS 資料可能無法擷取至 Cloud Storage 值區。此時您有下列災害復原選項：

  • 讓 POS 系統重試。如果系統無法將 POS 資料寫入 Cloud Storage，資料擷取程序就會失敗。如要解決這個問題，您可以實作重試策略，讓 POS 系統重試資料擷取作業。由於 Cloud Storage 提供高耐久性，因此在 Cloud Storage 服務恢復後，資料擷取和後續處理管道會繼續運作，資料流失量極少或完全不會流失。

  • 建立擷取資料的副本。Cloud Storage 支援多區域和雙區域位置類型。視資料區域性需求而定，您或許可以設定多地區或雙地區 Cloud Storage 值區，提高資料可用性。您也可以使用 gcloud storage Google Cloud CLI 指令等工具，在 Cloud Storage 和其他位置之間同步資料。

自動化調度及處理擷取的銷售點資料

在批次用途的架構圖中，Cloud Composer 會執行下列步驟：

  • 驗證新檔案是否已上傳至 Cloud Storage 擷取值區。
  • 啟動暫時性 Dataproc 叢集。
  • 啟動 Apache Spark 工作來處理資料。
  • 在工作結束時刪除 Dataproc 叢集。

Cloud Composer 會使用有向非循環圖 (DAG) 檔案定義這些步驟。這些 DAG 檔案會儲存在架構圖中未顯示的 Cloud Storage bucket。就雙區域和多區域的本機性而言，DAG 檔案 bucket 的 DR 注意事項與擷取 bucket 的注意事項相同。

Dataproc 叢集是暫時的，也就是說，叢集只會在處理階段執行時存在。這種暫時性特質表示，您不必針對 Dataproc 叢集執行任何明確的 DR 動作。

使用 Cloud Storage 建立資料湖泊儲存空間

您用於資料湖的 Cloud Storage 值區，與用於擷取值區的考量事項相同：雙區域和多區域考量事項、加密的使用方式，以及 gcloud storage rsync gcloud CLI 指令的使用方式。

設計資料湖的 DR 計畫時，請考量下列層面：

  • 資料大小。資料湖中的資料量可能很大。還原大量資料需要時間。在 DR 情境中，您需要考量資料湖的資料量對還原資料所需時間的影響，以達到下列條件：

    在目前的批次使用案例中，Cloud Storage 用於資料湖泊位置，並提供高耐久性。然而，勒索軟體攻擊事件卻有增加的趨勢。為確保您有能力從這類攻擊中復原，建議您遵循「Cloud Storage 如何提供 99.999999999% 的耐用性」一文中的最佳做法。

  • 資料依附元件。資料湖泊中的資料通常會由資料分析系統的其他元件 (例如處理管道) 使用。在 DR 情境中，處理管道和管道所依附的資料應共用相同的 RTO。在此情況下，請著重於系統無法使用的時間長度。

  • 資料年齡。歷來資料可能允許較高的 RPO。這類資料可能已由其他資料分析元件分析或處理，並可能保留在具有自身 DR 策略的其他元件中。舉例來說，每天都會將匯出至 Cloud Storage 的銷售記錄匯入 BigQuery，以供分析。如果 BigQuery 採用適當的 DR 策略，匯入 BigQuery 的歷來銷售記錄可能比未匯入的記錄有較低的復原目標。

使用 Dataproc Metastore 儲存資料湖中繼資料

Dataproc Metastore 是全代管、高可用性、可自動修復的無伺服器 Apache Hive Metastore。中繼存放區提供資料抽象化和資料探索功能。發生災難時，可以備份和還原中繼資料存放區。Dataproc Metastore 服務也支援匯出和匯入中繼資料。您可以新增匯出中繼存放區的工作，並連同 ETL 工作維護外部備份。

如果遇到中繼資料不符的情況，可以使用 MSCK 指令，從資料本身重新建立中繼資料存放區。

串流用途：使用 ELT 擷取變更資料

第二個用途是零售平台使用變更資料擷取 (CDC) 更新後端庫存系統，並追蹤即時銷售指標。下圖顯示的架構會處理交易資料庫 (例如 Cloud SQL) 中的事件，然後將事件儲存在資料倉儲中。

架構圖：串流用途，涉及零售資料的變更資料擷取。

此架構包含下列階段和元件：

  • 在擷取階段，系統會將傳入的變更事件推送至 Pub/Sub。Pub/Sub 是一種訊息傳遞服務，可擷取及發布串流分析資料。Pub/Sub 還有可擴充和無伺服器的優點。
  • 在處理階段，系統會使用 Dataflow 對擷取的事件執行 ELT 程序。
  • 資料倉儲階段會使用 BigQuery 儲存已處理的事件。合併作業會在 BigQuery 中插入或更新記錄。這項作業可讓儲存在 BigQuery 中的資訊與交易式資料庫保持同步。

雖然這個 CDC 架構不依賴 Cloud Composer，但有些 CDC 架構需要 Cloud Composer 來自動化調度管理串流與批次工作負載的整合。在這些情況下，Cloud Composer 工作流程會實作完整性檢查、回填和預測，但由於延遲限制，這些作業無法即時完成。如要瞭解 Cloud Composer 的 DR 技術，請參閱本文件稍早討論的批次處理用途。

規劃串流資料管道的 DR 架構時，請考慮下列事項：

  • 管道依附元件。處理管道會從一或多個系統 (來源) 取得輸入內容。管道接著會處理、轉換這些輸入內容，並儲存至其他系統 (接收器)。請務必設計 DR 架構，以達成端對端 RTO。您必須確保資料來源和接收器的 RPO 可滿足 RTO。除了設計雲端架構來滿足地域性需求，您也需要設計原始 CDC 來源，確保能達到端對端 RTO。
  • 加密和地區。如果加密可協助您減輕地域限制，則可使用 Cloud KMS 達成下列目標：
    • 管理自己的加密金鑰。
    • 善用個別服務的加密功能。
    • 在因地區限制而無法使用的區域部署服務。
  • 動態資料的地區性規則。部分地區規則可能只適用於靜態資料，不適用於動態資料。如果您的地區性規則不適用於傳輸中的資料，請設計 DR 架構，使用其他地區的資源來改善復原目標。您可以整合加密技術，輔助區域方法。

擷取至 Pub/Sub

如果沒有地域限制，您可以將訊息發布至全球 Pub/Sub 端點。 全球 Pub/Sub 端點可從任何Google Cloud 位置查看及存取。

如果當地法規允許使用加密技術，您可以設定 Pub/Sub，達到與全域端點類似的高可用性。雖然 Pub/Sub 訊息預設會以Google-owned and Google-managed encryption keys 加密，但您可以設定 Pub/Sub 改用 CMEK。搭配使用 Pub/Sub 和 CMEK，您就能遵守加密相關的地域性規則，同時維持高可用性。

根據部分地區法規，即使訊息經過加密，仍須保留在特定位置。如果您的地域性規則有這項限制，可以指定 Pub/Sub 主題的訊息儲存政策，並將其限制在特定區域。如果您採用這種訊息儲存方式，發布至主題的訊息絕不會儲存在您指定的 Google Cloud 區域以外。如果您的地區規則允許使用多個 Google Cloud 區域，您可以在 Pub/Sub 主題中啟用這些區域，提高服務可用性。請注意，實作訊息儲存政策來限制 Pub/Sub 資源位置時，會影響可用性。

Pub/Sub 訂閱項目可讓您儲存未確認的訊息，最多 7 天，且訊息數量不受限制。如果服務層級協議允許延遲資料，管道停止執行時，您可以在 Pub/Sub 訂閱中緩衝處理資料。管道再次執行時，您就可以處理備份的事件。這項設計的優點是 RPO 較低。如要進一步瞭解 Pub/Sub 的資源限制，請參閱 Pub/Sub 配額的資源限制。

使用 Dataflow 處理事件

Dataflow 是可執行各種資料處理模式的代管服務。Apache Beam SDK 是一種開放原始碼程式設計模型，可讓您開發批次和串流管道。您可以使用 Apache Beam 程式建立管道，然後在 Dataflow 服務上執行管道。

設計區域限制時，您需要考慮來源、接收器和暫時檔案的位置。如果這些檔案位置位於工作地區「外部」，則系統可能會跨地區傳送資料。如果您的地域性規則允許在其他位置處理資料，請設計 DR 架構，在其他 Google Cloud 區域部署工作站，以提供高可用性。

如果地區限制將處理作業限制在單一位置，您可以建立僅限特定區域或地帶的 Dataflow 工作。提交 Dataflow 工作時，您可以指定地區端點、工作站地區和工作站區域參數。這些參數可控管工作站的部署位置，以及工作的中繼資料儲存位置。

Apache Beam 提供架構，可讓管道在各種執行器上執行。您可以設計 DR 架構，充分運用這項功能。舉例來說，您可以設計 DR 架構，使用 Apache Spark Runner 在本機內部部署的 Spark 叢集上執行備份管道。如要瞭解特定執行器是否能執行特定管道作業，請參閱 Beam 功能矩陣。

如果加密可協助您減輕地區限制，您可以使用 Dataflow 中的 CMEK，同時加密管道狀態構件，以及存取受 Cloud KMS 金鑰保護的來源和接收器。透過加密，您可以設計 DR 架構，使用因地域限制而無法使用的區域。

以 BigQuery 為基礎建構的資料倉儲

資料倉儲可支援分析和決策。資料倉儲除了包含分析資料庫，還包含多個分析元件和程序。

設計資料倉儲的 DR 計畫時，請考量下列特性：

  • 大小。資料倉儲比線上交易處理 (OLTP) 系統大得多。資料倉儲擁有 TB 級到 PB 級的資料並不罕見。您必須考量還原這些資料需要多久時間，才能達到 RPO 和 RTO 值。規劃 DR 策略時，您也必須將復原數 TB 資料的相關費用納入考量。如要進一步瞭解 BigQuery 的 DR 緩解技術，請參閱「備份和復原機制，適用於 Google Cloud 上的受管理資料庫服務 Google Cloud」一節中的 BigQuery 資訊。

  • 可用性：建立 BigQuery 資料集時，請選取資料的儲存位置：區域或多區域。地區位置是指單一的特定地理位置，例如愛荷華州 (us-central1)。多區域位置是指包含兩個以上地理位置的大型地理區域，例如美國或歐洲。

    設計災害復原計畫時，請務必考量地域限制，因為失敗網域 (也就是失敗發生在機器層級、區域或地區) 會直接影響您是否能達到定義的復原時間目標。如要進一步瞭解這些故障網域以及對可用性的影響，請參閱「BigQuery 的可用性和耐久性」。

  • 資料性質。資料倉儲包含歷史資訊，且大部分的舊資料通常是靜態資料。許多資料倉儲都設計為僅供附加。如果資料倉儲只能附加資料，您或許可以只還原附加的資料，即可達到 RTO。採用這種方法時，您只需要備份附加資料。發生災害時，您就能還原附加資料，並使用資料倉儲，但資料會是子集。

  • 資料新增和更新模式。資料倉儲通常會使用 ETL 或 ELT 模式更新。控管更新路徑後，您就能從替代來源重現近期更新事件。

視當地法規要求而定，您可能只能為資料倉儲使用單一或多個區域。雖然 BigQuery 資料集可以是地區資源，但多地區儲存空間是確保資料可用性的最簡單且最具成本效益的方式，可防範災害發生。如果您的地區不支援多區域儲存空間，但您可以使用其他地區，請使用 BigQuery 資料移轉服務將資料集複製到其他地區。如果可以使用加密功能來減輕地域性限制，您可以透過 Cloud KMS 和 BigQuery 管理自己的加密金鑰。

如果只能使用一個地區，請考慮備份 BigQuery 表格。備份資料表最符合成本效益的解決方案是使用 BigQuery 匯出功能。使用 Cloud Scheduler 或 Cloud Composer 定期排定匯出工作，將資料寫入 Cloud Storage。您可以使用 Avro 等格式搭配 SNAPPY 壓縮，或使用 JSON 搭配 GZIP 壓縮。設計匯出策略時，請注意匯出作業的限制。

您可能也想以 Parquet 和 ORC 等直欄格式儲存 BigQuery 備份。這些格式提供高壓縮率，且可與許多開放原始碼引擎互通，例如您內部部署系統中的 Hive 和 Presto。下圖說明將 BigQuery 資料匯出為資料欄格式，並儲存在本機位置的程序。

架構圖：顯示將 BigQuery 資料匯出至資料欄儲存空間，以進行災難復原。

具體來說，將 BigQuery 資料匯出至內部部署儲存位置的程序包含下列步驟：

  • BigQuery 資料會傳送至 Dataproc 上的 Apache Spark 工作。使用 Apache Spark 工作可進行結構定義演變。
  • Dataproc 工作處理 BigQuery 檔案後，處理過的檔案會寫入 Cloud Storage，然後轉移至內部部署的 DR 位置。
  • Cloud Interconnect 可將虛擬私有雲網路連線至內部部署網路。
  • 透過 Spark 工作，即可轉移至內部部署的 DR 位置。

如果倉儲設計為僅供附加，且按日期分區，您需要在新資料表中建立所需分區的副本，然後在新資料表上執行 BigQuery 匯出工作。接著，您可以使用 gcloud storage gcloud CLI 指令等工具，將更新後的檔案轉移至地端或另一個雲端的備份位置。 (將資料移出 Google Cloud時，可能需要支付輸出作業費用)。

舉例來說，您有一個銷售資料倉儲，其中包含只能附加的 orders 資料表，新訂單會附加至代表目前日期的分區。不過，退貨政策可能會允許在 7 天內退貨。因此，orders 表格中過去 7 天內的記錄可能會更新。你的出口策略必須將退貨政策納入考量。在這個範例中，任何備份 orders 資料表的匯出工作，也需要匯出代表過去 7 天內訂單的分區，以免因退貨而遺漏更新。

後續步驟

貢獻者

作者：