張宇翔， 趙建民， 朱信忠， 徐慧英

(浙江師范大學(xué) 數(shù)理與信息工程學(xué)院,浙江 金華 321004)

基于HDFS的海量指紋數(shù)據(jù)云存儲(chǔ)優(yōu)化研究*1

張宇翔， 趙建民， 朱信忠， 徐慧英

(浙江師范大學(xué) 數(shù)理與信息工程學(xué)院,浙江 金華 321004)

HDFS設(shè)計(jì)之初只考慮到如何更好地處理大文件，并沒有針對(duì)海量小文件進(jìn)行優(yōu)化，因此,當(dāng)使用HDFS管理海量指紋數(shù)據(jù)小文件時(shí)會(huì)出現(xiàn)NameNode內(nèi)存負(fù)載過重、上傳及查詢性能過低等問題.采用SequenceFile序列化技術(shù)進(jìn)行小文件的合并，并且對(duì)于小文件合并、元數(shù)據(jù)存儲(chǔ)、緩存策略等進(jìn)行了針對(duì)性優(yōu)化.實(shí)驗(yàn)證明，該優(yōu)化方案可以有效地解決NameNode內(nèi)存負(fù)載過重的問題，并且海量指紋數(shù)據(jù)小文件的上傳和查詢性能得到了提高.

HDFS；小文件；SequenceFile；文件合并；元數(shù)據(jù)存儲(chǔ)；緩存策略

0 引 言

近年來(lái)電子商務(wù)的飛速發(fā)展使得網(wǎng)上的交易量日漸增大，例如在2013年的“雙十一”中，淘寶的日交易額就突破了350億元人民幣[1].隨之而來(lái)的問題是如何更好地保障網(wǎng)上交易的安全性.相對(duì)于傳統(tǒng)的密碼方式，有學(xué)者提出了使用每個(gè)人唯一的指紋信息來(lái)保證交易的安全性[2].采用指紋識(shí)別技術(shù)保證網(wǎng)上交易的安全性，首先要解決的問題就是海量指紋數(shù)據(jù)的存儲(chǔ)問題.最近出現(xiàn)的云存儲(chǔ)技術(shù)為我們提供了一種新的解決思路.云存儲(chǔ)系統(tǒng)有很多種，例如 GFS,HDFS,MooseFS,Haystack,TFS等.其中，HDFS已經(jīng)比較成熟，而且是一款開源軟件.因此,本文決定采用HDFS進(jìn)行指紋數(shù)據(jù)的存儲(chǔ)管理.HDFS(Hadoop Distributed File System)采用了Master/Slave架構(gòu)，該系統(tǒng)由一個(gè)NameNode和多個(gè)DataNode組成[3].由于HDFS在設(shè)計(jì)之初是用來(lái)處理大量的大文件的，所以當(dāng)需要用HDFS寫入海量指紋數(shù)據(jù)小文件時(shí)，就會(huì)出現(xiàn)NameNode內(nèi)存負(fù)載過重的問題：1)一個(gè)指紋數(shù)據(jù)文件大概需要1 kb的空間，而這一個(gè)文件的元數(shù)據(jù)大概需要150 b.由于云存儲(chǔ)集群中使用的大部分都是普通的PC機(jī)，因此,當(dāng)指紋數(shù)據(jù)文件的數(shù)量以億為單位時(shí)，NameNode的內(nèi)存就無(wú)法支持存儲(chǔ)這么多的元數(shù)據(jù)了[4]；2)上傳查詢大量小文件時(shí)速度過慢.為了更好地處理大文件，在HDFS中控制流與數(shù)據(jù)流是分開的，元數(shù)據(jù)的生成、查詢等由NameNode完成，而數(shù)據(jù)的上傳讀取由各個(gè)節(jié)點(diǎn)分布式完成.但是當(dāng)讀寫大量指紋數(shù)據(jù)小文件時(shí)，每一個(gè)小文件的讀寫都需要NameNode建立一個(gè)任務(wù)，每一個(gè)任務(wù)的啟動(dòng)和釋放都需要耗費(fèi)一定的控制時(shí)間，而這樣一次任務(wù)也許只需要1 kb的數(shù)據(jù)傳輸，造成數(shù)據(jù)流傳輸消耗的時(shí)間小于控制流傳輸消耗的時(shí)間，這樣會(huì)導(dǎo)致對(duì)小文件訪問的延遲.如果有大量的小文件等待，甚至?xí)斐蒒ameNode的崩潰.

