HBASE存儲(chǔ)架構(gòu)

1、hbase存儲(chǔ)架構(gòu)英文原文：hbase最隱秘的問題之一就是它的數(shù)據(jù)是如何存儲(chǔ)的。雖然大多數(shù)用戶都不會(huì)因?yàn)檫@個(gè)問題向你抱怨，但是如果你想學(xué)習(xí)哪些高級(jí)的配置選項(xiàng)并了解它們的意思，你可能就需要來(lái)了解一下這個(gè)存儲(chǔ)問題了?！霸鯓硬拍馨裩base調(diào)整到最適合我需求的狀態(tài)？”你可能對(duì)于這樣一系列類似的問題非常感興趣。那么你就需要繞過(guò)這些問題來(lái)學(xué)習(xí)hbase的基礎(chǔ)知識(shí)。另一個(gè)支持你學(xué)習(xí)這些基礎(chǔ)知識(shí)的理由是有時(shí)候各種各樣你想不到的災(zāi)難需要你恢復(fù)整個(gè)hbase。我首先學(xué)習(xí)了hbase中控制各種不同文件的獨(dú)立的類，然后根據(jù)我對(duì)整個(gè)hbase存儲(chǔ)系統(tǒng)的理解在腦海中構(gòu)建hbase架構(gòu)的圖像。但是我發(fā)現(xiàn)想要在頭腦中構(gòu)建出

2、一幅連貫的hbase架構(gòu)圖片很困難，于是我就把它畫了出來(lái)。你可能注意到了這不是一個(gè)uml圖或者調(diào)用圖。這個(gè)圖混合了類和他們管理控制的文件，將注意力集中到了本文要討論的主題上。后面我將會(huì)討論這張圖所涉及到的細(xì)節(jié)，包括一些配置文件項(xiàng)是如何影響底層的文件存儲(chǔ)系統(tǒng)的。好，我們現(xiàn)在來(lái)分析這張圖里面到底包含了什么。首先hbase操控兩種基本類型的文件，一種用于存儲(chǔ)wal的log，另一種用于存儲(chǔ)具體的數(shù)據(jù)。這兩種文件主要由hregionserver來(lái)管理，但是在有的情況下hmaster會(huì)跳過(guò)hregionserver，直接操作這兩種文件。你可能注意到了，這些文件都被存儲(chǔ)在hdfs上面，并且每個(gè)文件包含了多個(gè)

3、數(shù)據(jù)塊。配置文件中就有一個(gè)選項(xiàng)用來(lái)調(diào)整系統(tǒng)控制數(shù)據(jù)的大小。我們后面會(huì)詳細(xì)討論這個(gè)問題。接下來(lái)看一下數(shù)據(jù)的大致流程。假設(shè)你需要通過(guò)某個(gè)特定的rowkey查詢一行記錄，首先client端會(huì)連接zookeeper qurom，通過(guò)zookeeper，client能獲知哪個(gè)server管理-root- region。接著client訪問管理-root-的server，進(jìn)而獲知哪個(gè)server管理.meta.表。這兩個(gè)信息client只會(huì)獲取一次并緩存起來(lái)。在后續(xù)的操作中client會(huì)直接訪問管理.meta.表的server，并獲取region分布的信息。一旦client獲取了這一行的位置信息，比如這一

4、行屬于哪個(gè)region，client將會(huì)緩存這個(gè)信息并直接訪問hregionserver。久而久之client緩存的信息漸漸增多，即使不訪問.meta.表也能知道去訪問哪個(gè)hregionserver。注意：當(dāng)hbase啟動(dòng)的時(shí)候hmaster負(fù)責(zé)分配region給hregionserver，這其中當(dāng)然也包括-root-表和.meta.表的region。接下來(lái)hregionserver打開這個(gè)region并創(chuàng)建一個(gè)hregion對(duì)象。當(dāng)hregion打開以后，它給每個(gè)table的每個(gè)hcolumnfamily創(chuàng)建一個(gè)store實(shí)例。每個(gè)store實(shí)例擁有一個(gè)或者多個(gè)storefile實(shí)例。sto

