首先一起來畫個圖，回顧一下Hadoop HDFS中的超大數(shù)據(jù)文件上傳的原理。

其實(shí)說出來也很簡單，比如有個十億數(shù)據(jù)量級的超大數(shù)據(jù)文件，可能都達(dá)到TB級了，此時(shí)這個文件實(shí)在是太大了。

此時(shí)，HDFS客戶端會給拆成很多block，一個block就128MB。

這個HDFS客戶端你可以理解為是云盤系統(tǒng)、日志采集系統(tǒng)之類的東西，比如有人上傳一個1TB的大文件到網(wǎng)盤，或者是上傳個1TB的大日志文件。

然后HDFS客戶端把一個一個的block上傳到第一個DataNode，第一個DataNode會把這個block復(fù)制一份，做一個副本發(fā)送給第二個DataNode，然后第二個DataNode發(fā)送一個block副本到第三個DataNode。

所以你會發(fā)現(xiàn)，一個block有3個副本，分布在三臺機(jī)器上。任何一臺機(jī)器宕機(jī)，數(shù)據(jù)是不會丟失的。

然后一個TB級大文件就被拆散成了N多個MB級的小文件存放在很多臺機(jī)器上了，這不就是分布式存儲么？

今天要討論的問題，就是那個HDFS客戶端上傳TB級大文件的時(shí)候，到底是怎么上傳呢？

如果用一個比較原始的方式來上傳，我們大概能想到的是下面這個圖里的樣子。

其實(shí)很簡單，無非就是不停的從本地磁盤文件用輸入流讀取數(shù)據(jù)，然后讀到一點(diǎn)，就立馬通過網(wǎng)絡(luò)的輸出流寫到DataNode里去。

參見上圖，對文件的輸入流最多就是個FileInputStream，對DataNode的輸出流，最多就是個Socket返回的OutputStream，然后中間找一個小的內(nèi)存byte[]數(shù)組，進(jìn)行流對考就行了。從本地文件讀一點(diǎn)數(shù)據(jù)，就給DataNode發(fā)一點(diǎn)數(shù)據(jù)。

但是如果真是這么弄，性能真是極其的低下了，網(wǎng)絡(luò)通信講究的是適當(dāng)頻率，每次batch批量發(fā)送，你得讀一大批數(shù)據(jù)，通過網(wǎng)絡(luò)通信發(fā)一批數(shù)據(jù)。不能讀一點(diǎn)點(diǎn)數(shù)據(jù)，就立馬來一次網(wǎng)絡(luò)通信，就發(fā)出去這一點(diǎn)點(diǎn)的數(shù)據(jù)。

如果按照上面這種原始的方式，絕對會導(dǎo)致網(wǎng)絡(luò)通信效率極其低下，大文件上傳性能很差。相當(dāng)于你可能剛讀出來幾百個字節(jié)的數(shù)據(jù)，立馬就寫網(wǎng)絡(luò)，卡頓個比如幾百毫秒，然后再讀下一批幾百個字節(jié)的數(shù)據(jù)，再寫網(wǎng)絡(luò)卡頓個幾百毫秒，這個性能很差，幾乎在工業(yè)級的大規(guī)模分布式系統(tǒng)中，是無法容忍的。

Hadoop中的大文件上傳如何優(yōu)化性能？我們來看看下面那張圖。

你需要自己創(chuàng)建一個針對本地TB級磁盤文件的輸入流，然后讀到數(shù)據(jù)之后立馬寫入HDFS提供的FSDataOutputStream輸出流。

這個FSDataOutputStream輸出流在干啥呢？他會天真的立馬把數(shù)據(jù)通過網(wǎng)絡(luò)傳輸寫給DataNode嗎？

答案當(dāng)然是否定的！這么干的話，不就跟之前的那種方式一樣了！

1、Chunk緩沖機(jī)制

首先，數(shù)據(jù)會被寫入一個chunk緩沖數(shù)組，這個chunk是一個512字節(jié)大小的數(shù)據(jù)片段，你可以這么來理解。

然后這個緩沖數(shù)組可以容納多個chunk大小的數(shù)據(jù)在里面緩沖。光是這個緩沖，首先就可以讓客戶端快速的寫入數(shù)據(jù)了，不至于說幾百字節(jié)就要進(jìn)行一次網(wǎng)絡(luò)傳輸，對吧？

2、Packet數(shù)據(jù)包機(jī)制

接著，當(dāng)chunk緩沖數(shù)組都寫滿了之后，就會把這個chunk緩沖數(shù)組進(jìn)行一下chunk切割，切割為一個一個的chunk，一個chunk是一個數(shù)據(jù)片段。然后多個chunk會直接一次性寫入另外一個內(nèi)存緩沖數(shù)據(jù)結(jié)構(gòu)，就是Packet數(shù)據(jù)包。

一個Packet數(shù)據(jù)包，設(shè)計(jì)為可以容納127個chunk，大小大致為64mb。所以說大量的chunk會不斷的寫入Packet數(shù)據(jù)包的內(nèi)存緩沖中。通過這個Packet數(shù)據(jù)包機(jī)制的設(shè)計(jì)，又可以在內(nèi)存中容納大量的數(shù)據(jù)，進(jìn)一步避免了頻繁的網(wǎng)絡(luò)傳輸影響性能。

3、內(nèi)存隊(duì)列異步發(fā)送機(jī)制

當(dāng)一個Packet被塞滿了chunk之后，就會將這個Packet放入一個內(nèi)存隊(duì)列來進(jìn)行排隊(duì)，然后有一個DataStreamer線程會不斷的獲取隊(duì)列中的Packet數(shù)據(jù)包，通過網(wǎng)絡(luò)傳輸直接寫一個Packet數(shù)據(jù)包給DataNode。

如果一個Block默認(rèn)是128mb的話，那么一個Block默認(rèn)會對應(yīng)兩個Packet數(shù)據(jù)包，每個Packet數(shù)據(jù)包是64MB。

也就是說傳送兩個Packet數(shù)據(jù)包DataNode之后，就會發(fā)一個通知說，一個Block的數(shù)據(jù)都傳輸完畢，那DataNode就知道自己收到了一個Block了，包含了人家發(fā)送過來的兩個Packet數(shù)據(jù)包。

總結(jié)：

ok，大家看完了上面的那個圖以及hadoop采取的大文件上傳機(jī)制，是不是感覺設(shè)計(jì)的很巧妙？

工業(yè)級的大規(guī)模分布式系統(tǒng)，都不會采取特別簡單的代碼和模式，那樣性能很低下。這里都有大量的并發(fā)優(yōu)化、網(wǎng)絡(luò)IO優(yōu)化、內(nèi)存優(yōu)化、磁盤讀寫優(yōu)化的架構(gòu)設(shè)計(jì)、生產(chǎn)方案在里面。

所以大家觀察上面那個圖，hdfs客戶端可以快速的將tb級大文件的數(shù)據(jù)讀出來，然后快速的交給hdfs的輸出流寫入內(nèi)存，基于內(nèi)存里的chunk緩沖機(jī)制、packet數(shù)據(jù)包機(jī)制、內(nèi)存隊(duì)列異步發(fā)送機(jī)制，絕對不會有任何網(wǎng)絡(luò)傳輸?shù)目D，導(dǎo)致大文件的上傳速度變慢。反而通過上述幾種機(jī)制，可以大幅度提升一個TB級大文件的上傳性能。