基于改進(jìn)HDFS的冠字號(hào)小文件分布式存儲(chǔ)研究

徐俊　王慶華　趙云龍

摘要：針對(duì)冠字號(hào)小圖片存儲(chǔ)到HDFS系統(tǒng)中帶來(lái)的訪問(wèn)瓶頸問(wèn)題，改進(jìn)了原有的HDFS系統(tǒng)，新提出的分布式系統(tǒng)機(jī)制是充分基于文件相關(guān)性（File Correlation）進(jìn)行合并處理的HDFS（FCHDFS）。由于HDFS中所有的文件都是由單一的主節(jié)點(diǎn)服務(wù)器托管-NameNode，每個(gè)存儲(chǔ)到HDFS的文件在NameNode主存儲(chǔ)器中都需要存儲(chǔ)它的元數(shù)據(jù)，這必然導(dǎo)致小文件數(shù)量越大HDFS性能就越差。存儲(chǔ)和管理大量的小文件，對(duì)NameNode是一個(gè)沉重的負(fù)擔(dān)?？梢源鎯?chǔ)在HDFS的文件數(shù)量是受到NameNode的內(nèi)存大小約束。為了提高存儲(chǔ)和訪問(wèn)HDFS上的冠字號(hào)小文件的效率，該文提出了一個(gè)基于文件關(guān)聯(lián)性的小文件高效處理機(jī)制。在這種方法中，按照客戶(hù)和時(shí)間區(qū)分，一組相關(guān)的文件相結(jié)合為一個(gè)大文件，從而減少文件數(shù)目。而新建的索引機(jī)制能從相應(yīng)的聯(lián)合文件中訪問(wèn)單個(gè)文件。實(shí)驗(yàn)結(jié)果表明，F(xiàn)CHDFS大大減少主節(jié)點(diǎn)內(nèi)存中元數(shù)據(jù)數(shù)量，也提高了存儲(chǔ)和訪問(wèn)大量小文件的效率。

關(guān)鍵詞：Hadoop；小文件；HDFS；文件合并

中圖分類(lèi)號(hào)：TP18 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044（2014）17-3980-06

Research on Distributed Memory of Crown Size Small Files Based on Improved HDFS

XU Jun1，2， WANG Qing-hua1， ZHAO Yun-long1

（ 1. ATM Research Institute， GRGBanking，Guangzhou Radio Group， Guangzhou 510663， China； 2. College of Computer， South China Normal University， Guangzhou 510631， China ）

Abstract： Aiming at the access bottleneck problem caused by storage crown size small picture to the HDFS system， improved the existing HDFS system， new mechanism of distributed system is fully based on files correlation （File Correlation） and combined these correlated files. Because of all the files in HDFS are made by the master node server hosting the -NameNode single， each stored in the HDFS file needs to store the metadata it in NameNode main memory， which is bound to lead to a larger number of small file HDFS performance worse. For small file storage and management， NameNode is a heavy burden. The number of HDFS stored documents is constrainted by NameNode memory size. In addition， HDFS does not consider the correlation between files. In order to improve the efficiency of small file storage and access of HDFS， this paper proposes an efficient mechanism for handling small files based on crown size file association. In this method， according to differentiate customer and time， a group of related files are combined into one big file， thereby reducing the number of files. To access a single file from the file corresponding to the new index mechanism. The experimental results show that， FCHDFS greatly reduce the number of master nodes in data memory， and also improve the efficiency of storage and access to a large number of small files.

Key words： Hadoop； small file； HDFS； file merge

根據(jù)目前各大銀行總行的需求，冠字號(hào)信息需要集中到總行管理，冠字號(hào)圖像采用網(wǎng)點(diǎn)節(jié)點(diǎn)機(jī)保存，支持保存至少3個(gè)月的全行數(shù)據(jù)，數(shù)據(jù)量達(dá)幾十億上百億條。需求分析表明，記錄的產(chǎn)生速度和記錄的數(shù)量都滿(mǎn)足典型的大數(shù)據(jù)特征[1，2]，已經(jīng)接近或超過(guò)傳統(tǒng)數(shù)據(jù)庫(kù)技術(shù)的處理能力，而隨著系統(tǒng)的持久運(yùn)行和業(yè)務(wù)擴(kuò)大，記錄數(shù)量還有持續(xù)增長(zhǎng)的趨勢(shì)。因此分析系統(tǒng)的架構(gòu)應(yīng)以成熟的大數(shù)據(jù)系統(tǒng)架構(gòu)為基礎(chǔ)才能良好的實(shí)現(xiàn)其業(yè)務(wù)能力的要求。因此需要用到Hadoop[3]的分布時(shí)文件存儲(chǔ)系統(tǒng)（HDFS）[4]，然而采集的鈔票冠字號(hào)圖片是平均大小只有幾K的小文件，但存儲(chǔ)大量的小文件到HDFS中，NameNode節(jié)點(diǎn)需要存儲(chǔ)元數(shù)據(jù)將需要較大內(nèi)存開(kāi)銷(xiāo)。在這種情況下，當(dāng)應(yīng)用程序訪問(wèn)大量的這些小文件時(shí)，單個(gè)NameNode節(jié)點(diǎn)成為處理元數(shù)據(jù)請(qǐng)求的瓶頸。此外，NameNode節(jié)點(diǎn)的內(nèi)存大小限制HDFS可以存儲(chǔ)的文件數(shù)量。對(duì)于科學(xué)和許多其他需要產(chǎn)生了大量小文件應(yīng)用而言，正因?yàn)榇讼拗屏薍DFS被用來(lái)作為一個(gè)主要的數(shù)據(jù)存儲(chǔ)方式，也無(wú)法收益于Hadoop的數(shù)據(jù)處理能力，小文件處理問(wèn)題[5-7]也逐漸成為并行分布系統(tǒng)研究的一個(gè)熱點(diǎn)。endprint

Hadoop是一個(gè)開(kāi)源項(xiàng)目，開(kāi)發(fā)可靠性和可擴(kuò)展的分布式計(jì)算軟件。Hadoop框架已被廣泛應(yīng)用在各種集群構(gòu)建的大型高性能的系統(tǒng)中。Hadoop架構(gòu)由Hadoop分布式文件系統(tǒng)（HDFS）和MapReduce[8，9]編程模型，在商業(yè)的計(jì)算機(jī)集群中執(zhí)行數(shù)據(jù)密集型計(jì)算。Hadoop集群通過(guò)簡(jiǎn)單地增加商業(yè)機(jī)器，擴(kuò)充了計(jì)算能力、存儲(chǔ)容量和I/O帶寬。

