計算資源動態調整與成本文約策略

現代資料處理流程中，計算資源的動態調整對於系統效率和成本控制至關重要。資料管道各階段的資源需求差異巨大，例如 Household Data（HoD）管道，其資源消耗受資料特性和處理複雜度影響，尤其「Enrich with social」步驟的資源需求與調查資料和社群媒體資料的重疊程度直接相關。透過監控記憶體使用率等指標，可以有效識別資源調整的時機。相較於固定資源組態，雲端計算的彈性擴充套件能力能按需分配資源，避免浪費，從而降低成本。有效的擴充套件計劃應包含按需啟動、動態調整資源數量以及持續監測和調整等策略。系統設計方面，建議採用支援水平擴充套件的分散式處理引擎，如 Apache Spark，並注意資料檔案結構和轉換程式碼的最佳化，避免過多的 shuffle 操作。此外，縱向擴充套件在特定場景下也能提供更佳的效能，例如廣播連線的使用。設計可擴充套件系統時，需考慮資料處理結果的消費者，確保其能處理增加的資料量，並注意相關服務的擴充套件，例如資料函式庫和 API。分離儲存與計算也有助於更有效的擴充套件，雲端儲存的頻寬優勢和按需付費模式能有效降低成本。自動擴充套件的機制包括輪詢指標、評估、觸發擴充套件事件、組態資源和負載重新平衡。縮減和擴充套件操作存在時間差，需預留足夠時間以避免效能問題。最後，自動擴充套件的實施需要謹慎設定門檻值、觀察視窗和冷卻期等引數，避免資源波動和過度擴充套件等問題。

資源擴充套件的智慧：如何根據工作量變化最佳化計算資源

在現代資料處理流程中，計算資源的動態調整是確保系統高效運作的關鍵。尤其是在處理複雜的資料管道（pipeline）時，不同階段的工作負載可能會出現劇烈變化，這使得資源的有效分配變得至關重要。

不同階段的資源需求變化

資料處理管道的不同階段對資源的需求可能大不相同。以Household Data（HoD）管道為例，其處理流程包括多個步驟，每個步驟所需的計算資源取決於資料的特性和處理的複雜度。

圖 2-7：每個階段的資源擴充套件情況

圖 2-7 直觀地展示了不同階段的資源需求變化。填滿的方框表示該階段需要較高的資源。

另一個影響資源需求的重要因素是調查資料（survey data）與社群媒體資料（social media data）之間的重疊程度，這直接影響了「Enrich with social」步驟的資源消耗。

圖 2-8：不同資料重疊情況下的資源需求

圖 2-8 展示了資料重疊對資源需求的影響。左側顯示了調查資料與社群媒體資料之間的關係，右側則對應了「Enrich with social」步驟所需的資源量。「Enrich with social」步驟的背景顏色越深，表示需要的資源越多。

資源需求變化的識別

要有效擴充套件計算資源，首先需要識別何時需要調整資源。根據第一章的基準測試結果，我們知道HoD管道是一個記憶體密集型的處理過程。當資料量和調查資料與社群媒體資料的重疊程度增加時，記憶體的使用量也會隨之上升。因此，持續監測記憶體使用情況，可以作為判斷是否需要調整資源的重要指標。

縮放帶來的成本文約

如果為資料處理管道分配固定的計算資源，為了保證在資料重疊較多的情況下仍能正常運作，就需要預先組態足夠的資源。這樣一來，在資料重疊較少的情況下，就會造成資源浪費。利用雲端計算的彈性擴充套件能力，可以根據實際工作負載動態調整資源，在保證處理效能和可靠性的同時，大幅降低成本。

制定有效的擴充套件計劃

1. 按需啟動計算資源：在任務啟動時分配計算資源，任務完成後立即釋放，這樣可以最大限度地節省成本。

