分佈式文件存儲
隨着數據量的不斷增大,文件的大小取決於單機存儲的上限,這顯然知足不了咱們的需求。HDFS將大文件切塊,部署到不一樣的機器節點上,完成分佈式存儲。算法
在分佈式系統中,計算機節點放在機架上,每一個機架存在不少節點,不一樣機架之間經過交換機通訊,同一機架不一樣節點之間經過網絡互連。編程
遠程調用:遠程過程調用(RPC)是一種經常使用的分佈式網絡通訊協議,它容許運行於 一臺計算機的程序調用另外一臺計算機的子程序,同時將網絡的通訊細節隱藏起來, 使得用戶無須額外地爲這個交互做用編程。分佈式系統之間的通訊大都經過RPC實現。網絡
名稱節點負責文件和目錄的建立、刪除和重命名等,同時管理數據節點與文件塊的映射關係;數據節點負責數據的存儲和讀取。數據結構
客戶端讀數據會先訪問名稱節點,獲取數據塊對應數據節點的位置,進而讀取數據,寫入數據也會由名稱節點分配存儲位置,再向對應數據節點寫入數據。分佈式
名稱節點的兩個核心數據結構:大數據
FsImage
FsImage用於維護文件系統樹以及文件樹中全部的文件和文件夾的元數據
元數據信息包括文件的複製等級、修改和訪問時間、訪問權限、塊大小以及組成文件的塊
注:FsImage文件沒有記錄塊存儲在哪一個節點,數據塊和節點映射信息保存在NameNode的內存中。翻譯
EditLog
記錄對全部文件建立、刪除、重命名等操做。3d
secondDaryNameNode會按期與NameNode通訊,暫停EditLog,建立新的EditNew,瞬間完成 。cdn
FsImage和EditLog會不斷增大,secondDaryNameNode能夠解決這個問題,它會按期拉取這兩個文件,進行一個合併過程,經過執行EditLog文件,獲得最新的FsImage,推送到NameNode, 代替原有的FsImage,同時使用editNew代替原有EditLog文件。blog
secondDaryNameNode 還能夠做爲冷備份,在NameNode宕機後使用它進行恢復
HdFS按塊存儲,每一個塊默認大小是128M,遠遠大於普通文件系統,這樣作的目的是爲了最小化尋址開銷。
文件存儲在磁盤上,磁盤讀取數據靠的是機械運動。
因此每次讀取數據花費的時間能夠分爲尋道時間、旋轉延遲、傳輸時間三個部分
HDFS讀取文件的時間就能夠分爲尋址時間和數據傳輸時間,若是文件過小,在名稱節點的映射列表會過大,影響尋址時間,尋址時間若是大於傳輸時間,就沒有意義了。因此設置成大文件。
若是Block設置過大,在MapReduce任務中,Map或者Reduce任務的個數小於集羣機器數量,會使得做業運行效率很低。
HDFS採起多副本進行數據冗餘,一個數據塊默認冗餘三個副本,其中一個副本放到不一樣機架上,其它兩個副本放在同一個機架不一樣節點上。
如圖,數據塊1被分別存放到數據節點A和C上,數據塊2被存放在數據節點A和B上
網絡傳輸或者磁盤讀寫可能會致使數據錯誤
解決辦法:
寫入:
讀取:
HDFS提供了一個API能夠肯定一個數據節點所屬的機架ID,客戶端也能夠調用API獲取本身所屬的機架ID
客戶端請求NameNode,計算出距離client最近的副本,返回元數據信息;
當客戶端讀取數據時,從名稱節點得到數據塊不一樣副本的存放位置列表,列表中包含了副本所在的數據節點,能夠調用API來肯定客戶端和這些數據節點所屬的機架ID,當發現某個數據塊副本對應的機架ID和客戶端對應的機架ID相同時,就優先選擇該副本讀取數據,若是沒有發現,就隨機選擇一個副本讀取數據
客戶端讀取對應數據塊信息。
本文參考廈門大學林子雨老師的大數據課程