雲端儲存成本最佳化實務

雲端儲存成本最佳化已成為企業上雲後的重點課題。除了儲存空間費用，資料傳輸、存取操作、小檔案問題等都會顯著影響整體成本。本文將探討如何透過資料管線設計、生命週期管理、資料分割槽與壓縮等策略，有效降低雲端儲存開銷。同時，文章也將分析不同儲存類別的特性，並提供實務上的程式碼範例和圖表說明，協助讀者制定最佳的成本控制方案。

雲端儲存的最佳實踐

將資料儲存在雲端與整理衣櫃有相似之處。有些人會根據季節、形狀或顏色整理衣物，使尋找特定物品變得容易；而有些人則可能放棄整理，將衣物亂丟在衣櫃裡，需要時再進行搜尋。

雲端儲存的挑戰

雲端儲存也面臨著類別似的問題。如果資料沒有得到良好的組織和管理，可能會導致成本增加和效能下降。

瞭解儲存成本

在開始討論成本削減策略之前，首先需要了解儲存成本是如何累積的。除了雲端賬單上的直接成本外，工程團隊在管理和維護資料上投入的時間和資源也是一種間接成本。

成本削減策略

本章將重點介紹如何使用雲端服務提供商（CSP）提供的服務來組織和維護雲端儲存，並在適當的時候犧牲一些效能以換取更低的成本。

分離儲存與計算

將儲存與計算分離可以提高管線的可擴充套件性，並降低成本。HDFS 的擴充套件性不佳，因為其解除委任（decommissioning）時間較長；此外，資料函式庫將儲存和計算耦合在一起，需要同時擴充套件兩者。分離儲存和計算可以讓你利用雲端儲存更快的頻寬，並消除與資料函式庫相關的計算成本。

自動調整資源分配

自動調整資源分配需要謹慎規劃，以確保在新增或移除資源時能夠保持效能和可靠性。

雲端儲存成本最佳化：資料管線設計與實務考量

在雲端運算時代，資料儲存和管理成為企業的重要課題。資料管線（Data Pipeline）的設計不僅影響資料處理的效率，也直接關係到雲端儲存的成本。本文將探討雲端儲存成本的構成要素，並提供實務上的最佳化建議。

雲端儲存成本的三大主因

1. 儲存資料量：存放於雲端的資料總量
2. 資料傳輸量：資料在不同區域或系統間的傳輸
3. 操作次數：對雲端儲存物件的讀取、寫入、刪除等操作

靜態儲存成本與資料管理

企業在雲端儲存大量資料用於多種目的，包括原始資料儲存、中間處理結果、歷史資料備份、開發測試資料以及管線操作日誌等。由於雲端儲存的使用門檻低，容易導致資料無限制累積，進而增加儲存成本。

最佳實踐：計算與儲存分離

將計算與儲存分離是最佳化成本與效能的常見策略。例如，將原本儲存在資料函式庫中的大量歷史資料移至雲端儲存，不僅降低了資料函式庫的負擔，也節省了擴充資料函式庫資源的成本。

資料傳輸成本（Egress）與最佳化

將資料存入雲端儲存通常是免費的，但讀取或傳輸資料則會產生額外費用。跨區域傳輸資料的成本尤其高昂。以AWS S3為例，將10 TB的資料傳輸到另一個區域的費用，相當於四個月的基本儲存成本。

降低Egress成本的方法

1. 在同區域處理資料：盡量在資料儲存的同一區域進行處理，以避免跨區域傳輸費用。
2. 合併備份與容錯移轉資料：減少跨區域資料複製的需求。
3. 使用Delta Export：僅傳輸變更的資料，而非每次都傳輸完整資料集。
4. 請求者付費模式：利用AWS S3和GCS的請求者付費功能，將傳輸成本轉嫁給使用者。
5. 壓縮資料：壓縮可以減少儲存和傳輸的成本，但需注意解壓縮時的額外費用。

資料存取成本與小檔案問題

每次對雲端儲存物件的操作（如PUT、GET、LIST、DELETE）都會產生費用。雖然單次操作的費用不高，但頻繁的操作會累積成可觀的成本。

小檔案問題的成因與影響

