資料管線運算資源設計與採購策略

雲端時代，資料管線的設計與實施面臨諸多挑戰，其中運算資源的有效組態是確保管線穩定運作並控制成本的關鍵。本文將探討設計高效能、低成本資料管線的策略，涵蓋資源限制、採購選項、基準測試及效能最佳化等導向。從雲端服務供應商的帳戶限制到實際案例分析，幫助讀者瞭解容量規劃的重要性。同時，文章也比較了按需例項、Spot 例項和合約折扣等不同採購選項，並以實際案例說明如何選擇最合適的方案。

設計穩健的資料管線

即使您所處的環境中不擁有基礎設施，本章仍將為您提供有關穩健管線設計、成本效益權衡以及一些架構方面的寶貴見解。這些對於良好的管線設計是不可或缺的。

###效能基準測試與成本最佳化

在本章的最後一節，您將學習如何對不同叢集組態進行效能基準測試。這是本章中最令人興奮的部分，您將開始瞭解最佳化運算所需的多方面依賴關係，包括為什麼更多的叢集節點不一定意味著更好的效能。在本章結束時，我將重新討論採購選項，向您展示如何權衡效能與成本。

設計資料管道的運算資源限制與採購策略

在設計資料管道時，運算資源的可用性是一個至關重要的考量因素。無論是根據雲端的運算資源，還是本地佈署的基礎設施，瞭解並管理運算資源的限制對於確保資料管道的穩定運作至關重要。

帳戶限制與基礎設施限制

雲端服務提供商（CSP）通常會根據使用者的訂閱等級設定運算資源的限制。例如，使用者可能只能存取有限的CPU資源。當請求超出這些限制時，可能會導致錯誤或請求無法被滿足。瞭解這些限制，並在必要時升級訂閱等級或最佳化資源使用，是避免這些問題的關鍵。

此外，運算資源的可用性還取決於所設定的環境。例如，不同的可用區（AZ）或區域可能會提供不同型別的例項型別和大小。如果使用的是AWS Elastic MapReduce（EMR）等服務，還可能存在對例項型別的進一步限制。

容量限制的實際案例

曾經遇到過一個案例，由於特定AZ中某種例項大小的資源不足，導致資料管道在執行批次作業時出現“容量不足”的錯誤。為瞭解決這個問題，團隊修改了作業排程系統，以限制提交的作業數量，並在遇到容量不足時減少重試次數。

這個案例凸顯了在設計資料管道時需要考慮的多方面限制，包括客戶需求、雲端服務的可用性以及資源限制。解決方案包括跨多個AZ執行作業、最佳化作業排程和資料大小等。

利用不同的採購選項最佳化資料管道設計

雲端運算資源的採購選項主要分為三類別：按需、搶佔式/Spot例項和合約折扣（如預留例項和承諾使用折扣）。不同的採購選項具有不同的成本和可用性特徵。

按需

按需例項提供最大的靈活性，可以隨時請求例項而無需預先承諾。然而，這種靈活性是以較高的成本為代價的。按需例項適合於工作負載不固定、對服務中斷容忍度低的場景。

Spot/搶佔式例項

Spot例項是CSP提供的閒置運算資源，通常以較低的價格提供。然而，Spot例項的價格和可用性可能會波動，當需求增加時，CSP可能會回收這些例項。Spot例項適合於低優先順序、非時間敏感的工作負載。

合約折扣

透過承諾在一定期限內使用一定量的運算資源，可以獲得合約折扣。這種方式適合於有可預測運算需求的場景。然而，瞭解折扣的適用方式非常重要，以避免誤解導致的不必要成本。

雲端計算資源採購策略：合約折扣的應用與風險

在設計資料處理管線時，瞭解不同的雲端資源採購選項對於成本控制至關重要。合約折扣（Contractual Discounts）是雲端服務提供商（CSPs）提供的一種成本文省方案，但需要仔細規劃和了解其運作機制，以避免意外的費用。

合約折扣的基本原理