Hadoop分布式文件系統(tǒng)（HDFS）是Hadoop文件系統(tǒng)組件的核心子項(xiàng)目。靈感來(lái)自谷歌的分布式文件系統(tǒng)（GFS）[10]，HDFS為寫(xiě)一次讀很多次的模式。HDFS是主從式架構(gòu)，一個(gè)單一的主節(jié)點(diǎn)-NameNode和多個(gè)從數(shù)據(jù)節(jié)點(diǎn)-DataNode。NameNode節(jié)點(diǎn)管理HDFS元數(shù)據(jù)和文件系統(tǒng)配置數(shù)據(jù)。元數(shù)據(jù)是保存在NameNode的主內(nèi)存中，保證客戶(hù)端快速訪問(wèn)和讀寫(xiě)請(qǐng)求。在HDFS中，數(shù)據(jù)節(jié)點(diǎn)DataNode存儲(chǔ)文件和滿(mǎn)足讀/寫(xiě)請(qǐng)求，并按照NameNode節(jié)點(diǎn)指令進(jìn)行。每個(gè)存儲(chǔ)到HDFS文件都會(huì)在任何一個(gè)數(shù)據(jù)節(jié)點(diǎn)做備份，以確保數(shù)據(jù)可靠性和可用性，這些分布在集群中的副本能確保被快速訪問(wèn)。

在本文中，針對(duì)冠字號(hào)小圖片存儲(chǔ)到HDFS系統(tǒng)中帶來(lái)的訪問(wèn)瓶頸問(wèn)題，改進(jìn)了原有的HDFS系統(tǒng)，通過(guò)考慮每次交易產(chǎn)生的一組冠字號(hào)圖片文件的關(guān)聯(lián)性，通過(guò)合并小文件操作，該文的FCHDFS提供一個(gè)解決方案來(lái)減少節(jié)點(diǎn)的內(nèi)存元數(shù)據(jù)。這需要一種在HDFS存儲(chǔ)小文件的有效方式?；镜姆椒ㄊ菍蝹€(gè)客戶(hù)相關(guān)的小文件合成一個(gè)大文件。這有助于減少文件數(shù)量，從而減少元數(shù)據(jù)的存儲(chǔ)。新的索引機(jī)制能夠從合并的文件訪問(wèn)單個(gè)文件。此外，基于文件的相關(guān)性合并操作將有助于減少NameNode元數(shù)據(jù)請(qǐng)求負(fù)載，相關(guān)文件的索引也被緩存到客戶(hù)端，達(dá)到更好的讀請(qǐng)求的性能。

1 背景

Hadoop是一個(gè)開(kāi)源框架，為數(shù)據(jù)密集型的應(yīng)用提供分布式的數(shù)據(jù)存儲(chǔ)和處理能力。它包括兩個(gè)主要部分組成：Hadoop分布式文件系統(tǒng)（HDFS）和MapReduce分布式計(jì)算。

1）Hadoop分布式文件系統(tǒng)

Hadoop分布式文件系統(tǒng)提供了在集群中對(duì)文件全局統(tǒng)一訪問(wèn)。HDFS由兩類(lèi)服務(wù)器節(jié)點(diǎn)組成，即NameNode節(jié)點(diǎn)和DataNode節(jié)點(diǎn)。NameNode是集中式單一的服務(wù)器，負(fù)責(zé)維護(hù)文件在HDFS中的元數(shù)據(jù)。它也維護(hù)了配置數(shù)據(jù)，比如對(duì)文件每一塊的副本數(shù)量稱(chēng)為備份參數(shù)，塊的大小和其它HDFS參數(shù)等。每個(gè)塊作為一個(gè)單獨(dú)的文件存儲(chǔ)在節(jié)點(diǎn)的本地文件系統(tǒng)中。作為數(shù)據(jù)節(jié)點(diǎn)抽象了底層的文件系統(tǒng)的細(xì)節(jié)，所有節(jié)點(diǎn)的特征不需要是相同的。數(shù)據(jù)節(jié)點(diǎn)負(fù)責(zé)按照NameNode要求存儲(chǔ)，檢索和刪除數(shù)據(jù)塊。在HDFS中文件被分成塊，每個(gè)塊的大小默認(rèn)是64 MB，被復(fù)制和存儲(chǔ)在多個(gè)數(shù)據(jù)節(jié)點(diǎn)中。NameNode在主存儲(chǔ)器里維護(hù)了每個(gè)存儲(chǔ)在HDFS中的文件的元數(shù)據(jù)。這包括存儲(chǔ)文件名之間的映射，相應(yīng)每個(gè)文件在數(shù)據(jù)節(jié)點(diǎn)中的塊。因此，客戶(hù)創(chuàng)建、寫(xiě)入、讀取或刪除文件的每個(gè)請(qǐng)求都需要通過(guò)NameNode節(jié)點(diǎn)。使用元數(shù)據(jù)存儲(chǔ)，NameNode節(jié)點(diǎn)必須為來(lái)自客戶(hù)的每次請(qǐng)求導(dǎo)向到適當(dāng)?shù)臄?shù)據(jù)節(jié)點(diǎn)集合上。然后客戶(hù)端直接與數(shù)據(jù)節(jié)點(diǎn)通信來(lái)執(zhí)行文件操作。

單個(gè)NameNode節(jié)點(diǎn)，在主存儲(chǔ)器中存儲(chǔ)元數(shù)據(jù)，當(dāng)它必須處理大量的小文件時(shí)將成為一個(gè)瓶頸。小文件指的是任何尺寸小于HDFS塊大小的文件。這個(gè)問(wèn)題，稱(chēng)為小文件的問(wèn)題，阻礙了許多潛在的應(yīng)用使用Hadoop框架的好處。

2）小文件的問(wèn)題