1. 來源：串流管線在低流量時段或批次處理小量輸入資料時容易產生小檔案。
2. 影響：大量的小檔案會增加存取操作的次數，不僅提高成本，也會影響系統效能和可靠性。

解決方案

1. 檔案合併：定期將小檔案合併成較大的檔案，以減少操作次數。
2. 最佳化管線設計：在管線設計階段考慮檔案大小和數量，避免小檔案問題。

此圖示說明瞭雲端儲存成本的主要構成及其最佳化途徑

雲端儲存組織與成本最佳化

在前面的章節中，我們已經討論了小檔案問題如何影響雲端儲存成本和大資料處理效能。現在，我們將探討如何透過適當的雲端儲存組織來降低成本並提高效率。

儲存桶策略

組織雲端儲存的第一步是定義適合應用程式的儲存桶（bucket）。一種常見的方法是根據功能和環境建立儲存桶。例如，假設有三種型別的資料需要儲存：日誌、原始資料和處理後的資料，並且有兩個環境（測試和生產），那麼最終會得到六個不同的儲存桶：logs-test、logs-prod、raw-data-test、raw-data-prod、processed-data-test和processed-data-prod。

標籤與標記

在建立儲存桶時，考慮新增標籤（tags）和標記（labels）以幫助跟蹤資源和成本，就像在第一章中描述的那樣，用於計算資源。需要注意的是，其中一些服務可能會產生額外的成本，例如GCS（Google Cloud Storage）儲存桶標籤。

標籤和標記的粒度與報告和許可權的細分程度相關。如果想要檢視原始資料的成本，可以為每個原始資料儲存桶新增一個標籤。如果想要按環境檢視原始資料成本，則需要為每個儲存桶新增另一個表示環境的標籤。在較大的組織中，按部門檢視成本也是可取的，這可以是另一個標籤。

版本控制

考慮的另一個重要事項是版本控制（versioning），它可以在事情出錯時真正挽救局面。啟用版本控制後，每次寫入儲存位置時，都會建立一個新的物件。一個指標會跟蹤最新版本，因此從資料消費者的角度來看，似乎舊版本已被替換。

版本控制的好處

版本控制在處理根據時間戳記儲存的時間序列資料時特別有用，例如按字首YYYY-MM-DD儲存。在作業重新執行或回填的情況下，將使用相同的字首來儲存新資料。

在之前的專案中，我們使用版本控制建立了一個失敗資料攝取的還原機制。如果最新的攝取建立了錯誤的資料，我們的團隊可以快速回復到最後一個已知良好的狀態，因為版本控制使我們能夠存取先前的資料。Azure Blob Storage的檔案中有對物件版本控制和回復機制的詳細描述。

版本控制的成本

版本控制是一個強大的工具，但它可能會帶來成本。根據FinOps基金會的例子，一家公司在開發人員意識到陳舊的物件版本未被刪除後，將其儲存成本降低了60%。

此圖示說明瞭雲端儲存組織的主要組成部分，包括儲存桶策略和版本控制，以及它們之間的關係。圖中展示瞭如何透過適當的儲存桶策略和版本控制來最佳化雲端儲存資源。

雲端儲存組織的最佳實踐

自動化成本文約策略

為了充分利用雲端儲存的功能，組織應該考慮自動化成本文約策略。這可以包括自動刪除陳舊的物件版本、最佳化儲存桶組態等。

持續監控與最佳化

持續監控雲端儲存的使用情況和成本，並根據需要進行最佳化，是保持高效雲端儲存管理的關鍵。

自動化與監控的結合

結合自動化和持續監控，可以幫助組織實作最佳的雲端儲存管理，並降低成本。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 雲端儲存成本最佳化實務

package "資料視覺化流程" {
    package "資料準備" {
        component [資料載入] as load
        component [資料清洗] as clean
        component [資料轉換] as transform
    }

    package "圖表類型" {
        component [折線圖 Line] as line
        component [長條圖 Bar] as bar
        component [散佈圖 Scatter] as scatter
        component [熱力圖 Heatmap] as heatmap
    }

    package "美化輸出" {
        component [樣式設定] as style
        component [標籤註解] as label
        component [匯出儲存] as export
    }
}

load --> clean --> transform
transform --> line
transform --> bar
transform --> scatter
transform --> heatmap
line --> style --> export
bar --> label --> export