目前,解決HDFS下的小文件存儲(chǔ)效率問題的主流思想是將小文件合并為大文件[5-6].主要有2種方法:一種是基于Hadoop自帶的HAR[7](Hadoop archives)技術(shù)，HAR將大量的小文件合并到一個(gè)大文件中，雖然文件個(gè)數(shù)減少了,但是所需的存儲(chǔ)空間并不變，而且合并前的源文件不會(huì)被自動(dòng)刪除，需要管理員手動(dòng)進(jìn)行刪除；另一種方法是基于SequenceFile[8]的序列化文件技術(shù)，主要思想是采用〈key,value〉的形式合并大量的小文件，這種方法可以建立良好的索引，而且還可以支持?jǐn)?shù)據(jù)分割與數(shù)據(jù)壓縮.因此，本文選擇采用SequenceFile技術(shù)將大量的小文件合并為大文件.但是,實(shí)際應(yīng)用中僅僅采用SequenceFile技術(shù)并不能達(dá)到理想的效果，需要按照實(shí)際情況具體問題具體分析.

1 指紋數(shù)據(jù)存儲(chǔ)優(yōu)化方案設(shè)計(jì)

本文針對(duì)指紋數(shù)據(jù)小文件存儲(chǔ)問題提出了一種優(yōu)化方案.由于本文方案中指紋數(shù)據(jù)一般是一次存儲(chǔ)、多次讀取,所以主要優(yōu)化其讀取性能，提高查詢的速度.采用SequenceFile技術(shù)將大量小文件合并成大文件，并且按照地理位置信息進(jìn)行文件的合并及存儲(chǔ).大文件的元數(shù)據(jù)還是存儲(chǔ)在NameNode的內(nèi)存中，對(duì)于小文件來(lái)說(shuō),熱點(diǎn)文件的元數(shù)據(jù)放置在NameNode的內(nèi)存中，非熱點(diǎn)文件的元數(shù)據(jù)分布式地放置在DataNode的內(nèi)存中.由于本系統(tǒng)中的小文件是按照地理位置進(jìn)行合并及存儲(chǔ)的，因此,在搜索小文件時(shí)可以通過增加2～4位有關(guān)地理位置的控制信息來(lái)縮短搜索所需要的時(shí)間.同時(shí)，本文方案針對(duì)小文件采用特定的緩存策略，可以有效地減少磁盤寫入及讀取的次數(shù)，提高系統(tǒng)性能.

1.1文件合并

本文方案采用SequenceFile技術(shù)完成小文件的合并.SequenceFile是Hadoop提供的一個(gè)API接口，是為了存儲(chǔ)二進(jìn)制形式的Key-value對(duì)而設(shè)計(jì)的.SequenceFile共有3種壓縮類型，分別為None,Record和Block.其中：None 是不對(duì)記錄進(jìn)行壓縮；Record僅僅壓縮每一個(gè)Record中的value值；Block將一個(gè)塊中所有的Records壓縮到一起.由于本文提出的優(yōu)化方案是將元數(shù)據(jù)分布式存儲(chǔ)在DataNode上的，所以不需要考慮元數(shù)據(jù)所占的空間，為了查詢更方便,可以選擇僅僅壓縮每一個(gè)Record中的value的壓縮方式.同時(shí)，在每一個(gè)生成的塊的頭文件中增加4 bit的Location Parity用于以后地域位置校驗(yàn).經(jīng)過Record類型的SequenceFile合并壓縮之后生成的文件格式如圖1所示.

為了減輕NameNode負(fù)擔(dān)，系統(tǒng)設(shè)計(jì)在客戶端與NameNode之間增加一個(gè)文件判別合并器，該模塊的功能如流程圖2所示.

