海量小图片在HDFS下存储和访问优化

海量小图片在HDFS下的存储与访问优化摘要Web2.0时代，以微博、社交网站、网上交易平台等应用的快速发展，使数据呈现出几何级的增长，使用传统的技术框架越来越不能胜任当前海量数据的存储与处理等需求，海量数据的存储与处理成了当前的热点话题。Hadoop文件系统HDFS作为Google文件系统GFS的开源实现成为了业界研究海量数据存储与处理的一个典范模型，并得到了很好的应用。然而HDFS在海量小文件存储方面却存在着严重的性能问题，主要有文件元数据过多造成Namenode内存压力、Block的存储空间利用不充分造成严重的空间浪费、频繁的文件读写请求造成的文件读写效率低下等。小图片是一种特殊的小文件，HDFS的这些性能问题同样也适应于海量小图片的存储，同时，海量小文件的解决方案对设计海量小图片存储的解决方案也有相应的参考价值。在HDFS环境下，现有的小文件存储解决方案主要有：Hadoop自身提供的HAR和SequenceFile、利用HBase扩展HDFS、扩展为多Namenode、根据HAR和SequenceFile的思想而提出的文件合并方案等。这些解决方案都从一定程度上缓解了HDFS在海量小文件存储方面的性能问题，但都有一定的局限性：利用HBase扩展HDFS无法存储大于64KB的文件；HAR和SequenceFile、多Namenode等无法有效地减少客户端请求命名节点的次数；并且HAR和SequenceFile无法保证文件路径在HDFS中的透明性；文件合并方案容易导致读写低下等。本文在分析了HDFS体系结构和现有的小文件存储解决方案的基础上，提出了海量小图片在HDFS下的存储解决方案，其主要思想就是化小为大、建立索引、合理缓存。在设计该解决方案时借鉴了缓存、异步通信、并行处理等技术：客户端缓存来存储相关图片，以实现图片的合并、上传和下载等功能；消息队列连接用户操作和实际的HDFS操作；两级索引用于定位小图片在HDFS和缓存中的位置。该方案涉及到两种后台进程：消息处理进程、图片清理进程。消息处理进程一直运行在客户端所在的机器上，完成图片合并、文件上传等功能；图片清理进程周期性执行，完成HDFS中物理图片的删除和文件合并等功能。最后，本文搭建Hadoop集群完成了对比实验。通过对比和分析实验结果，该方案不但大大减少了图片的元数据个数和消耗的数据块个数，并且可以有效提高图片的读写速度。从而验证了本文提出的海量小图片存储解决方案的有效性。关键词：分布式文件系统；HDFS；小图片；存储优化；访问优化