為了滿(mǎn)足客戶(hù)端快捷、高效的請(qǐng)求服務(wù)，NameNode在主內(nèi)存中存儲(chǔ)整個(gè)元數(shù)據(jù)。文件的每個(gè)塊都需要對(duì)應(yīng)元數(shù)據(jù)被存儲(chǔ)。當(dāng)一個(gè)存儲(chǔ)的文件大小大于塊大小時(shí)，存儲(chǔ)的元數(shù)據(jù)量由文件大小決定。然而當(dāng)大量小于塊大小的小文件需要存儲(chǔ)時(shí)，每個(gè)文件都需要以塊的形式存儲(chǔ)，因此相應(yīng)存儲(chǔ)的元數(shù)據(jù)數(shù)量也是相當(dāng)高的。例如假設(shè)每一個(gè)元數(shù)據(jù)占用150個(gè)字節(jié)，那么對(duì)于一個(gè)1 GB的文件，分為16個(gè)不同64MB塊，就需要2.4KB的空間存儲(chǔ)元數(shù)據(jù)。然而對(duì)于10500個(gè)大小為100KB的文件（共1 GB），大約需要1.5MB空間存儲(chǔ)元數(shù)據(jù)。因此大量的小文件占用文件系統(tǒng)的空間小，但相應(yīng)的元數(shù)據(jù)卻需要占用較大的NameNode節(jié)點(diǎn)的主內(nèi)存量空間。這樣的情況是對(duì)集群的可用空間不合理的應(yīng)用。此外，訪問(wèn)大量的這些小文件的結(jié)果是會(huì)造成NameNode訪問(wèn)瓶頸的。這有礙于HDFS在各種應(yīng)用的最佳使用。

2 本文小文件處理機(jī)制

本文提出的考慮文件關(guān)聯(lián)性的分布式文件系統(tǒng)（FCHDFS）提供了一種小文件合并操作和改進(jìn)的索引機(jī)制。為提高HDFS處理小文件的效率，F(xiàn)CHDFS中四項(xiàng)技術(shù)發(fā)揮了重要的作用。它們分別是文件合并，文件映射，文件提取。如圖1所示系統(tǒng)的總體架構(gòu)描述處理這些業(yè)務(wù)模塊的位置。

下面的部分詳細(xì)描述了這些技術(shù)。

1）文件合并

HDFS小文件的主要問(wèn)題是NameNode節(jié)點(diǎn)需要較大的內(nèi)存空間用于管理這些小文件。HDFS不會(huì)從一個(gè)大的文件中區(qū)分小的文件，因此無(wú)論文件大小都需要存儲(chǔ)相同大小的元數(shù)據(jù)。NameNode節(jié)點(diǎn)在HDFS中維護(hù)兩種類(lèi)型的元數(shù)據(jù)即文件的元數(shù)據(jù)和文件塊的元數(shù)據(jù)。文件的元數(shù)據(jù)包括了文件的文件名、文件在名稱(chēng)空間樹(shù)中的位置、文件大小、修改時(shí)間、訪問(wèn)時(shí)間、所有的細(xì)節(jié)和文件權(quán)限等信息。塊的元數(shù)據(jù)包括關(guān)于這些塊的信息和存儲(chǔ)位置。

文件合并技術(shù)減少了NameNode節(jié)點(diǎn)處理小文件需要存儲(chǔ)的文件元數(shù)據(jù)和塊元數(shù)據(jù)。該技術(shù)是基于這個(gè)事實(shí)，客戶(hù)端把文件合并到一起上傳到HDFS系統(tǒng)與每一個(gè)文件單獨(dú)上傳到HDFS，所需要的文件元數(shù)據(jù)大小是相同的。文件合并保證NameNode節(jié)點(diǎn)只保存組合文件的元數(shù)據(jù)并不是所有存在于它的小文件的元數(shù)據(jù)。組成文件的名稱(chēng)和塊信息作為一個(gè)特殊的數(shù)據(jù)結(jié)構(gòu)在NameNode節(jié)點(diǎn)里維護(hù)處理。

使用FCHDFS創(chuàng)建文件時(shí)，文件合并過(guò)程在客戶(hù)端進(jìn)行。在創(chuàng)建組合文件時(shí)，客戶(hù)端說(shuō)明了小文件的名稱(chēng)和每個(gè)文件相關(guān)的數(shù)據(jù)。這個(gè)數(shù)據(jù)在客戶(hù)端緩存，直到?jīng)]有不超過(guò)HDFS塊大小的文件數(shù)據(jù)需要添加。這確保了沒(méi)有小文件在塊之間分割存儲(chǔ)。endprint

隨著文件數(shù)據(jù)，索引表放在每個(gè)數(shù)據(jù)塊的開(kāi)始。該表包含每個(gè)小文件的入口，這一塊的一部分。每個(gè)表項(xiàng)是一個(gè)（偏移量，長(zhǎng)度）對(duì)。在塊和文件，索引表中的第i項(xiàng)指定的小文件的第一個(gè)字節(jié)的偏移量從開(kāi)始的塊長(zhǎng)度的小文件的字節(jié)數(shù)。在索引表中的信息可以被用來(lái)確定相應(yīng)的文件的開(kāi)始和結(jié)束位置。所產(chǎn)生的塊結(jié)構(gòu)，稱(chēng)為擴(kuò)展塊，如圖2所示。

擴(kuò)展塊代表組合文件的一部分。在HDFS DataNode節(jié)點(diǎn)中，這些塊像任何其他正常文件塊一樣存儲(chǔ)。

2）文件映射

文件映射是將小文件名映射到包含該文件的組合文件塊的過(guò)程。這是由NameNode節(jié)點(diǎn)執(zhí)行的。用戶(hù)要從組合文件中讀取一個(gè)小文件，文件映射技術(shù)就起作用了。啟動(dòng)讀操作時(shí)，用戶(hù)必須明確指定組合文件和小文件的名稱(chēng)。一個(gè)請(qǐng)求發(fā)送到NameNode節(jié)點(diǎn)，根據(jù)這兩個(gè)文件名，能獲取所需的小文件的位置

對(duì)于每個(gè)組合文件，NameNode節(jié)點(diǎn)維護(hù)一個(gè)數(shù)據(jù)結(jié)構(gòu)叫做組合文件映射表。它包含一個(gè)小的文件名稱(chēng)和包含該小文件的合并文件的邏輯塊號(hào)之間的映射。針對(duì)邏輯塊號(hào)和數(shù)據(jù)節(jié)點(diǎn)的信息，NameNode還提供了一個(gè)“索引號(hào)”。對(duì)應(yīng)于請(qǐng)求的小文件，這種“索引號(hào)”指定了索引表存儲(chǔ)在塊開(kāi)始的入口地址，從而避免了線(xiàn)性搜索。