note right of scatter
  探索變數關係
  發現異常值
end note

@enduml

此圖示展示了自動化成本文約策略、持續監控與最佳化之間的關係，以及它們如何結合起來實作最佳的雲端儲存管理。圖中說明瞭如何透過自動化和監控來降低成本並提高效率。

雲端儲存組織與生命週期管理

在雲端儲存的資料管理中，生命週期管理（Lifecycle Management）扮演著至關重要的角色。透過在儲存桶（Bucket）或字首（Prefix）層級應用生命週期組態，可以有效控制物件的過期、儲存類別等屬性，從而最佳化儲存成本。

生命週期組態

生命週期組態能夠自動刪除物件或將其轉移到成本較低的儲存類別，幫助控制成本。以不同資料儲存桶為例，可以根據功能和環境應用不同的生命週期策略。下表展示了一個可能的生命週期組態和版本控制策略。

表：範例儲存桶的版本控制與過期生命週期

| 儲存桶名稱 | 版本控制 | 過期時間 | |

-|

|

| | logs-test | 否 | 7天 | | logs-prod | 否 | 30天 | | raw-data-test | 否 | 7天 | | raw-data-prod | 否 | 30天 | | processed-data-test| 否 | 7天 | | processed-data-prod| 是 | 365天 |

從表中可以看出，僅 processed-data-prod 啟用了版本控制。假設資料處理流程會覆寫 processed-data-prod 中的現有物件。對於測試環境，由於不需要版本控制，如果資料處理流程產生錯誤資料，可以重新執行測試。

測試環境中的儲存桶設定為7天後過期，過期的物件將被刪除，以降低儲存成本。生產環境中的儲存桶則有較長的過期時間，例如日誌和原始資料為30天，處理後的資料為一年，以滿足更長的資料保留需求。這些保留期限取決於需要提供給使用者的資料量、法規要求以及用於除錯、監控和分析的資料量。

內容解密：

1. 版本控制：啟用版本控制可以保留物件的多個版本，有助於資料還原和稽核。
2. 過期時間：設定合理的過期時間可以自動清理無用的資料，降低儲存成本。
3. 生產與測試環境區別：生產環境通常需要更長的資料保留期限，以滿足業務和法規需求。

儲存類別轉換

儲存類別是另一個可以透過生命週期策略控制的物件屬性。儲存類別指的是物件所處的服務層級，從高效能的「熱」層到效能較低的「冷」層。熱層適合活躍使用的物件，而冷層則以較低的成本儲存資料，但存取延遲較高。

表：從熱儲存到過期的生命週期組態

| 資料儲存時間（天） | 儲存類別 | |

-|

| | 0 | 熱 | | 90 | 暖 | | 180 | 冷 | | 365 | 過期 |

在上述組態中，processed-data-prod 中的物件最初儲存在高效能的熱儲存中，90天后轉移到暖儲存，180天后轉移到冷儲存，最終在一年後過期。

內容解密：

1. 熱儲存：適合頻繁存取的資料，提供高效能。
2. 暖儲存與冷儲存：隨著資料儲存時間的增加，將其轉移到成本更低的儲存類別，可以有效降低成本。
3. 過期處理：最終過期的資料將被刪除，避免無限期的儲存成本。

清理失敗的多部分上傳

另一個節省成本的生命週期策略是清理失敗的多部分上傳。在處理大檔案（大於100 MB）時，多部分上傳是一種克服暫時性網路問題的有效方法，但失敗的上傳會在雲端儲存中積累物件。透過生命週期策略自動清理這些失敗的上傳，可以保持儲存空間的整潔。

檔案結構設計

雲端儲存組織和生命週期組態是資料管道成本有效的基礎。在此基礎上，如何在雲端儲存中組織資料至關重要。檔案格式的選擇、壓縮和分割槽策略都能顯著影響資料處理的效率和成本。

檔案格式

欄位式檔案格式（如Parquet和ORC）能夠在儲存和計算兩方面降低成本。在儲存方面，這些格式提供了比平面檔案（如JSON或CSV）更好的壓縮效果。在計算方面，能夠修剪不需要的欄位，減少資料處理開銷。

程式碼範例：使用Parquet格式儲存資料

import pandas as pd