2. 動態調整資源數量：根據工作負載的變化，動態調整計算資源的數量。例如，透過基準測試確定最小和最大資源需求，分別對應低資料量且無重疊和高資料量且高重疊的情況。

   • 假設基準測試結果顯示，低資料量且無重疊的情況下需要3個工作節點，而高資料量且高重疊的情況下需要10個工作節點，那麼這兩個數字可以作為最小和最大資源組態的參考值。

3. 持續監測和調整：初始的最小和最大資源組態只是個起點，需要持續監測系統效能和資源利用率，並根據實際情況進行調整。

為擴充套件設計系統

具備彈性擴充套件能力的系統設計至關重要。首先，需要採用支援水平擴充套件的分散式資料處理引擎，如Apache Spark、Presto或Dask。這些引擎能夠有效地將計算任務分散到多個節點上執行，從而提高處理效率。

程式碼範例：使用Spark進行分散式資料處理

from pyspark.sql import SparkSession

# 初始化SparkSession
spark = SparkSession.builder.appName("Data Processing").getOrCreate()

# 載入資料
data = spark.read.csv("data.csv", header=True, inferSchema=True)

# 資料轉換
processed_data = data.filter(data['age'] > 30).groupBy('city').count()

# 結果儲存
processed_data.write.parquet("processed_data.parquet")

# 停止SparkSession
spark.stop()

內容解密：

1. 初始化SparkSession：建立Spark應用程式的核心入口。
2. 載入資料：使用Spark的read.csv方法讀取CSV檔案。
3. 資料轉換：對資料進行篩選和分組聚合操作，展現Spark的分散式處理能力。
4. 結果儲存：將處理結果以Parquet格式儲存，適合大資料儲存和查詢。
5. 停止SparkSession：釋放資源，結束Spark應用程式。

此外，資料檔案的結構和資料轉換程式碼的寫法也會影響系統的可擴充套件性。確保資料可以被分割，有助於透過分割槽來分散處理負載。同時，在進行資料轉換時，應注意避免過多的shuffle操作，因為這可能會影響效能。

圖表說明：分散式資料處理流程

圖表翻譯： 此圖展示了分散式資料處理的基本流程。首先，資料被輸入系統；接著，經過篩選步驟去除無關資料；然後，進行分組聚合操作以提取有價值的資訊；最後，將處理結果輸出儲存。

總之，透過結合動態資源調整、分散式處理引擎和高效的系統設計，可以顯著提升資料處理流程的效率和成本效益。隨著資料量的不斷增長，這些策略將變得越來越重要。

縱向擴充套件的重要性與應用

在 Jordan Tigani 那篇引人深思的文章《大資料已死》中，Google Big Query 的創始工程師指出，大多數企業並不需要龐大的資料量。隨著硬體技術的進步，大多數資料工作負載可以集中在一台機器上高效運作。

此外，某些資料工作負載在縱向擴充套件（Vertical Scaling）下表現更佳。例如，當橫向擴充套件（Horizontal Scaling）遇到 Spark shuffle 的問題時，縱向擴充套件可能提供更好的解決方案。如果可以使用廣播連線（Broadcast Join），將一側的小資料儲存在執行器（Executors）上，那麼透過縱向擴充套件增加可用資源將顯著提升效能。

設計可擴充套件的資料處理流程

除了設計可擴充套件的資料處理流程外，還需要考慮資料處理結果的消費者。如果擴充套件資料處理的吞吐量，那麼資料的消費者也需要相應擴充套件，否則資料管道可能會因 I/O 限制而停滯，等待消費者跟上增加的資料量。

在擴充套件資料處理管道時，需要考慮對相關服務（如資料函式庫和 API）的影響。如果擴充套件管道意味著請求的頻率或大小增加，則需要確保在可控範圍內擴充套件相關服務，或為第三方服務構建限流和重試邏輯。

分離儲存與計算

分離儲存與計算有助於在成本和效能方面實作更有效的擴充套件。例如，如果管道寫入資料函式庫，擴充套件管道並增加資料函式庫插入的頻率和大小可能需要升級資料函式庫。在某些情況下，這可能需要停機以增加資料函式庫容量。