圖4顯示了一個(gè)組合文件File的組合文件映射表數(shù)據(jù)結(jié)構(gòu)。此文件包含分布在2個(gè)塊中的5個(gè)小文件。塊1包含文件F1和F2。塊2保存從F3到F5的3個(gè)文件。文件名被散列到組合文件映射表中。除了文件的名稱(chēng)，還存儲(chǔ)了有關(guān)塊的排序信息。這個(gè)排序信息是存儲(chǔ)在“索引號(hào)”字段里。

“索引號(hào)”值1表示這是在給定的塊和它的索引表中的相應(yīng)條目出現(xiàn)在從塊開(kāi)始的偏移量為零的第一個(gè)文件。在文件合并過(guò)程中，索引號(hào)碼以類(lèi)似的方式分配給塊中的每個(gè)文件。塊如圖3所示。

相比傳統(tǒng)所使用的技術(shù)，該文的映射技術(shù)具有更好的可擴(kuò)展性。它也不會(huì)保持邏輯塊號(hào)映射為文件名的一部分的任何文件。這使該解決方案與領(lǐng)域無(wú)關(guān)。

3）文件提取

文件提取涉及到從一個(gè)塊中提取所需的文件內(nèi)容的過(guò)程。這個(gè)操作由DataNode數(shù)據(jù)節(jié)點(diǎn)完成。當(dāng)讀取文件時(shí)，用戶(hù)需要指明小文件名和組合文件名。此信息是用于獲得包含文件的塊，存儲(chǔ)塊的DataNode和NameNode 的“索引號(hào)”。所得的“索引號(hào)”發(fā)送到存儲(chǔ)數(shù)據(jù)塊的DataNode節(jié)點(diǎn)。DataNode然后使用此值去尋求所需放置在塊開(kāi)始的索引表中入口地址。索引表中的條目包含從塊開(kāi)始文件數(shù)據(jù)的偏移和數(shù)據(jù)文件的長(zhǎng)度。DataNode然后尋找所需的偏移量和讀取文件數(shù)據(jù)并將數(shù)據(jù)發(fā)送到客戶(hù)端。同時(shí)把整個(gè)數(shù)據(jù)塊發(fā)送回客戶(hù)端，此操作大大降低了網(wǎng)絡(luò)負(fù)載。

4）文件訪問(wèn)操作

以下各節(jié)描述文件的讀寫(xiě)操作在FCHDFS是如何進(jìn)行的。

1） 寫(xiě)操作：使用FCHDFS創(chuàng)建組合文件時(shí)，寫(xiě)操作被啟動(dòng)。在客戶(hù)端，用戶(hù)使用FCHDFS模塊調(diào)用創(chuàng)建操作。然后將請(qǐng)求發(fā)送到NameNode節(jié)點(diǎn)，通過(guò)RPC為所需存儲(chǔ)的組合文件創(chuàng)建和初始化數(shù)據(jù)結(jié)構(gòu)。從NameNode節(jié)點(diǎn)創(chuàng)建一個(gè)特殊的inode表示文件被創(chuàng)建的是一個(gè)組合文件并保存到命名空間樹(shù)。NameNod節(jié)點(diǎn)初始化一個(gè)組合文件映射。該映射是保存為代表的文件的inode部分認(rèn)為條目表示形式的聯(lián)合文件的部分的小的文件。

客戶(hù)端被提供了一個(gè)輸出流和一些額外的輔助方法，有助于關(guān)聯(lián)文件數(shù)據(jù)到組合文件中一個(gè)入口地址。寫(xiě)入輸出流數(shù)據(jù)最初在客戶(hù)端的緩存執(zhí)行文件合并。緩沖區(qū)可容納的數(shù)據(jù)塊的值。一個(gè)索引表是由目前在緩沖區(qū)中的所有文件構(gòu)成。該表包含每個(gè)文件的元組作為在合并過(guò)程中的解釋。緩沖區(qū)的內(nèi)容附加上索引表被發(fā)送到數(shù)據(jù)節(jié)點(diǎn)。表中被計(jì)算的每個(gè)項(xiàng)的偏移量，也包括在塊開(kāi)始的表的大小。

該索引表的目的是快速定位所需的塊的文件開(kāi)始位置而不需要掃描整個(gè)塊。隨著邏輯塊號(hào)所需文件元組在NameNode節(jié)點(diǎn)存儲(chǔ)，使得速度更快。

成功地寫(xiě)入數(shù)據(jù)塊到數(shù)據(jù)節(jié)點(diǎn)，客戶(hù)端發(fā)送一個(gè)更新請(qǐng)求到NameNode節(jié)點(diǎn)，指明被寫(xiě)入最近的塊文件名列表，以及每個(gè)文件的索引條目編號(hào)。這被NameNode節(jié)點(diǎn)使用來(lái)構(gòu)造組合文件的映射。重復(fù)此過(guò)程，直到用戶(hù)關(guān)閉被創(chuàng)建的組合文件。

2） 讀操作：用戶(hù)啟動(dòng)讀操作直接訪問(wèn)合并文件中的小文件。在文件系統(tǒng)中的文件的路徑是通過(guò)指定文件名的組合含有小文件的文件夾名來(lái)表示。換句話(huà)說(shuō)，如果“ABC”是組合文件和“file1”是小文件的名稱(chēng)，然后用戶(hù)可以指定“file1”“路徑為“組合文件的位置/ ABC / file1”。

客戶(hù)端模塊從給定的路徑提取組合的文件名和小文件名，并從NameNode請(qǐng)求對(duì)應(yīng)于小文件元數(shù)據(jù)。這是一個(gè)基于RPC的請(qǐng)求，NameNode節(jié)點(diǎn)響應(yīng)它通過(guò)存儲(chǔ)在指定的組合文件的組成文件映射查找小文件名。塊的位置（列表的數(shù)據(jù)節(jié)點(diǎn)）、邏輯塊號(hào)和索引號(hào)為響應(yīng)發(fā)送回客戶(hù)端。

請(qǐng)求文件的元數(shù)據(jù)從緩存或NameNode節(jié)點(diǎn)中獲取后，將在客戶(hù)端和存儲(chǔ)該塊的數(shù)據(jù)節(jié)點(diǎn)之間建立流連接。在這階段，請(qǐng)求文件的索引號(hào)發(fā)送到數(shù)據(jù)節(jié)點(diǎn)，并且數(shù)據(jù)節(jié)點(diǎn)在塊索引表中讀取到指定的項(xiàng)。在未來(lái)的讀操作中，它將使用該偏移量和長(zhǎng)度值。