# 建立DataFrame
data = {'name': ['Alice', 'Bob', 'Charlie'], 'age': [25, 30, 35]}
df = pd.DataFrame(data)

# 將DataFrame儲存為Parquet檔案
df.to_parquet('data.parquet', index=False)

內容解密：

1. 欄位式檔案格式：如Parquet和ORC，具有更好的壓縮效果和欄位修剪能力。
2. 壓縮效果：相比JSON或CSV，欄位式格式能顯著減少儲存空間。
3. 計算效率：能夠減少資料處理開銷，提高查詢效率。

分割槽策略

分割槽是指將一大塊資料按照某個共同的元素（分割槽鍵）分成更小的部分。這種技術可以提高資源利用效率，特別是在查詢時能夠根據查詢引數過濾掉無關資料，從而提升效能。

程式碼範例：使用分割槽儲存資料

import pandas as pd

# 建立分割槽DataFrame
data = {'date': ['2023-01-01', '2023-01-02', '2023-01-03'], 'value': [10, 20, 30]}
df = pd.DataFrame(data)

# 按日期分割槽儲存
df.to_parquet('data_partitioned', partition_cols=['date'], index=False)

內容解密：

1. 分割槽鍵：選擇合適的分割槽鍵能夠有效組織資料。
2. 查詢效率：分割槽能夠顯著提高查詢效率，特別是在處理大規模資料時。
3. 資源利用：分割槽有助於更有效地利用資源，降低查詢成本。

綜上所述，合理的雲端儲存組織、生命週期管理和檔案結構設計能夠顯著最佳化資料管道的成本和效率。透過選擇合適的檔案格式、壓縮方法和分割槽策略，可以進一步提升資料處理的效能和可擴充套件性。

資料分割槽與雲端儲存最佳化

在設計資料處理流程時，資料分割槽（Data Partitioning）是影響效能的關鍵因素之一。適當的分割槽策略能夠最佳化查詢效能，降低成本，並提升整體資料處理效率。

資料分割槽策略

1. 適度分割槽：過多的分割槽鍵（Partition Keys）會導致資料被切得過於細碎，反而影響效能。
2. 選擇合適的分割槽鍵：應選擇查詢篩選條件中常用的欄位，並且具備低基數（Low Cardinality）的特性，以避免產生過多的小檔案。
3. 監控查詢效能：持續觀察查詢模式和效能，找出最佳化機會。

例如，在處理鳥類別遷徙資料時，若大多數查詢是根據月份來篩選觀測資料（如「五月到七月觀察到的夜鷺數量」），則可採用日期為基礎的分割槽策略。這樣一來，不相關的分割槽（如其他月份的資料）便可被忽略，從而提升查詢效率。

在選擇分割槽粒度（Partition Granularity）時，應找到一個適當的平衡點，既能將資料分成較小的區塊，又不會導致小檔案問題（Small-Files Problem）。例如，若鳥類別調查資料在平日很少有觀測記錄，那麼按天分割槽會導致大多數分割槽的資料量極少，此時可改為按月分割槽，以聚合資料並獲得更合理的查詢粒度。

資料壓縮與最佳化

1. 資料合併（Compaction）：將多個小檔案合併為較大的檔案，是解決小檔案問題的常見方法。
2. 使用支援合併的表格格式：現代的表格格式，如 Delta Lake 和 Apache Iceberg，均支援自動或手動的資料合併功能。
3. 排程合併任務：可設定定期的任務來執行資料合併和重新分割槽，以保持查詢效能。

經濟有效的資料管線基礎

在前幾章中，您已經瞭解如何設計雲端運算和儲存解決方案，在整體產品目標下實作適當的成本與效能權衡。這為您建立具成本效益的設計奠定了堅實的基礎。

下一步是設計和實作可有效擴充套件的資料管線，透過明智地利用工程和運算資源來限制浪費，並盡量減少資料停機時間。此過程的第一部分涉及一些基本的資料管線設計策略：冪等性、檢查點、自動重試和資料驗證。

在本章中，您將看到常見的資料管線問題，以及如何使用這四種策略來緩解這些問題。與其只是定義冪等性、檢查點、重試和資料驗證，不如舉例說明如何在批次和串流環境中實作這些策略，並討論您將遇到的一些權衡。您還將看到這些策略（或缺乏這些策略）如何導致現實世界中的管線故障和成功。