合約折扣的核心是承諾使用一定量的雲端資源，以換取折扣優惠。承諾的時間越長，折扣通常越大。例如，若承諾保留特定例項型別在單一可用區（AZ），可以獲得比需要更多彈性（如多種例項型別）更好的折扣。

合約折扣的關鍵考量

明確承諾內容：瞭解你正在保留什麼。是特定的計算例項型別或大小，還是CPU核心數量或記憶體數量？合約是否允許更改這些選擇？
可用性保證：是否保證所保留的資源可用？某些CSPs的「保留」並不意味著資源一定可用，除非指定單一AZ。
變更或取消保留：如果不再需要保留的資源，是否可以出售未使用的保留資源或轉換為不同的例項組態？
折扣的應用方式：瞭解折扣如何應用於實際使用量。保留一定量的容量不一定意味著在使用比對資源時自動獲得折扣。

案例分析：合約折扣的陷阱

考慮一個資料處理管線，使用兩台工作節點（WORKER1和WORKER2），例項型別為INST3。根據歷史使用量，每月使用10個例項小時，決定購買一年期的保留例項。然而，實際使用量在某些月份超過了預期，導致帳單與預期不符。

預期與實際帳單差異

月份	WORKER1 使用量	WORKER2 使用量	總使用量
一月	5小時	5小時	10小時
二月	8小時	8小時	16小時
三月	5小時	5小時	10小時

預期帳單：

保留例項：30小時 * $0.2 = $6.00
按需例項：6小時 * $0.4 = $2.40
總計：$8.40

實際帳單：

保留例項：30小時 * $0.2 = $6.00（只應用於WORKER1）
按需例項：18小時 * $0.4 = $7.20
總計：$13.20

#### 內容解密：

此案例顯示了合約折扣的應用與預期不符的原因。保留例項的折扣只應用於單一例項（WORKER1），而未使用的保留例項小時仍需付費。這導致總成本遠高於預期。要獲得預期的價格，需要購買兩個保留例項，每個承諾60小時/年。

計算資源設計的需求收集

在設計計算資源時，除了關注特定任務的需求外，還需要了解系統級別的整體需求，包括業務需求、資料來源、處理排程、結果資料要求等。這些資訊有助於確定是否需要規劃容錯移轉系統，以及如何利用雲端的各種選項進行權衡。

業務需求

瞭解需要解決的業務問題，有助於確定高層級的管線需求，包括資料來源、攝取排程、結果資料要求等。同時，也需要確定系統執行時間要求，以規劃相應的資源。

#### 內容解密：

業務需求的收集是設計計算資源的第一步。它不僅關乎技術實作，也關乎如何滿足業務目標和使用者需求。透過瞭解業務問題，可以更好地規劃資源，最佳化成本，並確保系統的高用性。

資料管道運算設計的需求收集

在設計資料管道時，首要任務是瞭解業務需求並將其轉化為技術規格。這包括定義資料來源、處理結果以及完成處理所需的時間。業務需求決定了技術架構和資源分配。

業務需求

業務需求定義了資料管道的目的和目標。例如，資料管道可能需要處理來自不同來源的資料，並將其轉化為可用的格式。業務需求還包括對效能、可用性和成本的考量。

在定義業務需求時，需要考慮以下幾個因素：

資料來源和結果資料的定義
資料處理的速度和時效性要求
成本與效能之間的權衡
資料的複雜度和規模

以大資料的三個V（variety, velocity, 和 volume）為思考框架，有助於確定管道架構和資源需求。例如，如果資料來源的資料量隨時間變化很大，則需要考慮如何處理這種變化。

架構需求

架構需求將業務需求轉化為技術規格，提供實作業務需求所需的技術藍圖。這包括設定效能規格、正常執行時間要求和資料處理引擎的選擇。

在考慮架構需求時，需要將運算設計和資料處理引擎結合起來思考。同時，也需要考慮管道執行的環境，例如在 Kubernetes 環境中，需要正確設定名稱空間以限制資源爭用。

優先排程與工作負載分段