5、refile對(duì)hfile做了輕量級(jí)的包裝。除了store實(shí)例以外，每個(gè)hregion還擁有一個(gè)memstore實(shí)例和一個(gè)hlog實(shí)例。現(xiàn)在我們就可以看看這些實(shí)例是如何在一起工作的，遵循什么樣的規(guī)則以及這些規(guī)則的例外。保留住put現(xiàn)在看一下數(shù)據(jù)是怎樣被寫到實(shí)際的存儲(chǔ)中去的。client發(fā)起了一個(gè)htable.put(put)請(qǐng)求給hregionserver，hregionserver會(huì)將請(qǐng)求匹配到某個(gè)具體的hregion上面。緊接著的操作時(shí)決定是否寫wal log。是否寫wal log由client傳遞的一個(gè)標(biāo)志決定，你可以設(shè)置這個(gè)標(biāo)志：put.writetowal(boolean)。wal l

6、og文件是一個(gè)標(biāo)準(zhǔn)的hadoop sequencefile（現(xiàn)在還在討論是否應(yīng)該把文件格式改成一個(gè)更適合hbase的格式）。在文件中存儲(chǔ)了hlogkey，這些keys包含了和實(shí)際數(shù)據(jù)對(duì)應(yīng)的序列號(hào)，用途是當(dāng)regionserver崩潰以后能將wal log中的數(shù)據(jù)同步到永久存儲(chǔ)中去。做完這一步以后，put數(shù)據(jù)會(huì)被保存到memstore中，同時(shí)會(huì)檢查memstore是否已經(jīng)滿了，如果已經(jīng)滿了，則會(huì)觸發(fā)一個(gè)flush to disk的請(qǐng)求。hregionserver有一個(gè)獨(dú)立的線程來(lái)處理flush to disk的請(qǐng)求，它負(fù)責(zé)將數(shù)據(jù)寫成hfile文件并存到hdfs上。它也會(huì)存儲(chǔ)最后寫入的數(shù)據(jù)序列號(hào)，

7、這樣就可以知道哪些數(shù)據(jù)已經(jīng)存入了永久存儲(chǔ)的hdfs中?，F(xiàn)在讓我們來(lái)看看這些存儲(chǔ)文件。存儲(chǔ)文件hbase在hdfs上面的所有文件有一個(gè)可配置的根目錄，默認(rèn)根目錄是/hbase。通過(guò)使用hadoop的dfs工具就可以看到這些文件夾的結(jié)構(gòu)。在根目錄下面你可以看到一個(gè).logs文件夾，這里面存了所有由hlog管理的wal log文件。在.logs目錄下的每個(gè)文件夾對(duì)應(yīng)一個(gè)hregionserver，每個(gè)hregionserver下面的每個(gè)log文件對(duì)應(yīng)一個(gè)region。有時(shí)候你會(huì)發(fā)現(xiàn)一些oldlogfile.log文件（在大多數(shù)情況下你可能看不到這個(gè)文件），這個(gè)文件在一種異常情況下會(huì)被產(chǎn)生。這個(gè)異常情

8、況就是hmaster對(duì)log文件的訪問情況產(chǎn)生了懷疑，它會(huì)產(chǎn)生一種稱作“l(fā)og splits”的結(jié)果。有時(shí)候hmaster會(huì)發(fā)現(xiàn)某個(gè)log文件沒人管了，就是說(shuō)任何一個(gè)hregionserver都不會(huì)管理這個(gè)log文件（有可能是原來(lái)管理這個(gè)文件的hregionserver掛了），hmaster會(huì)負(fù)責(zé)分割這個(gè)log文件（按照它們歸屬的region），并把那些hlogkey寫到一個(gè)叫做oldlogfile.log的文件中，并按照它們歸屬的region直接將文件放到各自的region文件夾下面。各個(gè)hregion會(huì)從這個(gè)文件中讀取數(shù)據(jù)并將它們寫入到memstore中去，并開始將數(shù)據(jù)flush to d

