管道開發涉及不同階段和工作，例如程式碼開發、測試和交付至正式環境。本文說明：
- 持續整合與持續推送軟體更新 (CI/CD) 的考量事項，可支援自動建構、測試，以及將管道部署至不同環境。
- Dataflow 功能，可最佳化實際工作環境的效能和資源用量。
- 在正式環境中更新串流管道的方法和監控點。
- 改善正式環境中管道可靠性的最佳做法。
持續整合
持續整合 (CI) 需要開發人員經常將程式碼合併至共用存放區，這對於經常變更的應用程式很有用，例如經常更新的網站。雖然資料管道通常不像其他類型的應用程式那樣經常變更，但 CI 做法仍可為管道開發帶來許多好處。舉例來說，測試自動化功能可在發現缺點時快速提供回饋，並降低迴歸進入程式碼庫的可能性。
測試自動化是 CI 的重要環節。搭配適當的測試涵蓋範圍，測試自動化會在每次提交程式碼時執行測試套件。您的 CI 伺服器可搭配 Maven 等建構自動化工具，在 CI 管道中執行一或多個步驟的測試套件。您可以將成功通過單元測試和整合測試的程式碼，封裝到啟動管道的部署構件中。這個版本稱為「通過建構」。
從通過的建構作業建立的部署構件數量和類型，取決於管道的啟動方式。使用 Apache Beam Java SDK，您可以將管道程式碼封裝到自行執行的 JAR 檔案中。接著，您可以將 JAR 檔案儲存在專案中代管的 bucket，用於部署環境，例如前置製作或正式版 Google Cloud 專案。如果您使用傳統範本 (一種範本執行作業)，部署構件會包含 JSON 範本檔案、管道的 JAR 檔案，以及選用的中繼資料範本。接著，您可以使用持續交付功能，將構件部署到不同的部署環境，詳情請參閱下一節。
持續推送軟體更新和部署
持續推送軟體更新 (CD) 會將部署構件複製到一或多個部署環境，準備手動啟動。通常，CI 伺服器建構的構件會部署至一或多個預先發布環境，以執行端對端測試。如果所有端對端測試都順利通過，系統就會更新正式環境。
對於批次管道，持續部署可直接將管道啟動為新的 Dataflow 工作。或者，其他系統也可以在需要時使用構件啟動批次工作。舉例來說，您可以使用 Cloud Composer 在工作流程中執行批次工作，也可以使用 Cloud Scheduler 排定批次工作。
相較於批次管道，串流管道的部署作業可能較為複雜，因此使用持續部署自動化作業時，可能較為困難。舉例來說，您可能需要判斷如何取代或更新現有的串流管道。如果無法更新管道，或選擇不更新，可以使用其他方法 (例如協調多個 Dataflow 工作)，盡量減少或避免業務中斷。
持續整合/持續推送軟體更新所需的 ID 和角色
CI/CD 管道會與不同系統互動，以建構、測試及部署管道。舉例來說，您的管道需要存取原始碼存放區。如要啟用這些互動，請確保管道具有適當的身分和角色。下列管道活動也可能需要管道具備特定身分和角色。
與外部服務進行整合測試，包括 Google Cloud
使用 Direct Runner 執行臨時測試或系統整合測試時，管道會使用應用程式預設憑證 (ADC) 取得憑證。設定 ADC 的方式取決於管道的執行位置。詳情請參閱「設定應用程式預設憑證」。
請確認用於取得管道存取資源憑證的服務帳戶，具備足夠的角色和權限。Google Cloud
將構件部署至不同的部署環境
盡可能為每個環境 (實際上是每個專案) 使用專屬憑證，並據此限制資源存取權。
為每個專案使用專屬服務帳戶，以便讀取及寫入部署作業構件至儲存空間值區。視管道是否使用範本而定，部署程序可能需要暫存多個構件。舉例來說，建立及暫存 Dataflow 範本需要權限，才能將啟動管道所需的部署作業成品 (例如管道的範本檔案) 寫入 Cloud Storage bucket。
將管道部署至不同的部署環境
盡可能為每個專案使用專屬服務帳戶，存取及管理專案中的 Google Cloud 資源，包括存取 Dataflow 本身。
用來建立及管理 Dataflow 工作的服務帳戶，必須具備足夠的 IAM 權限，才能管理工作。詳情請參閱 Dataflow 安全性與權限頁面的「Dataflow 服務帳戶」一節。
您用來執行 Dataflow 工作的服務帳戶，必須具備管理 Compute Engine 資源的權限，才能在工作執行期間管理 Apache Beam 管道與 Dataflow 服務之間的互動。詳情請參閱 Dataflow 安全性與權限頁面的「工作人員服務帳戶」一節。
如要為工作指定使用者代管的工作人員服務帳戶，請使用 --serviceAccount pipeline 選項。如果您在建立工作時未指定工作站服務帳戶，Dataflow 會嘗試使用 Compute Engine 預設服務帳戶。建議您為正式環境指定使用者管理的服務帳戶，因為 Compute Engine 預設服務帳戶通常具有比 Dataflow 工作所需權限更廣泛的權限。
在實際運作情境中，建議您使用個別的服務帳戶來管理 Dataflow 工作，並使用工作站服務帳戶，與使用單一服務帳戶相比，這樣做可提高安全性。舉例來說，用於建立 Dataflow 工作的服務帳戶可能不需要存取資料來源和接收器，也不需要使用管道使用的其他資源。在本情境中，用來執行 Dataflow 工作的 Worker 服務帳戶會獲得使用管道資源的權限。系統會授予其他服務帳戶管理 (包括建立) Dataflow 工作的權限。
CI/CD 管道範例
下圖提供資料管道 CI/CD 的一般檢視畫面，不限於特定工具。此外，這張圖也顯示開發工作、部署環境和管道執行器之間的關係。
下圖顯示下列階段：
程式碼開發：在程式碼開發期間，開發人員會使用 Direct Runner 在本機執行管道程式碼。此外，開發人員還會使用沙箱環境，透過 Dataflow Runner 執行臨時管道。
在一般的 CI/CD 管道中，開發人員變更原始碼控管系統 (例如將新程式碼推送至存放區) 時，就會觸發持續整合程序。
建構及測試：持續整合程序會編譯管道程式碼，然後使用 Direct Runner 執行單元測試和轉換整合測試。您也可以選擇執行系統整合測試，包括使用小型測試資料集，與外部來源和接收器進行整合測試。
如果測試成功，CI 程序會儲存部署構件，其中可能包括啟動管道所需的 JAR 檔案、Docker 映像檔和範本中繼資料，並將這些構件儲存至持續交付程序可存取的位置。視產生的部署構件類型而定，您可能會使用 Cloud Storage 和 Artifact Registry 儲存不同類型的構件。
交付及部署：持續交付程序會將部署構件複製到前置製作環境，或讓這些構件可在該環境中使用。開發人員可以使用 Dataflow Runner 手動執行端對端測試，也可以使用持續部署功能自動啟動測試。一般來說，相較於串流管道，批次管道更容易啟用持續部署方法。由於批次管道不會持續執行，因此更容易以新版本取代。
更新串流管道的程序可能簡單或複雜，建議您在預先發布環境中測試更新。不同版本之間的更新程序可能不盡相同。舉例來說，管道可能會變更，導致無法進行就地更新。因此，有時很難使用持續部署自動更新管道。
如果所有端對端測試都通過，您可以複製部署構件，或在持續推送軟體更新程序中，將構件提供給實際工作環境。如果新管道更新或取代現有的串流管道，請使用在預先製作環境中測試的程序，部署新管道。
非範本式與範本式工作執行流程的比較
您可以直接從開發環境使用 Apache Beam SDK 建立 Dataflow 工作。這類工作稱為「非範本」工作。雖然這種做法對開發人員來說很方便，但您可能還是偏好將管道的開發和執行作業分開。如要進行這項區隔，可以使用 Dataflow 範本，將管道暫存並以獨立工作形式執行。範本暫存後，其他使用者 (包括非開發人員) 就能使用 Google Cloud CLI、Google Cloud 控制台或 Dataflow REST API，從範本執行工作。
Dataflow 提供下列工作範本類型：
- 傳統範本：開發人員使用 Apache Beam SDK 執行管道程式碼，並將 JSON 序列化執行圖儲存為範本。Apache Beam SDK 會將範本檔案暫存至 Cloud Storage 位置，以及管道程式碼所需的任何依附元件。
- 彈性範本：開發人員使用 Google Cloud CLI 將管道封裝為 Docker 映像檔，然後儲存在 Artifact Registry 中。系統也會自動產生彈性範本規格檔案，並儲存在使用者指定的 Cloud Storage 位置。彈性範本規格檔案包含中繼資料，說明如何執行範本，例如管道參數。
除了連結說明文件中說明的 Flex 範本功能外，Flex 範本在管理範本方面也比傳統範本更具優勢。
- 使用傳統範本時，多個構件 (例如 JAR 檔案) 可能會儲存在 Cloud Storage 暫存位置，但沒有任何功能可管理這些構件。相較之下，Flex 範本會封裝在 Docker 映像檔中。映像檔會將管線所需的所有依附元件 (Flex 範本規格除外) 打包成一個部署構件，並由 Artifact Registry 管理。
- 您可以對 Flex 範本使用 Docker 映像檔管理功能。舉例來說，您可以授予 Artifact Registry 提取 (及視需要推送) 權限，安全地共用彈性範本，並使用 Docker 映像檔標記，為彈性範本的不同版本加上標記。
開發人員可以使用傳統範本和彈性範本，在與擁有登錄檔和儲存空間值區的專案不同的專案中啟動工作，或僅使用儲存空間值區 (如果您使用傳統範本)。如果您需要將多位客戶的資料處理作業隔離到不同的專案和管道工作，這項功能就非常實用。使用彈性範本時，您可以進一步指定啟動管道時要使用的 Docker 映像檔版本。日後更新範本時，這項功能可簡化多個專案中批次管道或串流管道的階段性更換作業。
可最佳化資源用量的 Dataflow 功能
Dataflow 提供下列執行器專屬功能，可最佳化資源用量，進而提升效能並降低成本：
- Streaming Engine：Streaming Engine 會將串流管道的執行作業移出 VM 工作站，並移入專屬服務。優點包括提升自動調整規模的反應速度、減少耗用的工作站 VM 資源，以及自動更新服務，不必重新部署。在某些情況下，您也可以針對可容許重複項目的用途，使用至少一次處理來減少資源用量。建議為串流管道啟用 Streaming Engine。使用最新版本的 Apache Beam Java SDK 或 Python SDK 時，這項功能預設為啟用。
- Dataflow Shuffle：Dataflow Shuffle 會將批次管道的重組作業移出 VM 工作站，並移入專屬服務。優點包括：大部分批次管道的執行速度更快、工作站 VM 的資源耗用量減少、自動調度資源的反應速度提升，以及容錯能力提升。建議為批次管道啟用 Dataflow Shuffle。使用 Apache Beam Java SDK 和最新 Python SDK 時，這項功能預設為啟用。
- 彈性資源排程 (FlexRS)：FlexRS 會使用進階排程技術、Dataflow Shuffle 服務，並結合先占 VM 執行個體和一般 VM，藉此減少批次處理費用。
更新實際工作環境中的串流管道
請參閱「升級串流管道」。
Dataflow 工作生命週期
Dataflow 工作會經歷生命週期，並以各種工作狀態表示。如要執行 Dataflow 工作，請將工作提交至區域。然後，系統會將工作傳送至該區域內其中一個可用區的可用 Dataflow 後端。Dataflow 會先驗證您有足夠的配額和權限來執行工作，才會指派後端。完成這些預檢並指派後端後，工作會移至 JOB_STATE_PENDING 狀態。對於 FlexRS 工作，後端指派作業可能會延遲到未來時間，且這些工作會進入 JOB_STATE_QUEUED 狀態。
指派的後端會接手執行工作，並嘗試在 Google Cloud 專案中啟動 Dataflow 工作站。為工作站 VM 選擇的可用區取決於多項因素。對於使用 Dataflow Shuffle 的批次工作，服務也會盡量確保 Dataflow 後端和工作站 VM 位於同一可用區，以避免跨可用區流量。
Dataflow 工作站啟動後，會向 Dataflow 後端要求工作。後端會將工作分割成可平行處理的區塊 (稱為「套件」)，並分配給工作站。如果工作站無法處理現有工作，且已啟用自動調度資源功能，後端就會啟動更多工作站來處理工作。同樣地，如果啟動的工作站超出需求，系統會關閉部分工作站。
Dataflow 工作人員啟動後，Dataflow 後端會做為控制平面，負責協調工作執行作業。在處理期間，作業的資料平面會執行 Shuffle 作業，例如 GroupByKey、CoGroupByKey 和 Combine。工作會使用下列其中一種資料平面實作項目，執行重組作業：
- 資料平面會在 Dataflow 工作站上執行，重組資料則會儲存在「永久磁碟」上。
- 資料層會以服務形式執行，並從工作站 VM 外部化。這項實作方式有兩種變體，您可以在建立工作時指定：批次管道的 Dataflow Shuffle，以及串流管道的 Streaming Engine。與以工作站為基礎的重組作業相比，以服務為基礎的重組作業可大幅提升資料重組作業的效能和擴充性。
進入 JOB_STATE_RUNNING 狀態的串流工作會無限期持續執行，直到取消或排空為止 (工作失敗除外)。當所有處理作業完成或發生無法復原的錯誤時，批次工作會自動停止。視停止工作的方式而定，Dataflow 會將工作狀態設為多種終端狀態之一，包括 JOB_STATE_CANCELLED、JOB_STATE_DRAINED 或 JOB_STATE_DONE。
管道可靠性最佳做法
本節將討論使用 Dataflow 時可能發生的失敗情形，以及 Dataflow 工作的最佳做法。
遵循隔離原則
一般建議是遵循區域和可用區背後的隔離原則，提高整體管道的可靠性。請確保管道沒有重大跨區域依附元件。如果管道對多個區域的服務有重要依附元件，任何一個區域發生故障都可能影響管道。為避免發生這個問題，請部署至多個地區，以確保備援和備份。
建立 Dataflow 快照
Dataflow 提供快照功能，可備份管道狀態。您可以將管道快照還原至其他區域或地區的新串流 Dataflow 管道。然後，您就可以從快照時間戳記開始，重新處理 Pub/Sub 或 Kafka 主題中的訊息。如果定期建立管道快照，就能盡量縮短復原時間目標 (RTO) 時間。
如要進一步瞭解 Dataflow 快照，請參閱「使用 Dataflow 快照」。
處理工作提交失敗問題
您可以使用 Apache Beam SDK 提交非範本 Dataflow 工作。如要提交工作，請使用 Dataflow Runner執行管道，這項工具會指定為管道選項的一部分。Apache Beam SDK 會將檔案暫存於 Cloud Storage，然後建立工作要求檔案，並將檔案提交至 Dataflow。
此外，從 Dataflow 範本建立的工作會使用不同的提交方法，通常會依賴範本 API。
您可能會看到 Dataflow 傳回不同的錯誤，指出範本和非範本工作失敗。本節將討論不同類型的作業提交失敗，以及處理或減輕這些問題的最佳做法。
暫時性失敗後重試提交工作
如果工作因 Dataflow 服務問題而無法啟動，請重試幾次。重試可減輕暫時性服務問題。
指定工作站地區，降低區域故障風險
Dataflow 提供區域可用性，並適用於多個區域。使用者將工作提交至地區時，如果沒有明確指定可用區，Dataflow 會根據資源可用性，將工作路由至指定地區的可用區。
建議您盡可能使用 --region 標記指定工作站地區，而非 --zone 標記，以利工作放置。這個步驟可讓 Dataflow 自動為工作選擇最合適的區域，為管道提供額外的容錯能力。指定明確區域的工作無法享有這項優點，且如果區域發生問題，工作就會失敗。如果工作提交失敗是區域問題所致，通常只要重試工作，不必明確指定區域，即可解決問題。
將資料儲存在多個區域，降低區域故障的影響
如果整個區域都無法使用，請嘗試在其他區域執行工作。如果工作在不同地區發生失敗情形，請務必考量資料可用性。如要避免單一區域發生故障，且不想手動將資料複製到多個區域，請使用 Google Cloud 資源，這類資源會自動將資料儲存在多個區域。舉例來說，資料集可使用 BigQuery多地區位置，Cloud Storage bucket 則可使用雙重地區和多地區。如果某個區域無法使用，您可以在資料可用的其他區域重新執行管道。
如要瞭解如何搭配使用多區域服務與 Dataflow，請參閱高可用性和異地備援。
處理執行中管道的失敗事件
工作提交並獲准後，只能執行下列有效作業：
- 取消批次工作
- 更新、排除或取消串流工作
提交工作後，您無法變更執行中工作的位置。 如果您未使用 FlexRS，工作通常會在提交後幾分鐘內開始處理資料。FlexRS 工作最多可能要過六小時才會開始處理資料。
本節將討論執行工作時發生的失敗，以及處理這些失敗的最佳做法。
監控工作，找出並解決暫時性錯誤導致的問題
如果是批次工作，內含失敗項目的組合會重試四次。 如果單一組合失敗達四次，Dataflow 就會終止工作。這項程序可解決許多暫時性問題。不過，如果發生長時間的失敗，通常很快就會達到重試次數上限，工作也會迅速失敗。
如要監控及管理事件，請設定快訊規則來偵測失敗的工作。如果工作失敗，請檢查工作記錄，找出因工作項目失敗次數超過重試限制而導致的工作失敗。
如果是串流工作，Dataflow 會無限期重試失敗的作業項目。工作未終止。不過，工作可能會暫緩，直到問題解決為止。建立監控政策，偵測管道停滯的跡象，例如系統延遲時間增加和資料更新間隔縮短。在管道程式碼中實作錯誤記錄功能，有助於找出因工作項目重複失敗而導致管道停滯的問題。
如果發生區域性服務中斷，請在其他區域重新啟動工作
工作啟動後，執行使用者程式碼的 Dataflow 工作站會限制在單一可用區。如果發生區域性中斷，Dataflow 工作通常會受到影響，具體情況視中斷程度而定。
如果只有 Dataflow 後端受到停機影響，代管服務會自動將後端遷移至其他區域，以便繼續執行作業。如果工作使用 Dataflow Shuffle，後端就無法跨時區移動。如果發生 Dataflow 後端遷移作業，工作可能會暫時停止。
如果發生區域中斷，執行中的工作可能會失敗或停滯，直到區域恢復運作為止。如果可用區長時間無法使用，請停止工作 (批次工作請取消，串流工作請排空)，然後重新啟動工作，讓 Dataflow 選擇新的正常可用區。
如果發生區域性服務中斷，請在其他區域重新啟動批次工作
如果 Dataflow 工作執行的地區發生區域性服務中斷情形，工作可能會失敗或停滯。如果是批次工作，請盡可能在其他地區重新啟動工作。請務必確保資料可在不同區域使用。
使用高可用性或容錯移轉功能，降低區域性服務中斷的影響
對於串流工作，您可以根據應用程式的容錯能力和預算，選擇不同的方式來減輕故障影響。如果是區域性服務中斷，最簡單且最具成本效益的做法是等待服務恢復正常。不過，如果您的應用程式對延遲時間很敏感，或是資料處理作業不得中斷，或必須以最短延遲時間繼續執行，請參閱下列各節的選項。
高可用性：對延遲時間敏感，且不會遺失資料
如果應用程式無法容許資料遺失，請在兩個不同區域中平行執行重複的管道，並讓管道使用相同資料。兩個區域都必須提供相同的資料來源。依賴這些管道輸出的下游應用程式，必須能夠在這兩個區域的輸出之間切換。由於資源重複，與其他選項相比，這個選項的成本最高。如需部署範例，請參閱「高可用性和地理位置備援」一節。
容錯移轉：對延遲時間敏感，可能遺失部分資料
如果應用程式可容許潛在的資料遺失，請在多個區域提供串流資料來源。舉例來說，使用 Pub/Sub 時，可為同一主題維護兩個獨立的訂閱項目，每個區域各一個。如果發生區域性服務中斷，請在其他區域啟動替代管道，並讓管道使用備份訂閱項目中的資料。
重播備份訂閱項目至適當時間，盡量減少資料遺失，同時不犧牲延遲時間。下游應用程式必須知道如何切換至執行中管道的輸出內容，類似於高可用性選項。與執行重複管道相比，這個選項使用的資源較少，因為只有資料會重複。
高可用性和地理備援
您可以並行執行多個串流管道，以處理高可用性資料。舉例來說，您可以在不同地區執行兩個平行串流工作，為資料處理提供地理位置冗餘和容錯能力。
考量資料來源和接收器的地理位置可用性，您就能在多地區高可用性設定中，運作端對端管道。下圖為部署範例。
下圖顯示以下流程：
Pub/Sub 在全球大多數區域運作，因此這項服務可提供快速的全球資料存取權，同時讓您控管訊息的儲存位置。Pub/Sub 可以自動將發布的訊息儲存在最靠近訂閱者的「 Google Cloud 」區域，您也可以使用訊息儲存政策，將訊息儲存在特定區域或一組區域。
接著，Pub/Sub 會將訊息傳送給全球各地的訂閱者，無論訊息儲存在何處。Pub/Sub 用戶端不必知道連線的伺服器位置，因為全域負載平衡機制會將流量導向最接近的Google Cloud 資料中心，並在該處儲存訊息。
Dataflow 會在特定 Google Cloud 區域中執行。 在不同 Google Cloud 區域中平行執行管道，即可避免單一區域發生故障時影響工作。圖表顯示同一個管道的兩個執行個體，每個執行個體都在不同的 Google Cloud 區域中執行。
BigQuery 提供區域和多區域資料集位置。選擇多區域位置時，資料集會位於至少兩個地理區域。圖表顯示兩個不同的管道，各自寫入不同的多區域資料集。