背景

有時候，Hadoop 的計算集群和存儲集群之間宣虾，可能會有非常大的網(wǎng)絡(luò)延遲（例如異地部署的情況）惯裕，會影響 HDFS IO 效率。具體而言：

1. 網(wǎng)絡(luò)時延很高绣硝，相對于本地訪問蜻势，可能增加10倍以上。
2. 網(wǎng)絡(luò)帶寬并不緊張鹉胖，沒有打滿握玛。

很自然的，在這種情況下甫菠，可以通過多線程并發(fā)讀/寫的方式挠铲，更加充分的使用網(wǎng)絡(luò)帶寬，從而加快業(yè)務(wù) IO 完成速度寂诱，目前主要有下面幾種方案拂苹。

HDFS EC 方案（推薦）

優(yōu)勢

對于這個需求，EC 基本上可以說量身定制刹衫，以提高帶寬占用為代價醋寝，使用并發(fā)讀寫的方式加快客戶端的讀寫速度搞挣，這本身就是 EC 擅長的带迟。以默認(rèn)的 6+3 策略為例：

1. 客戶端寫入時音羞，相對于3副本的單線程寫，EC 是9倍并發(fā)寫仓犬，在高網(wǎng)絡(luò)時延嗅绰、低帶寬使用的情況下，可以大幅度提升寫入速度搀继。
2. 客戶端讀取時窘面，相對于3副本的單線程讀，EC 是6倍并發(fā)讀叽躯，同樣能大幅度提升讀取速度财边。
3. HDFS EC 可以做實(shí)時 EC，也可以做離線 EC点骑，具體的策略可以精確配置到目錄級別酣难。

可能存在的問題

1. EC 會失去計算和存儲的本地性
   實(shí)際上異地訪問本來就沒有本地性，因此非問題黑滴。

2. 由于客戶端使用多線程并發(fā)讀寫憨募，會比較顯著的提升集群整體的帶寬占用，特別是客戶端機(jī)器的帶寬占用袁辈。
   這正是我們的目的菜谣，因此非問題。

3. 目前晚缩，HDFS EC 不支持客戶端的 append尾膊、hflush、hsync 操作荞彼，具體即：

   1. 對 EC 文件 append 會拋異常冈敛，導(dǎo)致業(yè)務(wù)失敗（目前有社區(qū) patch 在推進(jìn)解決）卿泽。
   2. 對 EC 文件 hflush()莺债、hsync() 為空操作，直接返回签夭。

4. 由于上述第三點(diǎn)限制齐邦，并非所有業(yè)務(wù)都能使用實(shí)時 EC，此時只能使用離線 EC第租，具體即：

   1. 需要明確業(yè)務(wù)是否會使用 append 追加寫入方式措拇，如果會，則該業(yè)務(wù)的目標(biāo)目錄不能配置 EC慎宾，一般情況下丐吓，很少有業(yè)務(wù)會使用追加寫浅悉。
   2. 需要明確業(yè)務(wù)是否對 hflush、hsync 等有強(qiáng)需求券犁，如果有术健，則該業(yè)務(wù)的目錄不能配置 EC，一般情況下粘衬，很少有業(yè)務(wù)會對此有強(qiáng)需求荞估。 hflush() 和 hsync() 的主要用途是在業(yè)務(wù)進(jìn)程意外崩潰的情況下，確保 hflush()稚新、hsync() 之前的數(shù)據(jù)已固化勘伺，但在實(shí)際使用過程中，如果業(yè)務(wù)進(jìn)程異常崩潰褂删，則它正在寫入的文件無法確保完整性飞醉，此時正常的流程應(yīng)該是讓業(yè)務(wù)重跑，重新生成正確的文件屯阀。

5. 如果業(yè)務(wù)使用離線 EC缅帘，那么此時的問題是：

   1. 離線 EC 需要等待數(shù)據(jù)變冷之后，再將副本文件轉(zhuǎn)換為 EC 文件蹲盘，在此之前股毫，客戶端仍然只能用副本方式讀寫。
   2. 離線 EC 完成后召衔，客戶端可以使用 EC 方式讀取數(shù)據(jù)铃诬，此時才能享受到加速效果。
   3. 離線 EC 完成后苍凛，生成的 EC 文件不支持 append 追加寫入趣席。

