大數據：存儲和成本管理

• 數據存儲和成本管理：

  • 有效的降低存儲資源的消耗，節省存儲成本，是存儲管理孜孜追求的目標；
  • 一般從 4 個方面優化存儲：數據壓縮、數據重分布、存儲治理項優化、生命周期管理；

一、數據壓縮

• 實際中的數據存儲情況：在其它分布式計算系統中，為了提高數據的可用性和性能，通常會將數據存儲 3 份；這就意味着存儲 1 TB 的邏輯數據，實際上占用了 3 TB的物理空間；

 

• MaxCompute 提供了 archive 壓縮法：

  • 采用了更高效壓縮比的壓縮算法，可以將數據保存為 RAID file 的形式，數據不再是簡單的 3 份，而是使用盤古 RAID file 的默認值（6, 3）格式的文件，即 “6 份數據 + 3 份校驗塊” 的方式；將存儲比約為 1:3 提升到 1:1.5，大約能夠節省一半的物理空間；

  • archive 壓縮法存在的風險：

    • 如果數據損壞，恢復數據的時間更長；而且讀的性能會有一定損失；
    • 如果某個數據塊出現了損壞或者某台機器宕機（dang 機，down 機，死機的意思）損壞了，恢復數據塊的時間將要比原來的方式更長；

  • archive 壓縮法的使用：

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

        • archive table A partition(ds = '20200101') archive;

      • 輸出信息如下表：
        • 
      • 從輸出信息可以看到， archive 的前后的邏輯存儲（File size）和物理存儲（File physical size）的變化情況，在這個過程中有將多個小文件自動合並；

 

 

二、數據重分布

• 背景 / 數據壓縮過程中的問題：

  • 在 MaxCompute 中主要采用基於列存儲的方式，由於每個表的數據分布不同，插入數據的順序不一樣，會導致壓縮效果有很大的差異；
    • 數據分布情況主要跟重復值、字段本身的大小、其它字段的具體分布；

• 解決思路：

  • 通過修改表的數據重分布，避免列熱點，進而改善壓縮效果，節省一定的存儲空間；
    • 思考：為什么熱點列會影響數據的壓縮？（應該跟壓縮算法和壓縮后的數據的格式有關）

 

• 數據重分布的方法：

  • 主要通過修改 distribute by 和 sort by 字段的方法進行數據重分布；
  • 

 

• 哪些數據需要重分布：

  • 數據重分布的效果：主要跟數據表中的重復值、字段本身的大小、其它字段的具體分布有一定的關系；
  • 一般會篩選出重分布效果低於 15% 的表進行優化處理；
    • 重分布效果：數據重分布后節約的空間比例；
    • 重分布后，一些底層大表的效果對比：
      • 

  

 

三、存儲治理項優化

• 阿里內部的大數據優化方法：

  1. 存儲治理優化項

     • 在元數據的基礎上，診斷、加工成多個存儲治理優化項；
     • 目前已有的存儲治理優化項：
       • 未管理表、空表、最近 62 天未訪問表、數據無更新無任務表、數據無更新有任務表、開發庫數據大於 100 GB 且無訪問表、長周期表等；

  2. 治理項

     • 通過對優化項的數據診斷，形成治理項；
       • 治理項通過流程的方式進行運轉、管理，最終推動各個 ETL 開發人員進行操作，優化存儲管理，並及時回收優化的存儲效果（也就是回收節省出的內存）；

 

• 存儲治理項優化的閉環：

  • 通過上述的存儲治理優化體系，形成現狀分析、問題診斷、管理優化、效果反饋的存儲治理項優化的閉環；（如下圖）
  • 通過這個閉環，可以有效的推進數據存儲的優化，降低存儲管理的成本；

• 

 

 

四、生命周期管理

• 從數據價值及數據時間實用性方面綜合考慮，數據的生命周期管理是存儲管理的一項重要手段；

• 數據生命周期管理的根本目的：用最少的存儲成本滿足最大的業務需求，使數據價值最大化；

1、生命周期管理策略

　1/1）周期性刪除策略

• 所存儲的數據有一定的有效期，從數據創建到過時，可以周期性刪除 N 天前的數據；
  • 如，MySQL 業務庫同步到 MaxCompute 的全量數據、ETL 過程產生的結構數據，其中某些數據可能已經沒有價值，且占用存儲成本，那么針對無效的歷史數據可以定期清理；

 

　1/2）徹底刪除策略

• 無用表數據、 ETL 過程產生的臨時數據、不需要保留的數據，要及時刪除，包括刪除元數據；

 

　1/3）永久保留數據

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

 

　1/4）極限存儲策略

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

 

　1/5）冷數據管理策略

• 冷數據管理策略是永久保留策略的擴展；

• 永久保留的數據需要遷移到冷數據中心進行永久保存，同時將 MaxCompute 中對應的數據刪除；

• 冷數據：重要且不可恢復的、占用存儲空間大於 100 TB，且訪問頻次較低的數據；
  • 如，3 年以上的日志數據；

 