ABSTRACTIntheAgeofWeb2.0,theapplicationssuchastheMicro-blog,theSocialnetworkingsites,andtheonlinetradingplatformhaveachievedrapiddevelopment,thusproducemoreandmoredata.Thetraditionaltechnologyarchitectureisunabletomeettheneedofmassdataanymore,soithasbeenahottopicthathowtostorethemassdataandhowtodealwiththem.HDFS,whichisthefilesystemofHadoop,astheopensourceimplementationofGFS,whichisthefilesystemofGoogle,hasbeenthetypicalmodelofhowtostoreanddealwiththemassdata.AndHDFShasbeenwidelyusedintherealworld.However,thereisaseriousperformanceissuesforHDFStodealwithmasssmallfiles.ExistingstoragesolutionsformasssmallfileincludeHARandSequenceFile,basedonHBasesystem,extendtomorethanoneNamenode,mergemanysmallfileintooneandsoon.HARandSequenceFileareprovidedbyHadoopitself,andthemethodofmergingfilesintooneareproposedaccordingtothemethodofHARandSequenceFile.ThesetraditionalsolutionsrelievetheperformanceissuesofHDFScausedbylargeamountofsmallfiles,buttheyhaveacommonlimitation:unablereducetherequestnumberthatClientsrequestsNamenode.Inaddition,methodsofbasedonHBasesystem,makeuseofcacheintheHRegionServertoreducetherequestnumberofClients.Butthespaceforthecacheislimitedandthecacheiscentrallymanaged,thusitcannotmakerespondtimelywhenthereismountsofrequests.ThispaperproposedastoragesolutionformasssmallfilesafteranalyzingthearchitectureofHDFSandtheexistingsolutions,whichadoptsthefollowingideassuchasmergingsmallfilesintoone,creatingindices,establishingappropriatecache.Takingintoaccounttheadvantagesofasynchronouscommunicationsandparallelprocessing,theyareusedinthefinalsolutionthispaperputforward.CacheandMessageQueuedecreasethelogicalcomplexityofthesystemeffectively,andmakeiteasytoextendthesystem.Thetwo-levelindexisusedtolocatethefileinbothHDFSandcache.Finally,twokindsofbackgroundprocessareofferedtofulfillthefunctionsthesystemneedstoprovide.Theprocessdealswiththegivenmessagesrunsonthemachinewhichtheclientsrunon,andtheprocessrunsforever.TheprocessdealswiththealreadylogicallydeletedfilesrunsonSecondaryNamenode,andtheprocessrunsperiodicallyanddieswhenthetaskisover.Boththetwokindsofprocessareallmulti-threadedandeachthreaddealswiththespecifictypeofmessages.Finally,thispapersetsupanexperimentalplatformbasedonHadoopCluster,andcompletesasetofcomparativeexperiments.Therearetwogroupsofexperimentsintotal.Throughcontrastandanalysisoftheexperimentalresults,wefoundthatboththenumberoffilemetadataandthenumberofthecostdatablockareallreducedgreatly,sothevalidityofthissolutionwasproved.Keywords:DistributedFileSystem；HDFS;SmallPictures;StorageOptimization;AccessOptimization;目录摘要 表格58可知，清理进程运行后，命名节点中元数据的个数和数据节点中数据块的消耗个数都减少了。清理进程确实起到了文件清理和文件合并的作用。本章小结本章以Hadoop集群为主搭建了实验系统，并在此基础上设计以一组对比试验，从图片上传、图片读取、图片删除、图片清理等四个方面对本论文设计的HDFS下小图片存储优化方案进行了验证。实验结果证明，本文设计的HDFS下小图片存储优化方案可以有效地减少文件元数据的个数和文件消耗的数据块的总个数，文件删除的效率更好，在缓存合理的情况下，还可以大大提高文件请求的效率。验证了该优化方案确实是合理的、有效的。

总结与展望论文工作总结论文主要工作Web2.0时代，以微博、社交网站、网上交易平台等应用的快速发展，使数据呈现出几何级的增长，使用传统的技术框架越来越不能胜任当前海量数据的存储与处理等需求，海量数据的存储与处理成了当前的热点话题。Hadoop文件系统HDFS作为Google文件系统GFS的开源实现成为了业界研究海量数据存储与处理的一个典范模型，并得到了很好的应用。但它在小文件存储方面有着不可严重的性能问题，较之存储大文化相比，会浪费相当多的命名节点的内存空间和数据节点的磁盘存储空间。为此，Hadoop自身提供了自己的解决方案，也有很多人提出了小文件存储解决方案。但它们都有一定的局限性：无法有效地减少客户端请求命名节点的次数，并且无法保证文件在HDFS中路径的透明性。本文主要针对上述局限性，完成了HDFS下海量小图片存储的优化方案。为此，论文主要完成了以下工作：认真分析HDFS环境中文件的上传、下载等流程，并对现有的经典解决方案进行了透彻的分析，从而明确了各自的优缺点。分析多种相关技术，如Redis、消息队列、图片处理等，并将它们引入到解决方案的设计与实现中来。借鉴现有解决方案的优点，结合相关技术，完成了HDFS下海量小图片的存储与访问优化方案。搭建实验系统，设计测试用例对论文提出的优化方案进行测试，并对实验结果进行了分析。论文创新点采用客户端文件缓冲区。缓存区的作用就是减少对Namenode的读写请求次数和对Datanode的读写文件请求。在文件上传时，通过文件缓冲区，等达到一定条件时才发起写文件请求；在读取文件时，通过文件缓冲区，先从缓存中响应客户端请求，如果失败，再发起读文件请求。采用两级索引保存文件URL。两级索引保存的文件URL保证了文件在HDFS中路径的透明性，使用户不必关心优化后的文件路径变更。用户只需要知道自己保存至HDFS中的文件URL即可，通过这个URL就可获得对应的在HDFS系统中的文件，简化了用户使用HDFS操作图片时的逻辑复杂性。下一步工作HDFS下海量小图片的研究工作一直在进行，海量图片的存储遇到的问题也层出不穷。想要在实际的各种各样的需求中搭建完全通用的存储系统绝非易事。根据不同的实际情况，还需要更多的研究与探索。本系统的设计实现并非完美，还有很多地方需要提高和改进：小图片合并策略。将哪些小图片组合成为一个大文件是一个值得深入研究的问题。一般会将关联性比较大的图片合并在同一个大文件中，但具体将哪些小图片合放在一起，与具体的实践有着紧密的联系。调整图片合并时的参数，提高系统的整体效率。从理论上看，图片合并需要时间，合并后的文件上传也需要时间，文件的读取也需要时间。每个大文件中文件的数目或总大小会影响到这几个时间。在后续的工作中，会继续探讨这个参数对整体性能的影响。