9、isk。然后就可以把這個(gè)oldlogfile.log文件刪除了。注意：有時(shí)候你可能會(huì)發(fā)現(xiàn)另一個(gè)叫做oldlogfile.log.old的文件，這是由于hmaster做了重復(fù)分割log文件的操作并發(fā)現(xiàn)oldlogfile.log已經(jīng)存在了。這時(shí)候就需要和hregionserver以及hmaster協(xié)商到底發(fā)生了什么，以及是否可以把old的文件刪掉了。從我目前遇到的情況來(lái)看，old文件都是空的并且可以被安全刪除的。hbase的每個(gè)table在根目錄下面用一個(gè)文件夾來(lái)存儲(chǔ)，文件夾的名字就是table的名字。在table文件夾下面每個(gè)region也用一個(gè)文件夾來(lái)存儲(chǔ)，但是文件夾的名字并不是region

10、的名字，而是region的名字通過(guò)jenkins hash計(jì)算所得到的字符串。這樣做的原因是region的名字里面可能包含了不能在hdfs里面作為路徑名的字符。在每個(gè)region文件夾下面每個(gè)columnfamily也有自己的文件夾，在每個(gè)columnfamily文件夾下面就是一個(gè)個(gè)hfile文件了。所以整個(gè)文件夾結(jié)構(gòu)看起來(lái)應(yīng)該是這個(gè)樣子的：/hbase/在每個(gè)region文件夾下面你會(huì)發(fā)現(xiàn)一個(gè).regioninfo文件，這個(gè)文件用來(lái)存儲(chǔ)這個(gè)region的meta data。通過(guò)這些meta data我們可以重建被破壞的.meta.表，關(guān)于.regioninfo的應(yīng)用你可以參考hbase-7和

11、hbase-1867。有一件事情前面一直沒有提到，那就是region的分割。當(dāng)一個(gè)region的數(shù)據(jù)文件不斷增長(zhǎng)并超過(guò)一個(gè)最大值的時(shí)候（你可以配置這個(gè)最大值 hbase.hregion.max.filesize），這個(gè)region會(huì)被切分成兩個(gè)。這個(gè)過(guò)程完成的非?？?，因?yàn)樵嫉臄?shù)據(jù)文件并不會(huì)被改變，系統(tǒng)只是簡(jiǎn)單的創(chuàng)建兩個(gè)reference文件指向原始的數(shù)據(jù)文件。每個(gè)reference文件管理原始文件一半的數(shù)據(jù)。reference文件名字是一個(gè)id，它使用被參考的region的名字的hash作為前綴。例如：1278437856009925445.3323223323。reference文件只含有

12、非常少量的信息，這些信息包括被分割的原始region的key以及這個(gè)文件管理前半段還是后半段。hbase使用halfhfilereader類來(lái)訪問reference文件并從原始數(shù)據(jù)文件中讀取數(shù)據(jù)。前面的架構(gòu)圖只并沒有畫出這個(gè)類，因?yàn)樗皇桥R時(shí)使用的。只有當(dāng)系統(tǒng)做compaction的時(shí)候原始數(shù)據(jù)文件才會(huì)被分割成兩個(gè)獨(dú)立的文件并放到相應(yīng)的region目錄下面，同時(shí)原始數(shù)據(jù)文件和那些reference文件也會(huì)被清除。前面dump出來(lái)的文件結(jié)構(gòu)也證實(shí)了這個(gè)過(guò)程，在每個(gè)table的目錄下面你可以看到一個(gè)叫做compaction.dir的目錄。這個(gè)文件夾是一個(gè)數(shù)據(jù)交換區(qū)，用于存放split和compac

13、t region過(guò)程中生成的臨時(shí)數(shù)據(jù)。hfile現(xiàn)在我們將深入hbase存儲(chǔ)架構(gòu)的核心，探討hbase具體的數(shù)據(jù)存儲(chǔ)文件的結(jié)構(gòu)。storefile以hfile格式保存在hdfs上。hfile就是這個(gè)數(shù)據(jù)存儲(chǔ)文件的結(jié)構(gòu)（ryan rawson就是靠它揚(yáng)名立萬(wàn)的）。創(chuàng)建hfile這樣一個(gè)文件結(jié)構(gòu)的目的只有一個(gè)：快速高效的存儲(chǔ)hbase的數(shù)據(jù)。hfile是基于hadoop tfile的（參見 hadoop-3315）。hfile模仿了google bigtable中sstable的格式。原先hbase使用hadoop的mapfile，但是這種文件已經(jīng)被證明了效率差。現(xiàn)在讓我們來(lái)看看這個(gè)文件結(jié)構(gòu)到底是

