如何讓HDFS更高效之利用數據冷熱度篇

主題簡介：

1. HDFS優化存儲功能講解
2. SSM系統架構設計
3. SSM系統應用場景分析

1、背景

隨着大數據技術相關技術的發展和普及，愈來愈多的公司開始使用基於開源Hadoop的平臺系統，同時，愈來愈多的業務和應用也在從傳統的技術架構遷移到大數據平臺上。在典型的Hadoop大數據平臺中，人們使用HDFS做爲存儲服務的核心。

而在大數據發展之初，最主要的應用場景仍然是離線批處理場景，對存儲的需求追求的是吞吐量，HDFS正是針對這樣的場景而設計的，而隨着技術不斷的發展，愈來愈多的場景會對存儲提出新的需求，HDFS也面臨着新的挑戰。主要包括幾個方面：

一、數據量問題

一方面隨着業務的增加和新的應用接入，會給HDFS帶來更多的數據，另外一方面隨着深度學習，人工智能等技術的發展，用戶一般但願能保存更長時間的數據，以提高深度學習的效果。數據量的快速增長會使集羣不斷面臨擴容需求，從而致使存儲成本不斷增長。

二、小文件問題

衆所周知，HDFS的設計是針對離線批處理大文件的，處理小文件並不是傳統HDFS擅長的場景。HDFS小文件問題的根源在於文件的元數據信息都是維護在單點Namenode的內存中，單臺機器的內存空間始終是有限的。據估算，單臺namenode集羣能容納系統文件數量極限大約在1.5億左右。實際上，HDFS平臺一般做爲底層存儲平臺服務於上層多種計算框架，多個業務場景，因此小文件問題從業務的角度也難以免。目前也有方案例如HDFS-Federation解決Namenode單點擴展性問題，但同時也會帶來巨大的運維管理難度。

三、冷熱數據問題

隨着數據量的不斷增加積累，數據也會呈現出訪問熱度不一樣的巨大差別。例如一個平臺會不斷地寫入最新的數據，但一般狀況下最近寫入的數據訪問頻率會比好久以前的數據高不少。若是不管數據冷熱狀況，都採用一樣的存儲策略，是對集羣資源的一種浪費。如何根據數據冷熱程度對HDFS存儲系統進行優化是一個亟待解決的問題。

2、現有HDFS優化技術

從Hadoop誕生到今天也有超過10年的時間，在此期間HDFS技術自己也在不斷優化演進。HDFS現有一些技術可以必定程度上解決上述一些問題。這裏簡要介紹一下HDFS異構存儲和HDFS糾刪碼技術。

HDFS異構存儲：

Hadoop從2.6.0版本開始支持異構存儲功能。咱們知道HDFS默認的存儲策略，對於每一個數據塊，採用三個副本的存儲方式，保存在不一樣節點的磁盤上。異構存儲的做用在於利用服務器不一樣類型的存儲介質（包括HDD硬盤、SSD、內存等）提供更多的存儲策略（例如三個副本一個保存在SSD介質，剩下兩個仍然保存在HDD硬盤），從而使得HDFS的存儲可以更靈活高效地應對各類應用場景。

HDFS中預約義支持的各類存儲包括：

• ARCHIVE：高存儲密度但耗電較少的存儲介質，例如磁帶，一般用來存儲冷數據

• DISK：磁盤介質，這是HDFS最先支持的存儲介質

• SSD：固態硬盤，是一種新型存儲介質，目前被很多互聯網公司使用

• RAM_DISK ：數據被寫入內存中，同時會往該存儲介質中再（異步）寫一份

HDFS中支持的存儲策略包括：

1. Lazy_persist：一個副本保存在內存RAM_DISK中，其他副本保存在磁盤中

2. ALL_SSD：全部副本都保存在SSD中

3. One_SSD：一個副本保存在SSD中，其他副本保存在磁盤中

4. Hot：全部副本保存在磁盤中，這也是默認的存儲策略

5. Warm：一個副本保存在磁盤上，其他副本保存在歸檔存儲上

6. Cold：全部副本都保存在歸檔存儲上

整體上HDFS異構存儲的價值在於，根據數據熱度採用不一樣策略從而提高集羣總體資源使用效率。對於頻繁訪問的數據，將其所有或部分保存在更高訪問性能的存儲介質（內存或SSD）上，提高其讀寫性能；對於幾乎不會訪問的數據，保存在歸檔存儲介質上，下降其存儲成本。可是HDFS異構存儲的配置須要用戶對目錄指定相應的策略，即用戶須要預先知道每一個目錄下的文件的訪問熱度，在實際大數據平臺的應用中，這是比較困難的一點。

HDFS糾刪碼：

傳統HDFS數據採用三副本機制保證數據的可靠性，即每存儲1TB數據，實際在集羣各節點上佔用的數據達到3TB，額外開銷爲200%。這給節點磁盤存儲和網絡傳輸帶來了很大的壓力。

在Hadoop3.0開始引入支持HDFS文件塊級別的糾刪碼，底層採用Reed-Solomon（k,m）算法。RS是一種經常使用的糾刪碼算法，經過矩陣運算，能夠爲k位數據生成m位校驗位，根據k和m的取值不一樣，能夠實現不一樣程度的容錯能力，是一種比較靈活的糾刪碼算法。

常見的算法爲RS(3,2)、RS(6,3)、RS(10,4)，k個文件塊和m個校驗塊構成一個組，這個組內能夠容忍任意m個數據塊的丟失。

