跨 Google Cloud 區域遷移：為跨區域遷移作業準備資料和批次工作負載

Last reviewed 2024-12-02 UTC

本文說明如何在 Google Cloud 上設計資料平台，盡量減少日後擴展至其他區域，或從一個區域遷移至另一個區域時的影響。本文是系列文章之一，可協助您瞭解將資料平台擴展至其他區域的影響。這項功能可協助您瞭解如何執行下列操作：

  • 準備遷移資料和資料管道。
  • 在遷移階段設定檢查。
  • 將資料儲存空間和資料運算分開，建立彈性的遷移策略。

如果您事先未規劃跨區域遷移或擴展至多個區域，本系列指南也很有幫助。在這種情況下，您可能需要花費額外心力，為跨區域遷移作業和擴展至多個區域，準備基礎架構、工作負載和資料。

本文件是系列文章之一：

本系列教學課程假設您已閱讀並熟悉下列文件：

以下是遷移流程圖。

列出四個階段的遷移路徑。

在每個遷移步驟中，您會按照「遷移至 Google Cloud：開始使用」中定義的階段操作：

  1. 評估及探索工作負載。
  2. 規劃及奠定基礎。
  3. 部署工作負載。
  4. 將環境調整至最佳狀態。

Google Cloud上的現代化資料平台

本節說明現代資料平台的各個部分，以及這些部分通常在 Google Cloud中的建構方式。資料平台一般可分為兩個部分：

  • 「資料儲存」層會儲存資料。您儲存的資料可能以檔案形式存在，您可以在 Hadoop 分散式檔案系統 (HDFS) 或 Cloud Storage 等檔案系統上管理實際位元組，也可能使用特定領域的語言 (DSL) 管理資料庫管理系統中的資料。
  • 資料運算層是指您在儲存系統上啟動的任何資料處理作業。與儲存層一樣，實作方式有很多種，有些資料儲存工具也會處理資料運算。平台中的資料運算層負責從儲存層載入資料、處理資料，然後將結果儲存至目標系統。目標系統可以是來源儲存層。

部分資料平台會為資料儲存層使用多個儲存系統，並為資料處理層使用多個資料運算系統。在大多數情況下，資料儲存層和資料運算層會分開。舉例來說，您可能已使用下列Google Cloud 服務實作資料儲存層：

您可能已使用其他服務 (例如下列服務) 實作資料運算層：Google Cloud

為減少通訊時間和延遲、輸出資料傳輸成本，以及儲存層和運算層之間的 I/O 作業次數，建議您將資料儲存在處理資料的相同區域。

此外，我們也建議您將資料儲存層與資料運算層分開。將這些層級分開可提高變更運算層級和遷移資料的彈性。將圖層分開也能減少資源用量，因為您不必讓運算層持續運作。因此，建議您在同一個區域和地區，將資料儲存和資料運算部署在不同平台上。舉例來說，您可以將資料儲存空間從 HDFS 移至 Cloud Storage，並使用 Dataproc 叢集進行運算。

評估您的環境

在評估階段，您要判斷遷移已部署的批次資料管道所需的要求和依附元件：

  1. 建立鉅細靡遺的資料 pipeline 清單。
  2. 根據管道屬性和依附元件將管道編目。
  3. 訓練並教導您的團隊使用 Google Cloud。
  4. 在 Google Cloud上構建實驗和概念驗證。
  5. 計算目標環境的總持有成本 (TCO)。
  6. 選擇您要先遷移的工作負載。

如要進一步瞭解評估階段和這些工作，請參閱「遷移至 Google Cloud：評估及探索工作負載」。以下各節內容皆以該文件為依據。

建立廣告空間

如要劃定遷移範圍，您必須瞭解部署資料管道的資料平台環境：

  1. 建立資料基礎架構的清單，列出您用於資料儲存和批次資料處理的不同儲存層和運算層。
  2. 建立預定要遷移的資料管道清單。
  3. 建立資料集清單，列出資料管道讀取的資料集，以及需要遷移的資料集。

