本頁面說明規劃資料管道時的重要考量事項，讓您在開始開發程式碼前做好準備。資料管道可將資料從一個系統移至另一個系統，通常是業務資訊系統的重要元件。資料管道的效能和可靠性可能會影響這些更廣泛的系統，以及業務需求是否能有效達成。
如果您在開發資料管道前先規劃，就能提升管道的效能和可靠性。本頁說明 Dataflow 管道的各種規劃考量，包括：
- 管道的效能預期結果，包括可測量性的標準
- 將管道與資料來源、接收器和其他連線系統整合
- 管道、來源和接收器的區域化
- 安全性，例如資料加密和私人網路
定義及評估服務等級目標
衡量管道成效的重要指標是管道是否符合業務需求。服務等級目標 (SLO) 可提供具體的效能定義，方便您與可接受的門檻進行比較。舉例來說，您可以為系統定義下列範例 SLO：
資料更新間隔：根據使用者在 3 分鐘前的網站活動，產生 90% 的產品建議。
資料正確性：在一個月內，客戶發票的錯誤率低於 0.5%。
資料隔離/負載平衡：在一個工作天內，處理所有高優先順序付款，並在提交後 10 分鐘內完成，標準優先順序付款則會在下一個工作天完成。
您可以使用服務水準指標 (SLI) 評估 SLO 遵循情況。SLI 是可量化的指標，可指出系統達成特定 SLO 的程度。舉例來說，您可以將最近處理的使用者活動年齡做為 SLI，評估資料即時性 SLO。如果管道會根據使用者活動事件產生建議，且 SLI 報告指出事件時間與事件處理時間之間有 4 分鐘的延遲，則建議不會考量使用者在 4 分鐘前進行的網站活動。如果處理串流資料的管道超過 4 分鐘的系統延遲時間，您就會知道未達到 SLO。
因為管道以外的系統元件會影響服務等級目標，所以請務必擷取一系列服務等級指標，說明系統的整體效能 (不只是管道本身的效能)，包括說明系統端對端健康狀態的指標。舉例來說，您的 Dataflow 管道可能會以可接受的延遲時間計算結果，但下游系統可能會發生效能問題，進而影響更廣泛的 SLO。
如要進一步瞭解應考量的服務等級目標，請參閱網站可靠性工程一書。
資料更新間隔
資料更新間隔是指資料的可用性與資料時間的關係。《網站可靠性工程》一書中提到，下列資料更新服務等級目標是最常見的管道資料更新服務等級目標格式：
在 Y [秒、天、分鐘]內處理 X% 的資料。這項服務等級目標是指在特定時間範圍內處理的資料百分比。這項功能通常用於處理有界資料來源的批次管道。這類 SLO 的指標是重要處理步驟的輸入和輸出資料大小，與 pipeline 執行時間的關係。您可以選擇讀取輸入資料集的步驟，以及處理輸入內容中每個項目的步驟。舉例來說，服務等級目標可以是「在『剃除犛牛毛』遊戲中，99% 的使用者活動都會在賽事結束後 30 分鐘內計入玩家分數」。
最舊的資料不得超過 X [秒、天、分鐘]。這項 SLO 是指管道產生的資料年齡。這項功能通常用於處理不受限來源資料的串流管道。對於這類服務水準目標，請使用指標指出管道處理資料所需的時間。有兩種可能的指標：最舊未處理項目的時間 (也就是未處理項目在佇列中的時間長度)，或是最近處理項目的時間。舉例來說，SLO 可以是「系統會根據不超過 5 分鐘前的使用者活動，產生產品建議」。
管道工作在 X [秒、天、分鐘]內順利完成。 這項 SLO 會設定成功完成作業的期限，通常用於處理有界資料來源資料的批次管道。除了其他可指出工作是否成功的信號 (例如導致錯誤的處理元素百分比)，這項服務等級目標還需要管道總經過時間和工作完成狀態。舉例來說，服務等級目標可以是「當天收到的訂單會在隔天上午 9 點前處理完畢」。
如要瞭解如何使用 Cloud Monitoring 測量資料更新間隔，請參閱「Dataflow 工作指標」。
資料正確性
資料正確性是指資料沒有錯誤。您可以透過不同方式判斷資料是否正確，包括：
端對端管道測試，您可以在管道成功通過單元和整合測試後，在前置製作環境中執行這項測試。您可以使用持續推送軟體更新，自動執行端對端管道測試。
在正式環境中執行的管道，使用監控功能觀察與資料正確性相關的指標。
如要執行管道，定義資料正確性目標通常需要一段時間來評估正確性。例如：
- 以每項工作為單位，輸入項目中含有資料錯誤的比例低於 X%。您可以使用這項 SLO 評估批次管道的資料正確性。舉例來說，服務等級目標可以是「在每天處理電表讀數的批次工作中，資料輸入錯誤的讀數比例不得超過 3%」。
- 在 X 分鐘的移動視窗中，少於 Y% 的輸入項目含有資料錯誤。您可以使用這項 SLO 評估串流管道的資料正確性。舉例來說，服務等級目標可以是「過去一小時內，電力讀數的負值比例低於 2%」。
如要評估這些 SLO，請在適當的時間範圍內使用指標，累計各類型的錯誤數。舉例來說，資料可能因結構定義格式有誤而錯誤，或超出有效範圍。
如要瞭解如何使用 Cloud Monitoring 測量資料正確性，請參閱「Dataflow 工作指標」。
資料隔離和負載平衡
資料隔離是指依屬性區隔資料，可簡化負載平衡作業。舉例來說，在線上付款處理平台中，您可以區隔資料，讓個別付款作業的優先順序為標準或高。然後，管道就能使用負載平衡，確保系統優先處理高優先順序的付款，再處理標準優先順序的付款。
假設您為付款處理作業定義下列 SLO：
- 高優先順序付款會在 10 分鐘內處理完畢。
- 標準優先付款會在下一個工作天的上午 9 點前處理完畢。
如果付款平台符合這些 SLO，客戶就能在報表資訊主頁上，查看已完成的最終高優先順序付款。相較之下，標準付款可能要到隔天才會顯示在資訊主頁上。
在這個範例情境中，您有下列選項：
- 執行單一管道，處理標準優先順序和高優先順序的付款。
- 根據多個管道的優先順序，隔離資料並進行負載平衡。
以下各節將詳細說明各個選項。
使用單一管道，根據混合 SLO 放送廣告
下圖說明用來處理高優先順序和標準優先順序付款的單一管道。管道會從串流資料來源 (例如 Pub/Sub 主題或 Apache Kafka 主題) 接收新付款的通知。接著，系統會立即處理付款，並使用串流插入將事件寫入 BigQuery。
單一管道的優點在於簡化作業需求，因為您只需要管理單一資料來源和管道。Dataflow 會使用自動調整功能，盡可能快速且有效率地執行工作。
單一管道的缺點是，共用管道無法優先處理高優先順序付款，且管道資源會同時用於兩種付款類型。在先前描述的業務情境中，您的管道必須維持較嚴格的服務等級目標。也就是說，無論處理的付款實際優先順序為何，管道都必須使用高優先順序付款的 SLO。另一個缺點是，如果工作積壓，串流管道無法根據工作的緊急程度，優先處理積壓工作。
使用多個專為特定 SLO 量身打造的管道
您可以使用兩條管道隔離資源，並根據特定 SLO 放送廣告。下圖說明了這項做法。
高優先順序付款會隔離到串流管道，以優先處理。系統會透過每日執行的批次管道處理標準優先付款，並使用 BigQuery 載入工作寫入處理結果。
在不同管道中隔離資料有許多優點。如要根據更嚴格的服務等級目標，優先處理付款事宜，您可以將更多資源指派給專門處理優先付款的管道，縮短處理時間。資源設定包括新增 Dataflow 工作站、使用較大的機器，以及啟用自動調整資源配置。如果標準優先順序付款突然湧入，將高優先順序項目隔離到個別的處理佇列，也能減緩處理延遲情況。
如果您使用多個管道來隔離及負載平衡批次和串流來源的資料，Apache Beam 程式設計模型可讓高優先順序 (串流) 和標準優先順序 (批次) 管道共用相同的程式碼。唯一的例外是初始讀取轉換作業，該作業會從批次管道的有界來源讀取資料。詳情請參閱建立可重複使用的轉換程式庫。
規劃資料來源和接收器
如要處理資料，資料管道必須與其他系統整合。這些系統稱為「來源」和「接收器」。資料管道會從來源讀取資料，並將資料寫入接收器。除了來源和接收器，資料管道也可能會與外部系統互動，以便在處理步驟中擴充、篩選資料或呼叫外部業務邏輯。
為確保可擴充性，Dataflow 會在多個工作站上平行執行管道階段。管道程式碼和 Dataflow 服務以外的因素，也會影響管道的擴充性。這些因素可能包括：
外部系統的擴充性：管道互動的外部系統可能會限制效能，並形成擴充性的上限。舉例來說，如果為您需要的讀取輸送量設定的Apache Kafka 主題分區數量不足，可能會影響管道效能。為確保管道及其元件符合效能目標，請參閱所用外部系統的最佳做法說明文件。您也可以使用 Google Cloud 提供內建擴充性的服務，簡化基礎架構容量規劃。詳情請參閱本頁的「使用受管理來源和接收器 Google Cloud 」。
資料格式選擇：某些資料格式的讀取速度可能比其他格式快。舉例來說，使用支援可平行讀取的資料格式 (例如 Avro) 通常比使用欄位中含有內嵌換行的 CSV 檔案更快，也比使用壓縮檔更快。
資料位置和網路拓撲：資料來源和接收器與資料管道的地理位置和網路特性，可能會影響效能。詳情請參閱本頁面的「區域注意事項」一節。
外部服務呼叫
從管道呼叫外部服務會產生每次呼叫的額外負荷，可能會降低管道的效能和效率。如果資料管道會呼叫外部服務，請盡可能將多個資料元素批次處理為單一要求，以減少額外負荷。許多原生 Apache Beam I/O 轉換會自動執行這項工作，包括 BigQueryIO 和串流插入作業。除了容量限制外，部分外部服務也會強制執行配額，限制一段時間內的呼叫總數 (例如每日配額)，或限制呼叫頻率 (例如每秒要求數)。
由於 Dataflow 會在多個工作站之間平行處理工作，因此流量過大可能會導致外部服務不堪負荷，或用盡可用配額。使用自動調度資源時，Dataflow 可能會嘗試新增工作站，以補償外部呼叫等緩慢的步驟。新增工作人員可能會對外部系統造成額外壓力。請確認外部系統可支援預期的負載需求，或將管道流量限制在可持續的程度。詳情請參閱「限制批次大小和對外部服務的並行呼叫」。
使用 Google Cloud 受管理來源和接收器
搭配 Dataflow 管道使用 Google Cloud 代管服務，可提供內建的擴充性、一致的效能，以及符合大多數需求的配額和限制，因此能簡化容量管理作業。您仍須注意管道作業的不同配額和限制。Dataflow 本身會設定配額和限制。如要提高部分限制，請與Google Cloud 支援團隊聯絡。
Dataflow 會使用 Compute Engine VM 執行個體執行作業，因此您需要足夠的 Compute Engine 配額。如果 Compute Engine 配額不足，管道自動調度資源功能可能會受到阻礙，或導致工作無法啟動。
本節的其餘部分將探討不同的配額和限制，可能如何影響您設計、開發及監控管道的方式。 Google Cloud Pub/Sub 和 BigQuery 用於管道來源和接收器範例。
範例 1：Pub/Sub
搭配使用 Pub/Sub 與 Dataflow 時，Pub/Sub 會提供可擴充且持久的事件擷取服務，用於傳送訊息至串流資料管道，以及從串流資料管道傳送訊息。您可以使用控制台查看 Google Cloud Pub/Sub 配額用量，並提高配額上限。如果任何單一管道超出專案配額和限制，建議您要求增加配額。
Pub/Sub 配額和限制是根據專案層級用量設計，具體來說，不同專案中的發布者和訂閱者會獲得獨立的資料輸送量配額。如果多個管道發布或訂閱單一主題，您可以將每個管道部署到各自的專案，在該主題上取得允許的最大輸送量。在這個設定中，每個管道都會使用不同的專案型服務帳戶來取用及發布訊息。
在下圖中，管道 1 和管道 2 共用 專案 A 可用的訂閱者和發布者輸送量配額。相較之下，管道 3 可以使用附加至專案 B 的整個訂閱者和發布者輸送量配額。
多個管道可使用主題的個別訂閱項目，從單一 Pub/Sub 主題讀取內容，讓 Dataflow 管道獨立於其他訂閱者 (例如其他管道) 提取及確認訊息。這項功能會建立額外的 Pub/Sub 訂閱項目，方便您複製管道。建立額外訂閱項目有助於建立備用管道，以實現高可用性 (通常用於串流用途)、針對相同資料執行額外測試管道，以及啟用管道更新。
範例 2：BigQuery
Apache Beam SDK 支援多種語言，包括 Java、Python 和 Go，可讀取及寫入 BigQuery 資料。使用 Java 時，BigQueryIO 類別會提供這項功能。BigQueryIO 支援兩種資料讀取方法：EXPORT (資料表匯出) 和 DIRECT_READ。不同的讀取方法會消耗不同的 BigQuery 配額。
資料表匯出是預設的讀取方法。運作方式如下圖所示：
下圖顯示以下流程：
- BigQueryIO 會叫用 BigQuery 匯出要求，匯出資料表資料。匯出的資料表資料會寫入臨時的 Cloud Storage 位置。
- BigQueryIO 會從暫時的 Cloud Storage 位置讀取資料表資料。
BigQuery 匯出要求會受到匯出配額限制。 匯出要求也必須完成，管道才能開始處理資料，這會增加作業的額外執行時間。
相較之下，直接讀取方法會使用 BigQuery Storage API，直接從 BigQuery 讀取資料表資料。BigQuery Storage API 使用 gRPC，為資料表列資料提供高輸送量的讀取效能。使用 BigQuery Storage API 可省去匯出步驟，避免受到匯出配額限制，並可能縮短工作執行時間。
下圖顯示使用 BigQuery Storage API 時的流程。相較於使用 BigQuery 匯出要求的流程，這個流程較為簡單，因為它只有一個直接讀取步驟，可將資料從資料表傳輸至管道。
將資料寫入 BigQuery 資料表也會影響配額。使用 BigQuery 載入工作的批次管道會耗用不同的BigQuery 載入工作配額，這些配額適用於資料表和專案層級。同樣地，使用 BigQuery 串流插入的串流管道會消耗 BigQuery 串流插入配額。
如要判斷最適合的資料讀取和寫入方法，請考量您的用途。舉例來說，請避免每天使用 BigQuery 載入工作，將資料附加到資料表數千次。使用串流管道將近乎即時的資料寫入 BigQuery。串流管道應使用串流插入或 Storage Write API 達成此目的。
區域注意事項
Dataflow 是在多個 Google Cloud 區域提供的代管服務。選擇用於執行工作的區域時，請考量下列因素：
- 資料來源和接收器的位置
- 資料處理位置的偏好設定或限制
- 僅在特定區域提供的 Dataflow 功能
- 用來管理特定工作執行的區域
- 工作的工作站所用的區域
針對特定工作，您為工作和工作站使用的區域設定可能不同。如要進一步瞭解何時應指定地區和區域，請參閱 Dataflow 地區說明文件。
指定執行 Dataflow 工作的地區，即可根據地區考量規劃高可用性和災難復原。詳情請參閱高可用性和地理位置備援。
區域
Dataflow 地區會儲存及處理與工作相關的中繼資料，例如 Apache Beam 圖表本身的資訊 (如轉換名稱)。此外，這些設定也會控管工作站的行為，例如自動調度資源。指定地區有助於滿足安全性與法規遵循、資料位置和工作區域位置的需求。為避免跨區域網路呼叫影響效能，建議您盡可能為作業和工作人員使用相同區域。
Dataflow 工作者
Dataflow 工作會使用 Compute Engine VM 執行個體 (稱為 Dataflow 工作站) 執行管道。Dataflow 工作可使用任何 Compute Engine 區域做為工作站，包括沒有 Dataflow 位置的區域。為工作指定工作站區域，即可控管工作站的區域位置。如要指定工作站區域或地帶，請按照下列步驟操作：
- 如果您使用 gcloud CLI 從 Dataflow 範本建立作業，請使用
--worker-region旗標覆寫工作站區域，或使用--worker-zone旗標覆寫工作站可用區。 - 如果您使用 Apache Beam Java SDK 建立工作，請使用管道選項設定工作站的區域和可用區。使用
workerRegion覆寫工作站地區，或使用workerZone覆寫工作站區域。
為改善網路延遲時間和總處理量，建議您在地理位置上靠近資料來源和接收端的區域中建立工作人員。建立工作時，如果沒有指定工作站的地區或區域，Dataflow 會自動預設為與工作位於相同地區的區域。
如果您未使用 Dataflow Shuffle 服務或 Streaming Engine，則工作處理的資料 (即儲存在任何 PCollection 物件中的資料) 會位於工作站上，前提是沒有使用者程式碼將資料傳輸至工作站外部。如果啟用 Dataflow Shuffle 服務或 Streaming Engine，以 PCollection 物件表示的分散式資料集就能在工作站和這些服務之間傳輸。
資料加密注意事項
Dataflow 是全代管服務，可自動使用 Google-owned and Google-managed encryption keys 加密資料管道中的資料，包括傳輸中和靜態資料。您可能不想使用 Google-owned and Google-managed encryption keys，而是偏好自行管理加密金鑰。在這種情況下，Dataflow 支援使用 Cloud Key Management Service (KMS) 的客戶管理加密金鑰 (CMEK)。您也可以使用 Cloud HSM 這個雲端託管硬體安全性模組 (HSM) 服務來託管加密金鑰，並在 FIPS 140-2 第 3 級認證的 HSM 叢集中執行密碼編譯作業。
使用 CMEK 時，Dataflow 會使用您的 Cloud KMS 金鑰加密資料，但以資料金鑰為基礎的作業 (如時間區間設定、分組和彙整) 除外。如果資料鍵含有個人識別資訊 (PII) 等機密資料，您必須在鍵進入 Dataflow 管道前對鍵進行雜湊處理，或以其他方式加以轉換。
私人網路注意事項
您的網路和安全性需求可能規定，以 VM 為基礎的工作負載 (例如 Dataflow 工作) 只能使用私人 IP 位址。您可以指定 Dataflow 工作站使用私人 IP 位址進行所有網路通訊。如果停用公開 IP，您必須在子網路上啟用私人 Google 存取權，Dataflow 工作人員才能存取 Google API 和服務。
除非 Dataflow 工作需要公開 IP 位址才能存取 Google Cloud外部的網路資源，否則建議您停用 Dataflow 工作站的公開 IP 位址。停用公開 IP 後，Dataflow 工作站就無法存取子網路外部的資源，也無法存取對等互連的 VPC 網路。同樣地，系統會禁止從子網路或對等互連的虛擬私有雲網路外部，存取 VM 工作站的網路。
如要進一步瞭解如何使用 --usePublicIps 管線選項，指定工作站是否只能使用私人 IP，請參閱管線選項。
後續步驟
- 開發及測試管道。
- 瞭解如何設計完整的管道工作流程。
- 進一步瞭解 Google 的資料處理管道網站穩定性工程 (SRE) 做法。