相反，如果寫入雲端儲存，則具有更高的頻寬優勢，並且無需同時支付儲存和計算費用。使用雲端儲存支援的資料平台時，只有在存取資料時才需支付計算資源費用。

實作擴充套件計畫

到目前為止，我們已經討論瞭如何識別擴充套件機會以及設計可擴充套件性的建議。在本文中，我們將探討擴充套件的工作原理，這將有助於設計出避免常見陷阱的擴充套件組態。

擴充套件機制

當啟動擴充套件事件時，系統需要時間來觀察擴充套件指標、取得或釋放資源，並在擴充套件容量上重新平衡執行中的程式。一般來說，自動擴充套件（Autoscaling）執行以下步驟：

• 以設定的頻率輪詢擴充套件指標。
• 在觀察視窗內評估指標。
• 如果指標觸發了縮減或擴充套件規則，則啟動擴充套件事件。
• 終止或組態新的資源。
• 在還原輪詢之前等待負載重新平衡，這段時間稱為冷卻期（Cooldown Period）。

圖表翻譯： 此圖示描述了自動擴充套件的基本流程，從輪詢擴充套件指標到啟動擴充套件事件、組態資源，最後到負載重新平衡和還原輪詢，每一步驟都至關重要，以確保系統的平穩執行和資源的有效利用。

這個過程如圖 2-9 所示，描述了一個擴充套件事件的請求和重新平衡時間線。圓圈代表計算資源，資源利用率以圓圈的填充部分表示。工作負載顯示在每個計算資源下方的方框中。時間點之間的差異僅是繪圖的人工產物，並不代表連續階段之間的相對延遲。

縮減與擴充套件的時間差

當工作負載在 t1 時，使用了約 50% 的可用計算容量。到 t2 時，工作負載翻倍，增加了負載。這一增長超過了擴充套件指標，在 t3 時系統觀察到這一指標並請求更多資源。

如同第一章所述，在提出容量請求後，可能需要一些時間才能提供額外的計算資源。額外的容量在 t4 時上線，工作負載在 t5 時重新平衡到額外的計算容量上，完成擴充套件事件。由於具備了處理更大工作負載的能力，資源利用率還原到擴充套件事件前的水平。

縱向擴充套件的實際案例

以 Google Cloud Compute（GCS）使用自動擴充套件來處理高請求率為例，如請求率和存取分佈中所述。該檔案指出，GCS 識別高請求率並增加資源可能需要幾分鐘時間。在此期間，由於高請求率超過了可用容量，回應可能會顯著變慢或失敗。為了避免這一問題，建議使用者逐漸增加請求率，以便 GCS 有時間進行自動擴充套件。

這是一個非常重要的觀點：如果請求量在 GCS 能夠擴充套件之前增加，則可能會發生故障。如果不夠積極地擴充套件以滿足大規模工作負載的需求，您將遇到同樣型別的效能和可靠性問題。

縮減時的運作順序與此相反，如圖 2-10 所示。這種情況從圖 2-9 的結尾處開始，兩個計算容量單位各自執行兩個工作負載單位。到 t2 時工作負載減少，導致其中一個計算單位的資源利用率下降。這觸發了在 t3 時的縮減指標，傳送請求以終止未充分利用的計算容量。

縮減與 HDFS 解除委任的開銷

使用檢查點（Checkpointing）作為資料管道的容錯機制時，將中間結果儲存到雲端而不是叢集磁碟將提高可擴充套件性。特別是在縮減事件中，Hadoop 分散式檔案系統（HDFS）解除委任的開銷可能需要很長時間才能完成，如 Google Dataproc 檔案中所述。

HDFS 解除委任的開銷是雲端服務提供商（CSPs）建議在不使用 HDFS 的節點上擴充套件叢集的原因之一。在 AWS EMR 中，這些節點被稱為任務節點（Task Nodes），而在 Google Cloud Platform（GCP）中則被稱為次要節點（Secondary Nodes）。在本章的後面，我將分享一個涉及 HDFS 的擴充套件策略，您將更詳細地瞭解這個問題。

