HDFS有哪些缺點及改進策略

小編給大家分享一下HDFS有哪些缺點及改進策略，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

HDFS是一個不錯的分布式文件系統(tǒng)，它有很多的優(yōu)點，但也存在有一些缺點。目前而言，它在以下幾個方面就效率不佳：
　　低延時訪問
　　HDFS不太適合于那些要求低延時（數(shù)十毫秒）訪問的應用程序，因為HDFS是設(shè)計用于大吞吐量數(shù)據(jù)的，這是以一定延時為代價的。HDFS是單Master的，所有的對文件的請求都要經(jīng)過它，當請求多時，肯定會有延時。當前，對于那些有低延時要求的應用程序，HBase是一個更好的選擇?，F(xiàn)在HBase的版本是0.20，相對于以前的版本，在性能上有了很大的提升，它的口號就是goes real time。
　　使用緩存或多master設(shè)計可以降低client的數(shù)據(jù)請求壓力，以減少延時。還有就是對HDFS系統(tǒng)內(nèi)部的修改，這就得權(quán)衡大吞吐量與低延時了，HDFS不是萬能的銀彈。
　　大量小文件
　 　因為Namenode把文件系統(tǒng)的元數(shù)據(jù)放置在內(nèi)存中，所以文件系統(tǒng)所能容納的文件數(shù)目是由Namenode的內(nèi)存大小來決定。一般來說，每一個文件、 文件夾和Block需要占據(jù)150字節(jié)左右的空間，所以，如果你有100萬個文件，每一個占據(jù)一個Block，你就至少需要300MB內(nèi)存。當前來說，數(shù) 百萬的文件還是可行的，當擴展到數(shù)十億時，對于當前的硬件水平來說就沒法實現(xiàn)了。還有一個問題就 是，因為Map task的數(shù)量是由splits來決定的，所以用MR處理大量的小文件時，就會產(chǎn)生過多的Map task，線程管理開銷將會增加作業(yè)時間。舉個例子，處理10000M的文件，若每個split為1M，那就會有10000個Map tasks，會有很大的線程開銷；若每個split為100M，則只有100個Map tasks，每個Map task將會有更多的事情做，而線程的管理開銷也將減小很多。
　　要想讓HDFS能處理好小文件，有不少方法：
　　1、利用SequenceFile、MapFile、Har等方式歸檔小文件，這個方法的原理就是把小文件歸檔起來管理，HBase就是基于此的。對于這種方法，如果想找回原來的小文件內(nèi)容，那就必須得知道與歸檔文件的映射關(guān)系。
　　2、橫向擴展，一個Hadoop集群能管理的小文件有限，那就把幾個Hadoop集群拖在一個虛擬服務器后面，形成一個大的Hadoop集群。google也是這么干過的。
　　3、多Master設(shè)計，這個作用顯而易見了。正在研發(fā)中的GFS II也要改為分布式多Master設(shè)計，還支持Master的Failover，而且Block大小改為1M，有意要調(diào)優(yōu)處理小文件啊。
附帶個Alibaba DFS的設(shè)計，也是多Master設(shè)計，它把Metadata的映射存儲和管理分開了，由多個Metadata存儲節(jié)點和一個查詢Master節(jié)點組成。
　　Alibaba DFS（目前下載不了，加群60534259吧（Hadoop技術(shù)交流），群共享里有下 ：））
　　多用戶寫，任意文件修改
　　目前Hadoop只支持單用戶寫，不支持并發(fā)多用戶寫?？梢允褂肁ppend操作在文件的末尾添加數(shù)據(jù)，但不支持在文件的任意位置進行修改。這些特性可能會在將來的版本中加入，但是這些特性的加入將會降低Hadoop的效率，就拿GFS來說吧，這篇文章里就說了google自己的人都用著Multiple Writers很不爽。
　　利用Chubby、ZooKeeper之類的分布式協(xié)調(diào)服務來解決一致性問題。

以上是“HDFS有哪些缺點及改進策略”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學習更多知識，歡迎關(guān)注億速云行業(yè)資訊頻道！