　1/6）增量表、 merge 全量表策略

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

 

2、通用的生命周期管矩陣

• 阿里的生命周期管理規范：

  • 通過對歷史數據的等級划分與對表類型的划分生成相應的生命周期管理矩陣；
    • 生命周期管理矩陣：將具體的規則整體匯集成的一種表格；

　2/1）歷史數據等級划分

• 根據歷史數據的重要程度，一共划分了 P0、P1、P2、P3 四個等級：
  1. P0：非常重要的主題數據域數據和非常重要的應用數據；具有不可恢復性；
     • 如，交易、日志、集團 KPI 數據、IPO 關聯表；
  2. P1：重要的業務數據和重要的應用數據；具有不可恢復性；
     • 如，重要的業務產品數據；
  3. P2：重要的業務數據和重要的應用數據；具有可恢復性；
     • 如，交易線 ETL 產生的中間過程數據；
  4. P3：不重要的業務數據和不重要的應用數據，具有可恢復性；
     • 如，某些 SNS 產品報表；

 

　2/2）表類型划分

1. 事件型流水表（增量表）
   • 事件型流水表：指數據無重復或者無主鍵數據；（如，日志）
2. 事件型鏡像表（增量表）
   • 事件型鏡像表：指業務過程性數據，有主鍵，但是對於同樣主鍵的屬性會發生緩慢變化；
     • 如，交易、訂單狀態與時間會根據業務發生變更；
3. 維表
   • 維表：包括維度和維度屬性數據；
     • 如，用戶表、商品表；
4. Merge 全量表
   • Merge 全量表：包括業務過程性數據或者維表數據；
     • 由於數據本身有新增的或者發生狀態變更，對於同樣主鍵的數據可能會保留多份，因此可以對這些數據根據主鍵進行 Merge 操作，主鍵對應的屬性只會保留最新狀態，歷史狀態保留在前一天分區中；
     • 如，用戶表、交易表等都可以進行 Merge 操作；
5. ETL 臨時表
   • ETL 臨時表指 ETL 處理過程中產生的臨時數據，一般不建議保留，最多 7 天；
6. TT 臨時數據
   • TT 臨時數據：TT 拉取的數據和 DbSync 產生的臨時數據最終會流轉到 ODS 層，ODS 層數據作為原始數據保留下來，從而使得 TT& DBSync 上游數據成為臨時數據；
     • 這類數據不建議保留很長時間，生命周期默認設置為 93 天，可以根據實際情況適當減少保留天數；
7. 普通全量表
   • 很多小業務數據或者產品數據，BI 一般是直接全量拉取，這種方式效率快，對存儲壓力也不是很大，而且表保留很長時間，可以根據歷史數據等級確定保留策略；

 

　2/3）生命周期管理矩陣

• 根據歷史數據等級划分和表類型划分，生成相應的生命周期管理矩陣，如下表：

  • 
  • 

 

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

 

• 在阿里內部，大部分的數據都存儲在 MaxCompute 集群上，數據以數據表的形式存在，並且數據表之間存在比較復雜的關聯和上下游依賴關系；
  • 可以把表之間的依賴關系用樹形結構形象化的標示，如下圖：
    • 
      • A、B、C等代表不同的數據表，箭頭的連線代表數據之間的依賴和關聯關系；
        • 如，數據表B、C、D 都依賴數據表 A；
        • 如，數據表 E 依賴數據表 B 和 C；

 

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

 

 

五、數據成本計算

• 數據成本計算主要是計算數據表的存儲成本、計算成本、掃描成本：

  • 存儲成本是為了計算數據表消耗的存儲資源；
  • 計算成本是為了計算數據計算過程中的 CPU 消耗；
  • 掃描成本是指對上游數據表的掃描帶來的掃描成本；

 

• 對上游數據表掃描：

  • 例：如下圖：
    • 表 D 是業務方的一個數據表，表 D 依賴表 C，但是為了產生表 C，往往上面存在一個較長的數據刷新鏈路；表 C 的成本可能是 10 元，但是表 A、B 可能會是 100 元；像這樣的情況，如果表 C 的成本僅僅用數據表 C 自身的存儲和計算成本衡量是不合理、不准確的；（因為確定表 C 的時候，必須掃描表 B 才能確認）
    • 

 

• 通過在數據成本計算中引入掃描成本的概念：

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

 

 

六、數據使用計費

• 數據表的使用計費：

  • 分別依據數據的存儲、計算、掃描三部分成本進行收費，稱為：計算付費、存儲付費、掃描付費；

 

• 數據資產的成本管理：數據成本計算、數據使用計費；

  • 數據成本計算，可以比較合理的評估出數據加工鏈路中的成本，從成本的角度反映出在數據加工鏈路中是否存在加工復雜、鏈路過長、依賴不合理等問題，間接輔助數據模型優化，提升數據整合效率；
  • 數據使用計費，可以規范下游用戶的數據使用方法，提升數據使用效率，從而為業務提升優質的數據服務；