分布式文件系統(tǒng)HadoopHDFS與傳統(tǒng)文件系統(tǒng)LinuxFS的比較與分析-論文總結(jié)

1、1 許春玲，張廣泉. 分布式文件系統(tǒng)Hadoop HDFS與傳統(tǒng)文件系統(tǒng)Linux FS的比較與分析J.蘇州:蘇州大學(xué)學(xué)報（工科版）, 2010，30(4)：6-9.一、 HDFS實(shí)現(xiàn)分布式的關(guān)鍵技術(shù)分析1. 用戶群空間和物理空間的彼此獨(dú)立：通過添加Block層來實(shí)現(xiàn)l Map1: ;l Map2: ;(以上兩組映射封裝在B locksMap 以哈希映射實(shí)現(xiàn), 作為描述Block 的重要元數(shù)據(jù)Blockinfo封裝了該Block相關(guān)的INode、DataNode。)l Map3: (Map1逆向), 作為目錄樹的最底層存放在FSImage;l Map4: (Map2逆向), DataNodeD

2、escr iptor中定義的Block List。2. 數(shù)據(jù)塊映射BlockMap從HDFS目前的設(shè)計(jì)架構(gòu)來看, 前面的Map1、Map2通過Java的Map界面實(shí)現(xiàn), 而Hadoop基于MapReduce范式也實(shí)現(xiàn)了自己的應(yīng)用程序界面Mapper、Rducer。JavaMap以整個集合為操作對象, 不利于任務(wù)的分解和并行處理, 因此HDFS僅在數(shù)據(jù)的存儲上實(shí)現(xiàn)分布式, 對算法和操作的實(shí)現(xiàn)依舊是集中式的。這樣的設(shè)計(jì), 造成集群過分依賴NameNode, 當(dāng)文件系統(tǒng)越來越龐大、目錄樹的結(jié)構(gòu)越來越復(fù)雜時, NameNode的處理能力將成為HDFS的瓶頸。也許正是考慮到HDFS整個集群目錄的操作都集

3、中在一臺NameNode上, 所以出現(xiàn)了前面HDFS設(shè)計(jì)的兩個重點(diǎn), 努力簡化目錄樹結(jié)構(gòu)以減少空間占用。即便如此, 從長遠(yuǎn)來看日益龐大的集群(甚至可能在將來出現(xiàn)涵蓋整個互聯(lián)網(wǎng)的唯一集群)使簡化的目錄樹無法從根本上解決問題, 而一旦NameNode崩潰, 則意味著集群的癱瘓。3. NameNode瓶頸解決思路：將MapReduce范式引入HDFS統(tǒng)一空間中的Block有兩個屬性: 所屬的文件( INodefile)和所屬的DataNode, 第一個屬性可能為空。相應(yīng)的Map產(chǎn)生兩個鍵值對 、 , 如果將兩個鍵封裝在一起INodeF ile, DataNode 則有 。對于 , 假設(shè)Reduce 表示先根據(jù)INodeFile做Reduce, 再根據(jù)DataNode做Reduce, 則可以據(jù)此找出每個文件(由INodefile代表)存儲在哪些DatatNode, 過程類似于SQL中有兩個鍵值的Group By。以一次讀操作為例, 參考圖6先執(zhí)行Map3將INodeFile映射到Block, 再執(zhí)行Reduce2將同一個DataNode的Block聚集在一起; 反向則先執(zhí)行Map4將DataNode映射到Block, 再執(zhí)行Reduce1將同一個文件的Block聚集起來。其中Map3與Reduce1互逆, Map4與