高效能工作負載可能需要大量的空閒記憶體和CPU資源。為了充分利用這些資源，可以採用優先排程策略，讓低優先順序的程式在背景執行，以利用閒置的資源。

工作負載分段也可以幫助減少管道執行時間。例如，可以將某些任務安排在非繁忙時段或背景執行。

線上與離線處理

離線處理提供了一個使用低成本中斷例項的機會。例如，可以在背景執行壓縮任務，以降低儲存成本。

需求收集範例：HoD批次擷取

Herons on Demand（HoD）團隊與某大學實驗室合作，收集和分析候鳥資料。資料管道如圖1-3所示。

業務需求分析

研究人員希望盡快獲得資料，特別是在重要的截止日期前。然而，他們也需要謹慎管理用於雲端計算的資金。這是一個典型的成本與效能之間的權衡問題。

研究人員同意每兩週接收一次資料批次。HoD團隊提出了一個處理管道失敗的方案：透過監控和在當天重新執行，而不是花費更多的錢來建立一個更複雜的即時檢測和緩解方案。

架構決策

HoD團隊已經在使用Spark on EMR執行一些管道，並且對該系統很熟悉。因此，他們決定使用相同的工具來執行調查管道。

計算資源設計的基準測試與評估

在設計資料處理管線的計算資源時，需要進行基準測試來評估不同的計算組態，以找出最佳的資源組態方案。本章節將延續先前的範例，探討如何評估不同的資料處理引擎、技術和叢集大小，並說明它們之間的相互影響。

基準測試的重要性

基準測試是評估叢集設計和計算選項的過程，透過執行樣本工作負載來識別最佳組態。這個過程對於理解資料處理管線的效能和成本之間的權衡至關重要。

例項家族的選擇

選擇適當的例項家族需要綜合評估 CPU、記憶體和頻寬的需求，並分析叢集的效能。對於 HoD 鳥類別調查資料處理管線，使用 Spark 進行資料處理，主要在記憶體中進行資料操作。另一個方面是調查資料與 HoD 資料函式庫之間的連線操作，這需要大量的記憶體。因此，選擇記憶體最佳化型或具有大量記憶體的通使用案例項家族是合適的。

例項選擇標準

根據 Spark 檔案的建議，每台機器的核心數應組態在 8 至 16 之間，頻寬應達到 10 Gb 或更高。根據這些要求，AWS 提供了多種例項型別可供選擇，如表 1-4 所示。

基準測試的流程

進行基準測試時，需要考慮資料處理引擎的選擇、叢集大小和組態等因素。這些因素之間存在著複雜的相互依賴關係，因此需要仔細評估和測試。

#### 內容解密：

此段落主要介紹了在進行基準測試時，需要考慮的因素包括資料處理引擎、叢集大小和組態等。這些因素會相互影響，因此需要綜合評估。

效能與成本的權衡

在設計資料處理管線時，需要在效能和成本之間進行權衡。選擇適當的例項型別和數量，可以在滿足效能要求的同時，控制成本。

#### 內容解密：

此段落強調了在設計資料處理管線時，效能和成本之間的權衡非常重要。選擇適當的例項型別和數量，可以實作效能和成本的最佳平衡。

資源需求評估

評估資源需求需要考慮資料的大小、處理引擎的需求和叢集的組態等因素。對於 HoD 鳥類別調查資料處理管線，需要考慮調查資料的大小、HoD 資料函式庫的需求和 Spark 的組態等因素。

# 以下是一個簡單的 Python 範例，用於模擬資源需求評估
import pandas as pd

# 定義資源需求評估函式
def assess_resource_needs(data_size, processing_engine, cluster_config):
    # 根據資料大小、處理引擎和叢集組態評估資源需求
    resource_needs = {
        'cpu': 0,
        'memory': 0,
        'bandwidth': 0
    }
    
    # 簡單的模擬邏輯
    if processing_engine == 'Spark':
        resource_needs['memory'] = data_size * 2
    else:
        resource_needs['cpu'] = data_size * 1.5
    
    return resource_needs