客戶(hù)可以通過(guò)文件讀入指定偏移相對(duì)于文件的開(kāi)始，即第一個(gè)字節(jié)的文件偏移零從文件的開(kāi)始。這個(gè)偏移然后轉(zhuǎn)換為它添加在數(shù)據(jù)節(jié)點(diǎn)的索引表中的塊的偏移值計(jì)算等效。讀取操作，然后委托給現(xiàn)有的API，允許原HDFS讀取塊開(kāi)始在指定的偏移量。整個(gè)閱讀過(guò)程如圖7所示。

3 實(shí)驗(yàn)仿真及結(jié)果分析

本文提出的文件小文件處理技術(shù)方案需要在Hadoop集群上進(jìn)行相關(guān)實(shí)驗(yàn)。通過(guò)實(shí)驗(yàn)，該文針對(duì)完成讀寫(xiě)操作所占用的內(nèi)存和花費(fèi)時(shí)間等指標(biāo)參數(shù)，對(duì)比了傳統(tǒng)HDFS與FCHDFS系統(tǒng)性能。實(shí)驗(yàn)測(cè)試平臺(tái)包含3臺(tái)普通PC機(jī)，其中一臺(tái)作為名稱(chēng)服務(wù)器節(jié)點(diǎn)NameNode，其它兩臺(tái)作為數(shù)據(jù)服務(wù)器節(jié)點(diǎn)DataNode。這些機(jī)器都具有以下配置：Intel酷睿2雙核2.10 GHz，2GB的內(nèi)存，320 GB/5400硬盤(pán)。在每一臺(tái)機(jī)器安裝Linux操作系統(tǒng)。開(kāi)發(fā)環(huán)境是Hadoop版本0.20.1分布式系統(tǒng)、Eclipse4.2.1和Java版本1.6.0。endprint

對(duì)于NameNode內(nèi)存使用的測(cè)量，該試驗(yàn)測(cè)試工作共包含200000個(gè)文件。這些文件從20KB到300kb大小范圍。所有文件的累積大小約為12.35gb。采取的讀寫(xiě)操作時(shí)的工作量是用于內(nèi)存使用實(shí)驗(yàn)工作量的一個(gè)子集的分布，包含1000個(gè)文件。

基于以下參數(shù)測(cè)定集群性能：

1）使用NameNode節(jié)點(diǎn)存儲(chǔ)元數(shù)據(jù)的內(nèi)存量

2）完成讀寫(xiě)操作使用時(shí)間量

采用內(nèi)存分析器工具包測(cè)量NameNode節(jié)點(diǎn)存儲(chǔ)元數(shù)據(jù)所使用的內(nèi)存情況。Jmap工具被用來(lái)獲取所有目前在Java NameNode進(jìn)程內(nèi)存中活對(duì)象的堆轉(zhuǎn)儲(chǔ)。內(nèi)存分析器工具包進(jìn)行分析所得到的堆轉(zhuǎn)儲(chǔ)。完成讀寫(xiě)操作的時(shí)間使用操作系統(tǒng)Linux命令以毫秒測(cè)量。

實(shí)驗(yàn)是在原有的HDFS和FCHDFS上進(jìn)行。通過(guò)放置2000批文件在HDFS后分析堆轉(zhuǎn)儲(chǔ)，測(cè)定節(jié)點(diǎn)的內(nèi)存使用情況。共有2000000個(gè)文件被放置和100次讀寫(xiě)（以每2000個(gè)放置到HDFS的文件），重復(fù)3次及三個(gè)讀數(shù)，并計(jì)算平均值。FCHDFS采用同樣的步驟，比較了兩種情況下內(nèi)存使用情況，如圖5所示。

圖5 NameNode內(nèi)存使用

圖5顯示了兩種情況下內(nèi)存的使用模式。三角形標(biāo)記的曲線(xiàn)對(duì)應(yīng)的原始沒(méi)做任何更改的HDFS內(nèi)存使用情況。隨著文件的數(shù)量增加，內(nèi)存使用也線(xiàn)性增加。這是預(yù)期的結(jié)果，因?yàn)樽鳛镹ameNode節(jié)點(diǎn)必須保存文件和塊的元數(shù)據(jù)。第二條是正方形標(biāo)記的曲線(xiàn)代表FCHDFS，為了有效的文件訪問(wèn)，NameNode必須保存額外的數(shù)據(jù)結(jié)構(gòu)。存儲(chǔ)相同數(shù)量的文件，通過(guò)FCHDFS使用的內(nèi)存明顯小于使用HDFS。FCHDFS只維護(hù)每個(gè)小文件的文件元數(shù)據(jù)，而不用維護(hù)它們的塊元數(shù)據(jù)。NameNode只維護(hù)單個(gè)聯(lián)合文件的塊元數(shù)據(jù)，而不為每一個(gè)小文件維護(hù)它們的塊元數(shù)據(jù)，所以FCHDFS將占用更少的內(nèi)存。

在這個(gè)實(shí)驗(yàn)中，對(duì)HDFS和FCHDFS測(cè)試寫(xiě)操作的結(jié)果如圖6所示。

圖6 寫(xiě)操作所耗時(shí)間

FCHDFS的寫(xiě)操作是大大快于HDFS的寫(xiě)操作。通過(guò)圖6實(shí)驗(yàn)分析結(jié)果清楚地顯示這一點(diǎn)。10000個(gè)文件寫(xiě)到HDFS的時(shí)間是非常高的，因?yàn)镹ameNode節(jié)點(diǎn)必須為每個(gè)寫(xiě)入HDFS的文件創(chuàng)建和分配塊空間。FCHDFS避免了這種繁瑣的操作，文件的創(chuàng)建NameNode 節(jié)點(diǎn)被訪問(wèn)一次，并且只有再加入一新塊到合并文件中才調(diào)用寫(xiě)操作。另一個(gè)發(fā)揮作用的重要因素是用于客戶(hù)端合并文件的緩沖機(jī)制。添加一個(gè)新塊的請(qǐng)求發(fā)送到NameNode節(jié)點(diǎn)前，數(shù)據(jù)塊是先緩存到客戶(hù)端。只為每個(gè)64MB的數(shù)據(jù)發(fā)送一個(gè)請(qǐng)求到NameNode節(jié)點(diǎn)，而不是每一個(gè)小的文件。

