這篇文章給大家分享的是有關Hadoop中HDFS適用于什么場景的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。
Hadoop生態系統一直是大數據領域的熱點，其中包括今天要聊的HDFS，和計劃以后想聊的yarn, mapreduce, spark, hive, hbase, 已經聊過的zookeeper，等等。
今天主聊HDFS，hadoop distributed file system, 起源于Google 的 GFS，只不過GFS是用c++寫的，Hadoop是Doug Cutting在yahoo用Java寫的。2008 年 Hadoop成為Apache top-level project。
HDFS適用于什么場景呢？ 非常大的文件存儲，比如以G或T為單位，因為HDFS內部的block的基本單位已經是128MB。注意這里有一個小文件問題，誤區是說怕1K的小文件也能占用128MB的硬盤，其實不是的，它還是占用1K硬盤，但是小文件問題的bottle neck是在name node里，因為name node要存儲文件和block的相關信息在內存里，文件數量一多，name node的內存就不夠了（比如，百萬小文件要占用300MB 內存），當然hdfs federation能夠通過sharding的方式解決name node內存不夠用的問題，接下來會細說。HDFS還適用于“write once，read-many”的場景，而且它的寫是append only，所以想改也沒法改。如果是多次寫的話，應該考慮一下cassandra（參見我的上一篇文章）。同時HDFS的文件通常只能允許single writer寫入（是通過lease的方式來保證只有一個writer能夠當前寫某個文件）。HDFS因為只需要普通的commodity hardware而不需要昂貴的高可用硬件而被企業歡迎。HDFS不適用于需要low latency的數據訪問方式，因為HDFS是拿延遲交換高throughput。
HDFS里，文件是被分割成block大小的chunk，每個block是128MB，有人會問了，為什么非要搞這么大，主要是要縮短尋道時間在總硬盤讀寫時間中的比例，比如尋道時間需要5 ms，而尋到時間只能占總時間0.5%的比例，那么硬盤讀寫時間差不多在1s左右，1s中能穿多少文件呢，如果硬盤的讀寫為128MB／s，那么就能傳128MB，所以block大小就定義為128MB，這樣可以保證硬盤操作的時間有效的應用在讀寫上而不是花費在尋道上。當然太大了也不行，mapreduce的map通常是以block為單位，如果block太少，mapreduce的效率會比較低。
hdfs fsck $path -files -blocks -locations
上面的命令可以用來提供文件的block信息，比如block在哪臺機器，名字是什么，方便你進一步查詢block的具體信息。
namenode管理namespace， 管理文件系統樹狀結構和文件／目錄的metadata，這些信息以如下方式持久化在硬盤里：namespace image 和 edit log。同時block的metadata也存放在namd node，存放于內存中。前面提到過百萬小文件，會占用300MB內存的例子。block信息為什么不持久化呢，因為它會變動，系統重啟的時候會從datanode那里重新構建。
name node的備份有幾種方式，一種是把持久化存放于硬盤的信息既寫到本地硬盤也同時寫到遠程NFS 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信息是在內存中的）。這個過程有可能會話費30分鐘或更久。client等不了啊～～
Hadoop 2提供了HA的support。namenode采用active-standby的配置方式：
namenodes使用高可用共享存儲來存edit log。active每次寫入都會被standby讀出并synchronize到自己的內存中。
datanodes在發送block reports時會同時發給所有的name nodes，記住block mapping是在內存中。
客戶端需要配置來handle namenode failover，其實就是watch zookeeper的leader election（參見我之前講的zookeeper）
這樣就不需要secondary namenode啦，standby取代了它的作用會周期性的產生check points
上面提到的共享存儲主要指的是QJM（quorum journal manager），通常配置3個（當然我也見過50個node配5個journal nodes），寫的時候需要滿足quorum。
這樣當active namenode fail時，standby可以馬上扛住，因為latest edit log和 up-to-date block mapping都在內存中。
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
(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。
相當于namenode sharding了，如果不想用HA，然后namenode內存又要爆了怎么辦，答分區呀，每個namenode從根目錄下劃走幾個子目錄，無線分區無線擴充，每個namenode之間井水不犯河水，一個爆了或廢了絲毫不影響另一個。
思考題：
如果HDFS有1PB容量，每個block大小是64MB，平均的metadata大小是每個block300B，replication factor是3， 那么namenode最小的內存是多少呢？
答：差不多需要1.56G， 1024*1024*1024 MB/(64MB*3)*300B/(1024 * 1024 * 1024) = 1.56 GB
感謝各位的閱讀！關于“Hadoop中HDFS適用于什么場景”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