# 使用範例
data_size = 1000  # GB
processing_engine = 'Spark'
cluster_config = {'instance_type': 'r5.2xlarge'}

resource_needs = assess_resource_needs(data_size, processing_engine, cluster_config)
print(resource_needs)

#### 內容解密：

此程式碼範例展示了一個簡單的資源需求評估函式，根據資料大小、處理引擎和叢集組態評估所需的 CPU、記憶體和頻寬資源。在這個範例中，如果使用 Spark 作為處理引擎，則主要考慮記憶體的需求；否則，主要考慮 CPU 的需求。

設計資料處理管線的運算資源

在設計資料處理管線時，選擇適當的運算資源至關重要。本章節將探討如何在 AWS EMR 上選擇適當的例項型別和大小，以及如何進行叢集規模調整和效能監控。

AWS EMR 例項型別和大小比較

AWS EMR 提供了多種例項型別和大小，以滿足不同的運算需求。表 1-4 列出了幾種常見的例項型別和大小，包括通用型（m4 和 m5）和記憶體最佳化型（r4 和 r5）。

例項型別比較表

API 名稱	記憶體 (GB)	vCPU	網路效能	Linux 按需成本
m4.2xlarge	32	8	高	$0.40
m4.4xlarge	64	16	高	$0.80
m5.xlarge	16	4	高達 10 Gb	$0.19
m5.2xlarge	32	8	高達 10 Gb	$0.38
m5.4xlarge	64	16	高達 10 Gb	$0.77
r4.xlarge	30.5	4	高達 10 Gb	$0.27
r4.2xlarge	61	8	高達 10 Gb	$0.53
r4.4xlarge	122	16	高達 10 Gb	$1.06
r5.xlarge	32	4	高達 10 Gb	$0.25
r5.2xlarge	64	8	高達 10 Gb	$0.50
r5.4xlarge	128	16	高達 10 Gb	$1.01
r5.12xlarge	384	48	10 Gb	$3.02

vCPU 的計算方式

根據 Datacenters.com 的資料，vCPU 的計算方式為 (執行緒 × 處理器核心) × 物理 CPU = vCPU 數量。vCPU 有效地代表了可用的執行緒數量。更多的 vCPU 可以提高平行度，從而提高 Spark 的執行效率。

叢集規模調整

在設計叢集時，另一個常見的問題是如何選擇適當的節點數量。至少需要兩個工作節點以確保可靠性和效能。要達到所需的容量，可以選擇組態多個較小的例項或較少的大型例項。

程式碼範例：叢集組態

# 定義叢集組態
cluster_config = {
    "instance_type": "m5.xlarge",
    "instance_count": 3,
    "total_vcpu": 12,
    "total_memory": 48
}

程式碼解密：

定義了一個名為 cluster_config 的字典，用於儲存叢集組態的相關資訊。
instance_type 鍵對應的值為 "m5.xlarge"，表示使用的例項型別。
instance_count 鍵對應的值為 3，表示使用的例項數量。
total_vcpu 鍵對應的值為 12，表示總共的 vCPU 數量。
total_memory 鍵對應的值為 48，表示總共的記憶體容量。

效能監控

為了評估叢集組態的有效性，需要監控效能。監控的重點包括叢集資源利用率、資料處理引擎的內省資訊等。

效能監控流程

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 資料管線運算資源設計與採購策略

package "軟體測試架構" {
    package "測試層級" {
        component [單元測試
Unit Test] as unit
        component [整合測試
Integration Test] as integration
        component [端對端測試
E2E Test] as e2e
    }

    package "測試類型" {
        component [功能測試] as functional
        component [效能測試] as performance
        component [安全測試] as security
    }

    package "工具框架" {
        component [pytest] as pytest
        component [unittest] as unittest
        component [Selenium] as selenium
        component [JMeter] as jmeter
    }
}

unit --> pytest : 撰寫測試
unit --> integration : 組合模組
integration --> e2e : 完整流程
functional --> selenium : UI 自動化
performance --> jmeter : 負載測試

note right of unit
  測試金字塔基礎
  快速回饋
  高覆蓋率
