摘要

本文主要探討了數據存儲與成本管理的多種策略。介紹了數據壓縮技術，如MaxCompute的archive壓縮方法，通過RAID file形式存儲數據，可有效節省空間，但恢復時間較長，適用于冷備與日志數據。還詳細闡述了數據生命周期管理策略，包括周期性刪除、徹底刪除、永久保留、極限存儲、冷數據管理以及增量表merge全量表策略，并提出了通用的生命周期管理矩陣，以及數據成本量和數據使用費的概念，旨在優化數據存儲治理，降低成本。

1. 數據壓縮

在分布式文件系統中，為了提高數據的可用性與性能，通常會將數據存儲3份，這就意味著存儲1TB的邏輯數據，實際上會占用3TB的物理空間。目前MaxCompute中提供了archive壓縮方法，它采用了具有更高壓縮比的壓縮算法，可以將數據保存為RAID file的形式，數據不再簡單地保存為3份，而是使用盤古RAID file的默認值（6,3)格式的文件，即6份數據+3份校驗塊的方式，這樣能夠有效地將存儲比約為1：3提高到1：l.5,大約能夠省下一半的物理空間。當然，使用archive壓縮方式也有一定的風險，如果某個數據塊出現了損壞或者某臺機器宕機損壞了，恢復數據塊的時間將要比原來的方式更長，讀的性能會有一定的損失。因此，目前一般將archive壓縮方法應用在冷備數據與日志數據的壓縮存儲上。

例如，一些非常大的淘系日志數據，底層數據超過一定的時間期限后使用的頻率非常低，但是又是屬于不可恢復的重要數據，對于這部分數據就可以考慮對歷史數據的分區進行archive壓縮，使用RAID file來存儲，以此來節省存儲空間。示例如下：

alter table A partition(ds='20130101')archive;

在輸出信息中可以看到archive前后的邏輯存儲(File size)和物理存儲(File physical size)的變化情況，而且在這個過程中會將多個小文件自動合并。

2. 數據重分布

在MaxCompute中主要采用基于列存儲的方式，由于每個表的數據分布不同，插入數據的順序不一樣，會導致壓縮效果有很大的差異，因此通過修改表的數據重分布，避免列熱點，將會節省一定的存儲空間。目前我們主要通過修改distribute by和sort by字段的方法進行數據重分布，如圖14.1所示。

重分布前后一些底層大表的效果對比如表14.2所示。

3. 存儲治理項優化

阿里巴巴數據倉庫在資源管理的過程中，經過不斷地實踐，慢慢摸索出一套適合大數據的存儲優化方法，在元數據的基礎上，診斷、加工成多個存儲治理優化項。目前已有的存儲治理優化項有未管理表、空表、最近62天未訪問表、數據無更新無任務表、數據無更新有任務表、開發庫數據大于100GB且無訪問表、長周期表等。通過對該優化項的數據診斷，形成治理項，治理項通過流程的方式進行運轉、管理，最終推動各個ETL開發人員進行操作，優化存儲管理，并及時回收優化的存儲效果。在這個體系下，形成現狀分析、問題診斷、管理優化、效果反饋的存儲治理項優化的閉環。通過這個閉環，可以有效地推進數據存儲的優化，降低存儲管理的成本。

存儲治理項優化的主要流程如圖14.2所示。

4. 數據生命周期管理

MaxCompute作為阿里巴巴集團的大數據計算及服務引擎，存儲著阿里系大量且非常重要的數據，從數據價值及數據使用性方面綜合考慮，數據的生命周期管理是存儲管理的一項重要手段。生命周期管理的根本目的就是用最少的存儲成本來滿足最大的業務需求，使數據價值最大化。

4.1. 生命周期管理策略

4.1.1. 周期性刪除策略

所存儲的數據都有一定的有效期，從數據創建開始到過時，可以周期性刪除X天前的數據。例如對于MySQL業務庫同步到MaxCompute的全量數據，或者ETL過程產生的結果數據，其中某些歷史數據可能已經沒有價值，且占用存儲成本，那么針對無效的歷史數據就可以進行定期清理。

4.1.2. 徹底刪除策略

無用表數據或者ETL過程產生的臨時數據，以及不需要保留的數據，可以進行及時刪除，包括刪除元數據。

4.1.3. 永久保留策略

重要且不可恢復的底層數據和應用數據需要永久保留。比如底層交易的增量數據，出于存儲成本與數據價值平衡的考慮，需要永久保留，用于歷史數據的恢復與核查。

4.1.4. 極限存儲策略

極限存儲可以超高壓縮重復鏡像數據，通過平臺化配置手段實現透明訪問；缺點是對數據質量要求非常高，配置與維護成本比較高，建議一個分區有超過5GB的鏡像數據（如商品維表、用戶維表）就使用極限存儲。

4.1.5. 冷數據管理策略

冷數據管理是永久保留策略的擴展。永久保留的數據需要遷移到冷數據中心進行永久保存，同時將MaxCompute中對應的數據刪除。一般將重要且不可恢復的、占用存儲空間大于100TB,且訪問頻次較低的數據進行冷備，例如3年以上的日志數據。

4.1.6. 增量表merge全量表策略

對于某些特定的數據，極限存儲在使用性與存儲成本方面的優勢不是很明顯，需要改成增量同步與全量merge的方式，對于對應的delta增量表的保留策略，目前默認保留93天。例如，交易增量數據，使用訂單創建日期或者訂單結束日期作為分區，同時將未完結訂單放在最大分區中，對于存儲，一個訂單在表里只保留一份；對于用戶使用，通過分區條件就能查詢某一段時間的數據。

4.2. 通用的生命周期管理矩陣