如要建立資料平台清單，請針對資料基礎架構的每個部分，考慮下列事項：

  • 儲存層。除了 Cloud Storage 等標準儲存平台，也請考慮其他儲存層，例如 Firebase、BigQuery、Bigtable 和 Postgres 等資料庫，或是 Apache Kafka 等其他叢集。每個儲存空間平台都有自己的策略和方法來完成遷移作業。舉例來說，Cloud Storage 提供資料移轉服務，而資料庫可能內建移轉工具。請確認用於資料儲存的每項產品在目標環境中都可供使用，或你已準備好相容的替代產品。針對每個相關儲存空間平台，練習並驗證技術資料移轉程序。
  • 運算層。針對每個運算平台，驗證部署計畫，並驗證您可能對不同平台所做的任何設定變更。
  • 網路延遲。測試並驗證來源環境與目標環境之間的網路延遲。請務必瞭解資料複製作業需要多少時間。此外，您也需要測試從用戶端和外部環境 (例如內部部署環境) 到目標環境的網路延遲，並與來源環境進行比較。

  • 設定和部署。每個資料基礎架構產品都有自己的設定方法。清查您為每個元件建立的自訂設定，以及您在每個平台使用的預設版本元件 (例如您使用的 Dataproc 或 Apache Kafka 版本)。請確保這些設定可部署為自動部署程序的一部分。

    您必須瞭解每個元件的設定方式，因為計算引擎的行為可能會因設定而異，尤其是在遷移期間處理層架構發生變化時。舉例來說，如果目標環境執行的 Apache Spark 版本不同，Spark 架構的部分設定可能會因版本而異。這類設定變更可能會導致輸出內容、序列化和計算發生變化。

    遷移期間，建議您使用自動部署功能，確保版本和設定維持不變。如果無法保持版本和設定相同，請務必進行測試，驗證架構計算的資料輸出內容。

  • 叢集大小：如果是自行管理的叢集 (例如長期執行的 Dataproc 叢集，或在 Compute Engine 上執行的 Apache Kafka 叢集)，請記下叢集中的節點和 CPU 數量，以及每個節點的記憶體。遷移至其他區域可能會導致部署作業使用的處理器有所變更。因此，建議您在將遷移的基礎架構部署至正式環境後，分析及最佳化工作負載。如果元件是全代管或無伺服器 (例如 Dataflow)，大小會是每個個別作業的一部分，而不是叢集本身的一部分。

在清查期間評估下列項目時，請著重於資料管道：

  • 資料來源和接收器。請務必考量每個資料管道用於讀取和寫入資料的來源和接收器。
  • 服務水準協議 (SLA) 和服務等級目標 (SLO)。批次資料管道的 SLA 和 SLO 通常是以完成時間來衡量，但也可以用其他方式衡量，例如使用的運算能力。這項業務中繼資料對於推動業務持續性和災難復原計畫程序 (BCDR) 十分重要，例如在區域或區域性故障時，將最重要管道的子集容錯移轉至其他區域。
  • 資料管道依附元件。有些資料管道會使用其他資料管道產生的資料。將管道分割為遷移衝刺時，請務必考量資料依附元件。
  • 產生及使用的資料集。針對每個資料管道，找出管道使用的資料集，以及管道產生的資料集。這麼做有助於找出管道之間，以及整體架構中其他系統或元件之間的依附關係。

您在清查時評估的下列項目，著重於要遷移的資料集：

  • 資料集。找出需要遷移至目標環境的資料集。如果歷來資料已封存且未積極使用，您可能會認為不需要遷移，或是在不同時間遷移。定義遷移程序和遷移衝刺的範圍，有助於降低遷移作業的風險。
  • 資料大小。如果您打算先壓縮檔案再移轉，請務必記下壓縮前後的檔案大小。資料大小會影響從來源複製資料到目的地所需的時間和費用。考量這些因素有助於您選擇停機策略，詳情請參閱本文後續內容。
  • 資料結構。將要遷移的每個資料集分類，並確認您瞭解資料是結構化、半結構化還是非結構化。瞭解資料結構有助於制定策略，確保資料正確且完整地遷移。

完成評估