end note

@enduml

圖表說明：

首先開始監控叢集效能。
接著收集叢集資源利用率的相關資料。
同時收集資料處理引擎的內省資訊。
然後分析這些資料以找出效能瓶頸。
最後根據分析結果調整叢集組態，以最佳化效能。

Benchmarking 範例

本文將透過一個範例來說明如何進行 benchmarking。假設我們有一個鳥類別調查的批次處理管線，需要處理大量的資料。

表格：初始叢集組態

名稱	例項型別	例項數量	總 vCPU	總記憶體 (GB)	頻寬 (GB)
GP1	m5.xlarge	3	12	48	高達 10
M1	r5.xlarge	3	12	96	高達 10

分析：

GP1 和 M1 是兩種不同的叢集組態，分別使用通用型和記憶體最佳化型的例項。
這兩種組態在處理相同資料量時的效能表現相似。

雲端運算資源組態的最佳實踐：效能、成本與可用性的平衡

在設計資料處理管線的運算資源時，雲端提供了無數的組態選擇，這使得最佳化效能、成本和正常運作時間變得至關重要。本文將探討如何透過基準測試、自動擴充套件和適當的例項選擇來實作這一平衡。

自動擴充套件與叢集大小的動態調整

在討論具體的叢集組態之前，瞭解自動擴充套件（autoscaling）的重要性是至關重要的。自動擴充套件允許叢集管理服務（如 EMR）根據使用者定義的約束條件動態調整工作節點的數量。例如，若目標是保持 70% 的記憶體使用率，則可以設定自動擴充套件規則，在記憶體使用率超過此閾值一段時間後增加工作節點。最終的叢集大小可以為評估所需的作業員節點數量提供參考。

基準測試與效能評估

為了評估不同叢集組態的效能，我們進行了一系列基準測試。下表展示了兩種初始叢集組態：GP1 和 M1。

| 名稱 | 例項型別 | 例項數量 | 總 vCPU | 總記憶體 (GB) | 頻寬 (GB) | |

|

–|

|

–|

|

| | GP1 | m5.xlarge | 10 | 40 | 160 | 最多 10 | | M1 | r5.xlarge | 8 | 32 | 256 | 最多 10 |

在假設的 2 TB 批次處理範例中，這些組態顯示出不同的效能。GP1 和 M1 都出現了記憶體不足和節點失敗的問題，表明資源不足。

調整叢集組態：過度組態與適當組態

接下來，我們測試了過度組態的叢集（GP2 和 M2）和適當組態的叢集（GP3 和 M3）。

過度組態

| 名稱 | 例項型別 | 例項數量 | 總 vCPU | 總記憶體 (GB) | 頻寬 (GB) | |

|

–|

|

–|

|

| | GP2 | m5.xlarge | 40 | 160 | 640 | 最多 10 | | M2 | r5.xlarge | 30 | 120 | 960 | 最多 10 |

這兩種組態顯著提高了效能，完成了任務，但仍有很大的改進空間。

適當組態

| 名稱 | 例項型別 | 例項數量 | 總 vCPU | 總記憶體 (GB) | 頻寬 (GB) | |

|

–|

|

| | GP3 | m5.4xlarge | 10 | 160 | 640 | 最多 10 | | M3 | r5.2xlarge | 8 | 64 | 512 | 最多 10 |

結果顯示，適當組態的叢集不僅減少了洗牌（shuffling）操作，還降低了執行時間。

成本比較與最佳實踐

最後，我們比較了不同組態下的成本。

| 名稱 | 例項數量 | 小時數 | 按需價格 | 40% 競價例項 | 60% 競價例項 | |

|

-|

|

| | GP2 | 40 | 8 | $77 | $62 | $54 | | M2 | 30 | 6.5 | $58 | $49 | $44 | | GP3 | 10 | 7 | $67 | $56 | $51 | | M3 | 8 | 4.75 | $24 | $20 | $19 |

結果表明，適當組態的記憶體最佳化例項（如 M3）在成本和效能上都表現最佳。

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。