hadoop只讀文件系統

A. 請問hadoop的hdfs文件系統和本地windows文件系統或linux文件系統是什麼關系啊，謝謝

hdfs的數據來實際上是存儲在本地文件系統源中的。在配置hadoop時你需要配置hdfs的存儲文件夾，如果你的用戶名為root，文件夾位置是/root/tmp。那麼你的hdfs的數據存儲在/root/tmp/dfs/data/current中。其中block是塊文件，也就是數據文件，.meta是元數據。hadoop是java寫的，因此hadoop存儲的數據的方式使用的也是java的方式。

B. spark和hadoop的區別

直接比較Hadoop和Spark有難度，因為它們處理的許多任務都一樣，但是在一些方面又並不相互重疊。

比如說，Spark沒有文件管理功能，因而必須依賴Hadoop分布式文件系統(HDFS)或另外某種解決方案。

Hadoop框架的主要模塊包括如下：

• Hadoop Common

• Hadoop分布式文件系統(HDFS)

• Hadoop YARN

• Hadoop MapRece

雖然上述四個模塊構成了Hadoop的核心，不過還有其他幾個模塊。這些模塊包括：Ambari、Avro、Cassandra、Hive、 Pig、Oozie、Flume和Sqoop，它們進一步增強和擴展了Hadoop的功能。

Spark確實速度很快(最多比Hadoop MapRece快100倍)。Spark還可以執行批量處理，然而它真正擅長的是處理流工作負載、互動式查詢和機器學習。

相比MapRece基於磁碟的批量處理引擎，Spark賴以成名之處是其數據實時處理功能。Spark與Hadoop及其模塊兼容。實際上，在Hadoop的項目頁面上，Spark就被列為是一個模塊。

Spark有自己的頁面，因為雖然它可以通過YARN(另一種資源協調者)在Hadoop集群中運行，但是它也有一種獨立模式。它可以作為 Hadoop模塊來運行，也可以作為獨立解決方案來運行。

MapRece和Spark的主要區別在於，MapRece使用持久存儲，而Spark使用彈性分布式數據集(RDDS)。

性能

Spark之所以如此快速，原因在於它在內存中處理一切數據。沒錯，它還可以使用磁碟來處理未全部裝入到內存中的數據。

Spark的內存處理為來自多個來源的數據提供了近乎實時分析的功能：營銷活動、機器學習、物聯網感測器、日誌監控、安全分析和社交媒體網站。另 外，MapRece使用批量處理，其實從來就不是為驚人的速度設計的。它的初衷是不斷收集來自網站的信息，不需要這些數據具有實時性或近乎實時性。

易用性

支持Scala(原生語言)、Java、Python和Spark SQL。Spark SQL非常類似於SQL 92，所以幾乎不需要經歷一番學習，馬上可以上手。

Spark還有一種交互模式，那樣開發人員和用戶都可以獲得查詢和其他操作的即時反饋。MapRece沒有交互模式，不過有了Hive和Pig等附加模塊，採用者使用MapRece來得容易一點。

成本

「Spark已證明在數據多達PB的情況下也輕松自如。它被用於在數量只有十分之一的機器上，對100TB數據進行排序的速度比Hadoop MapRece快3倍。」這一成績讓Spark成為2014年Daytona GraySort基準。

兼容性

MapRece和Spark相互兼容;MapRece通過JDBC和ODC兼容諸多數據源、文件格式和商業智能工具，Spark具有與MapRece同樣的兼容性。

數據處理

MapRece是一種批量處理引擎。MapRece以順序步驟來操作，先從集群讀取數據，然後對數據執行操作，將結果寫回到集群，從集群讀 取更新後的數據，執行下一個數據操作，將那些結果寫回到結果，依次類推。Spark執行類似的操作，不過是在內存中一步執行。它從集群讀取數據後，對數據 執行操作，然後寫回到集群。

Spark還包括自己的圖形計算庫GraphX。GraphX讓用戶可以查看與圖形和集合同樣的數據。用戶還可以使用彈性分布式數據集(RDD)，改變和聯合圖形，容錯部分作了討論。

容錯