首先,文件判別合并器分析待上傳文件是否屬于小文件，本方案設(shè)定小于1 M的文件屬于小文件，然后按照文件的大小決定存儲(chǔ)方式.若待上傳的文件不屬于小文件，則按照HDFS的常規(guī)方式完成數(shù)據(jù)的存儲(chǔ)；若待上傳的文件屬于小文件，則在文件判別合并器中創(chuàng)建一個(gè)文件用來(lái)臨時(shí)存儲(chǔ)數(shù)據(jù)，以后上傳的小文件都寫入到這個(gè)文件中，當(dāng)這個(gè)文件大于等于63 M且系統(tǒng)空閑時(shí)進(jìn)行文件的合并上傳.同時(shí)，也要設(shè)定一個(gè)等待閾值，不能讓文件等待上傳的時(shí)間過長(zhǎng)，超過閾值時(shí)，即使塊的大小沒有達(dá)到63 M,也要在系統(tǒng)空閑時(shí)進(jìn)行數(shù)據(jù)的上傳.

圖1 SequenceFile中Record壓縮類型文件格式

圖2 文件判別合并器工作流程

網(wǎng)上支付系統(tǒng)中的指紋驗(yàn)證有其特殊性.用戶使用網(wǎng)上支付系統(tǒng)需要先登入賬號(hào)，然后通過指紋驗(yàn)證來(lái)完成交易，可以從用戶的賬戶信息中獲得其地理位置信息.本文方案按照地域信息將用戶的指紋數(shù)據(jù)進(jìn)行合并，相同地域信息的指紋數(shù)據(jù)合并到同一個(gè)數(shù)據(jù)塊中.若一個(gè)地域的指紋數(shù)據(jù)需要合并成多個(gè)數(shù)據(jù)塊,則盡量將它們保存到同一個(gè)DataNode中.將DataNode與地域信息之間的映射關(guān)系表存儲(chǔ)到NameNode中，方便客戶端的讀取.當(dāng)客戶端發(fā)出查詢請(qǐng)求時(shí)，需要在發(fā)給NameNode文件名之前增加4位地理位置位(可以根據(jù)需要具體設(shè)置，位數(shù)越多越精確，消耗的資源也相對(duì)越多).查詢時(shí)優(yōu)先查找NameNode內(nèi)存，若內(nèi)存命中,則完成此次查詢;若NameNode的內(nèi)存沒有命中，則可以根據(jù)地域信息與DataNode之間的映射表，告知客戶端需要聯(lián)系的DataNode列表，客戶端可以在這些DataNode的內(nèi)存中尋找元數(shù)據(jù).由于這些查找工作都是在內(nèi)存中進(jìn)行的，并不需要進(jìn)行磁盤讀取，因此提高了系統(tǒng)的查詢性能.

1.2元數(shù)據(jù)存儲(chǔ)

當(dāng)HDFS被用來(lái)處理大量小文件時(shí)會(huì)出現(xiàn)名字節(jié)點(diǎn)內(nèi)存不足的問題，很多學(xué)者提出采用SequenceFile技術(shù)解決這一問題.SequenceFile技術(shù)在一定程度上可以解決內(nèi)存占用率過高的問題，但是大量的小文件經(jīng)過SequenceFile處理之后，其元數(shù)據(jù)也將是大量的.傳統(tǒng)方案中將大量小文件合并時(shí)產(chǎn)生的索引信息存放在NameNode的磁盤中，當(dāng)有大量的小文件同時(shí)需要查找時(shí)，查找的速度會(huì)過慢.本文提出的針對(duì)指紋數(shù)據(jù)的存儲(chǔ)優(yōu)化案，大文件的元數(shù)據(jù)還是存儲(chǔ)在名字節(jié)點(diǎn)的內(nèi)存中，只有小文件元數(shù)據(jù)中的熱點(diǎn)數(shù)據(jù)才被存儲(chǔ)在名字節(jié)點(diǎn)的內(nèi)存中，非熱點(diǎn)的小文件的元數(shù)據(jù)則按照地域信息分布存儲(chǔ)在各個(gè)數(shù)據(jù)節(jié)點(diǎn)上.地域信息與數(shù)據(jù)節(jié)點(diǎn)的映射關(guān)系表存儲(chǔ)在名字節(jié)點(diǎn)的內(nèi)存中.每一個(gè)數(shù)據(jù)節(jié)點(diǎn)的內(nèi)存中只需要保存它所存儲(chǔ)的小文件的元數(shù)據(jù)，管理員可以根據(jù)實(shí)際情況具體分配名字節(jié)點(diǎn)的內(nèi)存.例如,在本方案中，由于重點(diǎn)處理的是大量的指紋數(shù)據(jù)小文件，因此分配給小文件的內(nèi)存可以適當(dāng)多一些，本文將名字節(jié)點(diǎn)內(nèi)存的60%用來(lái)存儲(chǔ)小文件的元數(shù)據(jù)，其余的內(nèi)存用來(lái)存儲(chǔ)大文件的元數(shù)據(jù)或者空閑.保存在名字節(jié)點(diǎn)中的小文件的元數(shù)據(jù)采用動(dòng)態(tài)置換策略，當(dāng)某一個(gè)小文件1 d的讀取次數(shù)達(dá)到設(shè)定的閾值時(shí)被判定為熱點(diǎn)文件，然后將它的元數(shù)據(jù)存儲(chǔ)到名字節(jié)點(diǎn)的內(nèi)存中；當(dāng)一個(gè)已經(jīng)被判定為熱點(diǎn)數(shù)據(jù)的小文件3 d內(nèi)讀取次數(shù)達(dá)不到設(shè)定的閾值時(shí)，判定為熱點(diǎn)失效，將其元數(shù)據(jù)從名字節(jié)點(diǎn)的內(nèi)存中移除.元數(shù)據(jù)存儲(chǔ)方案如圖3所示.

