HDFS是一個不錯的分佈式文件系統，它有很多的優點，但也存在有一些缺點。目前而言，它在以下幾個方面就效率不佳：
低延時訪問
HDFS不太適合於那些要求低延時（數十毫秒）訪問的應用程序，因爲HDFS是設計用於大吞吐量數據的，這是以一定延時爲代價的。HDFS是單Master的，所有的對文件的請求都要經過它，當請求多時，肯定會有延時。當前，對於那些有低延時要求的應用程序，HBase是一個更好的選擇。現在HBase的版本是0.20，相對於以前的版本，在性能上有了很大的提升，它的口號就是goes real time。
使用緩存或多master設計可以降低client的數據請求壓力，以減少延時。還有就是對HDFS系統內部的修改，這就得權衡大吞吐量與低延時了，HDFS不是萬能的銀彈。
大量小文件
因爲Namenode把文件系統的元數據放置在內存中，所以文件系統所能容納的文件數目是由Namenode的內存大小來決定。一般來說，每一個文件、 文件夾和Block需要佔據150字節左右的空間，所以，如果你有100萬個文件，每一個佔據一個Block，你就至少需要300MB內存。當前來說，數 百萬的文件還是可行的，當擴展到數十億時，對於當前的硬件水平來說就沒法實現了。還有一個問題就 是，因爲Map task的數量是由splits來決定的，所以用MR處理大量的小文件時，就會產生過多的Map task，線程管理開銷將會增加作業時間。舉個例子，處理10000M的文件，若每個split爲1M，那就會有10000個Map tasks，會有很大的線程開銷；若每個split爲100M，則只有100個Map tasks，每個Map task將會有更多的事情做，而線程的管理開銷也將減小很多。
要想讓HDFS能處理好小文件，有不少方法：
1、利用SequenceFile、MapFile、Har等方式歸檔小文件，這個方法的原理就是把小文件歸檔起來管理，HBase就是基於此的。對於這種方法，如果想找回原來的小文件內容，那就必須得知道與歸檔文件的映射關係。
2、橫向擴展，一個Hadoop集羣能管理的小文件有限，那就把幾個Hadoop集羣拖在一個虛擬服務器後面，形成一個大的Hadoop集羣。google也是這麼幹過的。
3、多Master設計，這個作用顯而易見了。正在研發中的GFS II也要改爲分佈式多Master設計，還支持Master的Failover，而且Block大小改爲1M，有意要調優處理小文件啊。
附帶個Alibaba DFS的設計，也是多Master設計，它把Metadata的映射存儲和管理分開了，由多個Metadata存儲節點和一個查詢Master節點組成。
多用戶寫，任意文件修改
目前Hadoop只支持單用戶寫，不支持併發多用戶寫。可以使用Append操作在文件的末尾添加數據，但不支持在文件的任意位置進行修改。這些特性可能會在將來的版本中加入，但是這些特性的加入將會降低Hadoop的效率，就拿GFS來說吧，這篇文章裏就說了google自己的人都用着Multiple Writers很不爽。
利用Chubby、ZooKeeper之類的分佈式協調服務來解決一致性問題。
本文轉載自：http://www.cnblogs.com/wycg1984/archive/2010/03/20/1690281.html