HDFS糾刪碼技術可以下降數據存儲的冗餘度，以RS(3,2)爲例，其數據冗餘度爲67%，相比Hadoop默認的200%大爲減小。可是糾刪碼技術存儲數據和數據恢復都須要消耗cpu進行計算，其實是一種以時間換空間的選擇，所以比較適用的場景是對冷數據的存儲。冷數據存儲的數據每每一次寫入以後長時間沒有訪問，這種狀況下能夠經過糾刪碼技術減小副本數。

3、大數據存儲優化：SSM

前面介紹的不管HDFS異構存儲仍是糾刪碼技術，前提都是須要用戶對特定的數據指定存儲的行爲，就是說用戶須要知道哪些數據是熱點數據，哪些是冷數據。那有沒有一種方法能夠自動對存儲進行優化呢？

答案是有的，這裏介紹的SSM(Smart Storage Management)系統，它從底層存儲（一般是HDFS）中獲取元數據信息，並經過數據讀寫訪問信息分析獲取數據熱度狀況，針對不一樣熱度的數據，按照預先制定的一系列規則，採用相應的存儲優化策略，從而提高整個存儲系統的效率。SSM是一個由Intel主導的開源的項目，中國移動也參與其中的研發，項目能夠在Github中獲取到：https://github.com/Intel-bigdata/SSM 。

SSM定位是一個存儲外圍優化的系統，總體上採用Server-Agent-Client的架構，其中Server負責SSM總體邏輯的實現，Agent用於對存儲集羣執行各類操做，Client是提供給用戶的數據訪問接口，一般其中包含了原生HDFS的接口。

SSM-Server的主要框架如上圖所示，從上到下，StatesManager與HDFS集羣進行交互，用於獲取HDFS元數據信息，並維護每一個文件的訪問熱度信息。StatesManager中的信息會持久化到關係型數據庫中。在SSM中採用TiDB做爲底層存儲的數據庫。RuleManager維護和管理規則相關信息，用戶經過前臺界面爲SSM定義一系列存儲規則，RuleManger負責規則的解析和執行。CacheManager/StorageManager根據熱度和規則，生成具體的action任務。ActionExecutor 負責具體的action任務，把任務分配給Agent，並在Agent節點執行。

SSM-Server內部邏輯實現依賴於規則的定義，須要管理員經過前臺web頁面爲SSM系統制定一系列規則。一條規則包括幾部分組成：

• 操做對象，一般是指符合特定條件的文件。
• 觸發器，指規則觸發的時間點，例如天天定時觸發。
• 執行條件，定義一系列基於熱度的條件，例如文件在一段時間訪問次數計數要求。
• 執行操做，對符合執行條件的數據進行相關操做，一般是指定其存儲策略等。

一個實際的規則示例：

file.path matchs 」/foo/*」: accessCount(10min) >= 3 | one-ssd

這條規則表示對於在/foo目錄下的文件，知足10分鐘內被訪問次數不低於三次，則對其採用One-SSD的存儲策略，即數據一個副本保存在SSD上，剩餘2個副本保存在普通磁盤上。

4、SSM應用場景

SSM可以針對數據的冷熱程度，採用不一樣存儲策略進行優化，如下是一些典型的應用場景：

最典型的場景就是針對冷數據，如上圖所示，定義相關規則，將較長時間爲沒有訪問的數據採用更低成本的存儲。例如原先的數據塊，從SSD存儲退化到HDD存儲。

與此相似，對於熱點的數據，一樣能夠根據不一樣的規則，對其採用更快速的存儲策略，如上圖所示，短期內訪問此處較多的熱點數據，會從HDD存儲上升至SSD存儲，更熱點的數據會採用內存存儲的策略。

針對冷數據的場景，SSM也能夠採用糾刪碼的優化，經過定義相應規則，對於訪問次數不多的冷數據，對其執行erasure code操做，下降數據副本冗餘。

 

另外值得一提的是SSM針對小文件也有相應優化手段，這個功能仍然處於開發過程當中。大致邏輯是SSM會對HDFS上一系列小文件執行合併成大文件的操做，同時，在SSM的元數據中記錄下原始小文件和合並後大文件的映射關係以及每一個小文件在大文件中的偏移量。當用戶須要訪問小文件時，經過SSM特定的客戶端（SmartClient），根據SSM元數據中的小文件映射信息，從合併後的文件中獲取到原始小文件。

最後SSM是個開源的項目，目前仍然在很是快速的迭代演進過程當中，歡迎任何感興趣的朋友參與項目的開發貢獻。

Q&A

Q1：HDFS自行搭建應該從多大規模開始？

A1：HDFS支持僞分佈模式，即便只有一個節點，也能搭建一個HDFS系統。若是但願更好體驗和理解HDFS的分佈式架構，建議有3到5個節點的環境來搭建。

Q2：蘇研在實際各省的大數據平臺用SSM了嗎？

A2：目前尚未，這個項目還在快速發展中，須要等到測試穩定後纔會逐步用到生產上。

Q3：HDFS和Spark區別是什麼？優缺點呢？

A3：HDFS和Spark並非同一個層面上的技術，HDFS是存儲系統，而Spark是一種計算引擎。咱們常常拿來和Spark對標的是Hadoop中的Mapreduce計算框架而非HDFS存儲系統。在實際項目建設中，一般HDFS和Spark是協做的關係，底層存儲使用HDFS，上層計算使用Spark。

原文來自： http://www.linuxprobe.com/hdfs-ha.html