一、讀寫機制　　

首先來看文件讀取機制：盡管DataNode實現(xiàn)了文件存儲空間的水平擴展和多副本機制，但是針對單個具體文件的讀取，Hadoop默認的API接口并沒有提供多DataNode的并行讀取機制?；贖adoop提供的API接口實現(xiàn)的云盤客戶端也自然面臨同樣的問題。Hadoop的文件讀取流程如下圖所示：

1. 使用HDFS提供的客戶端開發(fā)庫，向遠程的Namenode發(fā)起RPC請求；
2. Namenode會視情況返回文件的部分或者全部block列表，對于每個block，Namenode都會返回有該block拷貝的datanode地址；
3. 客戶端開發(fā)庫會選取離客戶端最接近的datanode來讀取block；
4. 讀取完當前block的數(shù)據(jù)后，關閉與當前的datanode連接，并為讀取下一個block尋找***的datanode；
5. 當讀完列表的block后，且文件讀取還沒有結束，客戶端開發(fā)庫會繼續(xù)向Namenode獲取下一批的block列表。
6. 讀取完一個block都會進行checksum驗證，如果讀取datanode時出現(xiàn)錯誤，客戶端會通知Namenode，然后再從下一個擁有該block拷貝的datanode繼續(xù)讀取。

　　這里需要注意的關鍵點是：多個Datanode順序讀取。

　　其次再看文件的寫入機制：

1. 使用HDFS提供的客戶端開發(fā)庫，向遠程的Namenode發(fā)起RPC請求；
2. Namenode會檢查要創(chuàng)建的文件是否已經(jīng)存在，創(chuàng)建者是否有權限進行操作，成功則會為文件創(chuàng)建一個記錄，否則會讓客戶端拋出異常；
3. 當客戶端開始寫入文件的時候，開發(fā)庫會將文件切分成多個packets，并在內(nèi)部以"data queue"的形式管理這些packets，并向Namenode申請新的blocks，獲取用來存儲replicas的合適的datanodes列表， 列表的大小根據(jù)在Namenode中對replication的設置而定。
4. 開始以pipeline（管道）的形式將packet寫入所有的replicas中。開發(fā)庫把packet以流的方式寫入***個 datanode，該datanode把該packet存儲之后，再將其傳遞給在此pipeline中的下一個datanode，直到***一個 datanode，這種寫數(shù)據(jù)的方式呈流水線的形式。
5. ***一個datanode成功存儲之后會返回一個ack packet，在pipeline里傳遞至客戶端，在客戶端的開發(fā)庫內(nèi)部維護著"ack queue"，成功收到datanode返回的ack packet后會從"ack queue"移除相應的packet。
6. 如果傳輸過程中，有某個datanode出現(xiàn)了故障，那么當前的pipeline會被關閉，出現(xiàn)故障的datanode會從當前的 pipeline中移除，剩余的block會繼續(xù)剩下的datanode中繼續(xù)以pipeline的形式傳輸，同時Namenode會分配一個新的 datanode，保持replicas設定的數(shù)量。

　　關鍵詞：開發(fā)庫把packet以流的方式寫入***個datanode，該datanode將其傳遞給pipeline中的下一個datanode，知道***一個Datanode，這種寫數(shù)據(jù)的方式呈流水線方式。

二、解決方案

　　1.下載效率優(yōu)化

　　通過以上讀寫機制的分析，我們可以發(fā)現(xiàn)基于Hadoop實現(xiàn)的云盤客戶段下載效率的優(yōu)化可以從兩個層級著手：

　　1.文件整體層面：采用并行訪問多線程（多進程）份多文件并行讀取。

　　2.Block塊讀?。焊膶慔adoop接口擴展，多Block并行讀取。

　　2.上傳效率優(yōu)化

　　上傳效率優(yōu)化只能采用文件整體層面的并行處理，不支持分Block機制的多Block并行讀取。

原文鏈接：http://www.cnblogs.com/hadoopdev/archive/2013/03/07/2947447.html

【編輯推薦】