建立 Kubernetes 叢集和工作負載的相關清查後，請在「遷移至 Google Cloud：評估及探索工作負載」中，完成評估階段的其餘活動。

規劃及建立基礎

遷移至 Google Cloud 的規劃和建構階段包含下列工作：

  1. 建立資源階層。
  2. 設定身分與存取權管理 (IAM)。
  3. 設定帳單資訊。
  4. 設定網路連線。
  5. 強化安全性。
  6. 設定記錄、監控和快訊功能。

如要進一步瞭解各項工作，請參閱「遷移至 Google Cloud：規劃及建構基礎」。

遷移資料和資料管道

以下各節說明遷移資料和批次資料管道的計畫。這份文件定義了資料管道特性的一些概念，有助您在建立遷移計畫時瞭解相關資訊。本文也會探討一些資料測試概念，協助您提高對資料遷移的信心。

遷移計畫

在遷移計畫中，您必須納入完成資料轉移的時間。您的計畫應考量網路延遲、測試資料完整性的時間、取得任何遷移失敗的資料，以及任何網路費用。由於資料會從一個區域複製到另一個區域，因此網路費用方案應包含跨區域網路費用。

建議您將不同的管道和資料集劃分為衝刺，並分別遷移。這種做法有助於降低每次遷移衝刺的風險，並在每次衝刺中進行改善。為改善遷移策略並及早發現問題，建議您先遷移較小且不重要的工作負載，再遷移較大且重要的工作負載。

遷移計畫的另一個重要部分，是說明運算層中不同資料管道的策略、依附元件和性質。如果資料儲存層和資料運算層是建構在同一個系統上，建議您在複製資料時監控系統效能。一般來說，複製大量資料可能會導致系統的 I/O 負荷過高，並降低運算層的效能。舉例來說，如果您執行工作負載，以批次方式從 Kafka 叢集擷取資料，讀取大量資料的額外 I/O 作業可能會導致來源環境中仍在執行的任何有效資料管道效能下降。在這種情況下，您應使用任何內建或自訂指標監控系統效能。為避免系統負載過重，建議您在資料複製程序期間，規劃停用部分工作負載，或降低複製階段的負載。

由於複製資料會使遷移程序耗時較長，建議您制定應變計畫，以解決遷移期間可能發生的任何問題。舉例來說，如果資料移動時間超出預期，或完整性測試在您將新系統上線前失敗，請考慮是否要回溯，或嘗試修正並重試失敗的作業。雖然回溯是較乾淨的解決方案，但多次複製大型資料集可能既費時又昂貴。建議您清楚瞭解並預先定義測試，以判斷在哪些情況下應採取哪些行動、允許多少時間嘗試建立修補程式，以及何時執行完整的回復作業。

請務必區分用於遷移的工具和指令碼，以及您要複製的資料。回溯資料移動作業表示您必須重新複製資料，並覆寫或刪除已複製的資料。回溯工具和指令碼的變更可能較為容易且成本較低，但工具變更可能會導致您必須重新複製資料。舉例來說，如果您在動態產生 Cloud Storage 位置的指令碼中建立新的目標路徑，可能就必須重新複製資料。為避免重新複製資料，請建構指令碼，允許可恢復性和等冪性。

資料管道特性

如要制定最佳遷移計畫，您需要瞭解不同資料管道的特性。請務必瞭解寫入資料的批次管道與讀取資料的批次管道不同：

  • 寫入資料的資料管道：由於這類管道會變更來源系統的狀態，因此在將資料複製到目標環境的同時，可能難以將資料寫入來源環境。請考量寫入資料的管道執行階段，並盡量在整體程序中優先遷移這些管道。這麼做可讓您在遷移讀取資料的管道前，先在目標環境中準備好資料。
  • 讀取資料的資料管道：讀取資料的管道可能對資料更新間隔有不同需求。如果來源系統上產生資料的管道已停止運作，讀取資料的管道或許能在資料複製到目標環境時執行。

資料是狀態，在區域之間複製資料並非不可分割的作業。因此，您必須留意資料複製期間的狀態變化。

