我要開始爲大四找工作做準備啦，開始複習關於大數據分佈式的知識。絕對乾貨！

1. 簡說分佈式文件系統

大數據時代必須要解決的就是海量數據的高效存儲問題，谷歌就針對這個問題開發出了GFS分佈式文件系統，近乎完美地解決了這個問題，而HDFS分佈式文件系統，則是GFS的開源實現，大家都可以來使用，這個也是Hadoop的兩大核心之一，其在設計之初就是爲了實現並提供在廉價服務器集羣中進行大規模分佈式文件存儲的能力，並且其還具有很好的容錯能力。

分佈式文件系統是一種通過網絡實現文件在多臺主機上進行分佈式存儲的文件系統，其採用一主多從結構，即“客戶機/服務器”模式，客戶端通過特定的通信協議與服務器建立連接，提出文件訪問要求，客戶端和服務器可以通過設置訪問權限來限制請求放對底層數據存儲塊的訪問。

目前通用且常見的分佈式文件系統就是GFS和HDFS.

2. 計算機集羣結構

分佈式文件系統就是把文件分佈式存儲到不同的計算機上，那麼這些不同的計算機就組成了計算機集羣，目前的計算機集羣都是廉價的普通計算機構成的，大大降低了在硬件上的開銷。

計算機集羣中的計算機放在機架上，每個機架可以存放8~64個計算機節點，同一機架上的計算機之間的通信通過網絡來完成，不同機架之間通過另一極網絡或者交換機來相互連接通信。

但所有計算機的數據都存放在本地的Linux操作系統上。

我自己總結畫的圖:

3. 分佈式文件系統的結構

常用的Windows，Linux等操作系統，文件系統一般會把磁盤空間劃分爲每512字節爲一組，稱之爲“磁盤”，它是文件系統讀寫操作的最小單位，文件系統中的塊通常是磁盤塊的整數倍，即每次讀寫的數據量必須是磁盤塊大小的整數倍。

與普通的文件系統類似，分佈式文件系統也採用了塊的概念，文件在進行存儲的時候被分成若干的塊進行存儲，塊是數據讀寫的基本單位，在分佈式文件系統中塊的大小默認爲64MB，認爲也可設置最基本的塊的大小，當進行文件的分塊的時候，若文件的大小小於64MB，它並不會佔據整個的存儲空間。

分佈式文件系統的整體結構可以看做是一主多從結構，其在物理節點上是由許多的計算機節點組成的，這些節點分爲兩類：主節點和從節點

3.1 主節點（NameNode）

主節點又被稱爲名稱節點（NameNode），負責文件和目錄的創建，刪除，重命名等，管理數據和文件塊的映射關係。因此客戶端要訪問存儲的文件的時候，必須先訪問名稱節點，得到其文件所分成的文件塊的存儲位置信息，直接與其文件塊進行信息的讀取。

3.2 從節點（DataNode）

從節點又被成爲數據節點（DataNode），負責數據的存儲，讀取，在存儲時由名稱節點分配存儲位置，之後客戶端直接把數據存儲相應的位置，其之間的映射關係也就存放在名稱節點當中。數據節點也是根據NameNode的命令進行創建和刪除。

3.3 NameNode 和 DataNode 二者和客戶端之間的關係圖

4. 客戶端，NameNode，DataNode之間的兩兩通信方式

客戶端和NameNode TCP
客戶端和DataNode RPC
NameNode和DataNode 數據協議

5. HDFS的相關概念

5.1 塊

在HDFS分佈式文件系統中，其最小的數據基本存儲單元是以塊爲單位的，默認爲64MB（最初的分佈式文件系統，現在的應該是128MB），當然塊的大小是人爲可以設定的，這麼做的原因是爲了最小化地址開銷。在Map任務中每次只對一個塊中的數據進行處理。這樣做的好處有三點：（1）支持大規模的文件存儲（2）簡化系統設計（3）適合的備份數據

5.2 名稱節點（NameNode）

名稱節點負責管理分佈式文件系統的命名空間（命名空間包括目錄，文件，塊），具有唯一性，也就是說只有一個名稱節點，它記錄了每個文件中各個塊的數據位置的信息，但不持久化存儲這些信息，當系統每次啓動的時候，就會全盤掃描所有的數據節點來重構得到這些文件的存儲的映射信息，所以在啓動時，其之對外提供讀，不提供寫。他有兩個核心的數據結構FsImage 和 EditLog。

5.2.1 FsImage

用於維護文件系統樹以及文件樹中的所有文件夾和文件夾下的元數據

5.2.3 EditLog

操作日誌文件，記錄了所有針對文件的創建，刪除，重命名等一系列的操作

5.3 數據節點（DataNode）

負責數據的存儲和讀取，向NameNode定期發送心跳信息，即自己的位置信息和自己所存儲的文件塊的信息，這些數據都保存才本地的Linux文件系統之中。

5.4 第二名稱節點（Secondary NameNode）

出現的原因：在HDFS運行時，更新的操作不斷地寫入EditLog當中，其不斷的變大，在HDFS重啓時，速度會變的很慢

功能：解決上述問題。（1）完成EditLog和FsImage的合併操作，減小EditLog的大小，縮短重啓的時間，提升效率（2）作爲NameNode的“檢查節點”，保存元數據信息，但並不能成爲NameNode的備份節點。

6. HDFS的工作機制

名稱節點在啓動時，會將FsImage中的內容加載到內存中，然後執行EditLog文件中的更新操作，使得內存中的元數據一直保持最新的狀態。這個操作完成後，就會創建一個空的新的EditLog文件，用於存放後續的新的對文件的各種操作，和一個新的FsImage文件。所以當EditLog不斷變大的時候，會影響名稱節點的啓動時間，大大降低了整體系統的使用效率。

7. 第二名稱節點的機制

7.1 圖形描述

7.2 文字解釋

（1）每隔一段時間，第二名稱節點會和名稱節點進行通信，請求停止使用EditLog，創建新的EditLog.new文件，將新的對文件的操作寫入new文件中。
（2）將名稱節點中的FsImage和EditLog文件拉回到本地中，並加載到內存中。
（3）二者進行合併，生成新的FsImage文件。
（4）將最新的FsImage文件返回給NameNode。
（5）新的FsImage替換舊的，用EditLog.new替換EditLog文件，整個操作執行完成。

8. 數據的備份冗餘機制

HDFS的默認冗餘因子是3：

（1）如果是在集羣中發起的寫操作，第一副本放在寫操作的請求數據節點上，如果是外部請求，從集羣中找一個磁盤不太慢，CPU不忙的數據節點進行存放。
（2）第二副本放在與第一副本不同的機架數據節點上。
（3）第三副本放在與第一副本相同的機架但不同的數據節點上。
（4）更多的副本，集羣中的隨機節點存放。

9. HDFS的讀寫過程

相關的類，FileSystem是一個通用的文件系統的抽象類，可以被分佈式文件系統繼承，所有可能使用到的Hadoop文件系統的代碼都要使用到這個類。
（1）輸出：open（）方法返回。輸入流，FSDataInputStream對象，具體的輸入流，DFSInputStream
（2）寫入：create（）方法返回。輸出流，FSDataOutputStream對象，具體的輸出流，DFSOutputStream

9.1 HDFS的讀數據的過程

自己總結的讀數據的過程：

分佈式文件系統HDFS整體剖析

HDFS原理剖析