至於容錯，MapRece和Spark從兩個不同的方向來解決問題。MapRece使用TaskTracker節點，它為 JobTracker節點提供了心跳(heartbeat)。如果沒有心跳，那麼JobTracker節點重新調度所有將執行的操作和正在進行的操作，交 給另一個TaskTracker節點。這種方法在提供容錯性方面很有效，可是會大大延長某些操作(即便只有一個故障)的完成時間。

Spark使用彈性分布式數據集(RDD)，它們是容錯集合，裡面的數據元素可執行並行操作。RDD可以引用外部存儲系統中的數據集，比如共享式文件系統、HDFS、HBase，或者提供Hadoop InputFormat的任何數據源。Spark可以用Hadoop支持的任何存儲源創建RDD，包括本地文件系統，或前面所列的其中一種文件系統。

RDD擁有五個主要屬性：

• 分區列表

• 計算每個分片的函數

• 依賴其他RDD的項目列表

• 面向鍵值RDD的分區程序(比如說RDD是散列分區)，這是可選屬性

• 計算每個分片的首選位置的列表(比如HDFS文件的數據塊位置)，這是可選屬性

RDD可能具有持久性，以便將數據集緩存在內存中。這樣一來，以後的操作大大加快，最多達10倍。Spark的緩存具有容錯性，原因在於如果RDD的任何分區丟失，就會使用原始轉換，自動重新計算。

可擴展性

按照定義，MapRece和Spark都可以使用HDFS來擴展。那麼，Hadoop集群能變得多大呢?

據稱雅虎有一套42000個節點組成的Hadoop集群，可以說擴展無極限。最大的已知Spark集群是8000個節點，不過隨著大數據增多，預計集群規模也會隨之變大，以便繼續滿足吞吐量方面的預期。

安全

Hadoop支持Kerberos身份驗證，這管理起來有麻煩。然而，第三方廠商讓企業組織能夠充分利用活動目錄Kerberos和LDAP用於身份驗證。同樣那些第三方廠商還為傳輸中數據和靜態數據提供數據加密。

Hadoop分布式文件系統支持訪問控制列表(ACL)和傳統的文件許可權模式。Hadoop為任務提交中的用戶控制提供了服務級授權(Service Level Authorization)，這確保客戶擁有正確的許可權。

Spark的安全性弱一點，目前只支持通過共享密鑰(密碼驗證)的身份驗證。Spark在安全方面帶來的好處是，如果你在HDFS上運行Spark，它可以使用HDFS ACL和文件級許可權。此外，Spark可以在YARN上運行，因而能夠使用Kerberos身份驗證。

總結

Spark與MapRece是一種相互共生的關系。Hadoop提供了Spark所沒有的功能特性，比如分布式文件系統，而Spark 為需要它的那些數據集提供了實時內存處理。完美的大數據場景正是設計人員當初預想的那樣：讓Hadoop和Spark在同一個團隊裡面協同運行。

然後看這篇文章：Link



註：對下面這一段持保留意見：

此外我們這里還要講到的是一個關於spark的重要誤區—「spark是基於內存的技術」。它不是基於內存的技術；spark是一個管道式的執行引擎，而且在shuffle的過程中會將數據寫入磁碟(比如說，如果我們想針對某個欄位做聚合操作)、如果內存不夠的話也一樣會內存溢出(但是內存可以調整)。因此，spark之所以比MapRece快主要是因為它是管道式處理方式而不是有些人說的「基於內存的優化」。當然，spark在內存中做了緩存來提高性能，但這不是spark真正工作快的原因。

現在，我們再來完整比對一下：

1. MapRece可以被Spark Core替換？是的，它會隨著時間的推移被替代，而且這種替代是合理的。但是spark目前還不是特別成熟能完全替代MapRece。此外，也沒有人會完全放棄MapRece,除非所有依賴MapRece的工具都有可替代方案。比如說，想要在pig上運行的腳本能在spark上執行還是有些工作要做的。

（註：Pig是一種數據流語言，用來快速輕松的處理巨大的數據，雅虎推出的，現在正在走下坡路。Pig可以非常方便的處理HDFS和HBase的數據，和Hive一樣,Pig可以非常高效的處理其需要做的，通過直接操作Pig查詢可以節省大量的勞動和時間。當你想在你的數據上做一些轉換，並且不想編寫MapRece jobs就可以用Pig.）

