HDFS的優點：

        1、處理超大檔案

                這裡的超大檔案通常是指百MB、甚至數百TB大小的檔案。目前在實際應用中，HDFS已經能用來儲存管理PB級的資料了。

        2、流式的訪問資料

                HDFS的設計建立在“一次寫入、多次讀寫”任務的基礎上。這意味著一個數據集一旦由資料來源生成，就會被複制分發到不同的儲存節點中，然後響應各種各樣的資料分析任務請求。在多數情況下，分析任務都會涉及資料集中的大部分資料，也就是說，對HDFS來說，請求讀取整個資料集要比讀取一條記錄更加高效。

        3、運行於廉價的商用機器叢集上

                Hadoop設計對應急需求比較低，只須執行在低廉的商用硬體叢集上，而無需在昂貴的高可用性機器上。廉價的商用機也就意味著大型叢集中出現節點故障情況的概率非常高。HDFS遇到了上述故障時，被設計成能夠繼續執行且不讓使用者察覺到明顯的中斷。

HDFS的缺點：

        1、不適合低延遲資料訪問

                如果要處理一些使用者要求時間比較短的低延遲應用請求，則HDFS不適合。HDFS是為了處理大型資料集分析任務的，主要是為達到高的資料吞吐量而設計的，這就可能要求以高延遲作為代價。

                改進策略：

                        對於那些有低延時要求的應用程式，HBase是一個更好的選擇，通過上層資料管理專案儘可能地彌補這個不足。在效能上有了很大的提升，它的口號是goes real time。使用快取或多個master設計可以降低Clinet的資料請求壓力，以減少延時。

        2、無法高效儲存大量的小檔案

                因為NameNode把檔案系統的元資料放置在記憶體中，所有檔案系統所能容納的檔案數目是由NameNode的記憶體大小來決定。還有一個問題就是，因為MapTask的數量是由Splits來決定的，所以用MR處理大量的小檔案時，就會產生過多的MapTask，執行緒管理開銷將會增加作業時間。當Hadoop處理很多小檔案(檔案大小小於HDFS中Block大小)的時候，由於FileInputFormat不會對小檔案進行劃分，所以每一個小檔案都會被當做一個Split並分配一個Map任務，導致效率底下。

                例如：一個1G的檔案，會被劃分成16個64MB的Split，並分配16個Map任務處理，而10000個100Kb的檔案會被10000個Map任務處理。

                改進策略：

                        要想讓HDFS能處理好小檔案，有不少方法。利用SequenceFile、MapFile、Har等方式歸檔小檔案，這個方法的原理就是把小檔案歸檔起來管理，HBase就是基於此的。

                    原因

                                   1.定址時間長 不划算

                                   2.會造成namenode的壓力過大

        3、不支援多使用者寫入及任意修改檔案

                在HDFS的一個檔案中只有一個寫入者，而且寫操作只能在檔案末尾完成，即只能執行追加操作，目前HDFS還不支援多個使用者對同一檔案的寫操作，以及在檔案任意位置進行修改。

                但是支援檔案追加