14、什么樣的。首先這個(gè)文件是不定長(zhǎng)的，長(zhǎng)度固定的只有其中的兩塊：trailer和fileinfo。正如圖中所示的，trailer中有指針指向其他數(shù)據(jù)塊的起始點(diǎn)。index數(shù)據(jù)塊記錄了每個(gè)data塊和meta塊的起始點(diǎn)。data塊和meta塊都是可有可無(wú)的，但是對(duì)于大部分的hfile，你都可以看到data塊。那么每個(gè)塊的大小是如何確定的呢？這個(gè)值可以在創(chuàng)建一個(gè)table的時(shí)候通過(guò)hcolumndescriptor（實(shí)際上應(yīng)該稱作familydescriptor）來(lái)設(shè)定。這里我們可以看一個(gè)例子：name = docs, families = name = cache, compression = no

15、ne, versions = 3, ttl = 2147483647, blocksize = 65536, in_memory = false, blockcache = false, name = contents, compression = none, versions = 3, ttl = 2147483647, blocksize = 65536, in_memory = false, blockcache = false, 從這里可以看出這是一個(gè)叫做docs的table，它有兩個(gè)family：cache和contents，這兩個(gè)family對(duì)應(yīng)的hfile的數(shù)據(jù)塊的大小都是64k

16、。關(guān)于如何設(shè)定數(shù)據(jù)塊的大小，我們應(yīng)用一段hfile源碼中的注釋：我們推薦將數(shù)據(jù)塊的大小設(shè)置為8kb至1mb。大的數(shù)據(jù)塊比較適合順序的查詢（比如scan），但不適合隨機(jī)查詢，想想看，每一次隨機(jī)查詢可能都需要你去解壓縮一個(gè)大的數(shù)據(jù)塊。小的數(shù)據(jù)塊適合隨機(jī)的查詢，但是需要更多的內(nèi)存來(lái)保存數(shù)據(jù)塊的索引(data index)，而且創(chuàng)建文件的時(shí)候也可能比較慢，因?yàn)樵诿總€(gè)數(shù)據(jù)塊的結(jié)尾我們都要把壓縮的數(shù)據(jù)流flush到文件中去（引起更多的flush操作）。并且由于壓縮器內(nèi)部還需要一定的緩存，最小的數(shù)據(jù)塊大小應(yīng)該在20kb 30kb左右?？赡軓那懊娴拿枋瞿銜?huì)發(fā)現(xiàn)數(shù)據(jù)塊（data block）是數(shù)據(jù)壓縮的一個(gè)單位

17、。后面我們會(huì)深入data block內(nèi)部去了解它的詳細(xì)構(gòu)造。在hbase的配置文件中你會(huì)看到一個(gè)參數(shù)：hfile.min.blocksize.size，這個(gè)參數(shù)看上去只會(huì)用在數(shù)據(jù)遷移或者通過(guò)工具直接創(chuàng)建hfile的過(guò)程中。（貌似hbase創(chuàng)建hfile不會(huì)使用這個(gè)參數(shù)，hbase使用的是.meta.表中記錄的那個(gè)值）。呼，到現(xiàn)在為止解釋的還不錯(cuò)吧。好了，讓我們繼續(xù)。有時(shí)候我們可能會(huì)想知道一個(gè)hfile是否正常以及它里面包含了什么內(nèi)容。沒問題，已經(jīng)有一個(gè)應(yīng)用程序來(lái)做這件事了。hfile.main()本身就提供了一個(gè)用來(lái)dump hfile的工具。這里有一個(gè)dump文件的例子：第一部分是存儲(chǔ)具體數(shù)