1.3緩存策略

為了進(jìn)一步加快客戶端查詢文件的速度，可以采取一定的緩存策略.首先，在客戶端的緩存中存儲(chǔ)一個(gè)最常訪問的DataNode列表，用戶查詢時(shí)可以先查詢這個(gè)列表中的DataNode內(nèi)存，如果內(nèi)存命中就可以節(jié)省大量的時(shí)間.其次，在DataNode的緩存中可以存儲(chǔ)一部分頻繁訪問的小文件數(shù)據(jù)，使得高頻率的小文件數(shù)據(jù)讀取不需要經(jīng)過磁盤I/O，一定程度上減少了磁盤讀取的次數(shù)，提高了訪問效率.最后，由于NameNode需要經(jīng)常訪問DataNode與地域位置信息的映射關(guān)系表，因此,可以將這個(gè)關(guān)系表也存放在緩存中.考慮到熱點(diǎn)數(shù)據(jù)，NameNode可以緩存一些熱點(diǎn)小文件的元數(shù)據(jù)，即其所在的DataNode、塊ID及在塊中的偏移量.這樣的緩存策略可以進(jìn)一步提高客戶端的訪問速度，優(yōu)化系統(tǒng)性能.

圖3 元數(shù)據(jù)存儲(chǔ)方案

2 實(shí)驗(yàn)設(shè)計(jì)及實(shí)驗(yàn)結(jié)果

接下來(lái)通過實(shí)驗(yàn)將本文方案、僅僅經(jīng)過SequenceFile改進(jìn)的HDFS方案和原HDFS方案在文件上傳、查詢過程中NameNode的內(nèi)存使用率和所需要的時(shí)間作性能比較.

2.1實(shí)驗(yàn)環(huán)境

為了對(duì)改進(jìn)后的HDFS性能進(jìn)行評(píng)估，搭建了一個(gè)有10個(gè)節(jié)點(diǎn)的HDFS集群，其中1個(gè)節(jié)點(diǎn)為NameNode，9個(gè)節(jié)點(diǎn)為DataNode.實(shí)驗(yàn)環(huán)境為：5臺(tái)SuperCloud SC-R6220服務(wù)器(2U,2節(jié)點(diǎn)),其中CPU為Intel Xeon 4C E5506，2.13 GHz；內(nèi)存4 G；硬盤1 000 G，7 200轉(zhuǎn).操作系統(tǒng)為64位CentOS 5.5；0.20.1版的Hadoop，千兆以太網(wǎng).

2.2實(shí)驗(yàn)數(shù)據(jù)集

采用中國(guó)科學(xué)院大規(guī)模多模式指紋數(shù)據(jù)庫(kù)中的多采集儀交叉匹配數(shù)據(jù)庫(kù).該數(shù)據(jù)庫(kù)包含9個(gè)子庫(kù)，分別由9種主流設(shè)備采集，共有10萬(wàn)個(gè)指紋數(shù)據(jù)文件.一個(gè)文件大約10 kb，文件的總大小為1 Gb.

2.3實(shí)驗(yàn)方案及實(shí)驗(yàn)結(jié)果

2.3.1 文件上傳性能測(cè)試

