雲端服務的彈性雖然方便，但成本控制仍是資料管道開發的挑戰。本文探討如何在兼顧效能的同時，有效控制雲端資源成本。從選用合適的雲端服務、最佳化計算資源組態、到善用監控工具及建立可測試的程式碼函式庫，提供全面的成本效益最佳化策略。同時，也涵蓋瞭如何選擇合適的雲端運算資源購買選項，例如按需例項、競價例項以及合約折扣，並說明如何根據工作負載需求進行調整，避免資源浪費。
在雲端環境中構建資料管道，成本效益是一大考量。資料管道的各個環節，從資料擷取、轉換、載入到儲存，都需要仔細規劃與最佳化，才能避免不必要的成本支出。選擇合適的雲端服務至關重要，不同服務的計價模式和效能特性差異甚大，需要根據實際需求進行評估。此外，計算資源的最佳化也不可忽視，依據工作負載的波動調整資源組態，才能避免閒置資源的浪費。監控和除錯工具的使用，則有助於及早發現並解決效能瓶頸和錯誤，進一步提升效率。最後，建立可測試且可擴充套件的程式碼函式庫，不僅能降低開發成本，也能提升管道的穩定性和可維護性，確保長期運作的成本效益。
在雲端開發資料管道的成本效益平衡
在雲端開發資料管道是一項具有挑戰性的任務，尤其是在成本控制和效能最佳化之間取得平衡。隨著雲端服務的普及，企業能夠輕鬆擴充套件其資料處理能力，但這也意味著成本可能會迅速增加。本篇文章將探討如何在雲端開發資料管道時實作成本效益的最佳化。
雲端資料管道的挑戰
雲端資料管道的開發涉及多個方面，包括資料的擷取、轉換和載入（ETL）、資料儲存和處理。這些過程需要大量的計算資源和儲存空間，從而導致成本的增加。此外，資料管道的效能和可靠性也是至關重要的，因為它們直接影響到資料的品質和可用性。
成本效益的最佳化策略
要在雲端開發資料管道時實作成本效益的最佳化，需要採取多種策略。以下是一些有效的最佳實踐：
- 選擇合適的雲端服務：不同的雲端服務提供不同的定價模型和效能特點。選擇合適的服務可以幫助降低成本並提高效能。
- 最佳化計算資源：根據工作負載的需求選擇適當的計算資源，可以避免資源浪費並降低成本。
- 使用有效的監控和除錯工具：監控和除錯工具可以幫助識別效能瓶頸和錯誤，從而提高資料管道的可靠性和效率。
- 建立可測試和可擴充套件的資料管道程式碼函式庫：良好的程式碼設計可以降低開發成本並加速資料管道的演進。
- 實施資料驗證和測試：資料驗證和測試可以確保資料的品質和可靠性，從而避免下游錯誤和重新處理。
程式碼最佳實踐
以下是一個範例程式碼，展示瞭如何在雲端開發資料管道時實作成本效益的最佳化：
import pandas as pd
from sklearn.model_selection import train_test_split
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import accuracy_score
# 載入資料
df = pd.read_csv('data.csv')
# 分割資料為訓練集和測試集
train_df, test_df = train_test_split(df, test_size=0.2, random_state=42)
# 訓練模型
model = RandomForestClassifier(n_estimators=100, random_state=42)
model.fit(train_df.drop('target', axis=1), train_df['target'])
# 評估模型
y_pred = model.predict(test_df.drop('target', axis=1))
print('Accuracy:', accuracy_score(test_df['target'], y_pred))
內容解密：
- 載入資料：使用
pd.read_csv載入資料，這是一種常見的資料載入方法。 - 分割資料：使用
train_test_split將資料分割為訓練集和測試集，以評估模型的效能。 - 訓練模型：使用
RandomForestClassifier訓練一個隨機森林模型，這是一種常見的機器學習演算法。 - 評估模型：使用
accuracy_score評估模型的效能，這是一種常見的評估指標。
高效能資料管線設計：雲端運算資源的選擇與最佳化
在當今的資料驅動時代，設計高效且具成本效益的資料管線（Data Pipelines）已成為企業成功的關鍵因素之一。資料管線負責處理和傳輸大量資料，從原始資料來源到資料倉儲或分析平台。隨著雲端運算的普及，企業得以利用靈活且可擴充套件的雲端資源來構建和最佳化其資料管線。本篇文章將探討如何在雲端環境中設計和最佳化資料管線，特別是在計算資源的選擇和擴充套件方面。
雲端運算資源的可用性和限制
在設計資料管線時，首先需要了解雲端運算資源的可用性和相關限制。這包括了中斷（Outages）、容量限制（Capacity Limits）、帳戶限制（Account Limits）以及基礎設施限制（Infrastructure Limits）等。
中斷與容量限制
雲端服務提供商雖然承諾高用性，但仍可能發生中斷事件。瞭解不同區域和可用區（Availability Zones）的中斷歷史和模式，可以幫助設計更具彈性的資料管線。同時，容量限制是指雲端服務提供商在特定區域內能夠提供的計算資源總量。當需求超過這些容量時，可能需要考慮跨區域佈署或與其他雲端服務提供商合作。
帳戶與基礎設施限制
大多數雲端服務提供商對帳戶級別的資源使用設有預設限制，例如每個區域的虛擬機器數量或儲存容量。這些限制可能會影響大規模資料管線的設計。此外，基礎設施限制涉及底層硬體和網路架構，這些都可能成為資料管線效能的瓶頸。
選擇合適的雲端運算資源購買選項
為了最佳化成本和效能，資料管線設計需要考慮不同的雲端運算資源購買選項，包括按需（On Demand）、競價（Spot/Interruptible）和合約折扣（Contractual Discounts）。
按需與競價例項
按需例項提供靈活性，但成本較高。競價例項則提供了顯著的成本文省，但需承擔被中斷的風險。對於可以容忍中斷的工作負載，如批次處理或無狀態應用，競價例項是一種經濟高效的選擇。
合約折扣與實際案例
與雲端服務提供商簽訂長期合約可以獲得折扣，這對於預測性工作負載或長期專案尤其有利。然而，企業需要仔細評估其未來需求，以避免過度承諾導致資源浪費。
需求收集與基準測試
在設計資料管線時，需求收集是至關重要的第一步。這包括業務需求和架構需求。業務需求關注資料處理的時間視窗、資料量和品質，而架構需求則涉及可擴充套件性、可用性和安全性。
例項：批次匯入的需求收集
以一個批次匯入（Batch Ingest）系統為例，需要確定匯入的時間視窗、資料量和所需的計算資源。透過與業務團隊合作，可以確定關鍵效能指標（KPIs），如匯入時間和資料處理吞吐量。
基準測試與例項族群識別
基準測試涉及在不同型別的雲端例項上執行工作負載，以確定最優的效能和成本組合。例項族群識別則是根據工作負載的需求（如CPU密集型或記憶體密集型）選擇適當的例項型別。
自動擴充套件與監控
自動擴充套件是確保資料管線能夠根據需求變化進行調整的關鍵技術。透過設定自動擴充套件策略，可以根據實時工作負載調整計算資源，從而最佳化成本和效能。
自動擴充套件計劃實施
實施自動擴充套件計劃需要定義擴充套件策略，包括何時增加或減少資源。這通常根據監控指標，如CPU使用率、佇列長度或延遲。
常見的自動擴充套件陷阱
雖然自動擴充套件提供了許多好處，但也存在一些常見陷阱，如過度擴充套件導致成本增加，或擴充套件不足導致效能下降。正確組態監控和警示機制對於避免這些問題至關重要。
內容解密：
本篇文章探討了在雲端環境中設計和最佳化資料管線的關鍵要素。首先，我們瞭解了雲端運算資源的可用性和相關限制，包括中斷、容量限制、帳戶限制和基礎設施限制。接著，我們討論瞭如何選擇合適的雲端運算資源購買選項，如按需、競價和合約折扣，以最佳化成本和效能。需求收集和基準測試是設計階段的重要步驟，透過這些步驟可以確定最優的計算資源組態。最後，我們介紹了自動擴充套件的概念及其實施方法，以及如何透過監控來最佳化資料管線的效能和成本。透過這些策略，企業可以建立高效、靈活且具成本效益的資料管線，以支援其資料驅動的業務決策。
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title 雲端資料管道成本效益最佳化策略
package "系統架構" {
package "前端層" {
component [使用者介面] as ui
component [API 客戶端] as client
}
package "後端層" {
component [API 服務] as api
component [業務邏輯] as logic
component [資料存取] as dao
}
package "資料層" {
database [主資料庫] as db
database [快取] as cache
}
}
ui --> client : 使用者操作
client --> api : HTTP 請求
api --> logic : 處理邏輯
logic --> dao : 資料操作
dao --> db : 持久化
dao --> cache : 快取
note right of api
RESTful API
或 GraphQL
end note
@enduml此圖示展示了設計高效能資料管線的主要步驟，從瞭解雲端運算資源限制到最終的監控與最佳化，每一步都至關重要，以確保資料管線的高效執行和成本效益。
前言
在我的資料管線（data pipelines）工作中，曾經遇見過最昂貴的事件是由一個臭蟲（bug）引起的：一個管線在數個月內錯誤地轉換了資料，而這個問題直到我們的客戶發現資料錯誤之前都未被察覺。
通常情況下，這種結果是由多個問題共同導致的。資料具有高度變異性，使得資料品質監控變得困難。我們有測試資料，但它已經嚴重過時。測試程式碼變更的唯一方法是執行完整的管線執行，這既耗時又昂貴。我們知道資料來源可能會不可預測地變更，但我們在管線中沒有資料驗證機制來檢測變更的發生。
我們本可以透過根據結構描述（schema-based validation）的驗證來捕捉到這個臭蟲，這是本文將會介紹的內容。相反，我們花費了年度雲端賬單中的相當一部分來重新計算錯誤的資料。更糟糕的是，它還讓我們失去了客戶的信任，以至於專案的有效性受到質疑。一個價值數百萬美元的合約支援著十多個工作職位，為近一億人提供了服務。這種規模的錯誤是每一位具有重要責任的資料工程師在其職業生涯中都會遇到的。
在嘗試控制雲端資料管線的成本時，人們經常面臨著權衡。達到效能需求，但減少浪費的計算週期。使用可觀察性（observability）進行除錯、降低成本和演進設計，但不要在監控和日誌記錄上過度花費。提高測試覆寫率，但資料中的不可預測變更使測試假設無效，而雲端服務介面的變更引入了額外的成本和複雜性。使用低成本、可中斷的計算例項，但不要犧牲管線的穩定性。
在本文中，我總結了您需要了解的內容，以便快速成功地處理這些權衡問題。本文重點關注有效的監控、資料管線開發和測試，以及針對雲端計算和儲存的設計建議，將幫助您從一開始就成功建立資料管線，並能夠以成本效益的方式管理其演進。
我曾在批次和串流系統中使用這些方法，處理從幾千行到PB級別的資料，從結構良好的結構化資料到頻繁變更的半結構化資料來源。
本文適用物件
我將內容針對中級到高階讀者進行了調整。我假設您熟悉軟體開發的最佳實踐，對雲端計算和儲存的基本操作有一定的瞭解，並且對批次和串流資料管線的操作有大致的瞭解。
本文是根據我在日常資料管線開發中的經驗寫成的。如果您已經或希望從事這方面的工作，可以將本文視為虛擬導師，提供常見陷阱的建議，並根據各種資料管線專案的工作經驗提供指導。
如果您來自資料分析背景，您將在本文中找到有關軟體最佳實踐的建議，幫助您構建可測試、可擴充套件的管線。這將幫助您將分析與資料採集和儲存連線起來，建立端對端的系統。
開發速度和成本意識設計是從個人貢獻者到經理都應該關注的領域。在本文中，您將找到有關如何將品質納入開發流程、有效利用雲端資源和降低成本的建議。此外，您還將瞭解監控的元素，不僅可以保持對系統健康和效能的關注，還可以深入瞭解應該考慮重新設計的地方。
如果您管理著資料工程團隊，您將在本文中找到有關有效開發實踐、成本可能增加的領域以及整體方法的有益提示，以幫助您的團隊成功。
您將學到的內容
如果您想學習或提高以下技能，本文將是一個有用的：
- 透過低成本的雲端服務供應和智慧設計策略來降低雲端支出。
- 在不犧牲效能的情況下，透過正確調整計算資源的大小來最小化浪費。
- 透過具有成本效益的監控和日誌記錄來推動管線演進、預防效能問題並快速除錯。
- 建立最小化雲端服務成本的開發和測試環境。
雲端資料管道開發的成本效益考量
在現代的雲端運算時代，企業越來越依賴資料管道（data pipelines）來處理和分析龐大的資料集。資料管道的開發和維護涉及多個層面，包括資料擷取、轉換、儲存和計算資源的管理。為了有效地管理這些流程，開發人員需要關注成本效益，以確保資料管道不僅能夠滿足業務需求，還能控制相關成本。
資料管道開發的核心挑戰
資料管道的開發面臨多項挑戰，包括資料品質、系統擴充套件性、成本控制等。其中一個主要問題是「資料停機時間」（data downtime），即資料不正確、部分缺失或完全遺失的情況。這種情況不僅會影響業務決策，還會增加額外的成本來修復和重新處理資料。
提升資料品質與降低成本
為了應對這些挑戰，本文將重點介紹如何建立可測試和可擴充套件的資料管道程式碼函式庫，以減少開發時間並加速管道演進。同時，透過驗證和測試來提高資料品質和管道運作，從而限制昂貴的資料停機時間。
本文的重點與限制
本文並非一本架構設計書籍，雖然會涉及一些與架構和系統需求相關的內容，但不會探討不同的架構方法和取捨。同樣，本文也不會涵蓋資料治理、資料目錄或資料血統等主題。
本文將提供實用的建議，說明如何在雲端建置資料管道時管理固有的成本與效能之間的取捨。然而，它並不是一本財務營運（FinOps）書籍，後者會指導讀者尋找未使用的計算例項小時數作為降低成本的潛在機會，而本文則探討如何減少例項小時數和相關成本的具體細節。
雲端服務與技術
本文將重點介紹多種雲端服務，包括物件儲存（如AWS S3和GCS）、無伺服器函式（如AWS Lambda）以及叢集計算服務（如AWS EC2、AWS EMR和Kubernetes）。雖然管理系統邊界、身份管理和安全是重要課題，但本文不會對這些主題進行探討。
案例研究：Herons on Demand (HoD)
為了闡述成本效益高的資料管道開發的不同方面，本文引入了一個虛構的社交媒體網站——Herons on Demand (HoD)——作為執行的範例。HoD由Lou和Sylvia建立，他們利用雲端服務提供商（CSP）的資源，迅速建立了一個可擴充套件的平台來分享有關禾鶴（herons）的資訊和影片。隨著使用者數量的激增，HoD面臨著如何管理龐大資料集和控制雲端成本的挑戰。
本文使用的排版約定
本文使用以下排版約定：
- 斜體字：表示新術語、URL、電子郵件地址、檔案名稱和檔案副檔名。
等寬字型：用於程式清單，以及在段落中參照程式元素，如變數或函式名稱、資料函式庫、資料型別、環境變數、陳述式和關鍵字。等寬粗體：顯示應該由使用者逐字輸入的命令或其他文字。等寬斜體：顯示應該被使用者提供的值或由上下文決定的值所替換的文字。
結語
本文旨在提供實用的指導，幫助讀者建立成本效益高且可擴充套件的資料管道。透過結合具體案例和技術細節，讀者將能夠更好地理解如何在雲端環境中最佳化資料處理流程，並控制相關成本。
為資料管線設計運算資源
在開發執行於專用硬體上的應用程式時，無論是在本地資料中心、筆記型電腦還是手機上，你都面對著預先確定且固定的資源數量。相反地，在雲端環境中，你可以根據工作負載的需求組態虛擬硬體，而非受限於預先定義的資源範圍。
為資料管線設計運算資源，主要涉及確定為了實作高效能和可靠運作所需的資源。除了CPU、記憶體、磁碟空間和頻寬之外，雲端運算還提供額外的採購選項軸，讓你能夠在成本和效能之間進行權衡。
這是一個令人望而生畏的主題，因為跨運算例項型別、大小和採購計畫有著無數可能的排列組合。在本章中，我將展示如何導航這個空間，根據資料管線的效能特徵縮小選項範圍，並透過效能基準測試來改進你的選擇。
首先要牢記的是，雲端運算是一個分享的分散式系統。因此，在某些時候，可能沒有足夠的容量來滿足你的資源請求。我將在本章開始時強調不同場景中可能出現的資源短缺問題，因為最終，如果你需要的資源不可用，那麼你設計的叢集再好也沒有意義。
接下來，你將看到關於雲端運算各種採購選項的建議，以及如何在資料管線設計中充分利用這些選項。
在確定正確的運算組態的過程中，另一個步驟是考慮設計空間中的業務和架構需求。為了說明這個過程，我將逐步介紹一個從業務問題開始的場景，並引導你識別高層次上相關的運算選項。
雲端運算資源短缺的場景
在雲端環境中，由於資源是分享的，因此可能會出現無法滿足資源請求的情況。這種情況可能由多種因素引起，包括但不限於：
- 資源過度分配：當多個使用者或應用程式同時請求超出可用容量的資源時。
- 區域性容量限制：某些區域或可用區的資源可能因為地理或硬體限制而無法滿足大規模請求。
- 突發性需求：在某些情況下，如突發性流量或大量資料處理需求，可能會導致資源短缺。
如何應對資源短缺
- 監控和預測：透過監控當前資源使用情況並預測未來需求，可以更好地規劃和避免資源短缺。
- 彈性伸縮：利用雲端服務的自動伸縮功能，根據實際需求動態調整資源。
- 多區域佈署：在多個區域或可用區佈署應用，以減少單一區域資源短缺的影響。
- 採購策略最佳化：根據工作負載特性選擇合適的採購選項，如預留例項、Spot例項等。
雲端運算採購選項
雲端運算提供了多種採購選項，以滿足不同的成本和效能需求。主要的選項包括：
- 按需例項：無需預付費用或承諾使用期限，按小時或秒計費。
- 預留例項：透過承諾使用期限（1年或3年），可以獲得顯著的折扣。
- Spot例項：利用未使用的雲端資源，通常以較低的價格提供，但可能會被收回。
如何選擇合適的採購選項
選擇合適的採購選項需要考慮工作負載的特性、成本敏感度和效能需求。例如，對於穩定且長期的工作負載，預留例項可能是最具成本效益的選擇；而對於靈活或間歇性的工作負載，按需例項或Spot例項可能更合適。
業務和架構考量
在設計資料管線時，除了技術層面的考量外，還需要考慮業務和架構需求。這包括：
- 成本控制：如何在滿足效能需求的前提下，最小化成本。
- 可擴充套件性：設計應能夠根據需求變化進行擴充套件或縮減。
- 可靠性：確保系統能夠抵禦故障並保持高用性。
透過綜合考慮這些因素，可以設計出既高效又具成本效益的資料管線運算資源組態方案。
雲端運算資源的可用性考量
在設計資料管線時，雲端運算資源的可用性是一個至關重要的考量因素。雖然雲端提供了大量的運算能力，但仍有一些因素需要考慮，以確保資源的可用性和可靠性。
中斷事件的影響
隨著越來越多的運算工作轉移到雲端，雲端服務供應商（CSP）的中斷事件可能會對許多行業產生廣泛的影響，包括政府網站、餐飲服務，甚至是機器人吸塵器的排程。
CSP 通常會提供服務水準協定（SLA），保證一定的正常執行時間百分比，如 Google Cloud 和 Amazon EC2。如果 SLA 未能達成，客戶可以獲得受影響的運算資源費用的部分賠償。然而，從業務角度來看，中斷事件所造成的財務損失遠遠超過了雲端資源的佈署成本。
根據 Lloyd’s of London 2018 年的一份報告，如果一家頂級 CSP 發生中斷事件，持續 3 至 6 天，可能會導致高達 150 億美元的收入損失。考慮到自該報告發布以來，企業在雲端的擴張，類別似事件在今天可能會造成更大的損失。
多樣化佈署以降低中斷風險
為了降低中斷事件的影響，可以考慮在多個可用區域（AZ）佈署運算資源。當中斷事件發生時，它們可能會影響 CSP 網路中的部分割槽域和 AZ，例如 2021 年 Amazon Web Services（AWS）發生的中斷事件。在多個 AZ 佈署管線可以幫助降低中斷風險。
然而，這也需要額外的基礎設施投入，並且可能會增加網路成本和資料管線的效能影響，如果工作負載跨越多個 AZ。
容錯移轉系統
容錯移轉系統可以在主要系統故障時提供備援。根據系統需要保持線上的緊急程度，可以採用不同的實施方式。熱備援系統是一種實時備援系統，可以快速切換，但需要始終保持備援系統線上和就緒。
從熱備援到冷備援系統，有不同的容錯移轉就緒程度。冷備援系統在故障發生時才啟動資源，這種方式犧牲了系統可用性，但降低了執行備援系統的成本。
雖然容錯移轉系統可以提供額外的保障，但在發生中斷事件時，這些系統可能會非常昂貴。在不同區域執行管線的容錯移轉策略需要將資料複製到多個區域，這將顯著增加資料儲存和存取成本。
容量限制
在使用雲端服務時，容易忽略的一點是資源通常是分享的。除非購買專用硬體，否則將與其他客戶分享運算資源。這意味著，當組態叢集時，實際上是在請求這些資源，而不是保證其可用性。
當啟動運算例項或叢集時，實際上是在請求特定的例項型別和大小。是否能夠滿足這個請求取決於所選區域和 AZ 的可用容量。
如果在需要啟動批次作業或增加串流管線容量時，所有資源都被佔用，則資源請求將無法滿足。在美國東部時區營業時間結束後的幾個小時內，我曾經見過這種情況，當時請求運算容量來執行工作負載。
即使已經預留了專用運算資源，如果嘗試組態超過已購買容量的資源，也可能會出現這種問題。
分割管線工作負載
透過將管線工作負載分割為時間關鍵型和可根據資源可用性執行的工作，可以幫助降低容量影響。您將在“架構需求”一節中瞭解更多相關內容。