在遷移計畫中區分系統也很重要。您的系統可能會有不同的功能性和非功能性需求 (例如，一個系統用於批次處理，另一個系統用於串流)。因此，您的計畫應包含不同的策略，以便遷移各個系統。請務必指定系統之間的依附元件，並說明如何在遷移作業的每個階段，減少各系統的停機時間。

遷移衝刺的典型計畫應包含下列項目：

  • 一般策略。請說明這個衝刺期間的遷移處理策略。如需常見策略，請參閱「部署工作負載」。
  • 資料複製和資源部署工具與方法清單。 指定您打算用來複製資料或將資源部署至目標環境的工具。這份清單應包含用於複製 Cloud Storage 資產的自訂指令碼、Google Cloud CLI 等標準工具，以及遷移服務等工具。 Google Cloud
  • 要部署至目標環境的資源清單。列出需要在目標環境中部署的所有資源。這份清單應包含所有資料基礎架構元件，例如 Cloud Storage 值區、BigQuery 資料集和 Dataproc 叢集。在某些情況下，早期遷移衝刺會以較小的容量部署適當大小的叢集 (例如 Dataproc 叢集)，而後續衝刺則會調整大小，以配合新的工作負載。確認方案包含潛在的調整大小作業。
  • 要複製的資料集清單。請務必為每個資料集指定下列資訊：
    • 複製順序 (如適用)：對於大多數策略，作業順序可能很重要。但排定維護時間策略是例外，詳情請參閱本文後續章節。
    • 大小
    • 重要統計資料：繪製重要統計資料圖表，例如列號，有助於確認資料集是否已成功複製。
    • 預估複製時間：根據遷移計畫，完成資料轉移所需的時間。
    • 複製方法：請參閱本文稍早列出的工具和方法。
    • 驗證測試：明確列出您打算完成的測試，以驗證資料是否已完整複製。
    • 應變計畫：說明驗證測試失敗時的處理方式。應變措施計畫應指定何時重試及繼續複製或填補缺口，以及何時完整回溯並重新複製整個資料集。

測試

本節說明您可以規劃的幾種典型測試類型。這些測試可協助您確保資料完整性。此外，這些工具也能協助您確保運算層正常運作，並準備好執行資料管道。

  • 摘要或雜湊比較：如要驗證資料複製完成後是否完整，您需要比較原始資料集和目標環境中的新副本。如果資料結構位於 BigQuery 資料表中，您就無法在查詢中聯結這兩個資料表，查看所有資料是否存在，因為資料表位於不同區域。考量到成本和延遲時間，BigQuery 不允許查詢跨區域聯結資料。反之，比較方法必須彙整每個資料集，並比較結果。視資料集結構而定，摘要方法可能有所不同。舉例來說，BigQuery 資料表可能會使用匯總查詢，但 Cloud Storage 上的一組檔案可能會使用 Spark 管道計算每個檔案的雜湊，然後匯總雜湊。

  • Canary 流程：Canary 流程會啟動工作，用來驗證資料完整性和完整程度。繼續進行資料分析等業務用途前，建議先執行 Canary 流程作業，確保輸入資料符合一組必要條件。您可以將 Canary 流程實作為自訂資料管道，或實作為以 Cloud Composer 為基礎的 DAG 流程。透過 Canary 流程，您可以完成下列工作：確認特定欄位沒有遺漏值，或驗證特定資料集的列數是否符合預期。

    您也可以使用 Canary 流程，建立摘要或資料欄的匯總，或是資料子集。接著，您可以使用 Canary 流程，將資料與從資料副本取得的類似摘要或匯總資料進行比較。

    當您需要評估以檔案格式 (例如 Cloud Storage 上的 Avro 檔案) 儲存及複製的資料準確度時，金絲雀流程方法就非常實用。Canary 流程通常不會產生新資料，但如果輸入資料未符合一組規則，就會失敗。

  • 測試環境：完成遷移計畫後，您應在測試環境中測試該計畫。測試環境應包含將取樣資料或暫存資料複製到其他區域，以估算透過網路複製資料所需的時間。這項測試有助於找出遷移計畫的任何問題，並驗證資料是否能順利遷移。測試應包含功能和非功能測試。功能測試可驗證資料是否正確遷移。非功能測試：驗證遷移作業是否符合效能、安全性和其他非功能性需求。計畫中的每個遷移步驟都應包含驗證條件，詳述何時可視為完成該步驟。

