HDFS資料流管道二三問

摘要： in：上游節點到當前節點的輸入流，當前節點通過in接收上游節點的packet。 replyOut：：當前節點到上游節點的輸出流，當前節點通過replyOut向上遊節點發送ack。 mirrorOut：當前節點到下游節點的輸出流，當前節點通過mirrorOut向下遊...

• in：上游節點到當前節點的輸入流，當前節點通過in接收上游節點的packet。
• replyOut：：當前節點到上游節點的輸出流，當前節點通過replyOut向上遊節點發送ack。
• mirrorOut：當前節點到下游節點的輸出流，當前節點通過mirrorOut向下遊節點映象傳送packet。
• mirrorIn：下游節點到當前節點的輸入流，當前節點通過mirrorIn接收下游節點的映象ack。

管道中的關鍵執行緒

除了客戶端，管道中的每一個dn都有兩個關鍵執行緒：

1. DataXceiver執行緒：dn上管道流的主執行緒，負責 接收上游的packet ，並 繼續向下遊節點管道寫 。（ BlockReceiver#receivePacket() ）。
2. PacketResponder執行緒：負責 接收下游節點的ack ，並 繼續向上遊管道響應 。

作為管道的發起者，也是管道的起點，需要主動寫入資料，有三個關鍵執行緒：

1. 使用者寫資料的執行緒：使用者以chunk為粒度向緩衝區寫資料，寫滿一個packet後放入dataQueue。
2. DataStreamer執行緒：客戶端上管道流的主執行緒，負責 將packet從dataQueue移動到ackQueue ，並 向下遊節點管道寫packet 。
3. PacketResponder執行緒：負責 接收下游節點的ack ，並 移除ackQueue中的packet 。

結合上圖，DataXceiver執行緒、DataStreamer執行緒維護 in->mirrorOut 方向的packet資料流，PacketResponder執行緒維護 mirrorIn->replyOut 方向的ack資料流。

管道的整體過程

管道的生命週期分為三個階段：

1. 管道建立：以管道的方式向下遊傳送管道建立的請求，從下游接收管道建立的響應。
2. 管道寫：當客戶端收到管道建立成功的ack時，才利用剛剛建立的管道開始管道寫資料塊的內容。
3. 管道關閉：以管道的方式向下遊傳送管道關閉的請求，從下游接收管道關閉的響應。

三個過程都是管道式的。

優缺點

• 優點：如果考慮上客戶端，那麼管道寫的優點是 網路負載比較均衡 。
• 缺點： 慢節點 會成為頻寬瓶頸，且整體上 延遲更高 。

如何優化延遲

管道寫 的方式通常稱為 pipeline ：

為了優化管道寫的延遲問題，業界還提出了多種寫方案：

超步寫

如果還使用 管道寫 ，可以支援 超步寫 。

傳統的 管道寫 方案相當於TCP中的 停-等協議 ，可仿照TCP，維護滑動視窗支援超步寫，快速重傳等方案同樣適用。

星型寫

如果網路資源充足，可以改用 星型寫 。

如果在星型寫中發生了失敗，既可以選擇管道寫最保守的方案，中斷整個寫重試，也可以使用更激進的方式，如其中2個DN寫成功就繼續向成功節點寫，而失敗的節點可以在後臺重試（當然，如果不低於minRep可以暫時忽略）。

顯然，上述方案對於慢節點的優化效果非常顯著。