Hadoop中HDFS適用于什么場景

這篇文章給大家分享的是有關(guān)Hadoop中HDFS適用于什么場景的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

Hadoop生態(tài)系統(tǒng)一直是大數(shù)據(jù)領(lǐng)域的熱點，其中包括今天要聊的HDFS，和計劃以后想聊的yarn, mapreduce, spark, hive, hbase, 已經(jīng)聊過的zookeeper，等等。

今天主聊HDFS，hadoop distributed file system, 起源于Google 的 GFS，只不過GFS是用c++寫的，Hadoop是Doug Cutting在yahoo用Java寫的。2008 年 Hadoop成為Apache top-level project。

應(yīng)用

HDFS適用于什么場景呢？ 非常大的文件存儲，比如以G或T為單位，因為HDFS內(nèi)部的block的基本單位已經(jīng)是128MB。注意這里有一個小文件問題，誤區(qū)是說怕1K的小文件也能占用128MB的硬盤，其實不是的，它還是占用1K硬盤，但是小文件問題的bottle neck是在name node里，因為name node要存儲文件和block的相關(guān)信息在內(nèi)存里，文件數(shù)量一多，name node的內(nèi)存就不夠了（比如，百萬小文件要占用300MB 內(nèi)存），當(dāng)然hdfs federation能夠通過sharding的方式解決name node內(nèi)存不夠用的問題，接下來會細(xì)說。HDFS還適用于“write once，read-many”的場景，而且它的寫是append only，所以想改也沒法改。如果是多次寫的話，應(yīng)該考慮一下cassandra（參見我的上一篇文章）。同時HDFS的文件通常只能允許single writer寫入（是通過lease的方式來保證只有一個writer能夠當(dāng)前寫某個文件）。HDFS因為只需要普通的commodity hardware而不需要昂貴的高可用硬件而被企業(yè)歡迎。HDFS不適用于需要low latency的數(shù)據(jù)訪問方式，因為HDFS是拿延遲交換高throughput。

概念

Blocks

HDFS里，文件是被分割成block大小的chunk，每個block是128MB，有人會問了，為什么非要搞這么大，主要是要縮短尋道時間在總硬盤讀寫時間中的比例，比如尋道時間需要5 ms，而尋到時間只能占總時間0.5%的比例，那么硬盤讀寫時間差不多在1s左右，1s中能穿多少文件呢，如果硬盤的讀寫為128MB／s，那么就能傳128MB，所以block大小就定義為128MB，這樣可以保證硬盤操作的時間有效的應(yīng)用在讀寫上而不是花費在尋道上。當(dāng)然太大了也不行，mapreduce的map通常是以block為單位，如果block太少，mapreduce的效率會比較低。

hdfs fsck $path -files -blocks -locations

上面的命令可以用來提供文件的block信息，比如block在哪臺機(jī)器，名字是什么，方便你進(jìn)一步查詢block的具體信息。

Namenodes and datanodes

namenode管理namespace， 管理文件系統(tǒng)樹狀結(jié)構(gòu)和文件／目錄的metadata，這些信息以如下方式持久化在硬盤里：namespace image 和 edit log。同時block的metadata也存放在namd node，存放于內(nèi)存中。前面提到過百萬小文件，會占用300MB內(nèi)存的例子。block信息為什么不持久化呢，因為它會變動，系統(tǒng)重啟的時候會從datanode那里重新構(gòu)建。

name node的備份有幾種方式，一種是把持久化存放于硬盤的信息既寫到本地硬盤也同時寫到遠(yuǎn)程N(yùn)FS mount。另一種方式是運行secondary namenode，它其實并沒有扮演namenode的角色，而是周期性的merge namesapce image以及edit log來防止edit log過大。它會保存一份merged namespace image，一旦primary fail了，就把NFS上的metadata copy到secondary namenode上，這樣secondary就成為了新的primary。

具體過程如下圖所示，edit log和fsimage都是在硬盤中，edit log就是WAL（cassandra寫操作也用到了WAL的手段，WAL很流行，可以單拉出來講一次），fsimage是check point of the filesystem metadata。寫的時候先寫edit log，然后update in-memory representation of filesystem metadata（用來serve讀請求），圖中沒有畫出這部分操作。

有沒有更好的方法呢？上述方法沒能提供HA， namenode仍然是single point of failure。新的primary需要（1）load namespace image into memory （2）replay edit log （3）從datanode那邊接收足夠的block reports（前文提到block信息是在內(nèi)存中的）。這個過程有可能會話費30分鐘或更久。client等不了啊～～

Hadoop 2提供了HA的support。namenode采用active-standby的配置方式：

• namenodes使用高可用共享存儲來存edit log。active每次寫入都會被standby讀出并synchronize到自己的內(nèi)存中。

• datanodes在發(fā)送block reports時會同時發(fā)給所有的name nodes，記住block mapping是在內(nèi)存中。

• 客戶端需要配置來handle namenode failover，其實就是watch zookeeper的leader election（參見我之前講的zookeeper）

• 這樣就不需要secondary namenode啦，standby取代了它的作用會周期性的產(chǎn)生check points

上面提到的共享存儲主要指的是QJM（quorum journal manager），通常配置3個（當(dāng)然我也見過50個node配5個journal nodes），寫的時候需要滿足quorum。

這樣當(dāng)active namenode fail時，standby可以馬上扛住，因為latest edit log和 up-to-date block mapping都在內(nèi)存中。

HDFS write

HDFS read

CLI Example

touch test.txt
hdfs dfs -mkdir /user/qingge/testdir
hdfs dfs -copyFromLocal ./test.txt /user/qingge/testdir/ hdfs dfs -ls /user/qingge/testdir/test.txt
hdfs dfs -chmod o-r /user/qingge/testdir/test.txt hdfs dfs -cat /user/qingge/testdir/test.txt | head -10 hdfs dfs -mv /user/qingge/testdir/test.txt /user/qingge/testdir/test2.txt

hdfs fsck /data/lalala -files -blocks -locations
hdfs fsck -blockId blk_10101010

HTTP 訪問

(1) direct access: HDFS daemons server HTTP requests, embedded web servers in the name node and datanodes act as WebHDFS endpoionts.

(2) proxy access: 中間有多個HDFS proxy，for strictr firewall and bandwidth-limiting policies, proxy和node之間使用RPC request和block request。

HDFS Federation

相當(dāng)于namenode sharding了，如果不想用HA，然后namenode內(nèi)存又要爆了怎么辦，答分區(qū)呀，每個namenode從根目錄下劃走幾個子目錄，無線分區(qū)無線擴(kuò)充，每個namenode之間井水不犯河水，一個爆了或廢了絲毫不影響另一個。

思考題：

如果HDFS有1PB容量，每個block大小是64MB，平均的metadata大小是每個block300B，replication factor是3， 那么namenode最小的內(nèi)存是多少呢？

答：差不多需要1.56G， 1024*1024*1024 MB/(64MB*3)*300B/(1024 * 1024 * 1024) = 1.56 GB

感謝各位的閱讀！關(guān)于“Hadoop中HDFS適用于什么場景”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！