18、據(jù)的keyvalue對(duì)，每個(gè)數(shù)據(jù)塊除了開頭的magic以外就是一個(gè)個(gè)keyvalue對(duì)拼接而成。后面會(huì)詳細(xì)介紹每個(gè)keyvalue對(duì)的內(nèi)部構(gòu)造。第二部分是tailer塊的具體內(nèi)容，最后一部分是fileinfo塊的具體內(nèi)容。dump hfile還有一個(gè)作用就是檢查hfile是否正常。keyvalue對(duì)hfile里面的每個(gè)keyvalue對(duì)就是一個(gè)簡(jiǎn)單的byte數(shù)組。但是這個(gè)byte數(shù)組里面包含了很多項(xiàng)，并且有固定的結(jié)構(gòu)。我們來(lái)看看里面的具體結(jié)構(gòu)：開始是兩個(gè)固定長(zhǎng)度的數(shù)值，分別表示key的長(zhǎng)度和value的長(zhǎng)度。緊接著是key，開始是固定長(zhǎng)度的數(shù)值，rowlength表示row的長(zhǎng)度，緊接著是ro

19、w，然后是固定長(zhǎng)度的數(shù)值，表示family的長(zhǎng)度，然后是family，接著是qualifier，然后是兩個(gè)固定長(zhǎng)度的數(shù)值，表示time stamp和key type。value部分沒有這么復(fù)雜的結(jié)構(gòu)，就是純粹的數(shù)據(jù)。.apache.hadoop.hbase.keyvalue是用來(lái)處理這個(gè)keyvalue，你可能會(huì)發(fā)現(xiàn)在這個(gè)類里面有兩個(gè)方法：getkey和getrow。getkey當(dāng)然是用來(lái)獲取key的內(nèi)容，那么getrow是什么？其實(shí)是用來(lái)獲取rowkey的。rowkey不是hbase的基本元素嗎？是的，這個(gè)類已經(jīng)不是純粹的key&value處理，它已經(jīng)打上了hbase的烙印。

20、好了，這篇文章就到此為止了，它對(duì)hbase的存儲(chǔ)架構(gòu)做了一個(gè)大致的介紹。希望這篇文章對(duì)于那些想更深入的挖掘hbase細(xì)節(jié)的人來(lái)說(shuō)，能作為一個(gè)起點(diǎn)。hbase 數(shù)據(jù)文件在hdfs上的存儲(chǔ)posted on july 24, 2010 by harry_ding hbase 數(shù)據(jù)文件在hdfs上的存儲(chǔ)英文原文：在hdfs上面最不明確的事情之一就是數(shù)據(jù)的冗余。它完全是自動(dòng)進(jìn)行的，因?yàn)闊o(wú)法得知其中詳細(xì)的信息，我們需要做的就是相信它。hbase完全相信hdfs存儲(chǔ)數(shù)據(jù)的安全性和完整性，并將數(shù)據(jù)文件交給hdfs存儲(chǔ)。正是因?yàn)閔dfs的數(shù)據(jù)冗余方式對(duì)于hbase來(lái)說(shuō)是完全透明的，產(chǎn)生了一個(gè)問題：hbase的

21、效率會(huì)受到多大的影響？說(shuō)的簡(jiǎn)單一點(diǎn)，當(dāng)hbase需要存取數(shù)據(jù)時(shí)，如何保證有一份冗余的數(shù)據(jù)塊離自己最近？當(dāng)我們對(duì)hbase做一次mapreduce的掃描操作時(shí)，這個(gè)問題尤其顯現(xiàn)出來(lái)。所有的regionserver都在從hdfs上面讀取數(shù)據(jù)，理想的狀況當(dāng)然是每個(gè)regionserver要讀取的數(shù)據(jù)都離自己很近。這個(gè)問題就牽扯到hbase的數(shù)據(jù)文件是如何在hdfs上面存儲(chǔ)的。讓我們首先拋開hbase，假設(shè)要處理的數(shù)據(jù)就是hdfs上面的數(shù)據(jù)塊，看看hadoop是如何工作的。mapreduce總是有一個(gè)建議，那就是在每個(gè)tasktracker上面map/reduce程序要處理的數(shù)據(jù)在本地就有一份冗余。這