2. Hive可以被Spark SQL替換？是的，這又是對的。但是我們需要理解的是Spark SQL對於spark本身來說還是比較年輕的，大概要年輕1.5倍。相對於比較成熟的Hive來說它只能算是玩具了吧，我將在一年半到兩年之內再回頭來看Spark SQL.。如果我們還記得的話，兩到三年前Impala就號稱要終結Hive,但是截止到目前兩種技術也還是共存狀態，Impala並沒有終結Hive。在這里對於Spark SQL來說也是一樣的。

3. Storm可以被Spark Streaming替換？是的，可以替換。只不過平心而論storm並不是Hadoop生態系統中的一員，因為它是完全獨立的工具。他們的計算模型並不太形同，所以我不認為storm會消失，反而仍會作為一個商業產品。

4. Mahout可以被MLib替換？公平的講，Machout已經失去了市場，而且從過去的幾年來看它正在快速失去市場。對於這個工具，我們可以說這里是Spark真正可以替換Hadoop生態系統中的地方。 (註：同意！Spark的ML非常好用！要好好學！)

因此，總的來說，這篇文章的結論是：

1.不要被大數據供應商的包裝所愚弄。他們大量推進的是市場而不是最終的真理。Hadoop最開始是被設計為可擴展的框架，而且其中很多部分是可替換的：可以將HDFS替換為Tachyon（現在新的名字是Alluxio），可以將YARN替換為Mesos，可以將MapRece替換為Tez並且在Tez之上可以運行Hive。這將會是Hadoop技術棧的可選方案或者完全替代方案？倘若我們放棄的MR（MapRece）而使用Tez,那麼它還會是Hadoop嗎？

2. Spark不能為我們提供完整的技術棧。它允許我們將它的功能集成到我們的Hadoop集群中並且從中獲益，而不用完全脫離我們老的集群方案。

3. Spark還不夠成熟。我認為在過三到四年我們就不會再叫「Hadoop棧」而是叫它「大數據棧」或者類似的稱呼。因為在大數據棧中我們有很廣泛的選擇可以選出不同的開源產品來組合在一起形成一個單獨的技術棧使用。

C. hadoop是分布式文件系統嗎

是的
Hadoop分布式文件系統(HDFS)是一種被設計成適合運行在通用硬體上的分布式文件系統。HDFS是一個高度容錯性的系統，適合部署在廉價的機器上。它能提供高吞吐量的數據訪問，非常適合大規模數據集上的應用。要理解HDFS的內部工作原理，首先要理解什麼是分布式文件系統。
1.分布式文件系統
多台計算機聯網協同工作(有時也稱為一個集群)就像單台系統一樣解決某種問題，這樣的系統我們稱之為分布式系統。
分布式文件系統是分布式系統的一個子集，它們解決的問題就是數據存儲。換句話說，它們是橫跨在多台計算機上的存儲系統。存儲在分布式文件系統上的數據自動分布在不同的節點上。
分布式文件系統在大數據時代有著廣泛的應用前景，它們為存儲和處理來自網路和其它地方的超大規模數據提供所需的擴展能力。
2.分離元數據和數據：NameNode和DataNode
存儲到文件系統中的每個文件都有相關聯的元數據。元數據包括了文件名、i節點(inode)數、數據塊位置等，而數據則是文件的實際內容。
在傳統的文件系統里，因為文件系統不會跨越多台機器，元數據和數據存儲在同一台機器上。
為了構建一個分布式文件系統，讓客戶端在這種系統中使用簡單，並且不需要知道其他客戶端的活動，那麼元數據需要在客戶端以外維護。HDFS的設計理念是拿出一台或多台機器來保存元數據，並讓剩下的機器來保存文件的內容。
NameNode和DataNode是HDFS的兩個主要組件。其中，元數據存儲在NameNode上，而數據存儲在DataNode的集群上。NameNode不僅要管理存儲在HDFS上內容的元數據，而且要記錄一些事情，比如哪些節點是集群的一部分，某個文件有幾份副本等。它還要決定當集群的節點宕機或者數據副本丟失的時候系統需要做什麼。
存儲在HDFS上的每份數據片有多份副本(replica)保存在不同的伺服器上。在本質上，NameNode是HDFS的Master(主伺服器)，DataNode是Slave(從伺服器)。

