【hadoop】11.HDFS-數據流

簡介

經過本教程您能夠學習到:

1. 讀數據模型
2. 寫數據模型
3. 一致模型

二、hadoop傳輸數據模型

爲了瞭解客戶端與之交互的HDFS、namenode以及datanode之間的數據流是什麼樣的，咱們須要來了解一下幾個模型。

2.一、讀數據模型

當咱們須要從DFS中下載一個文件時，其大概的流程以下圖所示

能夠看到，客戶端能夠直接鏈接DataNode進行文件下載，而且namenode在第一次交互中還會給客戶端提供最佳的datanode。

這種方式的好處不言而喻，因爲數據流分散在集羣中的各個節點智商，因此這種設計能使HDFS擴展到大量的併發客戶端。同時，NameNode只須要響應塊位置的請求（這些信息是存儲在內存中的，所以很是的高效），無需響應數據請求（DN處理）。不然，隨着客戶端數量的增加，namenode很快就會成爲瓶頸。

2.二、寫數據模型

HDFS寫數據（上傳）的過程很像咱們傳統的通訊協議那樣須要通過幾回握手。假設咱們目前具有1個NN，3個DN。請求發送一個超過128M的數據。參考下圖：

一、客戶端向namenode請求上傳文件，namenode檢查目標文件是否已存在，父目錄是否存在。

二、namenode返回是否能夠上傳。

三、客戶端請求第一個 block上傳到哪幾個datanode服務器上。

四、namenode返回3個datanode節點，分別爲dn一、dn二、dn3。

五、客戶端請求dn1上傳數據，dn1收到請求會繼續調用dn2，而後dn2調用dn3，將這個通訊管道創建完成

六、dn一、dn二、dn3逐級應答客戶端

七、客戶端開始往dn1上傳第一個block（先從磁盤讀取數據放到一個本地內存緩存），以packet爲單位，dn1收到一個packet就會傳給dn2，dn2傳給dn3；dn1每傳一個packet會放入一個應答隊列等待應答

八、當一個block傳輸完成以後，客戶端再次請求namenode上傳第二個block的服務器。（重複執行3-7步）

hdoop實戰這裏引進了「副本如何存放？」的問題，接着講述了機架感知這一問題，請前往本系列教程的10小節查看，書中提到的是12模型，但是通過測試以後發現2.7版本爲21模型，待解惑。

2.三、一致型模型

學過數據庫的同窗都知道，一談到多節點共享或者複製相同數據的時候，都會面臨一個同步性問題。每個成熟的系統都應該對同步性問題有所處理。

當咱們進行數據上傳的時候，系統是須要必定的時間去處理、先處理一份拷貝，在處理接下來的拷貝的，也就是說，數據不是立馬就能獲得同步。咱們不妨作一個測試，編寫一段測試代碼：

@Test
    public void testConsist() throws Exception {
        Path path = new Path("/user/consisit.txt");

        Configuration configuration = new Configuration();
        FileSystem fs = FileSystem.get(new URI(HDFS_URL),configuration,HADOOP_USER);
        System.out.println(fs.getFileStatus(path).getLen());
        // 獲取輸出流
        FSDataOutputStream fos = fs.create(path);
        // 寫入數據
        fos.write("some intersted text".getBytes());
        System.out.println(fs.getFileStatus(path).getLen());
        // 只對當前操做的節點刷新
        fos.hflush();
        fos.close();
    }

經過斷點測試，咱們能夠知道，在未調用flush方法以前，Path對應的文件長度爲0，也就是數據沒有即時的刷新到數據中。

HDFS提供了FSDataOutPutStream的hflush方法。當該方法執行成功以後，就會將全部的數據刷新到datanode中。

須要注意的是，該方法並不保證datanode已經寫到了磁盤上，只能確保數據在datanode的內存中。所以，若是數據中心斷電，數據仍是會丟失。爲確保數據寫入到磁盤上，能夠調用hsync方法。固然，有利就有弊，hsync耗損的資源要比hflush多得多。

fos.close()隱含調用了hfluash方法。