摘要: 隨著大數(shù)據(jù)技術(shù)相關(guān)技術(shù)的發(fā)展和普及土童，越來越多的公司開始使用基于開源Hadoop的平臺系統(tǒng)诗茎，同時，越來越多的業(yè)務(wù)和應(yīng)用也在從傳統(tǒng)的技術(shù)架構(gòu)遷移到大數(shù)據(jù)平臺上献汗。在典型的Hadoop大數(shù)據(jù)平臺中敢订，人們使用HDFS作為存儲服服務(wù)
Hadoop
一、背景
隨著大數(shù)據(jù)技術(shù)相關(guān)技術(shù)的發(fā)展和普及雀瓢，越來越多的公司開始使用基于開源Hadoop的平臺系統(tǒng)枢析，同時，越來越多的業(yè)務(wù)和應(yīng)用也在從傳統(tǒng)的技術(shù)架構(gòu)遷移到大數(shù)據(jù)平臺上刃麸。在典型的Hadoop大數(shù)據(jù)平臺中醒叁，人們使用HDFS作為存儲服務(wù)的核心。
而在大數(shù)據(jù)發(fā)展之初泊业，最主要的應(yīng)用場景仍然是離線批處理場景把沼，對存儲的需求追求的是吞吐量，HDFS正是針對這樣的場景而設(shè)計的吁伺，而隨著技術(shù)不斷的發(fā)展饮睬，越來越多的場景會對存儲提出新的需求，HDFS也面臨著新的挑戰(zhàn)篮奄。主要包括幾個方面：
1捆愁、數(shù)據(jù)量問題
一方面隨著業(yè)務(wù)的增長和新的應(yīng)用接入，會給HDFS帶來更多的數(shù)據(jù)窟却，另一方面隨著深度學習昼丑，人工智能等技術(shù)的發(fā)展，用戶通常希望能保存更長時間的數(shù)據(jù)夸赫，以提升深度學習的效果菩帝。數(shù)據(jù)量的快速增加會使集群不斷面臨擴容需求，從而導(dǎo)致存儲成本不斷增加茬腿。
2呼奢、小文件問題
眾所周知，HDFS的設(shè)計是針對離線批處理大文件的切平，處理小文件并非傳統(tǒng)HDFS擅長的場景握础。HDFS小文件問題的根源在于文件的元數(shù)據(jù)信息都是維護在單點Namenode的內(nèi)存中，單臺機器的內(nèi)存空間始終是有限的悴品。據(jù)估算弓候，單臺namenode集群能容納系統(tǒng)文件數(shù)量極限大約在1.5億左右郎哭。實際上，HDFS平臺通常作為底層存儲平臺服務(wù)于上層多種計算框架菇存，多個業(yè)務(wù)場景夸研，所以小文件問題從業(yè)務(wù)的角度也難以避免。目前也有方案例如HDFS-Federation解決Namenode單點擴展性問題依鸥，但同時也會帶來巨大的運維管理難度亥至。
3、冷熱數(shù)據(jù)問題
隨著數(shù)據(jù)量的不斷增長積累贱迟，數(shù)據(jù)也會呈現(xiàn)出訪問熱度不同的巨大差異姐扮。例如一個平臺會不斷地寫入的數(shù)據(jù)，但通常情況下最近寫入的數(shù)據(jù)訪問頻率會比很久之前的數(shù)據(jù)高很多衣吠。如果無論數(shù)據(jù)冷熱情況茶敏，都采用同樣的存儲策略，是對集群資源的一種浪費缚俏。如何根據(jù)數(shù)據(jù)冷熱程度對HDFS存儲系統(tǒng)進行優(yōu)化是一個亟待解決的問題惊搏。
二、現(xiàn)有HDFS優(yōu)化技術(shù)
從Hadoop誕生到今天也有超過10年的時間忧换，在此期間HDFS技術(shù)本身也在不斷優(yōu)化演進恬惯。HDFS現(xiàn)有一些技術(shù)能夠一定程度上解決上述一些問題。這里簡要介紹一下HDFS異構(gòu)存儲和HDFS糾刪碼技術(shù)亚茬。
HDFS異構(gòu)存儲：
Hadoop從2.6.0版本開始支持異構(gòu)存儲功能酪耳。我們知道HDFS默認的存儲策略，對于每個數(shù)據(jù)塊刹缝，采用三個副本的存儲方式碗暗，保存在不同節(jié)點的磁盤上。異構(gòu)存儲的作用在于利用服務(wù)器不同類型的存儲介質(zhì)（包括HDD硬盤梢夯、SSD言疗、內(nèi)存等）提供更多的存儲策略（例如三個副本一個保存在SSD介質(zhì)，剩下兩個仍然保存在HDD硬盤）厨疙，從而使得HDFS的存儲能夠更靈活高效地應(yīng)對各種應(yīng)用場景。
HDFS中預(yù)定義支持的各種存儲包括：
ARCHIVE：高存儲密度但耗電較少的存儲介質(zhì)疑务，例如磁帶沾凄，通常用來存儲冷數(shù)據(jù)
DISK：磁盤介質(zhì)，這是HDFS最早支持的存儲介質(zhì)
SSD：固態(tài)硬盤知允，是一種新型存儲介質(zhì)撒蟀，目前被不少互聯(lián)網(wǎng)公司使用
RAM_DISK ：數(shù)據(jù)被寫入內(nèi)存中，同時會往該存儲介質(zhì)中再（異步）寫一份
HDFS中支持的存儲策略包括：
Lazy_persist：一個副本保存在內(nèi)存RAM_DISK中温鸽，其余副本保存在磁盤中
ALL_SSD：所有副本都保存在SSD中
One_SSD：一個副本保存在SSD中保屯，其余副本保存在磁盤中
Hot：所有副本保存在磁盤中手负，這也是默認的存儲策略
Warm：一個副本保存在磁盤上，其余副本保存在歸檔存儲上
Cold：所有副本都保存在歸檔存儲上
總體上HDFS異構(gòu)存儲的價值在于姑尺，根據(jù)數(shù)據(jù)熱度采用不同策略從而提升集群整體資源使用效率竟终。對于頻繁訪問的數(shù)據(jù)，將其全部或部分保存在更高訪問性能的存儲介質(zhì)（內(nèi)存或SSD）上切蟋，提升其讀寫性能统捶；對于幾乎不會訪問的數(shù)據(jù)，保存在歸檔存儲介質(zhì)上柄粹，降低其存儲成本喘鸟。但是HDFS異構(gòu)存儲的配置需要用戶對目錄指定相應(yīng)的策略，即用戶需要預(yù)先知道每個目錄下的文件的訪問熱度驻右，在實際大數(shù)據(jù)平臺的應(yīng)用中什黑，這是比較困難的一點。
HDFS糾刪碼：
傳統(tǒng)HDFS數(shù)據(jù)采用三副本機制保證數(shù)據(jù)的可靠性堪夭，即每存儲1TB數(shù)據(jù)愕把，實際在集群各節(jié)點上占用的數(shù)據(jù)達到3TB，額外開銷為200%茵瘾。這給節(jié)點磁盤存儲和網(wǎng)絡(luò)傳輸帶來了很大的壓力礼华。
在Hadoop3.0開始引入支持HDFS文件塊級別的糾刪碼，底層采用Reed-Solomon（k,m）算法拗秘。RS是一種常用的糾刪碼算法圣絮，通過矩陣運算，可以為k位數(shù)據(jù)生成m位校驗位雕旨，根據(jù)k和m的取值不同扮匠，可以實現(xiàn)不同程度的容錯能力，是一種比較靈活的糾刪碼算法凡涩。
常見的算法為RS(3,2)棒搜、RS(6,3)、RS(10,4)活箕，k個文件塊和m個校驗塊構(gòu)成一個組力麸，這個組內(nèi)可以容忍任意m個數(shù)據(jù)塊的丟失。
HDFS糾刪碼技術(shù)能夠降低數(shù)據(jù)存儲的冗余度育韩，以RS(3,2)為例克蚂，其數(shù)據(jù)冗余度為67%，相比Hadoop默認的200%大為減少筋讨。但是糾刪碼技術(shù)存儲數(shù)據(jù)和數(shù)據(jù)恢復(fù)都需要消耗cpu進行計算埃叭，實際上是一種以時間換空間的選擇，因此比較適用的場景是對冷數(shù)據(jù)的存儲悉罕。冷數(shù)據(jù)存儲的數(shù)據(jù)往往一次寫入之后長時間沒有訪問赤屋，這種情況下可以通過糾刪碼技術(shù)減少副本數(shù)立镶。
三、大數(shù)據(jù)存儲優(yōu)化：SSM
前面介紹的無論HDFS異構(gòu)存儲還是糾刪碼技術(shù)类早，前提都是需要用戶對特定的數(shù)據(jù)指定存儲的行為媚媒，就是說用戶需要知道哪些數(shù)據(jù)是熱點數(shù)據(jù)，哪些是冷數(shù)據(jù)莺奔。那有沒有一種方法可以自動對存儲進行優(yōu)化呢欣范？
答案是有的，這里介紹的SSM(Smart Storage Management)系統(tǒng)令哟，它從底層存儲（通常是HDFS）中獲取元數(shù)據(jù)信息恼琼，并通過數(shù)據(jù)讀寫訪問信息分析獲取數(shù)據(jù)熱度情況，針對不同熱度的數(shù)據(jù)屏富，按照預(yù)先制定的一系列規(guī)則晴竞，采用相應(yīng)的存儲優(yōu)化策略，從而提升整個存儲系統(tǒng)的效率狠半。SSM是一個由Intel主導(dǎo)的開源的項目噩死，中國移動也參與其中的研發(fā)，項目可以在Github中獲取到：https://github.com/Intel-bigdata/SSM 神年。
SSM定位是一個存儲外圍優(yōu)化的系統(tǒng)已维，整體上采用Server-Agent-Client的架構(gòu)，其中Server負責SSM整體邏輯的實現(xiàn)已日，Agent用于對存儲集群執(zhí)行各種操作垛耳，Client是提供給用戶的數(shù)據(jù)訪問接口，通常其中包含了原生HDFS的接口飘千。
SSM-Server的主要框架如上圖所示堂鲜，從上到下，StatesManager與HDFS集群進行交互护奈，用于獲取HDFS元數(shù)據(jù)信息缔莲，并維護每個文件的訪問熱度信息。StatesManager中的信息會持久化到關(guān)系型數(shù)據(jù)庫中霉旗。在SSM中采用TiDB作為底層存儲的數(shù)據(jù)庫痴奏。RuleManager維護和管理規(guī)則相關(guān)信息，用戶通過前臺界面為SSM定義一系列存儲規(guī)則厌秒，RuleManger負責規(guī)則的解析和執(zhí)行读拆。CacheManager/StorageManager根據(jù)熱度和規(guī)則，生成具體的action任務(wù)简僧。ActionExecutor 負責具體的action任務(wù)建椰，把任務(wù)分配給Agent雕欺，并在Agent節(jié)點執(zhí)行岛马。
SSM-Server內(nèi)部邏輯實現(xiàn)依賴于規(guī)則的定義棉姐，需要管理員通過前臺web頁面為SSM系統(tǒng)制定一系列規(guī)則。一條規(guī)則包括幾部分組成：
操作對象啦逆，通常是指符合特定條件的文件伞矩。
觸發(fā)器，指規(guī)則觸發(fā)的時間點夏志，例如每天定時觸發(fā)乃坤。
執(zhí)行條件，定義一系列基于熱度的條件沟蔑，例如文件在一段時間訪問次數(shù)計數(shù)要求湿诊。
執(zhí)行操作，對符合執(zhí)行條件的數(shù)據(jù)進行相關(guān)操作瘦材，通常是指定其存儲策略等厅须。
一個實際的規(guī)則示例：
file.path matchs ”/foo/*”: accessCount(10min) >= 3 | one-ssd
這條規(guī)則表示對于在/foo目錄下的文件，滿足10分鐘內(nèi)被訪問次數(shù)不低于三次食棕，則對其采用One-SSD的存儲策略朗和，即數(shù)據(jù)一個副本保存在SSD上，剩余2個副本保存在普通磁盤上簿晓。
四眶拉、SSM應(yīng)用場景
SSM能夠針對數(shù)據(jù)的冷熱程度，采用不同存儲策略進行優(yōu)化憔儿，以下是一些典型的應(yīng)用場景：
最典型的場景就是針對冷數(shù)據(jù)忆植，如上圖所示，定義相關(guān)規(guī)則皿曲，將較長時間為沒有訪問的數(shù)據(jù)采用更低成本的存儲唱逢。例如原先的數(shù)據(jù)塊，從SSD存儲退化到HDD存儲屋休。
與此類似坞古，對于熱點的數(shù)據(jù)，同樣可以根據(jù)不同的規(guī)則劫樟，對其采用更快速的存儲策略痪枫，如上圖所示，短時間內(nèi)訪問此處較多的熱點數(shù)據(jù)叠艳，會從HDD存儲上升至SSD存儲奶陈，更熱點的數(shù)據(jù)會采用內(nèi)存存儲的策略。
針對冷數(shù)據(jù)的場景附较，SSM也可以采用糾刪碼的優(yōu)化吃粒，通過定義相應(yīng)規(guī)則，對于訪問次數(shù)很少的冷數(shù)據(jù)拒课，對其執(zhí)行erasure code操作徐勃，降低數(shù)據(jù)副本冗余事示。
另外值得一提的是SSM針對小文件也有相應(yīng)優(yōu)化手段，這個功能仍然處于開發(fā)過程中僻肖。大體邏輯是SSM會對HDFS上一系列小文件執(zhí)行合并成大文件的操作肖爵，同時，在SSM的元數(shù)據(jù)中記錄下原始小文件和合并后大文件的映射關(guān)系以及每個小文件在大文件中的偏移量臀脏。當用戶需要訪問小文件時劝堪，通過SSM特定的客戶端（SmartClient），根據(jù)SSM元數(shù)據(jù)中的小文件映射信息揉稚，從合并后的文件中獲取到原始小文件秒啦。
最后SSM是個開源的項目，目前仍然在非巢缶粒快速的迭代演進過程中帝蒿，歡迎任何感興趣的朋友參與項目的開發(fā)貢獻。
Q&A
Q1：HDFS自行搭建應(yīng)該從多大規(guī)模開始巷怜？
A1：HDFS支持偽分布模式葛超，即使只有一個節(jié)點，也能搭建一個HDFS系統(tǒng)延塑。如果希望更好體驗和理解HDFS的分布式架構(gòu)绣张，建議有3到5個節(jié)點的環(huán)境來搭建。
Q2：蘇研在實際各省的大數(shù)據(jù)平臺用SSM了嗎关带？
A2：目前還沒有侥涵，這個項目還在快速發(fā)展中，需要等到測試穩(wěn)定后才會逐步用到生產(chǎn)上宋雏。
Q3：HDFS和Spark區(qū)別是什么芜飘？優(yōu)缺點呢？
A3：HDFS和Spark并不是同一個層面上的技術(shù)磨总，HDFS是存儲系統(tǒng)嗦明，而Spark是一種計算引擎。我們經(jīng)常拿來和Spark對標的是Hadoop中的Mapreduce計算框架而非HDFS存儲系統(tǒng)蚪燕。在實際項目建設(shè)中娶牌，通常HDFS和Spark是協(xié)作的關(guān)系，底層存儲使用HDFS馆纳，上層計算使用Spark诗良。