D. hadoop-hdfs safemode安全模式

當hdfs啟動的時候，會從fsimage當中載入文件系統狀態信息，然後會等到datanode報告塊的存儲情況，防止namenode過早地對塊進行復制。在等待datanode報告的這一段時間內，namenode會進入safemode，此時只是只讀模式，當datanode報告完之後，會自動退出safemode模式。

可以通過shell來人工打開 hdfs dfsadmin -safemode enter ,打開後，會在namenode的前端頁面中看到，此時進入了安全模式。如果這時候在進行寫操作，則會報錯，提醒進入了寫模式。eg：

$: bin/hadoop fs -touch /foodir/newfile.txt

touch: Cannot create file/foodir/newfile.txt. Name node is in safe mode.

也可以通過shell退出該模式 hdfs dfsadmin -safemode leave 。

E. Hadoop分布式文件系統HDFS和OpenStack對象存儲系統Swift有何不同

最近在Quora上有人提到一個問題，有關Hadoop分布式文件系統和OpenStack對象存儲的不同。
問題原文如下：
「HDFS （Hadoop分布式文件系統）和OpenStack對象存儲（OpenStack Object Storage）似乎都有著相似的目的：實現冗餘、快速、聯網的存儲。什麼樣的技術特性讓這兩種系統因而不一樣？這兩種存儲系統最終趨於融合是否大有意義？」
問題提出之後，很快有OpenStack的開發者進行了回復。本文在此摘抄了前兩名回復進行翻譯，以供各位參考。
排名第一的答案來自RackSpace的OpenStack Swift開發者Chuck Their：
雖然HDFS與Openstack對象存儲（Swift）之間有著一些相似之處，但是這兩種系統的總體設計卻大不一樣。
1. HDFS使用了中央系統來維護文件元數據（Namenode，名稱節點），而在Swift中，元數據呈分布式，跨集群復制。使用一種中央元數據系統對HDFS來說無異於單一故障點，因而擴展到規模非常大的環境顯得更困難。
2. Swift在設計時考慮到了多租戶架構，而HDFS沒有多租戶架構這個概念。
3. HDFS針對更龐大的文件作了優化（這是處理數據時通常會出現的情況），Swift被設計成了可以存儲任何大小的文件。
4. 在HDFS中，文件寫入一次，而且每次只能有一個文件寫入；而在Swift中，文件可以寫入多次；在並發操作環境下，以最近一次操作為准。
5. HDFS用Java來編寫，而Swift用Python來編寫。
另外，HDFS被設計成了可以存儲數量中等的大文件，以支持數據處理，而Swift被設計成了一種比較通用的存儲解決方案，能夠可靠地存儲數量非常多的大小不一的文件。
排名第二的答案來自Joshua McKenty，他是美國宇航局Nebula雲計算項目的首席架構師，是OpenStack Nova軟體的早期開發者之一，目前是OpenStack項目監管委員會的成員，還是Piston.cc這家基於OpenStack的公司的創始人。
Chuck剛才詳細介紹了兩者的技術差異，但是沒有討論兩者可想而知的融合，OpenStack設計峰會上拋出了融合這個話題。簡而言之，HDFS被設計成可以使用Hadoop，跨存儲環境裡面的對象實現MapRece處理。對於許多OpenStack公司（包括我自己的公司）來說，支持Swift裡面的處理是路線圖上面的一個目標，不過不是每個人都認為MapRece是解決之道。
我們已討論過為HDFS編寫包裝器，這將支持OpenStack內部存儲應用編程介面（API），並且讓用戶可以針對該數據來執行Hadoop查詢。還有一個辦法就是在Swift裡面使用HDFS。但是這些方法似乎沒有一個是理想的。
OpenStack社區方面也在開展研究開發方面的一些工作，認真研究其他替代性的MapRece框架（Riak和CouchDB等）。
最後，現在有別的一些存儲項目，目前「隸屬於」OpenStack社區（SheepDog和HC2）。充分利用數據局部性，並且讓對象存儲變得「更智能」，這是預計會取得進步的一個領域。

