FusionInsight大數據開發---HDFS應用開發

HDFS應用開發

HDFS(Dadoop Distributed File System)

HDFS概述

• 高容錯性
• 高吞吐量
• 大文件存儲

HDFS架構包含三部分

1. Name Node
2. DataNode
3. Client

HDFS數據寫入流程

 

HDFS應用開發方式

• HDFS Client

Java/shell/Web UI

• Kerbors控制

HDFSJava應用開發

下載客戶端/獲取樣例工程/生產樣例工程/導入eclipse/編碼

Java開發流程

• 初始化
• 目錄操做
• 文件讀取
• 文件寫入/追加（

1. 初始化FSDataOutputstream對象
2. 使用FSDataOutputStream對象初始化BufferedOutputStream.
3. 使用BufferedOutputStream.write寫入HDFS數據。
4. 使用BufferedOutputStream.flush和FSDataOutputstream.hflush()將數據刷新到HDFS。
5. 關閉數據流。)

應用開發規範

規範1：Java開發時，申請資源須要及時釋放。
規範2：HDFS不適用於存儲大量小文件。
規範3：HDFS中數據備份3份便可。
規範4：若是有多線程進行login的操做，當第一次登錄成功後，全部線程再次登錄時應該使用relogin的方式。

 

更新中......

 

HDFS

在Hadoop的底層有個很是重要的部分，咱們通常稱之爲「核心」——分佈式文件存儲系統，即HDFS。我以前說過，單個服務器的內存和磁盤空間是有上限的，不可能無限支持線性增長。面對海量的大數據，單個服務器是存不下的，這輩子都不可能存的下的。面對傳統存儲的技術瓶頸，「分佈式」的概念就很好的解決了問題。

 

1、什麼是HDFS

　GFS的設計理念有兩個很重要的假設：只存儲大文件、不能修改（update）只能追加（append）。他有幾個顯著的特性：

• 高容錯性
• 高吞吐量
• 支持大文件（TB、PB）的存儲

2、HDFS的重要角色和概念

　　一、NameNode（NN節點）

• HDFS的管理者。負責監控DataNode，記錄文件的存儲信息，協調客戶端的讀寫請求，等。至關於目錄。

　　二、DataNode（DN節點）

• HDFS的執行者。負責文件的存儲，以塊爲存儲單位，數據分散在不一樣DN節點，支持一次寫入屢次讀取，等。至關於正文。

　　三、SecondaryNameNode

• NameNode的冷備份,同步NameNode的日誌(EditLog)和鏡像文件(FsImage),並將日誌和鏡像合併成新的鏡像文件回傳給NameNode

　　四、Editlog

• 日誌文件,記錄每次元數據的變化

　　五、FsImage

• 鏡像文件,內存中元數據在本地磁盤的映射

　　PS:NameNode的內存中是FsImage+EditLog

　　六、熱備份

• NameNode中止工做後,熱備份NameNode立刻接替NameNode的工做

　　七、冷備份

　　同SecondaryNmaeNode

　　

3、HDFS的讀寫流程

這個咱們能夠類比圖書館，寫就是新書入館，讀就是客戶借書。你們應該聽過一個問題：把大象裝進冰箱分幾步？咱們就以3大步來看這個問題。

先看看寫流程。有一批新書要入館，咱們要走哪些流程？

• 員工先找到館長，告訴他你要的貨……你要的書我帶來了：打開了冰箱門。
• 館長看到書來了先是喜上眉梢，緊接着眉頭一皺，發現事情並不簡單：大象怎麼塞進冰箱？
• 館長終於想起來「目錄」這麼個玩意，費了老半天勁指揮員工把書存好，而後把目錄放好：關上冰箱門。

根據圖書館的例子，運用到HDFS上：

Round1 寫流程

 

 

A：打開冰箱門

　　一、用戶在客戶端（Client）發起寫命令，存入一個文件

　　　　①用戶需先將文件分塊，通常塊大小爲128MB

　　　　②還須要制定文件的副本參數,通常爲3

　　二、客戶端向NN節點發起寫請求

　　　　①請求信息中包含但不限於文件大小(塊)、副本參數

　　三、NN節點收到請求，給Client發送一個回覆信息

　　　　　①NN從本身管理的(DN)節點信息中找出適合的3個(與副本參數一致)DN節點

　　　　　②將選中的DN節點地址和路徑參數的等信息發送給Client

B：把大象塞進去

　　一、Client收到回覆信息，開始發送第一個數據塊(Block)

　　　　　①Client經過NN的回覆信息找到第一個DN節點，開始發送數據塊，以及備份副本DN地址列表

　　　　　②第一個DN開始按數據包分批接受Block存盤，每存盤一個數據包同時將相同的數據包再轉發給的二個DN節點，以此類推直到最後一個DN節點存盤後不在轉發

　　　　　③全部DN都接受到了完整的Block後，向NN節點發送確認信息，第一個DN節點還要向Client發送確認信息