詳細解說：

1. 輪詢擴充套件指標：系統定期檢查當前的工作負載和資源使用情況，以決定是否需要進行擴充套件。

2. 評估指標：根據設定的規則和閾值，評估當前的工作負載是否超過了現有的資源能力。

3. 啟動擴充套件事件：當檢測到工作負載超過現有資源能力時，系統會啟動擴充套件事件以增加資源。

4. 組態或終止資源：根據需要增加或減少計算資源，以滿足當前的工作負載需求。

5. 等待負載重新平衡：在新增或移除資源後，系統需要一段時間來重新分配工作負載，以確保資源得到有效利用。

透過這種自動化的過程，系統能夠動態地調整資源，以應對不斷變化的工作負載，從而實作高效、可擴充套件的資料處理。

自動擴充套件計畫的實施與常見陷阱

在現代的雲端運算環境中，自動擴充套件（autoscaling）是一項至關重要的功能，它能夠根據工作負載的變化動態調整運算資源，從而實作成本效益和系統效能的最佳化。本章節將探討自動擴充套件計畫的實施細節，並分析其中常見的陷阱以及避免方法。

自動擴充套件的時間軸與運作原理

Figure 2-10 展示了一個縮減運算資源（scale-in）的事件時間軸。在時間點 t4，不同的處理方式會對系統產生不同的影響。其中一種方式是等待節點上的活躍程式完成後再進行終止，例如 YARN 的優雅解除委任（graceful decommissioning）機制。這種方式適合於具有明確結束時間的工作任務。

程式碼範例：YARN 優雅解除委任

// YARN 優雅解除委任範例程式碼
Configuration conf = new Configuration();
conf.set("yarn.resourcemanager.decommissioning.timeout", "300"); // 設定解除委任超時時間
YarnClient yarnClient = YarnClient.createYarnClient();
yarnClient.init(conf);
yarnClient.start();
// 進行節點解除委任
yarnClient.decommissionNodes(Arrays.asList("node1", "node2"));

內容解密：

1. 首先，我們建立了一個 Configuration 物件並設定了解除委任的超時時間。
2. 接著，建立並初始化 YarnClient 物件。
3. 呼叫 decommissionNodes 方法，將指定的節點進行解除委任。

另一種方式則是不等待程式完成，直接移除運算單元。這種情況下，被終止的程式所執行的任務需要被重試，例如在串流處理管線（streaming pipeline）中，可以透過檢查點（checkpointing）機制來重試被終止的工作。

縮減資源事件的時間軸分析

在 Figure 2-10 的 t4 時間點，系統面臨不同的選擇。一方面，可以選擇優雅地解除委任，讓工作任務自然完成。另一方面，也可以直接移除運算單元，由其他剩餘的運算單元接管工作負載。

縮減資源事件流程圖

@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

圖表翻譯： 此圖示呈現了縮減資源事件的流程。首先，系統決定是否要等待程式完成。如果選擇等待，則進行優雅解除委任，讓工作任務自然完成。如果選擇不等待，則直接移除運算單元，並透過檢查點機制重試被終止的工作。

自動擴充套件計畫的常見陷阱

1. 擴充套件門檻過高：將擴充套件門檻設定得過高可能會導致資源無法及時擴充套件，從而影響系統效能和可靠性。
2. 波動（Flapping）：當擴充套件和縮減門檻設定得過於接近，或者觀察視窗過短時，系統可能會頻繁地進行擴充套件和縮減操作，導致資源浪費和系統不穩定。

波動問題的解決方案

Figure 2-12 和 Figure 2-13 展示了波動問題的發生和解決方法。透過增加觀察視窗，可以避免不必要的縮減操作，從而減少資源浪費和系統負擔。

自動擴充套件的挑戰與最佳實踐

在現代雲端運算環境中，自動擴充套件（autoscaling）是確保系統能夠根據需求變化動態調整資源的關鍵技術。然而，實作有效的自動擴充套件並非易事，需要仔細設計和調整擴充套件策略，以避免諸如資源波動（flapping）、過度擴充套件（over-scaling）等問題。