F. hadoop全家桶系列1-zookeeper

啟動ZK服務: sh bin/zkServer.sh start
查看ZK服務狀態: sh bin/zkServer.sh status
停止ZK服務: sh bin/zkServer.sh stop
重啟ZK服務: sh bin/zkServer.sh restart

顯示根目錄下、文件： ls / 使用 ls 命令來查看當前 ZooKeeper 中所包含的內容
顯示根目錄下、文件： ls2 / 查看當前節點數據並能看到更新次數等數據
創建文件，並設置初始內容： create /zk "test" 創建一個新的 znode節點「 zk 」以及與它關聯的字元串
獲取文件內容： get /zk 確認 znode 是否包含我們所創建的字元串
修改文件內容： set /zk "zkbak" 對 zk 所關聯的字元串進行設置
刪除文件： delete /zk 將剛才創建的 znode 刪除
退出客戶端： quit
幫助命令： help

執行hdfs zkfc -formatZK 初始化HA的zookeeper信息
hadoop namenode -format
在nn1上執行hadoop-daemon.sh start namenode
在nn2上執行hadoop namenode -bootstrapStandby 同步
在nn2上執行 hadoop-daemon.sh start namenode
在nn1和nn2分別啟動hadoop-daemon.sh start zkfc,這時兩個一個變成active,一個變成standby
hdfs haadmin -getServiceState 可查看HA狀態

注意HA不能切換是因為nn1和nn2的沒有安裝fuser
在nn1和nn2上執行yum -y install psmisc

改變文件副本數 setrep
hadoop fs -setrep -R -w 2 /test.txt
-R 遞歸改變目錄下所有文件的副本數。
-w 等待副本數調整完畢後返回。可理解為加了這個參數就是阻塞式的了。
hadoop dfsadmin
例如：hadoop dfsadmin -report
dfsadmin命令詳解
-report：查看文件系統的基本信息和統計信息。
-safemode <enter | leave | get | wait>：安全模式命令。安全模式是NameNode的一種狀態，在這種狀態下，NameNode不接受對名字空間的更改（只讀）；不復制或刪除塊。NameNode在啟動時自動進入安全模式，當配置塊的最小百分數滿足最小副本數的條件時，會自動離開安全模式。enter是進入，leave是離開。

G. 如何查看hadoop hdfs文件系統

使用插件——Hadoop-Eclipse-Plugin
此方法需要藉助Eclipse，插件的安裝及使用請參考博文。
藉助Eclipse只能進行簡單的HDFS操作，如查看，刪除，上傳，下載。以下是操作界面：

H. hadoop分布式文件系統具有怎樣的特性

硬體錯誤
硬體錯誤是常態而不是異常。HDFS可能由成百上千的伺服器所構成，每個伺服器上存儲著文件系統的部分數據。我們面對的現實是構成系統的組件數目是巨大的，而且任一組件都有可能失效，這意味著總是有一部分HDFS的組件是不工作的。因此錯誤檢測和快速、自動的恢復是HDFS最核心的架構目標。
流式數據訪問
運行在HDFS上的應用和普通的應用不同，需要流式訪問它們的數據集。HDFS的設計中更多的考慮到了數據批處理，而不是用戶交互處理。比之數據訪問的低延遲問題，更關鍵的在於數據訪問的高吞吐量。POSIX標准設置的很多硬性約束對HDFS應用系統不是必需的。為了提高數據的吞吐量，在一些關鍵方面對POSIX的語義做了一些修改。
大規模數據集
運行在HDFS上的應用具有很大的數據集。HDFS上的一個典型文件大小一般都在G位元組至T位元組。因此，HDFS被調節以支持大文件存儲。它應該能提供整體上高的數據傳輸帶寬，能在一個集群里擴展到數百個節點。一個單一的HDFS實例應該能支撐數以千萬計的文件。
簡單的一致性模型
HDFS應用需要一個「一次寫入多次讀取」的文件訪問模型。一個文件經過創建、寫入和關閉之後就不需要改變。這一假設簡化了數據一致性問題，並且使高吞吐量的數據訪問成為可能。Map/Rece應用或者網路爬蟲應用都非常適合這個模型。目前還有計劃在將來擴充這個模型，使之支持文件的附加寫操作。
「移動計算比移動數據更劃算」
一個應用請求的計算，離它操作的數據越近就越高效，在數據達到海量級別的時候更是如此。因為這樣就能降低網路阻塞的影響，提高系統數據的吞吐量。將計算移動到數據附近，比之將數據移動到應用所在顯然更好。HDFS為應用提供了將它們自己移動到數據附近的介面。
異構軟硬體平台間的可移植性
HDFS在設計的時候就考慮到平台的可移植性。這種特性方便了HDFS作為大規模數據應用平台的推廣。