4 結(jié)束語(yǔ)

HDFS最初被設(shè)計(jì)為存儲(chǔ)大文件的。當(dāng)它是用來(lái)存儲(chǔ)大量的小文件時(shí)，I/O性能成為瓶頸。在本文中，針對(duì)冠字號(hào)小圖片存儲(chǔ)到HDFS系統(tǒng)中帶來(lái)的訪問(wèn)瓶頸問(wèn)題，改進(jìn)了原有的HDFS系統(tǒng)，提出了基于文件關(guān)聯(lián)性合并機(jī)制的FCHDFS，它把大量的小文件合并成一個(gè)單一的聯(lián)合文件。從性能進(jìn)行分析，對(duì)于小文件的存儲(chǔ)和管理，F(xiàn)CHDFS提高了對(duì)小文件的訪問(wèn)效率和減少節(jié)點(diǎn)的內(nèi)存元數(shù)據(jù)數(shù)量。FCHDFS通過(guò)提供更高效的小文件元數(shù)據(jù)管理，允許更充分的利用HDFS的資源。該文對(duì)于2000000個(gè)小文件進(jìn)行試驗(yàn)測(cè)試，結(jié)果證實(shí)內(nèi)存的使用量大大減少了。相比原來(lái)的HDFS，F(xiàn)CHDFS寫(xiě)操作時(shí)間也有較明顯的縮短。

參考文獻(xiàn)：

[1] 覃雄派，王會(huì)舉，王珊，等.大數(shù)據(jù)分析-RDBMS與MapReduce的競(jìng)爭(zhēng)與共生[J].軟件學(xué)報(bào)，2012，23（1）：32-45.

[2] 王珊，王會(huì)舉，等.架構(gòu)大數(shù)據(jù)：挑戰(zhàn)、現(xiàn)狀與展望[J].計(jì)算機(jī)學(xué)報(bào)，2011，34（10）：1742-1752.

[3] Chuck Lam.Hadoop實(shí)戰(zhàn)[M].北京：人民郵電出版社，2012.

[4] Shvachko K，Hairong Kuang，Radia S.The Hadoop Distributed File System，Mass Storage Systems and Technologies（MSST）[C].2010 IEEE 26th Symposium， 2010：1-10， 3-7.

[5] Li xiu-qiao，Dong bin，Xiao Li-min，et al.Small Files Problem inParallel File System[J].Network Computing and Information Security，New York： IEEE Computer Society，2011：227-232.

[6] Carns P，Lang S，Ross R，et al.Small-file access in parallel file systems[C].International Parallel and Distributed Processing Symposium，New York：IEEE Computer Society，2009：1-11.

[7] Faraz Shaikh，Mikhil Chainani.A case for small file packing in parallel virtual file system （pvfs2）[C].Advanced and Distributed Operating Systems Fall 07， 2007.

[8] Grant Mackey，Saba Sehrish，Julio LopezIntroducing Map-Reduce to High End Computing. InPetascale Data Storage Workshop at SC08， Austin， Texas， November 2008.

[9] Michael C Schatz.CloudBurst：Highly Sensitive Read Mapping with MapReduce[J].Bioinformatics，2009.

[10] Ghemawat S，Gobioff H，Leung S.The Google file system[C].Symposium on Operating Systems Principles 2003.New York：ACM.2003：29-43.endprint

對(duì)于NameNode內(nèi)存使用的測(cè)量，該試驗(yàn)測(cè)試工作共包含200000個(gè)文件。這些文件從20KB到300kb大小范圍。所有文件的累積大小約為12.35gb。采取的讀寫(xiě)操作時(shí)的工作量是用于內(nèi)存使用實(shí)驗(yàn)工作量的一個(gè)子集的分布，包含1000個(gè)文件。

基于以下參數(shù)測(cè)定集群性能：

1）使用NameNode節(jié)點(diǎn)存儲(chǔ)元數(shù)據(jù)的內(nèi)存量

2）完成讀寫(xiě)操作使用時(shí)間量

采用內(nèi)存分析器工具包測(cè)量NameNode節(jié)點(diǎn)存儲(chǔ)元數(shù)據(jù)所使用的內(nèi)存情況。Jmap工具被用來(lái)獲取所有目前在Java NameNode進(jìn)程內(nèi)存中活對(duì)象的堆轉(zhuǎn)儲(chǔ)。內(nèi)存分析器工具包進(jìn)行分析所得到的堆轉(zhuǎn)儲(chǔ)。完成讀寫(xiě)操作的時(shí)間使用操作系統(tǒng)Linux命令以毫秒測(cè)量。

實(shí)驗(yàn)是在原有的HDFS和FCHDFS上進(jìn)行。通過(guò)放置2000批文件在HDFS后分析堆轉(zhuǎn)儲(chǔ)，測(cè)定節(jié)點(diǎn)的內(nèi)存使用情況。共有2000000個(gè)文件被放置和100次讀寫(xiě)（以每2000個(gè)放置到HDFS的文件），重復(fù)3次及三個(gè)讀數(shù)，并計(jì)算平均值。FCHDFS采用同樣的步驟，比較了兩種情況下內(nèi)存使用情況，如圖5所示。

圖5 NameNode內(nèi)存使用

圖5顯示了兩種情況下內(nèi)存的使用模式。三角形標(biāo)記的曲線(xiàn)對(duì)應(yīng)的原始沒(méi)做任何更改的HDFS內(nèi)存使用情況。隨著文件的數(shù)量增加，內(nèi)存使用也線(xiàn)性增加。這是預(yù)期的結(jié)果，因?yàn)樽鳛镹ameNode節(jié)點(diǎn)必須保存文件和塊的元數(shù)據(jù)。第二條是正方形標(biāo)記的曲線(xiàn)代表FCHDFS，為了有效的文件訪問(wèn)，NameNode必須保存額外的數(shù)據(jù)結(jié)構(gòu)。存儲(chǔ)相同數(shù)量的文件，通過(guò)FCHDFS使用的內(nèi)存明顯小于使用HDFS。FCHDFS只維護(hù)每個(gè)小文件的文件元數(shù)據(jù)，而不用維護(hù)它們的塊元數(shù)據(jù)。NameNode只維護(hù)單個(gè)聯(lián)合文件的塊元數(shù)據(jù)，而不為每一個(gè)小文件維護(hù)它們的塊元數(shù)據(jù)，所以FCHDFS將占用更少的內(nèi)存。