如要協助驗證資料，可以使用資料驗證工具 (DVT)。 這項工具會執行多層級的資料驗證功能，從資料表層級到資料列層級，並協助您比較來源和目標系統的結果。

測試應驗證運算層的部署作業，並測試複製的資料集。其中一種做法是建構測試管道，計算複製資料集的某些匯總，並確保來源資料集和目標資料集相符。如果您在區域之間複製的檔案，並非來源和目標系統之間完全相同的位元組副本 (例如變更檔案格式或檔案壓縮)，來源和目標資料集之間就更容易出現不符的情況。

舉例來說，假設資料集是由以換行符號分隔的 JSON 檔案組成。檔案會儲存在 Cloud Storage bucket 中，並以 BigQuery 中的外部資料表形式掛接。如要減少透過網路傳輸的資料量，您可以在遷移期間執行 Avro 壓縮，再將檔案複製到目標環境。這項轉換作業有許多優點，但也有一些風險，因為寫入目標環境的檔案並非來源環境中檔案的位元組副本。

為降低轉換情境帶來的風險，您可以建立 Dataflow 工作，或使用 BigQuery 計算資料集的某些匯總和檢查碼雜湊 (例如計算每個數值資料欄的總和、平均值或分位數)。如果是字串資料欄，您可以根據字串長度或該字串的雜湊碼計算匯總。針對每個資料列，您可以從所有其他資料欄的組合計算匯總雜湊，以高準確度驗證資料列是否與來源相同。系統會在來源和目標環境中進行這些計算，然後進行比較。在某些情況下 (例如資料集儲存在 BigQuery 中)，您無法從來源和目標環境聯結資料表，因為這些資料表位於不同區域，因此您需要使用可連線至這兩個環境的用戶端。

您可以在 BigQuery 中或以批次工作 (例如在 Dataflow 中) 實作上述測試方法。接著，您可以執行匯總作業，並比較來源環境的計算結果與目標環境的計算結果。這種做法有助於確保資料完整且準確。

測試運算層的另一個重要環節，是執行包含各種處理引擎和運算方法的管道。如果是 BigQuery 或 Dataflow 等代管運算引擎，測試管道的重要性就比較低。不過，請務必測試管道是否適用於 Dataproc 等非受管理運算引擎。舉例來說，如果 Dataproc 叢集處理多種運算類型 (例如 Apache Spark、Apache Hive、Apache Flink 或 Apache MapReduce)，您應測試每個執行階段，確保不同類型的工作負載都已準備好轉移。

遷移策略

透過適當的測試驗證遷移計畫後，即可遷移資料。遷移資料時，您可以針對不同的工作負載採用不同的策略。以下列舉幾種遷移策略，您可以直接採用，或是根據需求自訂：

  • 排定維護時間：您可以規劃轉換空窗期的發生時間。如果資料經常變更，但服務水準目標和服務水準協議可承受一些停機時間，這個策略就很適合。這項策略可確保資料轉移的準確度，因為資料在複製時完全不會更新。詳情請參閱「遷移至 Google Cloud：轉移大型資料集」一文中的「定期維護」。
  • 唯讀轉換：這是排定維護策略的稍微變化版本，來源系統資料平台允許唯讀資料管道在資料複製期間繼續讀取資料。這項策略相當實用，因為部分資料管道可以繼續運作，並為終端系統提供洞察資料。這項策略的缺點是，遷移期間產生的資料會過時，因為來源資料不會更新。因此，您可能需要在遷移後採用追趕策略，以解決終端系統中的過時資料問題。
  • 完全有效：您在特定時間戳記複製資料，而來源環境仍處於有效狀態，可供讀取和寫入資料管道使用。複製資料並切換至新部署作業後，請執行差異複製階段，取得來源環境中遷移時間戳記後產生的資料。相較於其他策略，這種做法需要更多協調和考量。因此，遷移計畫必須包含如何處理來源資料的更新和刪除作業。
  • 雙重寫入：資料複製期間，資料管道可在來源和目標環境中執行。如果您使用完全啟用或唯讀策略，就必須進行差異副本階段，才能回填資料，但這項策略可避免這種情況。不過，為確保資料管道產生相同的結果，雙重寫入策略需要更多測試才能遷移。如果未事先進行測試，嘗試合併腦裂情境時會遇到問題。雙重寫入策略也可能導致成本增加，因為您需要在不同區域執行相同的工作負載兩次。這項策略有機會在平台遷移期間實現零停機，但需要更多協調作業才能正確執行。