　　二、Client收到第一個Block存盤完畢的信息後開始執行第二個Block的操做，從新向NN節點發送請求

C：關閉冰箱門

　　一、Client收到DN節點最後一個Block存盤成功的確認信息後，向NN節點發送結束信息

　　二、NN節點收到Client發來的結束信息，關閉目錄文件，此時存儲文件的元數據信息已經記錄在了目錄文件中

小結：在寫流程中，Client負責發起命令，將文件分塊和設置副本參數；NN節點負責協調Client和DN節點的交互，包括爲每一個文件的多個數據塊分配存儲地址及記錄元數據；DN負責幹活，存儲從Client發來的數據，同時多副本機制保障了數據的高可靠性。

 

　　Round2 讀流程

　　

讀流程相較於寫流程基本一致，且實現更加簡單，我就簡單描述一下：

• Client向NN節點發出讀請求，包含文件名等信息
• NN收到請求，根據文件名查找該文件所對應的全部塊信息
• NN根據塊信息找到相對應的DN節點，將全部DN節點的位置及路徑開銷回復給Client
• Client根據收到的DN節點信息，選取每一個塊所在路徑開銷最小的DN節點執行讀取操做。

 

4、HDFS的高可靠性

一、NN的高可靠性

　　NN節點做爲HDFS的管理者，裏面存儲了全部文件數據的元數據和節點的狀態信息。一旦NN節點宕機那麼全部文件的元數據將會丟失，海量的文件數據被存放在不一樣的DN節點上，元數據的丟失意味着丟失了查找數據的能力。爲防止因爲NN節點的宕機而致使的元數據丟失，咱們採用NN節點的冗餘備份機制。NN節點的備份分爲冷備份和熱備份，在第二部分也將這兩個備份的概念簡單說了一下，如今詳細介紹一下。

　　　　

　　上一篇隨筆簡單講到Hadoop分爲三個層次，中間層負責資源協調。ZooKeeper就是協調機制，在HDFS中主要就是協調選舉主備NameNode節點。每一個NN節點都會經過「心跳」與ZooKeeper保持聯繫，報告本身的狀態信息。ZooKeeper經過這些狀態信息選舉出主NN節點做爲整個HDFS的管理節點，其餘做爲備份。備份NN通常不工做，但數據會與主NN節點同步更新。當主NN節點宕機後，其與ZooKeeper的聯繫就會中斷，ZooKeeper接受不到主NN發來的心跳信息就默認主NN節點損壞，會在備選NN節點中從新選舉主NN節點。雖然備NN節點不工做，但它裏面的元數據信息和DN節點狀態信息跟主NN節點是同步更新的，因此一旦備NN被選爲主NN節點，會馬上接替主NN節點的工做。固然，這是熱備份。

冷備份，即SecondaryNameNode。它與主NN節點之間有個「元數據持久化」機制

①當有對元數據執行操做時，NN節點會生成新的對應日誌文件(Editlog.new)

②NN節點內存裏存放的是日誌文件(Editlog)和元數據鏡像文件(Fsimage)，SecondaryNN經過NN節點同步獲取獲得

③SecondaryNN中將兩者合併成新的鏡像文件Fsimage.ckpt文件

④SecondaryNN將新生成的鏡像文件上傳到主節點上

⑤Fsimage.ckpt在主節點上回滾成Fsimage文件，其實就是將原來的鏡像文件更新NN

⑥此時在以前過程當中新的日誌文件(Editlog.new)已經變成Editlog，不在是新日誌，與更新後的鏡像文件從新同步到SecondaryNN上，重複以上操做

NN和SecondaryNN的工做目錄存儲結構徹底相同，因此，當NN故障退出須要從新恢復時，能夠從SecondaryNN的工做目錄中將Fsimage拷貝到NN的工做目錄，以恢復NN中的元數據。

二、DN的高可靠性

　　DN節點做爲實際存儲數據的執行者，其高可靠性主要就是數據的副本機制，即數據冗餘存儲。當數據寫入HDFS時，Client有個」副本參數「設置，這就是咱們對數據的備份。並且咱們在備份時選擇的時不一樣的DN節點來進行存儲，一次來保證在一臺DN損壞的狀況下，依靠其餘DN節點依然能夠恢復數據。

　　DN節點受NN節點的監控，它們之間也有」心跳「聯繫的機制。DN節點定時向NN節點發送本身的狀態信息，NN節點經過這些信息監控DN節點。當NN節點在一段時間內沒有接受到某臺DN節點的心跳信息，則認爲該DN節點損壞。此時NN節點會根據本身的元數據信息肯定其所存放數據的副本的DN節點，從新找一帶DN節點，根據副本數據進行備份。同時修改元數據信息和DN節點狀態信息。這樣，經過NN節點的調控備份，始終使數據保持必定數量的副本，保證了數據的完整性。