22、樣程序只需要與本地?cái)?shù)據(jù)交互，減少了網(wǎng)絡(luò)流量并提高了效率。為了做到這一點(diǎn)，hdfs會(huì)把大文件分割成很多小文件來(lái)存儲(chǔ)，我們稱之為數(shù)據(jù)塊（block）。每個(gè)數(shù)據(jù)塊的大小比操作系統(tǒng)數(shù)據(jù)塊的大小要大得多，默認(rèn)是64m，但通常我們選擇128m，或者某個(gè)更大的值（這取決與你的文件大小，最好你的單個(gè)文件大小總是大于一個(gè)數(shù)據(jù)塊）。在mapreduce中，每個(gè)數(shù)據(jù)塊會(huì)被分配給一個(gè)task，這個(gè)task就負(fù)責(zé)處理這個(gè)數(shù)據(jù)塊中的數(shù)據(jù)。所以數(shù)據(jù)塊越大，產(chǎn)生的task就越少，需要mapper的數(shù)量就越少。hadoop自己知道每個(gè)數(shù)據(jù)塊存儲(chǔ)的位置，這樣在任務(wù)分配的時(shí)候就可以直接在存儲(chǔ)數(shù)據(jù)塊的機(jī)器上啟動(dòng)task，或者選擇一個(gè)

23、最近機(jī)器啟動(dòng)task。真是因?yàn)槊總€(gè)數(shù)據(jù)塊有多份冗余，使得hadoop有更大的選擇空間。只要找到一份冗余符合條件就行了，不是嗎？這樣hadoop就可以保證在mapreduce期間task總是操作本地?cái)?shù)據(jù)。讓我們回到hbase，現(xiàn)在你已經(jīng)理解了hadoop是如何保證在mapreduce的過(guò)程中每個(gè)task都盡量處理本地?cái)?shù)據(jù)。如果你看過(guò)hbase的存儲(chǔ)架構(gòu)你就會(huì)知道hbase只是簡(jiǎn)單的將hfile和wal log存儲(chǔ)在hdfs上面。通過(guò)簡(jiǎn)單的調(diào)用hdfs的api來(lái)創(chuàng)建文件：filesystem.create(path path)。接下來(lái)你會(huì)關(guān)心兩件事情的效率：1）隨機(jī)的訪問 2)通過(guò)mapreduc

24、e掃描全表。我們當(dāng)然希望當(dāng)每個(gè)regionserver讀取數(shù)據(jù)時(shí)存儲(chǔ)數(shù)據(jù)的數(shù)據(jù)塊就在本地。它能做到嗎？第一種情況，你有兩個(gè)集群，一個(gè)集群裝hadoop，另一個(gè)集群裝hbase，兩個(gè)集群是分隔開的，只有網(wǎng)線來(lái)傳輸數(shù)據(jù)。好了，討論到此為止，神也幫不了你。第二種情況，你有一個(gè)大的集群，每臺(tái)機(jī)器都混裝了hadoop和hbase，每個(gè)regionserver上面都有一個(gè)datanode（這是我們最希望看到的）。好，這樣的話regionserver就具備了從本地讀取數(shù)據(jù)的前提。我們還剩下一個(gè)問題，如何保證每個(gè)regionserver管理的region所對(duì)應(yīng)的hfile和wal log就存在本地的datan

25、ode上面？設(shè)想一種情況，你對(duì)hbase創(chuàng)建了大量的數(shù)據(jù)，每個(gè)regionserver都管理了各自的region，這時(shí)你重啟了hbase，重啟了所有的regionserver，所有的region都會(huì)被隨機(jī)的分配給各個(gè)regionserver，這種情況下你顯然無(wú)法保證我們希望的本地?cái)?shù)據(jù)存儲(chǔ)。在討論如何解決這個(gè)問題之前我們先強(qiáng)調(diào)一點(diǎn)：hbase不應(yīng)該頻繁的被重啟，并且部署的架構(gòu)不應(yīng)該被頻繁的改變，這是能解決這個(gè)問題的一個(gè)基礎(chǔ)。寫入hdfs的文件都有一個(gè)特點(diǎn)，一旦寫入一個(gè)文件就無(wú)法更改（由于種種原因）。因此hbase會(huì)定期的將數(shù)據(jù)寫入hdfs中并生成一個(gè)新文件。這里有一個(gè)讓人驚奇的地方：hdfs足夠