I. Hadoop分布式文件系統HDFS和OpenStack對象存儲系統Swift有何不同

1.HDFS使用集中式單一節點架構(NameNode)來維護文件系統元數據，而在Swift中，元數據分布在整個集群中並擁有多個副本。注意：集中式元數據存儲使HDFS存在性能、單點故障和擴展性問題，因此規模越大就性能越低，就越容易不可用，就越難擴展甚至不能擴展，所幸的是HDFS2使用NameNode
HA和HDFS
Federation解決了這三個問題。
2.
Swift在設計時考慮到了多租戶架構，而HDFS沒有多租戶架構這個概念。
3.
HDFS針對大文件作了優化(HDFS關注吞吐量，常用於批量數據處理)，而Swift被設計成可以存儲任意大小的文件。
4.
在HDFS中，文件只能寫入一次（部分版本可以使用Append操作在文件的末尾添加數據，但不支持在文件的任意位置進行修改），而在Swift中，文件可以寫入多次。
5.
HDFS用Java來編寫，而Swift用Python來編寫。

J. Hadoop分布式文件系統（HDFS）會不會被淘汰

首先我們應該更具體的理解這樣一個現象，為什麼流行的技術框架會被淘汰。談到淘汰，常見兩種情況：

第一：應用模式被淘汰了，例如：BB機，功能機，最終被智能機淘汰，膠卷被數碼相機淘汰，即便諾基亞的功能機做得再完美，也會被淘汰。軟體方面例如：終端的字處理，郵件收發等應用軟體被視窗應用軟體淘汰。

第二：技術升級，新技術彌補了老技術的缺陷，並且引入了更多有優勢的功能。例如：Springframework的橫空出世，配合Hibernate，在具有同樣功效的情況下，解決了EJB的部署復雜，體態臃腫，計算效率低，用靈活性，面向程序員的友好性，淘汰了曾經企業級經典的EJB。

那麼對於Hadoop分布式文件系統（HDFS），我們要討論它的淘汰可能性，淘汰時間，首先我們就要看它為什麼要被淘汰的因素。從模式上，分布式文件系統是大數據存儲技術極為重要的一個領域，我們還看不到分布式文件系統有被淘汰的任何理由，那麼我就再看技術升級是否有淘汰它的可能性。

談技術升級，首先要看HDFS的缺點，然後再看這種缺點的解決辦法，是否會帶來新的技術框架，然後讓HDFS埋進歷史的垃圾堆。

HDFS為集中式協調架構，namenode若是單節點，部署並不復雜，但是namenode作為單節點無法可靠的運行在生產環境，必須對namenode實現雙機HA，那麼部署復雜度就變得極高，這時候需要在namenode，datanode的基礎上再引入namenode active，namenode standby的概念，需要引入QJM的元數據共享存儲並基於Paxos做一致性協調，另外需要引入ZKFC和ZooKeeper，解決主備選舉，健康探測，主備切換等操作。

因此HDFS的部署復雜度完全是因為namenode HA導致的。這是集中式管理的分布式架構一個原生問題，如果在這個地方進行優化的話，那麼就是簡化QJM，ZKFC，ZooKeeper的多組服務，用一組服務來代替，但是namenode和datanode的分布式數據塊的讀寫，復制，恢復機制，目前看非常成熟，高效，這是核心問題，並不是缺點，不需要更具顛覆性的優化。