遷移後測試

遷移完成後，請測試資料完整性，並測試資料管道的有效性。如果您在衝刺中完成遷移作業，則每次衝刺後都必須執行這些測試。您在這個階段執行的測試與整合測試類似：您會測試資料管道的有效性，該管道會以完整的正式版資料做為輸入內容，執行業務用途，然後檢查輸出內容的有效性。在來源環境和目標環境中執行相同的資料管道，即可比較整合測試的輸出內容與來源環境的輸出內容。只有在資料管道具有決定性，且能確保兩個環境的輸入內容完全相同時，這類測試才有效。

當資料符合一組預先定義的條件時，您即可確認資料是否完整，也就是來源環境中的資料與目標環境中的資料相等 (或足夠相似)。視您在上一節中使用的策略而定，資料可能不會完全相符。因此，您需要預先定義條件，說明用途的資料完整性。舉例來說，如果是時間序列資料，當最新記錄與目前時間戳記的差距不超過五分鐘時，您可能會認為資料已完整。

系統截承

在目標環境中驗證及測試資料和資料管道後，即可開始轉換階段。開始這個階段表示用戶端可能需要變更設定，才能參照新系統。在某些情況下，設定無法與指向來源系統的設定相同。舉例來說，如果服務需要從 Cloud Storage 值區讀取資料，用戶端就必須變更要使用的值區設定。Cloud Storage bucket 名稱在全域範圍內不可重複，因此目標環境的 Cloud Storage bucket 與來源環境不同。

在轉換階段，您應停用並取消排定來源環境工作負載。建議您保留來源環境資料一段時間，以防需要還原。

遷移前測試階段不像資料管道的正式執行作業那麼完整。因此，在轉換完成且目標系統運作後，您需要監控資料管道的指標、執行階段和語意輸出內容。這項監控作業有助於找出測試階段可能遺漏的錯誤，確保遷移作業順利完成。

最佳化環境

最佳化是遷移的最後階段。在這個階段，您會執行可重複的迴圈多次疊代，直到環境符合最佳化需求為止，藉此提高環境效率：

  1. 評估目前的環境、團隊和最佳化迴圈。
  2. 建立最佳化需求和目標。
  3. 最佳化環境和團隊。
  4. 調整最佳化迴圈。

如要進一步瞭解如何最佳化環境，請參閱「遷移至 Google Cloud：最佳化環境」。 Google Cloud

準備 Google Cloud 資料和運算資源，以便跨區域遷移

本節將概略說明Google Cloud 上的資料和運算資源，以及跨區域遷移的準備設計原則。

BigQuery

由於 BigQuery 是無伺服器的 SQL 資料倉儲，因此您不必部署運算層。如果部分 BigQuery 用戶端指定了處理作業的地區，您需要調整這些用戶端。否則，來源環境和目標環境中的 BigQuery 相同。BigQuery 資料會儲存在兩種資料表中：

  • BigQuery 資料表：BigQuery 格式的資料表。BigQuery 會為您管理資料檔案。如要進一步瞭解如何以 BigQuery 格式遷移資料，請參閱「管理資料集」。
  • BigQuery 外部資料表：資料儲存在 BigQuery 外部的資料表。資料移轉完成後，您必須在新目的地重新建立外部資料表。如要進一步瞭解如何遷移外部資料表，請參閱外部資料表簡介。

Cloud Storage

Cloud Storage 提供 Storage 移轉服務，可協助您遷移資料。

Dataflow (批次)

