hadoop數據存儲結構
Ⅰ Hadoop系列之HDFS架構
本篇文章翻譯了Hadoop系列下的 HDFS Architecture ,原文最初經過筆者翻譯後大概有6000字,之後筆者對內容進行了精簡化壓縮,從而使筆者自己和其他讀者們閱讀本文時能夠更加高效快速的完成對Hadoop的學習或復習。本文主要介紹了Hadoop的整體架構,包括但不限於節點概念、命名空間、數據容錯機制、數據管理方式、簡單的腳本命令和垃圾回收概念。
PS:筆者新手一枚,如果看出哪裡存在問題,歡迎下方留言!
Hadoop Distributed File System(HDFS)是高容錯、高吞吐量、用於處理海量數據的分布式文件系統。
HDFS一般由成百上千的機器組成,每個機器存儲整個數據集的一部分數據,機器故障的快速發現與恢復是HDFS的核心目標。
HDFS對介面的核心目標是高吞吐量而非低延遲。
HDFS支持海量數據集合,一個集群一般能夠支持千萬以上數量級的文件。
HDFS應用需要對文件寫一次讀多次的介面模型,文件變更只支持尾部添加和截斷。
HDFS的海量數據與一致性介面特點,使得遷移計算以適應文件內容要比遷移數據從而支持計算更加高效。
HDFS支持跨平台使用。
HDFS使用主從架構。一個HDFS集群由一個NameNode、一個主伺服器(用於管理系統命名空間和控制客戶端文件介面)、大量的DataNode(一般一個節點一個,用於管理該節點數據存儲)。HDFS對外暴露了文件系統命名空間並允許在文件中存儲用戶數據。一個文件被分成一個或多個塊,這些塊存儲在一組DataNode中。NameNode執行文件系統命名空間的打開關閉重命名等命令並記錄著塊和DataNode之間的映射。DataNode用於處理客戶端的讀寫請求和塊的相關操作。NameNode和DataNode一般運行在GNU/Linux操作系統上,HDFS使用Java語言開發的,因此NameNode和DataNode可以運行在任何支持Java的機器上,再加上Java語言的高度可移植性,使得HDFS可以發布在各種各樣的機器上。一個HDFS集群中運行一個NameNode,其他機器每個運行一個(也可以多個,非常少見)DataNode。NameNode簡化了系統的架構,只用於存儲所有HDFS元數據,用戶數據不會進入該節點。下圖為HDFS架構圖:
HDFS支持傳統的分層文件管理,用戶或者應用能夠在目錄下創建目錄或者文件。文件系統命名空間和其他文件系統是相似的,支持創建、刪除、移動和重命名文件。HDFS支持用戶數量限制和訪問許可權控制,不支持軟硬鏈接,用戶可以自己實現軟硬鏈接。NameNode控制該命名空間,命名空間任何變動幾乎都要記錄到NameNode中。應用可以在HDFS中對文件聲明復制次數,這個次數叫做復制系數,會被記錄到NameNode中。
HDFS將每個文件存儲為一個或多個塊,並為文件設置了塊的大小和復制系數從而支持文件容錯。一個文件所有的塊(除了最後一個塊)大小相同,後來支持了可變長度的塊。復制系數在創建文件時賦值,後續可以更改。文件在任何時候只能有一個writer。NameNode負責塊復制,它周期性收到每個數據節點的心跳和塊報告,心跳錶示數據節點的正常運作,塊報告包含了這個DataNode的所有塊。
副本存儲方案對於HDFS的穩定性和性能至關重要。為了提升數據可靠性、靈活性和充分利用網路帶寬,HDFS引入了機架感知的副本存儲策略,該策略只是副本存儲策略的第一步,為後續優化打下基礎。大型HDFS集群一般運行於橫跨許多支架的計算機集群中,一般情況下同一支架中兩個節點數據傳輸快於不同支架。一種簡單的方法是將副本存放在單獨的機架上,從而防止丟失數據並提高帶寬,但是增加了數據寫入的負擔。一般情況下,復制系數是3,HDFS存儲策略是將第一份副本存儲到本地機器或者同一機架下一個隨機DataNode,另外兩份副本存儲到同一個遠程機架的不同DataNode。NameNode不允許同一DataNode存儲相同副本多次。在機架感知的策略基礎上,後續支持了 存儲類型和機架感知相結合的策略 ,簡單來說就是在機架感知基礎上判斷DataNode是否支持該類型的文件,不支持則尋找下一個。
HDFS讀取數據使用就近原則,首先尋找相同機架上是否存在副本,其次本地數據中心,最後遠程數據中心。
啟動時,NameNode進入安全模式,該模式下不會發生數據塊復制,NameNode接收來自DataNode的心跳和塊報告,每個塊都有一個最小副本數量n,數據塊在NameNode接受到該塊n次後,認為這個數據塊完成安全復制。當完成安全復制的數據塊比例達到一個可配的百分比值並再過30s後,NameNode退出安全模式,最後判斷是否仍然存在未達到最小復制次數的數據塊,並對這些塊進行復制操作。
NameNode使用名為EditLog的事務日誌持續記錄文件系統元數據的每一次改動(如創建文件、改變復制系數),使用名為FsImage的文件存儲全部的文件系統命名空間(包括塊到文件的映射關系和文件系統的相關屬性),EditLog和FsImage都存儲在NameNode本地文件系統中。NameNode在內存中保存著元數據和塊映射的快照,當NameNode啟動後或者某個配置項達到閾值時,會從磁碟中讀取EditLog和FsImage,通過EditLog新的記錄更新內存中的FsImage,再講新版本的FsImage刷新到磁碟中,然後截斷EditLog中已經處理的記錄,這個過程就是一個檢查點。檢查點的目的是確保文件系統通過在內存中使用元數據的快照從而持續的觀察元數據的變更並將快照信息存儲到磁碟FsImage中。檢查點通過下面兩個配置參數出發,時間周期(dfs.namenode.checkpoint.period)和文件系統事務數量(dfs.namenode.checkpoint.txns),二者同時配置時,滿足任意一個條件就會觸發檢查點。
所有的HDFS網路協議都是基於TCP/IP的,客戶端建立一個到NameNode機器的可配置的TCP埠,用於二者之間的交互。DataNode使用DataNode協議和NameNode交互,RPC包裝了客戶端協議和DataNode協議,通過設計,NameNode不會發起RPC,只負責響應來自客戶端或者DataNode的RPC請求。
HDFS的核心目標是即使在失敗或者錯誤情況下依然能夠保證數據可靠性,三種常見失敗情況包括NameNode故障、DataNode故障和network partitions。
網路分區可能會導致部分DataNode市區和NameNode的連接,NameNode通過心跳包判斷並將失去連接的DataNode標記為掛掉狀態,於是所有注冊到掛掉DataNode的數據都不可用了,可能會導致部分數據塊的復制數量低於了原本配置的復制系數。NameNode不斷地追蹤哪些需要復制的塊並在必要時候進行復制,觸發條件包含多種情況:DataNode不可用、復制亂碼、硬體磁碟故障或者認為增大負值系數。為了避免DataNode的狀態不穩定導致的復制風暴,標記DataNode掛掉的超時時間設置比較長(默認10min),用戶可以設置更短的時間間隔來標記DataNode為陳舊狀態從而避免在對讀寫性能要求高的請求上使用這些陳舊節點。
HDFS架構兼容數據各種重新平衡方案,一種方案可以在某個DataNode的空閑空間小於某個閾值時將數據移動到另一個DataNode上;在某個特殊文件突然有高的讀取需求時,一種方式是積極創建額外副本並且平衡集群中的其他數據。這些類型的平衡方案暫時還未實現(不太清楚現有方案是什麼...)。
存儲設備、網路或者軟體的問題都可能導致從DataNode獲取的數據發生亂碼,HDFS客戶端實現了對文件內容的校驗,客戶端在創建文件時,會計算文件中每個塊的校驗值並存儲到命名空間,當客戶端取回數據後會使用校驗值對每個塊進行校驗,如果存在問題,客戶端就會去另一個DataNode獲取這個塊的副本。
FsImage和EditLog是HDFS的核心數據結構,他們的錯誤會導致整個HDFS掛掉,因此,NameNode應該支持時刻維持FsImage和EditLog的多分復制文件,它們的任何改變所有文件應該同步更新。另一個選擇是使用 shared storage on NFS 或者 distributed edit log 支持多個NameNode,官方推薦 distributed edit log 。
快照能夠存儲某一特殊時刻的數據副本,從而支持HDFS在發生錯誤時會滾到上一個穩定版本。
HDFS的應用場景是大的數據集下,且數據只需要寫一次但是要讀取一到多次並且支持流速讀取數據。一般情況下一個塊大小為128MB,因此一個文件被切割成128MB的大塊,且每個快可能分布在不同的DataNode。
當客戶端在復制系數是3的條件下寫數據時,NameNode通過目標選擇演算法收到副本要寫入的DataNode的集合,第1個DataNode開始一部分一部分的獲取數據,把每個部分存儲到本地並轉發給第2個DataNode,第2個DataNode同樣的把每個部分存儲到本地並轉發給第3個DataNode,第3個DataNode將數據存儲到本地,這就是管道復制。
HDFS提供了多種訪問方式,比如 FileSystem Java API 、 C language wrapper for this Java API 和 REST API ,而且還支持瀏覽器直接瀏覽。通過使用 NFS gateway ,客戶端可以在本地文件系統上安裝HDFS。
HDFS使用目錄和文件的方式管理數據,並提供了叫做 FS shell 的命令行介面,下面有一些簡單的命令:
DFSAdmin命令集合用於管理HDFS集群,這些命令只有集群管理員可以使用,下面有一些簡單的命令:
正常的HDFS安裝都會配置一個web服務,通過可配的TCP埠對外暴露命名空間,從而使得用戶可以通過web瀏覽器查看文件內容。
如果垃圾回收配置打開,通過FS shell移除的文件不會立刻刪除,而是會移動到一個垃圾文件專用的目錄(/user/<username>/.Trash),類似回收站,只要文件還存在於那個目錄下,則隨時可以被回復。絕大多數最近刪除的文件都被移動到了垃圾目錄(/user/<username>/.Trash/Current),並且HDFS每個一段時間在這個目錄下創建一個檢查點用於刪除已經過期的舊的檢查點,詳情見 expunge command of FS shell 。在垃圾目錄中的文件過期後,NameNode會刪除這個文件,文件刪除會引起這個文件的所有塊的空間空閑,需要注意的是在文件被刪除之後和HDFS的可用空間變多之間會有一些時間延遲(個人認為是垃圾回收機制佔用的時間)。下面是一些簡單的理解刪除文件的例子:
當文件復制系數減小時,NameNode會選擇多餘的需要刪除的副本,在收到心跳包時將刪除信息發送給DataNode。和上面一樣,這個刪除操作也是需要一些時間後,才能在集群上展現空閑空間的增加。
HDFS Architecture
Ⅱ hadoop集群的存儲架構一般適宜採用das,nas,san或其他什麼架構
數據局部性(data locality):這是Hadoop的主要特性,指的是直接在存儲數據的節點上做CPU密集型計算。顯然,SAN/NAS不適用於任何形式的CPU密集型計算。
RAID:SAN/NAS採用RAID磁碟陣列進行存儲,而Hadoop框架通過復本來確保數據的可靠性和容錯性。
DAS採用JBOD磁碟數組進行存儲,如果Hadoop節點的內置存儲容量較小,可以採用DAS做擴展。如果只是想通過Hadoop做數據歸檔,沒有計算,好吧,SAN/NAS是個選擇。