實(shí)驗(yàn)1為了方便描述，將本文提出的方案、僅僅采用SequenceFile技術(shù)的HDFS方案分別簡(jiǎn)稱為本文方案和SF_HDFS.分別從數(shù)據(jù)集中取出100,1 000,5 000，10 000，50 000，100 000個(gè)數(shù)據(jù)上傳到3種系統(tǒng)中，每種實(shí)驗(yàn)進(jìn)行3次，記錄每次上傳所需的時(shí)間，并計(jì)算其平均值及當(dāng)10萬(wàn)個(gè)數(shù)據(jù)上傳完畢后NameNode內(nèi)存的占用率，最后將3種方案得出的結(jié)果進(jìn)行對(duì)比.得出的實(shí)驗(yàn)結(jié)果分別如圖4與圖5所示.

圖4 小文件上傳時(shí)間

圖5 NameNode內(nèi)存占用百分比

由實(shí)驗(yàn)結(jié)果可以得出，雖然SF_HDFS采用了SequenceFile對(duì)小文件進(jìn)行合并有效地節(jié)省了NameNode的內(nèi)存空間，但是由于每一個(gè)小文件進(jìn)行上傳時(shí)都要進(jìn)行一次SequenceFile，因此,當(dāng)小文件數(shù)量增多時(shí)就會(huì)將很多時(shí)間浪費(fèi)在SequenceFile工作中.而本文方案增加了文件判別合并器，減少了SequenceFile的次數(shù)，在節(jié)省內(nèi)存的同時(shí)減少了上傳文件所需要的時(shí)間.

2.3.2 文件查詢性能測(cè)試

實(shí)驗(yàn)2當(dāng)系統(tǒng)中分別存儲(chǔ)100,1 000,5 000,10 000,50 000,100 000個(gè)小文件時(shí)分別用3種方案對(duì)隨機(jī)小文件進(jìn)行查詢，每一種情況進(jìn)行20次隨機(jī)查詢，統(tǒng)計(jì)各種情況下查詢所需要的平均時(shí)間，并進(jìn)行對(duì)比.考慮到熱點(diǎn)數(shù)據(jù)問題，對(duì)同一文件連續(xù)進(jìn)行30次查詢，從實(shí)驗(yàn)數(shù)據(jù)集中選擇30組指紋數(shù)據(jù)文件，計(jì)算查詢的平均時(shí)間.實(shí)驗(yàn)結(jié)果分別如圖6與圖7所示.

圖6 小文件隨機(jī)查詢測(cè)試

圖7 熱點(diǎn)小文件查詢測(cè)試

從隨機(jī)小文件性能測(cè)試的結(jié)果中可以看出，當(dāng)文件數(shù)量較少時(shí)，3種方案的性能差別不明顯，但隨著小文件數(shù)量的增大，本文方案的優(yōu)勢(shì)逐漸體現(xiàn)出來(lái).這是由于SF_HDFS需要進(jìn)行二級(jí)查詢，HDFS需要進(jìn)行遍歷查詢，但本文方案是針對(duì)地域進(jìn)行查詢，只需要查詢地域表再去DataNode的內(nèi)存中進(jìn)行查找.由于在DataNode的內(nèi)存中所需遍歷的數(shù)據(jù)較少，同時(shí)在查找到的DataNode上可以直接進(jìn)行數(shù)據(jù)讀取而不需要再進(jìn)行DataNode間的跳躍，因此,當(dāng)小文件增多時(shí)本文方案的性能才能更好地體現(xiàn)出來(lái).

從熱點(diǎn)小文件查詢測(cè)試結(jié)果可以得出，當(dāng)文件數(shù)量增多時(shí)，SF_HDFS的性能會(huì)變差，這是由于它沒有針對(duì)熱點(diǎn)數(shù)據(jù)進(jìn)行改進(jìn)，相比于HDFS多了一層硬盤級(jí)別的查詢，因此,性能不是特別理想.本文方案設(shè)定對(duì)應(yīng)的緩存策略，客戶端可以直接從其經(jīng)常訪問的DataNode列表進(jìn)行查詢，同時(shí)熱點(diǎn)小文件的內(nèi)容也會(huì)保存在緩存中，一定程度上提高了本文方案的查詢效率.