Dataflow 是由 Google 管理的資料處理引擎，為簡化 Dataflow 遷移作業，並確保工作可部署至任何區域，您應將所有輸入和輸出內容做為參數插入工作。建議您將 Cloud Storage 路徑和資料庫連線字串做為引數或參數傳遞，而不是在原始碼中寫入輸入和輸出資料位置。

Dataproc

Dataproc 是代管的 Apache Hadoop 環境，可執行與 Apache Hadoop 架構相容的任何工作負載。並與 Apache Spark、Apache Flink 和 Apache Hive 等架構相容。

您可以使用下列方式存取 Dataproc，這會影響您跨區域遷移 Dataproc 環境的方式：

  • 使用 Cloud Storage 中的資料建立暫時叢集：叢集是為執行特定工作而建構，工作完成後就會銷毀。也就是說，HDFS 層或叢集的任何其他狀態也會遭到破壞。如果您的設定符合下列條件，相較於其他使用類型，這類使用方式更容易遷移：
    • 工作的輸入和輸出不會在原始碼中硬式編碼。而是以引數形式接收輸入內容和輸出內容。
    • Dataproc 環境佈建作業會自動執行，包括環境所用個別架構的設定。
  • 含有外部資料的長期叢集：您有一或多個叢集，但這些叢集是長期叢集，即使叢集上沒有執行中的工作，叢集仍會持續運作。資料和運算作業是分開的，因為資料會儲存在叢集外部的Google Cloud 解決方案 (例如 Cloud Storage 或 BigQuery)。如果叢集上經常有工作在執行，這個模型通常會很有效，因此不適合像臨時模型一樣拆除及設定叢集。由於資料和運算作業是分開的，因此遷移作業與暫時性模型遷移作業類似。
  • 叢集內有資料的長期叢集：叢集長期存在，但叢集也會在內部保留狀態、資料或兩者，最常見的是 HDFS 中的資料。這類用途會使遷移作業變得複雜，因為資料和運算並未分開；如果只遷移其中一項，很可能會造成不一致。在這種情況下，建議您在遷移前將資料和狀態移出叢集，以區隔兩者。如果無法這麼做，建議您使用排定維護時間策略，降低資料不一致的風險。

由於潛在架構眾多，且這些架構有許多版本和設定，因此您必須先徹底測試，再執行遷移計畫。

Cloud Composer

Cloud Composer 是 Apache Airflow 的代管版本，可自動調度及安排流程。 Google Cloud'DAG、設定和記錄檔會儲存在 Cloud Storage bucket 中，您應一併遷移這些資料和 Cloud Composer 部署作業。如要遷移 Cloud Composer 部署作業的狀態，可以儲存及載入環境快照。

如果您已將任何自訂外掛程式部署至 Cloud Composer 執行個體，建議您採用基礎架構即程式碼的方法，以全自動方式重新建立環境。

Cloud Composer 不會管理資料，但會啟動其他資料處理架構和平台。因此，Cloud Composer 的遷移作業可以完全與資料隔離。Cloud Composer 也不會處理資料，因此部署作業不必與資料位於相同區域。因此，您可以在目標環境中建立 Cloud Composer 部署作業，並繼續在來源環境中執行管道。在某些情況下，當整個平台正在遷移時，這麼做有助於在不同區域運作不同的管道。

Cloud Data Fusion

Cloud Data Fusion 是一種視覺化整合工具，可協助您使用視覺化編輯器建構資料管道。Cloud Data Fusion 以開放原始碼專案 CDAP 為基礎。與 Cloud Composer 類似，Cloud Data Fusion 本身不會管理資料，但會啟動其他資料處理架構和平台。您應從來源環境匯出 Cloud Data Fusion 管道，並透過下列其中一種方式匯入目標環境：

視需要遷移的流程數量而定，您可能會偏好其中一種方法。使用 CDAP API 建構遷移指令碼可能很困難，而且需要更多軟體工程技能。不過，如果流程數量眾多，或流程變更頻率較高，自動化程序可能就是最佳做法。

後續步驟

貢獻者

作者：Eyal Ben Ivri | 雲端解決方案架構師

其他貢獻者：Marco Ferrari | 雲端解決方案架構師