在這個(gè)實(shí)驗(yàn)中，對(duì)HDFS和FCHDFS測(cè)試寫(xiě)操作的結(jié)果如圖6所示。

圖6 寫(xiě)操作所耗時(shí)間

FCHDFS的寫(xiě)操作是大大快于HDFS的寫(xiě)操作。通過(guò)圖6實(shí)驗(yàn)分析結(jié)果清楚地顯示這一點(diǎn)。10000個(gè)文件寫(xiě)到HDFS的時(shí)間是非常高的，因?yàn)镹ameNode節(jié)點(diǎn)必須為每個(gè)寫(xiě)入HDFS的文件創(chuàng)建和分配塊空間。FCHDFS避免了這種繁瑣的操作，文件的創(chuàng)建NameNode 節(jié)點(diǎn)被訪問(wèn)一次，并且只有再加入一新塊到合并文件中才調(diào)用寫(xiě)操作。另一個(gè)發(fā)揮作用的重要因素是用于客戶(hù)端合并文件的緩沖機(jī)制。添加一個(gè)新塊的請(qǐng)求發(fā)送到NameNode節(jié)點(diǎn)前，數(shù)據(jù)塊是先緩存到客戶(hù)端。只為每個(gè)64MB的數(shù)據(jù)發(fā)送一個(gè)請(qǐng)求到NameNode節(jié)點(diǎn)，而不是每一個(gè)小的文件。

4 結(jié)束語(yǔ)

HDFS最初被設(shè)計(jì)為存儲(chǔ)大文件的。當(dāng)它是用來(lái)存儲(chǔ)大量的小文件時(shí)，I/O性能成為瓶頸。在本文中，針對(duì)冠字號(hào)小圖片存儲(chǔ)到HDFS系統(tǒng)中帶來(lái)的訪問(wèn)瓶頸問(wèn)題，改進(jìn)了原有的HDFS系統(tǒng)，提出了基于文件關(guān)聯(lián)性合并機(jī)制的FCHDFS，它把大量的小文件合并成一個(gè)單一的聯(lián)合文件。從性能進(jìn)行分析，對(duì)于小文件的存儲(chǔ)和管理，F(xiàn)CHDFS提高了對(duì)小文件的訪問(wèn)效率和減少節(jié)點(diǎn)的內(nèi)存元數(shù)據(jù)數(shù)量。FCHDFS通過(guò)提供更高效的小文件元數(shù)據(jù)管理，允許更充分的利用HDFS的資源。該文對(duì)于2000000個(gè)小文件進(jìn)行試驗(yàn)測(cè)試，結(jié)果證實(shí)內(nèi)存的使用量大大減少了。相比原來(lái)的HDFS，F(xiàn)CHDFS寫(xiě)操作時(shí)間也有較明顯的縮短。

參考文獻(xiàn)：

[1] 覃雄派，王會(huì)舉，王珊，等.大數(shù)據(jù)分析-RDBMS與MapReduce的競(jìng)爭(zhēng)與共生[J].軟件學(xué)報(bào)，2012，23（1）：32-45.

[2] 王珊，王會(huì)舉，等.架構(gòu)大數(shù)據(jù)：挑戰(zhàn)、現(xiàn)狀與展望[J].計(jì)算機(jī)學(xué)報(bào)，2011，34（10）：1742-1752.

[3] Chuck Lam.Hadoop實(shí)戰(zhàn)[M].北京：人民郵電出版社，2012.

[4] Shvachko K，Hairong Kuang，Radia S.The Hadoop Distributed File System，Mass Storage Systems and Technologies（MSST）[C].2010 IEEE 26th Symposium， 2010：1-10， 3-7.

[5] Li xiu-qiao，Dong bin，Xiao Li-min，et al.Small Files Problem inParallel File System[J].Network Computing and Information Security，New York： IEEE Computer Society，2011：227-232.

[6] Carns P，Lang S，Ross R，et al.Small-file access in parallel file systems[C].International Parallel and Distributed Processing Symposium，New York：IEEE Computer Society，2009：1-11.

[7] Faraz Shaikh，Mikhil Chainani.A case for small file packing in parallel virtual file system （pvfs2）[C].Advanced and Distributed Operating Systems Fall 07， 2007.

[8] Grant Mackey，Saba Sehrish，Julio LopezIntroducing Map-Reduce to High End Computing. InPetascale Data Storage Workshop at SC08， Austin， Texas， November 2008.

[9] Michael C Schatz.CloudBurst：Highly Sensitive Read Mapping with MapReduce[J].Bioinformatics，2009.

[10] Ghemawat S，Gobioff H，Leung S.The Google file system[C].Symposium on Operating Systems Principles 2003.New York：ACM.2003：29-43.endprint

對(duì)于NameNode內(nèi)存使用的測(cè)量，該試驗(yàn)測(cè)試工作共包含200000個(gè)文件。這些文件從20KB到300kb大小范圍。所有文件的累積大小約為12.35gb。采取的讀寫(xiě)操作時(shí)的工作量是用于內(nèi)存使用實(shí)驗(yàn)工作量的一個(gè)子集的分布，包含1000個(gè)文件。

基于以下參數(shù)測(cè)定集群性能：

1）使用NameNode節(jié)點(diǎn)存儲(chǔ)元數(shù)據(jù)的內(nèi)存量

2）完成讀寫(xiě)操作使用時(shí)間量

采用內(nèi)存分析器工具包測(cè)量NameNode節(jié)點(diǎn)存儲(chǔ)元數(shù)據(jù)所使用的內(nèi)存情況。Jmap工具被用來(lái)獲取所有目前在Java NameNode進(jìn)程內(nèi)存中活對(duì)象的堆轉(zhuǎn)儲(chǔ)。內(nèi)存分析器工具包進(jìn)行分析所得到的堆轉(zhuǎn)儲(chǔ)。完成讀寫(xiě)操作的時(shí)間使用操作系統(tǒng)Linux命令以毫秒測(cè)量。