参考文献SanjayGhemawat,HowardGobioff,Shun-TakLeung.TheGoogleFileSystem[A].In:19thACMSymposiumonOperatingSystemsPrinciples[C].LakeGeorge,NY,October,2003:29-43.JeffreyDean,SanjayGhemawat.MapReduce:SimplifiedDataProcessingonLargeClusters[A].In:OSDI'04:SixthSymposiumonOperatingSystemDesignandImplementation[C].SanFrancisco,CA,December,2004:137-150.FayChang,JeffreyDean,SanjayGhemawat,WilsonC.Hsieh,DeborahA.Wallach,MikeBurrows,TusharChandra,AndrewFikes,RobertE.Gruber.Bigtable:ADistributedStorageSystemforStructuredData[A].In:OSDI'06:SeventhSymposiumonOperatingSystemDesignandImplementation,Seattle[C].WA,November,2006:205-218.Boehm,Matthias,Habich,Dirk;Lehner,Wolfgang.Multi-processoptimizationviahorizontalmessagequeuepartitioning[J].ICEIS2010-Proceedingsofthe12thInternationalConferenceonEnterpriseInformationSystems,2010,1(1):5-14.Apache:TheApacheSoftwareFoundation.HDFSHighAvailability[EB/OL].:/docs/current/hadoop-yarn/hadoop-yarn-site/HDFSHighAvailabilityWithNFS.html,2013-04-12:Apache:TheApacheSoftwareFoundation.HDFSArchitecture[EB/OL].:/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html,2013-04-12:Apache:TheApacheSoftwareFoundation.SettingupaSingleNodeCluster[EB/OL].:/docs/r0.23.7/hadoop-project-dist/hadoop-common/SingleCluster.html,2013-04-11:Apache:TheApacheSoftwareFoundation.ClusterSetup[EB/OL].:/docs/r0.23.7/hadoop-project-dist/hadoop-common/ClusterSetup.html,2013-04-11:文继荣，毛新生，孟小峰，张瑞，陆嘉恒等.分布式文件系统及云计算概述[M].北京:清华大学出版社，2011:191-194.AndrewS.Tanenbanum,MaartenvanSteen.分布式系统原理与范型.杨剑锋，常晓波，李敏译.北京:清华大学出版社.2004:447-448,452-456,462-463.江柳.HDFS下小文件存储优化相关技术研究[D].北京：北京邮电大学，2010：蔡睿诚.基于HDFS的小文件处理与相关MapReduce计算模型性能的优化与改进[D].吉林：吉林大学，2012：陈虎.基于HDFS的云存储平台的优化与实现[D].广东：华南理工大学，2012：王玲惠，李小勇，张轶彬.海量小文件存储文件系统研究综述[J].ComputerApplicationsandSoftware,2012,29(8):106-109.马灿，孟丹.曙光星云分布式文件系统：海量小文件存取[J].JournalofChineseComputerSystems,2012,33(7):1481-1488.TomWhite.Hadoop权威指南[M].周敏奇，王晓玲，金澈清等译.北京:清华大学出版社.2011:44-48,80-81.MichaelArmbrust,ArmandoFox,ReanGriffith,AnthonyD.Joseph,RandyKatz,AndyKonwinski,GunhoLee,DavidPatterson,ArielRabkin,IonStoica,andMateiZaharia.AViewofCloudComputing[J].CommunicationsoftheACM,2010,53(4):50-58.KeithSeymour,HidemotoNakada,SatoshiMatsuoka,JackDongarra,CraigLee,andHenriCasanova.OverviewofGridRPC:ARemoteProcedureCallAPIforGridComputing[J].LectureNotesinComputerScience,2002,25(36):274-278.Hu,Yiming,NightingaleTycho,YangQing.RAPID-Cache-Areliableandinexpensivewritecacheforhighperformancestoragesystems[J].IEEETransactionsonParallelandDistributedSystems,2002,13(3):290-307.NguyenAndrew,WyndenRob,SunYao.HBase,MapReduce,andintegrateddatavisualizationforprocessingclinicalsignaldata[J].AAAISpringSymposium–TechnicalReport,2011,11(4):40-44.BrianW.Fitzpatrick,

