建站
咨詢
售后
建站咨詢
新聞中心
一、寫在前面
上一篇文章，我們聊了一下Hadoop中的NameNode里的edits log寫機制。
企業(yè)建站必須是能夠以充分展現(xiàn)企業(yè)形象為主要目的，是企業(yè)文化與產(chǎn)品對外擴展宣傳的重要窗口，一個合格的網(wǎng)站不僅僅能為公司帶來巨大的互聯(lián)網(wǎng)上的收集和信息發(fā)布平臺，創(chuàng)新互聯(lián)公司面向各種領域：成都紙箱等網(wǎng)站設計、營銷型網(wǎng)站解決方案、網(wǎng)站設計等建站排名服務。
主要分析了edits log寫入磁盤和網(wǎng)絡的時候，是如何通過分段加鎖以及雙緩沖的機制，大幅度提升了多線程并發(fā)寫edits log的吞吐量，從而支持高并發(fā)的訪問。
如果沒看那篇文章的同學，可以回看一下：《?每秒上千次高并發(fā)訪問，HDFS優(yōu)雅的抗住了?》。
這篇文章，我們來看看，Hadoop的HDFS分布式文件系統(tǒng)的文件上傳的性能優(yōu)化。
首先，我們還是通過一張圖來回顧一下文件上傳的大概的原理。
?由上圖所示，文件上傳的原理，其實說出來也簡單。
比如有個TB級的大文件，太大了，HDFS客戶端會給拆成很多block，一個block就是128MB。
這個HDFS客戶端你可以理解為是云盤系統(tǒng)、日志采集系統(tǒng)之類的東西。
比如有人上傳一個1TB的大文件到網(wǎng)盤，或者是上傳個1TB的大日志文件。
然后，HDFS客戶端把一個一個的block上傳到第一個DataNode
第一個DataNode會把這個block復制一份，做一個副本發(fā)送給第二個DataNode。
第二個DataNode發(fā)送一個block副本到第三個DataNode。
所以你會發(fā)現(xiàn)，一個block有3個副本，分布在三臺機器上。任何一臺機器宕機，數(shù)據(jù)是不會丟失的。
最后，一個TB級大文件就被拆散成了N多個MB級的小文件存放在很多臺機器上了，這不就是分布式存儲么？?
二、原始的文件上傳方案
今天要討論的問題，就是那個HDFS客戶端上傳TB級大文件的時候，到底是怎么上傳呢？
我們先來考慮一下，如果用一個比較原始的方式來上傳，應該怎么做？
大概能想到的是下面這個圖里的樣子。
很多java的初學者，估計都知道這樣來上傳文件，其實無非就是不停的從本地磁盤文件用輸入流讀取數(shù)據(jù)，讀到一點，就立馬通過網(wǎng)絡的輸出流寫到DataNode里去。
上面這種流程圖的代碼，估計剛畢業(yè)的同學都可以立馬寫出來。因為對文件的輸入流最多就是個FileInputStream。
而對DataNode的輸出流，最多就是個Socket返回的OutputStream。
然后中間找一個小的內存byte[]數(shù)組，進行流對拷就行了，從本地文件讀一點數(shù)據(jù)，就給DataNode發(fā)一點數(shù)據(jù)。
但是如果你要這么弄，那性能真是極其的低下了，網(wǎng)絡通信講究的是適當頻率，每次batch批量發(fā)送，你得讀一大批數(shù)據(jù)，通過網(wǎng)絡通信發(fā)一批數(shù)據(jù)。
不能說讀一點點數(shù)據(jù)，就立馬來一次網(wǎng)絡通信，就發(fā)出去這一點點的數(shù)據(jù)。
如果按照上面這種原始的方式，絕對會導致網(wǎng)絡通信效率極其低下，大文件上傳性能很差。
為什么這么說呢？
相當于你可能剛讀出來幾百個字節(jié)的數(shù)據(jù)，立馬就寫網(wǎng)絡，卡頓個比如幾百毫秒。
然后再讀下一批幾百個字節(jié)的數(shù)據(jù)，再寫網(wǎng)絡卡頓個幾百毫秒，這個性能很差，在工業(yè)級的大規(guī)模分布式系統(tǒng)中，是無法容忍的。
三、HDFS對大文件上傳的性能優(yōu)化
好，看完了原始的文件上傳，那么我們來看看，Hadoop中的大文件上傳是如何優(yōu)化性能的呢？一起來看看下面那張圖。
首先你需要自己創(chuàng)建一個針對本地TB級磁盤文件的輸入流。
然后讀到數(shù)據(jù)之后立馬寫入HDFS提供的FSDataOutputStream輸出流。
這個FSDataOutputStream輸出流在干啥？
大家覺得他會天真的立馬把數(shù)據(jù)通過網(wǎng)絡傳輸寫給DataNode嗎？
答案當然是否定的了！這么干的話，不就跟之前的那種方式一樣了！
1、Chunk緩沖機制
首先，數(shù)據(jù)會被寫入一個chunk緩沖數(shù)組，這個chunk是一個512字節(jié)大小的數(shù)據(jù)片段，你可以這么來理解。
然后這個緩沖數(shù)組可以容納多個chunk大小的數(shù)據(jù)在里面緩沖。
光是這個緩沖，首先就可以讓客戶端快速的寫入數(shù)據(jù)了，不至于說幾百字節(jié)就要進行一次網(wǎng)絡傳輸，想一想，是不是這樣？
2、Packet數(shù)據(jù)包機制
?接著，當chunk緩沖數(shù)組都寫滿了之后，就會把這個chunk緩沖數(shù)組進行一下chunk切割，切割為一個一個的chunk，一個chunk是一個數(shù)據(jù)片段。
然后多個chunk會直接一次性寫入另外一個內存緩沖數(shù)據(jù)結構，就是Packet數(shù)據(jù)包。
一個Packet數(shù)據(jù)包，設計為可以容納127個chunk，大小大致為64mb。所以說大量的chunk會不斷的寫入Packet數(shù)據(jù)包的內存緩沖中。
通過這個Packet數(shù)據(jù)包機制的設計，又可以在內存中容納大量的數(shù)據(jù)，進一步避免了頻繁的網(wǎng)絡傳輸影響性能。?
3、內存隊列異步發(fā)送機制
?當一個Packet被塞滿了chunk之后，就會將這個Packet放入一個內存隊列來進行排隊。
然后有一個DataStreamer線程會不斷的獲取隊列中的Packet數(shù)據(jù)包，通過網(wǎng)絡傳輸直接寫一個Packet數(shù)據(jù)包給DataNode。
如果一個Block默認是128mb的話，那么一個Block默認會對應兩個Packet數(shù)據(jù)包，每個Packet數(shù)據(jù)包是64MB。
也就是說，傳送兩個Packet數(shù)據(jù)包給DataNode之后，就會發(fā)一個通知說，一個Block的數(shù)據(jù)都傳輸完畢。
這樣DataNode就知道自己收到一個Block了，里面包含了人家發(fā)送過來的兩個Packet數(shù)據(jù)包。?
四、總結
OK，大家看完了上面的那個圖以及Hadoop采取的大文件上傳機制，是不是感覺設計的很巧妙？
說白了，工業(yè)級的大規(guī)模分布式系統(tǒng)，都不會采取特別簡單的代碼和模式，那樣性能很低下。
這里都有大量的并發(fā)優(yōu)化、網(wǎng)絡IO優(yōu)化、內存優(yōu)化、磁盤讀寫優(yōu)化的架構設計、生產(chǎn)方案在里面。
所以大家觀察上面那個圖，HDFS客戶端可以快速的將tb級大文件的數(shù)據(jù)讀出來，然后快速的交給HDFS的輸出流寫入內存。
基于內存里的chunk緩沖機制、packet數(shù)據(jù)包機制、內存隊列異步發(fā)送機制。絕對不會有任何網(wǎng)絡傳輸?shù)目D，導致大文件的上傳速度變慢。
反而通過上述幾種機制，可以上百倍的提升一個TB級大文件的上傳性能。
分享名稱：性能提升100倍！基于Hadoop的TB級大文件上傳優(yōu)化實踐
鏈接地址：http://www.5511xx.com/article/cdeiech.html