6. 總結(jié)

   1. EC 基本可以認(rèn)為是為此場景量身定制，完全滿足需求醇蝴。
   2. 有 append 和 hflush()宣肚、hsync() 需求的業(yè)務(wù)，只能使用離線 EC. 業(yè)務(wù)一般情況下不會對 hflush()悠栓、hsync()有強(qiáng)需求霉涨，因此需要重點(diǎn)關(guān)注 append。

附：分別從清遠(yuǎn)惭适、深圳笙瑟、重慶，通過副本方式癞志、EC方式訪問清遠(yuǎn) HDFS 集群對比：

可以看到：

1. 同機(jī)房的讀寫速度肯定是最高的往枷，這個確定無疑。
2. 從重慶訪問清遠(yuǎn) HDFS 集群時，相比從深圳訪問错洁，其 IO 速度大概只有 1/3 -1/2秉宿。
3. 客戶端和集群之間的網(wǎng)絡(luò)延遲較高時，EC 的 IO 速度大概是副本的 4-5倍（三副本對比 6+3 EC屯碴，前提是帶寬夠用描睦，沒有打滿）。
4. 綜上所述窿锉，異地 EC 讀寫的速度可以基本可以打平本地副本讀寫速度酌摇。

類 distcp 方案（即：在文件級別實(shí)現(xiàn)并發(fā) put/get膝舅，不太推薦）

模仿 distcp嗡载，在文件級別并發(fā)執(zhí)行 put/get，舉例：針對100個文件仍稀，啟動10個線程負(fù)責(zé) put/get洼滚，每個線程平均負(fù)責(zé)10個文件，相比于單線程技潘，速度可以有10倍提高遥巴。

優(yōu)勢

1. 不需要額外啟用 EC，distcp 對 EC 文件和副本文件都可用享幽。
2. 并發(fā)強(qiáng)度可以靈活配置铲掐。

劣勢

1. 只能以命令行的方式提供，供管理員手動執(zhí)行值桩。如果業(yè)務(wù)直接調(diào)用 FileSystem API摆霉，則無效，此時依然只能使用老的單線程寫入奔坟、讀取携栋。
2. 有一定的編碼工作量。

重構(gòu) HDFS 客戶端方案（即：在 HDFS 流水線級別實(shí)現(xiàn)并發(fā)讀寫,直接否決）

縱觀業(yè)界的存儲方案咳秉，無論是 Ceph婉支，Ozone 等等，無一例外是使用 master 副本 + slave 副本 的方式來保證數(shù)據(jù)的強(qiáng)一致性澜建，基本沒有像 HDFS 這樣使用流水線機(jī)制的向挖，原因也很簡單：流水線機(jī)制實(shí)在過于復(fù)雜，實(shí)現(xiàn)難度炕舵、錯誤處理與恢復(fù)復(fù)雜度何之、后續(xù)維護(hù)難度等都太大，社區(qū)對這部分代碼的修改一直都是持非常謹(jǐn)慎的態(tài)度幕侠，現(xiàn)在如果要對流水線機(jī)制動刀的話帝美，風(fēng)險太大，承受不起。

如果要強(qiáng)行去做這件事情悼潭，那么庇忌，幾個重大的修改點(diǎn)是：

1. 客戶端和 DN 之間，不能再像現(xiàn)在這樣舰褪，只使用一個 socket 來傳輸數(shù)據(jù)皆疹，而是需要同時使用多個 socket 并行傳輸，例如每個 socket 傳輸一個 HDFS packet占拍。需要注意的是略就，如果只是多線程使用一個 socket，那沒有任何意義晃酒，因?yàn)樵谶@種高網(wǎng)絡(luò)時延的條件下表牢，無論是單線程還是多線程，都會在瞬間打滿客戶端的 socket 發(fā)送緩存，然后陷入等待，所以必須同時使用多個 socket 并行傳輸數(shù)據(jù)胯陋。

2. 使用多個 socket 并行傳輸數(shù)據(jù)時赘来，需要考慮到多個 packet 的亂序和重排，以及某個 packet 丟失之后的處理等等，類似于迅雷的多線程并發(fā)下載技術(shù)。