由以上實(shí)驗(yàn)結(jié)果可以得出，本文針對(duì)海量指紋數(shù)據(jù)小文件存儲(chǔ)提出的優(yōu)化方案確實(shí)可以提高小文件存儲(chǔ)性能.

3 結(jié) 語(yǔ)

針對(duì)海量指紋數(shù)據(jù)小文件，采用SequenceFile技術(shù)進(jìn)行小文件的合并，解決NameNode的內(nèi)存問題，同時(shí)進(jìn)行了優(yōu)化.通過實(shí)驗(yàn)證明,本文提出的方案確實(shí)解決了海量小文件上傳時(shí)NameNode內(nèi)存負(fù)載過重的問題，同時(shí)提高了小文件上傳及查詢的效率.由于本文方案只用由10個(gè)節(jié)點(diǎn)組成的實(shí)驗(yàn)平臺(tái)進(jìn)行驗(yàn)證，當(dāng)真正應(yīng)用到幾千個(gè)節(jié)點(diǎn)組成的集群時(shí)，索引信息在DataNode上如何更好地進(jìn)行分布式存儲(chǔ)，各個(gè)DataNode之間的負(fù)載如何均衡，都需要進(jìn)行進(jìn)一步的研究.本文提出的優(yōu)化方案一定程度上增加了系統(tǒng)設(shè)計(jì)的復(fù)雜度，如何減少系統(tǒng)的復(fù)雜度也需要進(jìn)一步的研究.

[1]魏一東.“雙十一”天貓?zhí)詫毥灰最~破350億突破馬云預(yù)期[EB/OL].2013-03-04[2013-11-12].http://cq.people.com.cn/news/20131112/20131112119149310301.html.

[2]于秀霞.指紋識(shí)別技術(shù)在身份認(rèn)證系統(tǒng)中的應(yīng)用[J].現(xiàn)代情報(bào),2005,9(5):217-220.

[3]White T.Hadoop:The definitive guide[M].Peking:O′Reilly Media Inc,2011:30-32.

[4]Konstantin S,Kuang H,Radia S,et al.The Hadoop distributed file system[C]//Proceedings of the 2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST).Nevada:IEEE,2010:273.

[5]趙曉永,楊揚(yáng),孫莉莉,等.基于hadoop的海量MP3文件存儲(chǔ)架構(gòu)[J].計(jì)算機(jī)應(yīng)用，2012,32(6):1724-1726.

[6]余思,桂小林,黃汝維,等.一種提高云存儲(chǔ)中小文件存儲(chǔ)效率的方案[J].西安交通大學(xué)學(xué)報(bào),2011,45(6):59-63.

[7]Dhruba B.Hadoop Archives[EB/OL].2013-08-04[2014-03-04].http://hadoop.apache.org/common/docs/current/Hadooparchives.html.

[8]Liu X J,Xu Z Q,Gu X.Study on the small files problem of Hadoop[C]//2012 IEEE 2nd International Conference on Cloud Computing and Intelligence Systems.Hangzhou:IEEE Beijing Section,2010:278-281.

(責(zé)任編輯 陶立方)

HDFS-basedstorageresearchformassfingerprintdata

ZHANG Yuxiang, ZHAO Jianmin, ZHU Xinzhong, XU Huiying

(CollegeofMathematics,PhysicsandInformationEngineering,ZhejiangNormalUniversity,JinhuaZhejiang321004,China)

When designed the HDFS, it was usually only considered how to handle large files better, and HDFS was not optimized for massive small files. When used HDFS to manage massive small files such as fingerprint datafiles there were some difficulties. For example, overloading of the NameNode and the performances of upload and query were not satisfied. The serialization technology named SequenceFile to merge small files was used and some targeted optimization about the merging of small files, the storage of metadata and the caching strategies were considered. Experimental results showed that the proposed scheme could effectively deal with the problem of NameNode memory′s overloading. The upload and query performances about massive small files sucn as fingerprint datafiles were also improved.

HDFS; small files; SequenceFile; merging of files; metadata storage; caching strategies

10.16218/j.issn.1001-5051.2015.02.010

2014-09-12

國(guó)家自然科學(xué)基金資助項(xiàng)目(6127268)

張宇翔(1989-)，男，河南安陽(yáng)人，碩士研究生.研究方向：云計(jì)算；虛擬現(xiàn)實(shí)技術(shù).

TP391.4

A

1001-5051(2015)02-0179-06