冪等性

首先要從設計管線的冪等性開始。冪等性意味著您可以對相同的來源資料重複執行管線，並且結果將完全相同。這本身具有好處，也是實作重試的先決條件，如本章後面所述。

防止資料重複

冪等性的定義可能會根據管線輸出的使用方式而有所不同。思考冪等性的一種方式是，如果管線多次使用相同的來源資料執行，則不會出現重複資料。

例如，考慮一個管線，它透過迴圈遍歷資料集並將每一行插入資料函式庫來將資料插入資料函式庫。如果發生錯誤，例如網路閃斷中斷了與資料函式庫的連線，您將無法判斷哪些資料已寫入資料函式庫，哪些尚未寫入。如果從此狀態重試，管線可能會建立重複資料。

要使此過程具有冪等性，您可以將資料函式庫插入包裝在事務中，確保如果任何插入失敗，任何先前的插入都將回復。這消除了部分寫入的可能性。

您還可以構建拒絕重複資料的資料接收器。如果您可以為攝入的資料建立唯一鍵，您可以檢測到重複的條目並決定如何處理它們。在這種情況下，您需要絕對確定您提出的鍵是真正唯一的，例如自然鍵。請記住，唯一約束可能會減慢插入速度，因為資料函式庫需要驗證鍵是否唯一並更新索引。

在列式資料函式庫和資料湖中，您可以透過雜湊強制唯一性，如果雜湊與現有資料比對，則防止更新和插入。一些資料湖支援合併鍵，例如Delta Lake合併，您可以在其中指定唯一鍵和處理比對的指令。

減少資料重複將透過限制您的儲存足跡來降低成本。根據資料的使用方式，這也可以節省運算費用。

在處理雲端儲存時，您可以使用覆寫方法，也稱為刪除-寫入。考慮一個每天執行一次的管線，將資料寫出到以當前日期命名的資料夾。在寫出資料之前，管線可以檢查當前日期資料夾中是否已存在任何資料。如果是，則刪除資料，然後寫入新資料。這可以防止部分資料攝入以及重複資料。

對於串流過程，您可以透過唯一訊息識別實作冪等性。您可以透過設定資料生產者來建立相同的ID，當遇到相同的資料時。在消費者端，您可以保留已處理的訊息ID記錄，以防止重複訊息被攝入。

特別是對於串流或長時間執行的過程，請考慮維護您需要的資訊的可持久記錄，以確保冪等性。例如，Kafka維護了一個已處理的偏移記錄，使消費者能夠在正確的位置重新啟動。

檢查點

檢查點是另一種確保資料管線可靠性的策略。檢查點涉及定期儲存管線的狀態，以便在發生故障時可以從最近的檢查點還原，而不是從頭開始重新啟動。

實作檢查點

要實作檢查點，您需要確定管線中適合儲存狀態的位置。這可能是在處理了一定量的資料之後，或者是在特定的時間間隔之後。

一旦您確定了檢查點的位置，您就需要決定如何儲存狀態。這可能涉及將狀態寫入持久儲存，例如資料函式庫或檔案系統，或者使用專門為此目的設計的系統，例如Kafka的偏移管理。

檢查點的一個關鍵好處是，它允許管線從故障中快速還原，而無需從頭開始重新啟動。這可以大大減少停機時間並提高整體效率。

自動重試

自動重試是另一種提高資料管線可靠性的策略。當發生暫時性錯誤（例如網路故障）時，重試機制可以自動重新執行失敗的操作。

實作自動重試

要實作自動重試，您需要確定可能發生暫時性錯誤的位置，並組態重試機制來處理這些錯誤。這可能涉及設定最大重試次數、重試之間的延遲等引數。

自動重試的一個關鍵好處是，它可以減少手動干預的需求並提高整體效率。然而，它也需要仔細組態，以避免無限重試迴圈或其他問題。

資料驗證

最後，資料驗證是確保資料管線可靠性的另一個重要方面。資料驗證涉及檢查資料是否符合預期的格式、結構和內容。

實作資料驗證

要實作資料驗證，您需要在管線中加入檢查和驗證機制，以確保輸入和輸出的資料符合預期的標準。這可能涉及使用schema驗證、資料品品檢查或其他技術。