講師介紹

陶捷

中國移動蘇州研發中心

高階軟體開發工程師

• 目前負責中國移動大資料平臺產品線CMH套件產品的研發，擁有豐富的Hadoop大資料平臺研發和建設經驗；開源Hadoop社群貢獻者。
• 曾任職於阿里巴巴，先後從事Hadoop（雲梯）、MaxCompute（ODPS）平臺研發工作。

主題簡介：

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

一、背景

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

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

1、資料量問題

一方面隨著業務的增長和新的應用接入，會給HDFS帶來更多的資料，另一方面隨著深度學習，人工智慧等技術的發展，使用者通常希望能儲存更長時間的資料，以提升深度學習的效果。資料量的快速增加會使叢集不斷面臨擴容需求，從而導致儲存成本不斷增加。

2、小檔案問題

眾所周知，HDFS的設計是針對離線批處理大檔案的，處理小檔案並非傳統HDFS擅長的場景。HDFS小檔案問題的根源在於檔案的元資料資訊都是維護在單點Namenode的記憶體中，單臺機器的記憶體空間始終是有限的。據估算，單臺namenode叢集能容納系統檔案數量極限大約在1.5億左右。實際上，HDFS平臺通常作為底層儲存平臺服務於上層多種計算框架，多個業務場景，所以小檔案問題從業務的角度也難以避免。目前也有方案例如HDFS-Federation解決Namenode單點擴充套件性問題，但同時也會帶來巨大的運維管理難度。

3、冷熱資料問題

隨著資料量的不斷增長積累，資料也會呈現出訪問熱度不同的巨大差異。例如一個平臺會不斷地寫入最新的資料，但通常情況下最近寫入的資料訪問頻率會比很久之前的資料高很多。如果無論資料冷熱情況，都採用同樣的儲存策略，是對叢集資源的一種浪費。如何根據資料冷熱程度對HDFS儲存系統進行優化是一個亟待解決的問題。

二、現有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進行計算，實際上是一種以時間換空間的選擇，因此比較適用的場景是對冷資料的儲存。冷資料儲存的資料往往一次寫入之後長時間沒有訪問，這種情況下可以通過糾刪碼技術減少副本數。

三、大資料儲存優化：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個副本儲存在普通磁碟上。

四、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。

直播回放連結

https://m.qlchat.com/topic/details?topicId=2000000067659642密碼：123

原文來自微信公眾號：DBAplus社群