隨著業務的發展和不斷的數據實踐，我們慢慢摸索出一套適合大數據生命周期管理的規范，主要通過對歷史數據的等級劃分與對表類型的劃分生成相應的生命周期管理矩陣。

4.2.1. 歷史數據等級劃分

目前我們對歷史數據進行了重要等級的劃分，主要將歷史數據劃分為P0、P1、P2、P3四個等級，其具體定義如下。

1. P0:非常重要的主題域數據和非常重要的應用數據，具有不可恢復性，如交易、日志、集團KPI數據、IPO關聯表。
2. P1:重要的業務數據和重要的應用數據，具有不可恢復性，如重要的業務產品數據。
3. P2:重要的業務數據和重要的應用數據，具有可恢復性，如交易線ETL產生的中間過程數據。
4. P3:不重要的業務數據和不重要的應用數據，具有可恢復性，如某些SNS產品報表。

4.2.2. 表類型劃分

1. 事件型流水表（增量表）

事件型流水表（增量表）指數據無重復或者無主鍵數據，如日志。

1. 事件型鏡像表（增量表)

事件型鏡像表（增量表)指業務過程性數據，有主鍵，但是對于同樣主鍵的屬性會發生緩慢變化，如交易、訂單狀態與時間會根據業務發生變更。

1. 維表

維表包括維度與維度屬性數據，如用戶表、商品表。

1. Merge全量表

Merge全量表包括業務過程性數據或者維表數據。由于數據本身有新增的或者發生狀態變更，對于同樣主鍵的數據可能會保留多份，因此可以對這些數據根據主鍵進行Merge操作，主鍵對應的屬性只會保留最新狀態，歷史狀態保留在前一天分區中。例如，用戶表、交易表等都可以進行Merge操作。

1. ETL臨時表

ETL臨時表是指ETL處理過程中產生的臨時表數據，一般不建議保留，最多7天。

1. TT臨時數據

TT拉取的數據和DbSync產生的臨時數據最終會流轉到ODS層，ODS層數據作為原始數據保留下來，從而使得TT&DbSync上游數據成為臨時數據。這類數據不建議保留很長時間，生命周期默認設置為93天，可以根據實際情況適當減少保留天數。

1. 普通全量表

很多小業務數據或者產品數據，BI一般是直接全量拉取，這種方式效率快，對存儲壓力也不是很大，而且表保留很長時間，可以根據歷史數據等級確定保留策略。

通過上述歷史數據等級劃分與表類型劃分，生成相應的生命周期管理矩陣，如表14.3所示。

MaxCompute集群中海量數據的存儲和大量計算任務每天都會消耗巨額成本，并且隨著數據量的不斷增長，這個成本還在逐步增加。如何在服務好業務的前提下，更好地管控數據成本，提升資源利用率，已成為數據資產管理工作中非常重要的一環。

在阿里巴巴集團內部，大部分數據都會存儲在MaxCompute集群上，數據以數據表的形式存在，并且數據表之間存在比較復雜的關聯和上下游依賴關系。可以把數據表之間的依賴關系用樹形結構形象化地表示，如圖14.3所示。圖中的A、B、C等代表不同的數據表，帶箭頭的連線代表數據表之間的依賴和關聯關系。比如數據表B、C、D都依賴數據表A,數據表E依賴數據表B和C。

MaxCompute中的任何一個計算任務都會涉及計算和存儲資源的消耗，其中計算資源的消耗主要考慮CPU消耗。為了下面更好地描述數據計量計費的算法和規則，特做如下定義：CPU消耗的單位定義為CU,代表CPU的一個核心(Core)運行一天的消耗量。存儲資源的消耗主要考慮磁盤存儲的消耗，這里采用國際通用的存儲單位PB來衡量。例如：計算資源的單價為1元/CU,存儲資源的單價為1元/PB天。

4.3. 數據成本量

對數據成本的計量，可以采用最簡單的方式，將一個數據表的成本分為存儲成本和計算成本。存儲成本是為了計量數據表消耗的存儲資源，計算成本是為了計量數據計算過程中的CPU消耗。但是，對這樣的數據成本計量方式會存在較大的質疑和挑戰。例如，如圖14.4所示，表D是業務方的一個數據表，表D依賴表C,但是為了產生表C,往往上面存在一個較長的數據刷新鏈路。表C的成本可能是10元，但是表A、B可能會是100元。像這樣的情況，如果表C的成本僅僅用數據表C自身的存儲和計算成本衡量顯然是不合理、不準確的。

因此，在計量數據表的成本時，除考慮數據表本身的計算成本、存儲成本外，還要考慮對上游數據表的掃描帶來的掃描成本。我們將數據成本定義為存儲成本、計算成本和掃描成本三個部分。

通過在數據成本計量中引入掃描成本的概念，可以避免僅僅將表自身硬件資源的消耗作為數據表的成本，以及對數據表成本進行分析時，孤立地分析單獨的一個數據表，能夠很好地體現出數據在加工鏈路中的上下游依賴關系，使得成本的評估盡量準確、公平、合理。

4.4. 數據使用費

在上一節中，已經清楚地將數據成本分為：存儲成本、計算成本和掃描成本。那么對于數據表的使用計費，在阿里巴巴集團內部，分別依據這三部分成本進行收費，稱為：計算付費、存儲付費和掃描付費。

我們把數據資產的成本管理分為數據成本計量和數據使用計費兩個步驟。通過成本計量，可以比較合理地評估出數據加工鏈路中的成本，從成本的角度反映出在數據加工鏈路中是否存在加工復雜、鏈路過長依賴不合理等問題，間接輔助數據模型優化，提升數據整合效率；通過數據使用計費，可以規范下游用戶的數據使用方法，提升數據使用效率，從而為業務提供優質的數據服務。

博文參考

《阿里巴巴大數據實戰》