實(shí)驗(yàn)是在原有的HDFS和FCHDFS上進(jìn)行。通過(guò)放置2000批文件在HDFS后分析堆轉(zhuǎn)儲(chǔ)，測(cè)定節(jié)點(diǎn)的內(nèi)存使用情況。共有2000000個(gè)文件被放置和100次讀寫(xiě)（以每2000個(gè)放置到HDFS的文件），重復(fù)3次及三個(gè)讀數(shù)，并計(jì)算平均值。FCHDFS采用同樣的步驟，比較了兩種情況下內(nèi)存使用情況，如圖5所示。

圖5 NameNode內(nèi)存使用

圖5顯示了兩種情況下內(nèi)存的使用模式。三角形標(biāo)記的曲線(xiàn)對(duì)應(yīng)的原始沒(méi)做任何更改的HDFS內(nèi)存使用情況。隨著文件的數(shù)量增加，內(nèi)存使用也線(xiàn)性增加。這是預(yù)期的結(jié)果，因?yàn)樽鳛镹ameNode節(jié)點(diǎn)必須保存文件和塊的元數(shù)據(jù)。第二條是正方形標(biāo)記的曲線(xiàn)代表FCHDFS，為了有效的文件訪問(wèn)，NameNode必須保存額外的數(shù)據(jù)結(jié)構(gòu)。存儲(chǔ)相同數(shù)量的文件，通過(guò)FCHDFS使用的內(nèi)存明顯小于使用HDFS。FCHDFS只維護(hù)每個(gè)小文件的文件元數(shù)據(jù)，而不用維護(hù)它們的塊元數(shù)據(jù)。NameNode只維護(hù)單個(gè)聯(lián)合文件的塊元數(shù)據(jù)，而不為每一個(gè)小文件維護(hù)它們的塊元數(shù)據(jù)，所以FCHDFS將占用更少的內(nèi)存。

在這個(gè)實(shí)驗(yàn)中，對(duì)HDFS和FCHDFS測(cè)試寫(xiě)操作的結(jié)果如圖6所示。

圖6 寫(xiě)操作所耗時(shí)間

FCHDFS的寫(xiě)操作是大大快于HDFS的寫(xiě)操作。通過(guò)圖6實(shí)驗(yàn)分析結(jié)果清楚地顯示這一點(diǎn)。10000個(gè)文件寫(xiě)到HDFS的時(shí)間是非常高的，因?yàn)镹ameNode節(jié)點(diǎn)必須為每個(gè)寫(xiě)入HDFS的文件創(chuàng)建和分配塊空間。FCHDFS避免了這種繁瑣的操作，文件的創(chuàng)建NameNode 節(jié)點(diǎn)被訪問(wèn)一次，并且只有再加入一新塊到合并文件中才調(diào)用寫(xiě)操作。另一個(gè)發(fā)揮作用的重要因素是用于客戶(hù)端合并文件的緩沖機(jī)制。添加一個(gè)新塊的請(qǐng)求發(fā)送到NameNode節(jié)點(diǎn)前，數(shù)據(jù)塊是先緩存到客戶(hù)端。只為每個(gè)64MB的數(shù)據(jù)發(fā)送一個(gè)請(qǐng)求到NameNode節(jié)點(diǎn)，而不是每一個(gè)小的文件。

4 結(jié)束語(yǔ)

HDFS最初被設(shè)計(jì)為存儲(chǔ)大文件的。當(dāng)它是用來(lái)存儲(chǔ)大量的小文件時(shí)，I/O性能成為瓶頸。在本文中，針對(duì)冠字號(hào)小圖片存儲(chǔ)到HDFS系統(tǒng)中帶來(lái)的訪問(wèn)瓶頸問(wèn)題，改進(jìn)了原有的HDFS系統(tǒng)，提出了基于文件關(guān)聯(lián)性合并機(jī)制的FCHDFS，它把大量的小文件合并成一個(gè)單一的聯(lián)合文件。從性能進(jìn)行分析，對(duì)于小文件的存儲(chǔ)和管理，F(xiàn)CHDFS提高了對(duì)小文件的訪問(wèn)效率和減少節(jié)點(diǎn)的內(nèi)存元數(shù)據(jù)數(shù)量。FCHDFS通過(guò)提供更高效的小文件元數(shù)據(jù)管理，允許更充分的利用HDFS的資源。該文對(duì)于2000000個(gè)小文件進(jìn)行試驗(yàn)測(cè)試，結(jié)果證實(shí)內(nèi)存的使用量大大減少了。相比原來(lái)的HDFS，F(xiàn)CHDFS寫(xiě)操作時(shí)間也有較明顯的縮短。

參考文獻(xiàn)：

[1] 覃雄派，王會(huì)舉，王珊，等.大數(shù)據(jù)分析-RDBMS與MapReduce的競(jìng)爭(zhēng)與共生[J].軟件學(xué)報(bào)，2012，23（1）：32-45.

[2] 王珊，王會(huì)舉，等.架構(gòu)大數(shù)據(jù)：挑戰(zhàn)、現(xiàn)狀與展望[J].計(jì)算機(jī)學(xué)報(bào)，2011，34（10）：1742-1752.

[3] Chuck Lam.Hadoop實(shí)戰(zhàn)[M].北京：人民郵電出版社，2012.

[4] Shvachko K，Hairong Kuang，Radia S.The Hadoop Distributed File System，Mass Storage Systems and Technologies（MSST）[C].2010 IEEE 26th Symposium， 2010：1-10， 3-7.

[5] Li xiu-qiao，Dong bin，Xiao Li-min，et al.Small Files Problem inParallel File System[J].Network Computing and Information Security，New York： IEEE Computer Society，2011：227-232.

[6] Carns P，Lang S，Ross R，et al.Small-file access in parallel file systems[C].International Parallel and Distributed Processing Symposium，New York：IEEE Computer Society，2009：1-11.

[7] Faraz Shaikh，Mikhil Chainani.A case for small file packing in parallel virtual file system （pvfs2）[C].Advanced and Distributed Operating Systems Fall 07， 2007.

[8] Grant Mackey，Saba Sehrish，Julio LopezIntroducing Map-Reduce to High End Computing. InPetascale Data Storage Workshop at SC08， Austin， Texas， November 2008.

[9] Michael C Schatz.CloudBurst：Highly Sensitive Read Mapping with MapReduce[J].Bioinformatics，2009.

[10] Ghemawat S，Gobioff H，Leung S.The Google file system[C].Symposium on Operating Systems Principles 2003.New York：ACM.2003：29-43.endprint