26、聰明，它知道如何將文件寫到最合適的地方。換句話說(shuō)，它知道把文件放到什么地方使得regionserver用起來(lái)最方便。如果想知道hdfs如何做到這一點(diǎn)，我們需要深入學(xué)習(xí)hadoop的源代碼，看看前面提到的filesystem.create(path path) 具體是怎么工作的。在hdfs中實(shí)際調(diào)用的函數(shù)是：distributedfilesystem.create(path path), 他看起來(lái)是這個(gè)樣子的：public fsdataoutputstream create(path f) throws ioexception return create(f, true);public fsda

27、taoutputstream create(path f, fspermission permission, boolean overwrite, int buffersize, short replication, long blocksize, progressable progress) throws ioexception return new fsdataoutputstream(dfs.create(getpathname(f), permission, overwrite, replication, blocksize, progress, buffersize), statis

28、tics);其中dfs是一個(gè)連接到hdfs namenode的dfsclient。當(dāng)你向hdfs寫入數(shù)據(jù)的時(shí)候，數(shù)據(jù)都流過(guò)dfsclient.dfsoutputstream，dfsclient將這些數(shù)據(jù)收集，積攢到一定程度后，作為一個(gè)block寫入到datanode里面。將一個(gè)block寫到datanode的過(guò)程都發(fā)生在dfsclient.dfsoutputstream.datastreamer里面，它是一個(gè)運(yùn)行在后臺(tái)的守護(hù)線程。注意，從現(xiàn)在開始我們將逐漸揭開解決問題的秘密方法。在接收到一個(gè)block以后，datastreamer需要知道這個(gè)block應(yīng)該被寫到哪些datanode上面，同時(shí)它

29、也應(yīng)該讓namenode知道這個(gè)block寫到了哪些datanode上面。它的做法是聯(lián)絡(luò)namenode：hi，我這里有一個(gè)文件的一個(gè)block，請(qǐng)告訴我應(yīng)該寫在哪些datanode上面？nodes = nextblockoutputstream(src);-long starttime = system.currenttimemillis();lb = locatefollowingblock(starttime);block = lb.getblock();nodes = lb.getlocations();-return namenode.addblock(src, clientname

30、);這時(shí)namenode收到了一個(gè)添加block的請(qǐng)求，它包含兩個(gè)參數(shù)：src和clientname其中src標(biāo)明了這個(gè)block屬于哪個(gè)文件，clientname則是client端的名稱。我們跳過(guò)一些簡(jiǎn)單的步驟來(lái)看最重要的一步：public locatedblock getadditionalblock(string src, string clientname) throws ioexception inodefileunderconstruction pendingfile = checklease(src, clientname);filelength = pendingfputeco

31、ntentsummary().getlength();blocksize = pendingfile.getpreferredblocksize();clientnode = pendingfile.getclientnode();replication = (int)pendingfile.getreplication();/ choose targets for the new block tobe allocated.datanodedescriptor targets = replicator.choosetarget(replication, clientnode, null, bl

32、ocksize);最重要的一步就是replicator.choosetarget()，它的具體實(shí)現(xiàn)如下：private datanodedescriptor choosetarget(int numofreplicas, datanodedescriptor writer, list excludednodes, long blocksize, int maxnodesperrack, list results) if (numofreplicas = 0 | clustermap.getnumofleaves()=0) return writer;int numofresults = res

33、ults.size();boolean newblock = (numofresults=0);if (writer = null & !newblock) writer = (datanodedescriptor)results.get(0);try switch(numofresults) case 0:writer = chooselocalnode(writer, excludednodes, blocksize, maxnodesperrack, results);if (numofreplicas = 0) break;case 1:chooseremoterack(1, results.get(0), excludednodes, blocksize, maxnodesperrack, results);if (numofreplicas = 0) break;case