HDFS是一個(gè)不錯(cuò)的分布式文件系統(tǒng)，它有很多的優(yōu)點(diǎn)，但也存在有一些缺點(diǎn)。目前而言，它在以下幾個(gè)方面就效率不佳：

低延時(shí)訪問

HDFS不太適合于那些要求低延時(shí)（數(shù)十毫秒）訪問的應(yīng)用程序，因?yàn)镠DFS是設(shè)計(jì)用于大吞吐量數(shù)據(jù)的，這是以一定延時(shí)為代價(jià)的。HDFS是單Master的，所有的對(duì)文件的請(qǐng)求都要經(jīng)過它，當(dāng)請(qǐng)求多時(shí)，肯定會(huì)有延時(shí)。當(dāng)前，對(duì)于那些有低延時(shí)要求的應(yīng)用程序，HBase是一個(gè)更好的選擇。現(xiàn)在HBase的版本是0.20，相對(duì)于以前的版本，在性能上有了很大的提升，它的口號(hào)就是goes real time。

使用緩存或多master設(shè)計(jì)可以降低client的數(shù)據(jù)請(qǐng)求壓力，以減少延時(shí)。還有就是對(duì)HDFS系統(tǒng)內(nèi)部的修改，這就得權(quán)衡大吞吐量與低延時(shí)了，HDFS不是萬能的銀彈。

大量小文件

因?yàn)镹amenode把文件系統(tǒng)的元數(shù)據(jù)放置在內(nèi)存中，所以文件系統(tǒng)所能容納的文件數(shù)目是由Namenode的內(nèi)存大小來決定。一般來說，每一個(gè)文件、文件夾和Block需要占據(jù)150字節(jié)左右的空間，所以，如果你有100萬個(gè)文件，每一個(gè)占據(jù)一個(gè)Block，你就至少需要300MB內(nèi)存。當(dāng)前來說，數(shù)百萬的文件還是可行的，當(dāng)擴(kuò)展到數(shù)十億時(shí)，對(duì)于當(dāng)前的硬件水平來說就沒法實(shí)現(xiàn)了。還有一個(gè)問題就是，因?yàn)镸ap task的數(shù)量是由splits來決定的，所以用MR處理大量的小文件時(shí)，就會(huì)產(chǎn)生過多的Maptask，線程管理開銷將會(huì)增加作業(yè)時(shí)間。舉個(gè)例子，處理10000M的文件，若每個(gè)split為1M，那就會(huì)有10000個(gè)Maptasks，會(huì)有很大的線程開銷；若每個(gè)split為100M，則只有100個(gè)Maptasks，每個(gè)Maptask將會(huì)有更多的事情做，而線程的管理開銷也將減小很多。

要想讓HDFS能處理好小文件，有不少方法：

1、利用SequenceFile、MapFile、Har等方式歸檔小文件，這個(gè)方法的原理就是把小文件歸檔起來管理，HBase就是基于此的。對(duì)于這種方法，如果想找回原來的小文件內(nèi)容，那就必須得知道與歸檔文件的映射關(guān)系。

2、橫向擴(kuò)展，一個(gè)Hadoop集群能管理的小文件有限，那就把幾個(gè)Hadoop集群拖在一個(gè)虛擬服務(wù)器后面，形成一個(gè)大的Hadoop集群。google也是這么干過的。

3、多Master設(shè)計(jì)，這個(gè)作用顯而易見了。正在研發(fā)中的GFS II也要改為分布式多Master設(shè)計(jì)，還支持Master的Failover，而且Block大小改為1M，有意要調(diào)優(yōu)處理小文件啊。

附帶個(gè)Alibaba DFS的設(shè)計(jì)，也是多Master設(shè)計(jì)，它把Metadata的映射存儲(chǔ)和管理分開了，由多個(gè)Metadata存儲(chǔ)節(jié)點(diǎn)和一個(gè)查詢Master節(jié)點(diǎn)組成。

多用戶寫，任意文件修改

目前Hadoop只支持單用戶寫，不支持并發(fā)多用戶寫。可以使用Append操作在文件的末尾添加數(shù)據(jù)，但不支持在文件的任意位置進(jìn)行修改。這些特性可能會(huì)在將來的版本中加入，但是這些特性的加入將會(huì)降低Hadoop的效率，就拿GFS來說吧，這篇文章里就說了google自己的人都用著Multiple Writers很不爽。

利用Chubby、ZooKeeper之類的分布式協(xié)調(diào)服務(wù)來解決一致性問題。