JJLueck.TheCaseagainstDataLock-in[J].CommunicationsoftheACM,2010,53(11):42-46.LayaliK.Rashid,WessamHassanein,

MoustafaA.Hammad.Analyzingandenhancingtheparallelsortoperationonmultithreadedarchitectures[J].TheJournalofSupercomputing,2010,vol.53(2010):293-312.JeffreyDean,

SanjayGhemawat.MapReduce:Aflexibledataprocessingtool[J].CommunicationsoftheACM,2010,53(1):72-77.LuizAndréBarroso,

JeffreyDean,

UrsHölzle.WebSearchforaPlanet:TheGoogleClusterArchitecture[J].IEEEMicro,2003,23(2003):22-28.BruceEckel.Java编程思想[M].陈昊鹏译.北京:机械工业出版社.2007:525-589,650-762.EricFreeman.HeadFirst设计模式[M].O’ReillyTaiwan公司译.北京:中国电力出版社.2007:169-190.TomasH.Cormen,CharlesE.Leiserson.算法导论[M].潘金贵,顾铁成等译.北京:机械工业出版社.2008:119-127.白中英.计算机组成原理[M].北京:科学出版社.2001:251-259.ZhangYang,LiuDan.Improvingtheefficiencyofstoringforsmallfilesinhdfs[A].In:2012InternationalConferenceonComputerScienceandServiceSystem,CSSS2012[C].2012:2239-2242.MohandasNeethu,ThampiSabuM.Improvinghadoopperformanceinhandlingsmallfiles[A].In:CommunicationsinComputerandInformationScience,v193CCIS,nPART4[C].2011:187-194.LiuJiang,BingLi,MeinaSong.TheoptimizationofHDFSbasedonsmallfiles[A].In:20103rdIEEEInternationalConferenceonBroadbandNetworkandMultimediaTechnology,IC-BNMT2010[C].2010:912-915.YuLihua,ChenGang,WangWei,DongJinxiang.MSFSS:Astoragesystemformasssmallfiles[A].In:Proceedingsofthe200711thInternationalConferenceonComputerSupportedCooperativeWorkinDesign,CSCWD[C].2007:1087-1092.ZhouLu,FangZhiyi,XiangLiyun,CaiRuicheng,HuNiya.PerformanceoptimizationofprocessingsmallfilesbasedonHDFS[J].InternationalReviewonComputersandSoftware,2012,7(6):3386-3391.DongBo,ZhengQinghua,TianFeng,ChaoKuo-Ming,MaRui,AnaneRachid.Anoptimizedapproachforstoringandaccessingsmallfilesoncloudstorage[J].JournalofNetworkandComputerApplications,2012,35(6):1847-1862.站长之家:Facebook大数据：每天处理逾25亿条内容和500TB数据[EB/OL].:/news/2012/0823/270885.shtml,2013-04-12:新浪科技:Facebook每天数据处理量超500TB[EB/OL].:/i/2012-08-23/10597538323.shtml,2012-08-23:百度百科:搜索引擎原理[EB/OL].:/view/3492159.htm,2013-05-13:Share:Share社交网站[EB/OL].:/,2013-05-13:阿里巴巴:TaobaoFileSystem[EB/OL].:/,2013-05-13:YangZhengyi,WangShilong.Modelandperformanceanalysisofreal-timemonitoringdataprocessing[J].InternationalJournalofDigita