由於namenode在內存中記錄了所有數據塊（block 默認128M）的信息，索引了數據塊與datanode的關系，並且構建了文件系統樹，因此可想而知namenode的元數據內存區是大量佔用內存，這是沒有上限的。對於較大型數據存儲項目，例如上百個datanode節點和上千萬個數據塊的容量來說，元數據在namenode的內存大概能控制在32G以內，這是還沒問題的，但是對於構建海量數據中心的超大型項目，這個問題就好像達摩克斯之劍，首先堆內存超過臨界范圍導致的內存定址性能問題不說，一旦namenode內存超限到單機內存可承載的物理上最大承受范圍，整個hdfs數據平台將面臨停止服務。

這個問題的本質還是Google設計GFS時候採用粗放的實用主義，先把元數據都交給主節點在內存中節制，超大問題以後再解決。目前Google的GFS2設計上，已經將元數據在內存中遷移至了BigTable上，那麼問題就來了：「BigTable基於GFS，而GFS2的元數據基於BigTable」？有點雞生蛋還是蛋生雞的自相矛盾。是的，看似矛盾實質上是架構的嵌套復用，可以這么去解讀：GFS2是基於<基於GFS的BigTable的元數據存儲>的下一代GFS架構。用BigTable的k-v存儲模型放GFS2的元數據，雖然沒有內存高效，但是夠用，而且可以無限存儲，用BigTable專門存儲元數據形成的k-v記錄最終保存成GFS數據塊，因此在GFS的元數據內存中只需少量的內存佔用，就能支撐天量的真正應用於數據塊存儲的GFS2元數據。

基於GFS2的設計思想，我相信下一代HDFS應該也是這樣的方案去解決元數據的內存瓶頸問題，也就是基於<基於HDFS的HBase的元數據存儲>的下一代HDFS架構。那麼HDFS的元數據瓶頸問題將被徹底解決，很難看到比這更具優勢的替代性技術框架了。

如下圖所示：

副本數默認為3最大的問題就是占空間，這幾乎是所有傳統分布式文件系統（DFS）的通病。因此HDFS集群的默認空間利用率只有33.3%，這么低的利用率顯然不符合一些場景，例如長期的冷數據備份，那麼有沒有更好的方式呢？是有的，目前比較成熟的方案就是糾刪碼技術，類似raid5，raid6，HDFS 3.0版本以後支持這種模式，叫做Erasure Coding(EC)方案。

HDFS是怎麼通過EC方案解決磁碟利用率的問題呢？我們先聊點比較硬的原理，說說EC方案之一的條形布局：

首先數據文件寫的時候會向N個節點的塊(Block)依次寫入，N個Block會被切成多組條(stripe 1... stripe n)，如果分布式環境有五個存儲節點(DataNode)，那麼就把stripe切成3個單元(cell)，然後再根據這3個cell計算出2個校驗cell，然後這5個cell（3個data+2個parity）分別寫入5個Block中。數據條就這么依次輪巡的方式，將校驗塊的位置輪換存儲在不同Block上，直至寫滿，這樣校驗塊的分布可以更均勻。

其次再說取數據，取數據每次只從3個DataNode中各取出1個cell，如果這3個cell都是數據cell，那麼就成功拿到一組數據條stripe，如果有一個cell是校驗cell，那麼就能通過校驗cell和另外2個數據cell計算出第3個數據cell，完成數據條stripe的組合。這種情況下，即便是5個datanode節點有2個datanode宕機了，另外3個datanode也能通過校驗碼計算完成剩餘2個節點的數據，這就是利用糾刪碼技術實現數據冗餘的原理。

通過這種方式，我們就比傳統2副本50%，3副本33.3%的多副本模式要省空間，EC中2+1可以達到66.7%的磁碟利用率，例子是3+2可以達到60%的磁碟利用率

但是其問題是特別消耗CPU計算，上面那種讀取情況，五分之三的讀取數據條時間都要進行校驗碼計算。因此可以利用Intel CPU推出的ISA-L底層函數庫專門用於提升校糾刪碼演算法的編解碼性能。通常情況下，糾刪碼用於冷數據的冗餘，也就是不經常訪問，但又必須聯機存儲以備查詢的數據。除了磁碟利用率，多副本方式用空間換效率的方式肯定是最好，沒什麼問題。