資源波動問題

資源波動是指系統在擴充套件和縮減資源之間頻繁切換的現象，這通常是由於擴充套件和縮減的門檻值設定過於接近所致。例如，當系統的記憶體使用率超過70%時觸發擴充套件，而低於60%時又觸發縮減，如果這兩個門檻值過於接近，系統可能會頻繁地在擴充套件和縮減之間切換，導致資源浪費和管理開銷增加。

解決方案

為瞭解決資源波動問題，可以採取以下措施：

1. 調整擴充套件和縮減的門檻值：將擴充套件和縮減的門檻值設定得更遠離，例如，將縮減門檻值降低到30%，以減少頻繁切換的可能性。

2. 保守縮減，積極擴充套件：這是一種常見的最佳實踐，即在縮減資源時更加保守，而在擴充套件資源時更加積極。這是因為縮減資源通常涉及到解除委任和重新平衡的開銷，而擴充套件資源則能夠更好地滿足效能和可靠性需求。

3. 設定更長的觀察視窗：對於縮減事件，可以設定更長的觀察視窗，以確保系統在縮減資源之前已經穩定了一段時間。

過度擴充套件問題

當擴充套件事件被觸發時，如果沒有給予足夠的時間讓系統負載重新平衡和擴充套件指標更新，可能會導致多個擴充套件事件被連續觸發，從而造成過度擴充套件或資源不足。過度擴充套件會浪費資源，而資源不足則會影響系統的可靠性和效能。

解決方案

1. 設定適當的冷卻期：冷卻期是指在一次擴充套件事件之後，系統需要一段時間來穩定和重新平衡。在這段時間內，不應該觸發新的擴充套件事件。設定適當的冷卻期可以避免連續觸發擴充套件事件。

2. 監控和調整：持續監控系統的表現，並根據需要調整擴充套件策略，包括門檻值、觀察視窗和冷卻期等引數。

自動擴充套件例項分析

以下是一個實際的自動擴充套件案例，展示瞭如何透過基準測試、監控和自動擴充套件規則來節省成本，並解決因擴充套件HDFS（Hadoop分散式檔案系統）所帶來的挑戰。

案例背景

該案例涉及一個在AWS EMR（Amazon Web Services Elastic MapReduce）上執行的資料處理管線，該管線根據需求批次處理資料。資料從雲端儲存讀取，複製到HDFS，然後透過Spark作業進行轉換，最後將轉換後的資料寫回雲端儲存。

面臨的問題

1. BlockMissingException：由於HDFS健康狀況不佳，作業失敗。隨著資料量的增加，這種失敗變得更加頻繁。

2. HDFS擴充套件挑戰：由於小檔案問題和資料複製的開銷，HDFS的擴充套件變得困難。根據HDFS利用率的自動擴充套件規則導致了長時間的擴充套件事件，並進一步加劇了問題。

3. 資源浪費和作業失敗：由於冷卻期設定不足，多個擴充套件事件被連續觸發，導致資源浪費和作業失敗。

解決方案

透過重新設計自動擴充套件策略，包括調整門檻值、觀察視窗和冷卻期等引數，可以有效地解決上述問題。同時，最佳化資料處理管線，例如改善資料複製機制和減少小檔案問題，也可以進一步提高系統的效率和可靠性。

圖表解密：

1. 系統首先進入監控狀態。
2. 當記憶體使用率超過設定的門檻值（例如70%），系統會自動觸發一次擴充套件事件。
3. 隨著資源的增加，系統進入冷卻期，在此期間不會有新的擴充套件或縮減事件被觸發。
4. 冷卻期結束後，系統會重新評估當前的記憶體使用率。
5. 如果記憶體使用率已經下降到足夠低的水平（例如低於30%），系統會觸發縮減事件。
6. 如果記憶體使用率仍然保持在高水平，則會再次觸發擴充套件事件。
7. 這種機制確保了系統能夠根據實際需求動態調整資源，避免資源浪費或不足。