基于Hadoop的海量数据处理模型研究和应用


北京邮电大学 硕士学位论文 基于Hadoop的海量数据处理模型研究和应用 姓名:朱珠 申请学位级别:硕士 专业:密码学 指导教师:胡正名 20080101基于Hadoop的海量数据处理模型研究和应用摘要数据是信息的载体,信息是数据的内涵,一般认为数据是信息系统的基础。利用计算机来处理数据,提取信息是信息系统的基本功能。在当今高度信息化的社会里,Web可以说是目前最大的信息系统,其数据具有海量、多样、异构、动态变化等特性。如何实现快速地从这些海量数据中提取出对企业有用的价值信息已成为程序员在开发应用软件的过程中碰到的最令人头疼的问题。基于这个问题的出发点,本文在分析现有分布式储存和计算等关键技术基础上,结合对Hadoop的集群技术的研究以及自身的业务需求和实际软硬件实力,提出了一种基于Hadoop的海量数据处理模型,并从数据结构设计、程序流程组织和编程技术的使用等几个方面来介绍这个模型的开发方法,最后将该模型应用于大型网站的web日志数据预处理过程中。针对该模型我们还设计了一种有效的基于分布式的预处理模式。该模式首先在各分布式服务器上进行关联匹配,然后将各个服务器上的挖掘结果合成。这有利于减轻网络频繁的通讯负担,体现并行计算、异步挖掘、异构数据规约的优势。同时,它允许程序员可以不需要有什么并发处理或者分布式系统的经验,就可以处理超大的分布式系统得资源。除了数据挖掘之外,该模型还可以应用在诸如图片存储、搜索引擎、网格计算等需要处理大数据量的网络应用中。本课题的特点是将研究的模型与实际业务应用相结合,利用前沿的分布式框架技术来很好的满足项目的需求,并将模型部署到实例当中,用实验结果来检验模型的实用价值,比如高效率、低成本、可拓展性和易维护性等。在与原来的预处理系统相融合的基础上,我们还对初级的模型进行了性能的优化,主要包括:简化规则的改进、多任务的优先级设定和网络负载平衡算法的优化。关键词Hadoop海量数据分布式数据预处理RESEARCHANDAPPLICATIONOFMASSr\忸DAlAPROCESSINGMODELBASEDONHadoopABSTRACTDataiSthecarderofinformation,theinformationcontentofthedataisgenerallybelievedthatdataisthebasisofinformationsystems.Usingcomputerstoprocessdata,extractinginformationisthebasicfunctionofinformationsystems.Intoday'shighlyinformation-orientedsociety,theWebcanbesaidtobecurrentlythelargestinformationsystem,ofwhichthedataaremassive,diverse,heterogeneous,dynamicchangecharacteristics.Howtorapidlyextractusefulin.formationfromthemassivedataofenterprisehasbecomeadauntingproblemofprogrammersintheprocessofapplicationdevelopment.Basedonthestartingpointofthisproblem,afteranalyzingthekeytechnologiesofexistingdistributedstorageandcomputing,combinedwithHadoopclustertechnologyresearch,aswellasthebusinessneedsandtheactualstrengthofhardwareandsoftware,whichisbasedonthemassiveHadoopData-processingmodel,andfromthedatastructuredesign,programflowandtheuseofprogrammingtointroduceseveralaspectsofthedevelopmentofthismodel.Themodelisappliedtothelarge—scalewebsitelogdatapre-process.Wealsodesignaneffectivemodelagainstthismodelbasedondistributedpre—processparadigm.Thedistributedmodelappliescorrelationpatternmatchestoeachdistributedserversfirst,andthencombineallresultsoftheexcavationofservers.Thiswillhelptoalleviatethecongestiononthecommunicationsnetwork,reflectsparallelcomputing,asynchronousmining,theadvantagesofthereductionofheterogeneousdata.Atthesametime,itallowsprogrammerstodealwithverylargedistributedsystemofresourceswithoutanyknowledgeofparallelprogrammingortheexperienceofdistributedsystem.Inadditiontodatamining,themodelalsoCanbeappliedinareassuchaSpicturestorage,searchengines,andgridcomputingtohandlelargedatanetworkapplications.ThecharacteristicofthisstudyiStheintegrationofmodelresearchandbusinessapplications.Usingleadingedgedistributedtechnicalframeworktomeetthedemandoftheprojectanddeploythemodeltoactualinstance.Withtheexperimentalresultsfortestingmodelsofpracticalvalue,such鹤high—efficiency,low-cost,scalability,andmaintenanceandSOon.Wealsoperformtheperformanceoptimizationagainstthebasicmodelonthebasisoftheintegrationwithoriginalpre—processsystem,whichincludes:therefinementofsimplifiedrules,theconfigurationofpriorityofmulti—taskandoptimizationofthenetworkloadbalancingalgorithm.KEYWORDShadoopmassivedatadistributeddatapre-process声明独创性(或创新性)声明本人声明所呈交的论文是本人在导师指导下进行的研究工作及取得的研究成果。尽我所知,除了文中特别加以标注和致谢中所罗列的内容以外,论文中不包含其他人已经发表或撰写过的研究成果,也不包含为获得北京邮电大学或其他教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的说明并表示了谢意。申请学位论本人签名:处,本人承担一切相关责任。日期:—上进譬L关于论文使用授权的说明学位论文作者完全了解北京邮电大学有关保留和使用学位论文的规定,即:研究生在校攻读学位期间论文工作的知识产权单位属北京邮电大学。学校有权保留并向国家有关部门或机构送交论文的复印件和磁盘,允许学位论文被查阅和借阅;学校可以公布学位论文的全部或部分内容,可以允许采用影印、缩印或其它复制手段保存、汇编学位论文。(保密的学位论文在解密后遵守此规定)保密论文注释:本学位论文属于保密在一年解密后适用本授权书。非保密论文注释:本学位本人签名:导师签名:适用本授权书。日期:巡:!:兰Z一17t期:芝Z.!:兰21.1课题研究背景1.1.1项目背景第1章绪论在当今高度信息化的社会里,Web可以说是目前最大的信息系统,其数据具有海量、多样、异构、动态变化等特性。Web的主要价值来自于由众多用户生成的数据,如delicious、Digg、Facebook,它已经超越了任何个人运行大规模的服务器软件的商业意义,如Gmail、GoogleSearch、Live、Y!Search。然而如何在这些具有数据源多样性,数据传输条件等不确定性以及用户对最终统计数据的选择性等特点的海量数据中提取出企业想利用的价值信息,即海量Web日志挖掘,是程序员在开发应用软件的过程中亟待解决的难题。Web日志挖掘就是根据用户访问网站服务器时所留下的同志文件,再经过数据清理,数据转换,利用数据挖掘技术,发现有用的知识。尤其对于一些大型的商业网站,利用weblog挖掘有利于找出用户潜在的访问模式,这对于如何构建网页间的组织模式特别重要,在便利客户访问、加快访问速度、提供个性化服务方面都有很大的作用。“啤酒与尿布”的故事家喻户晓,在IT界里,几乎是数据挖掘的代名词,当前,市场竞争异常激烈,各商家企业为了能在竞争中占据优势,费劲心思。他们都希望把企业大量的数据变成了客户需要的信息,把这些信息变成了价值,提高了企业的产值和效益,增强了客户自身的竞争实力,给企业带来新的生机和活力。于是各种数据挖掘技术应运而生,其中最常用的是数据库技术。随着数据库和网络等技术的迅速发展,人们迅速搜集数据的能力越来越强,大量的数据储存在数据库和数据仓库中。目前国内外很多文章提供了很多优秀的web日志挖掘方案。其中RobertCooley等人在Web日志数据预处理中设计实现了WebMiner系统【11,将Web日志挖掘分为三个阶段:预处理、应用挖掘算法和模式分析。这个Web日志挖掘方案现在已经被广泛的采用并在此基础上衍生了一系列的改进。海量数据对数据库服务器的CPU,10吞吐都是严峻的考验,随着网络资源的迅速膨胀,不论在存储空间,还是在访问速度,清除网络瓶颈等方面,单靠数据库系统来完成所有的数据挖掘过程已经不能适应网络发展的需要。与此同时,应用系统体系的核心、系统数据的存放地——数据库也随着实际应用而急剧膨胀,一些大规模系统的数据甚至超过了1000万条,可谓海量。于是我们常常遇到这样的难题:“有这样一个系统,每个月系统自动生成一张数据表,表名按业务代码和年月来命名,每张表的数据一个月平均在8k万这样的数据量,但是每天我们都要等到下午2点才能看到昨天的R志分析结果,并且查询的时候速度很慢。如果希望能够查到最近三个月的数据,那就需要再重新提炼计算、入库、关联,也就是要从三个数据量非常庞大的表中来把查询的数据汇聚到一起,用什么比较好的办法来提高效率昵?”在某种意义上说目前我们不是缺少信息,而是被信息淹没了。目前的数据库系统可以高效地实现数据的录入、修改、统计、查询等功能,但是无法发现数据中存在的关系和规则,无法根据现有的数据预测未来的发展趋势,缺乏挖掘数据背后隐藏的知识的手段,导致了“数据爆炸但知识贫乏”的现象。大量底层的简化和规则计算,还有结构化原始同志等计算在很大程度上消耗了原本用于发现数据中存在的关系和规则的数据库性能,让数据库过度的存储垃圾信息和疲于拼命的跑在初级计算当中,从而抹杀掉了数据库在数据挖掘方面的分析和关联优势,力没有用到刀刃上。鉴于这个问题,我们的解决办法是将数据挖掘的数据清洗、数据转换、数据简化和数据规约等数据预处理过程从庞大的数据库处理中分离出来,只将最后提炼的具有合理的数据结构的规约结果数据入库,用于深度挖掘。这就是本文要探讨的一个关于数据挖掘中数据预处理模型的课题。数据预处理是保证W曲同志挖掘质量的重要基础,预处理主要包括数据清洗、数据转换、数据聚合等工作.海量日志的数据预处理是一项艰巨而复杂的任务。原因有以下几个方面:一、数据量过大,数据中什么情况都可能存在。如果说有10条数据,那么大不了每条去逐一检查,人为处理,如果有上百条数据,也可以考虑,如果数据上到千万级别,甚至过亿,那不是手工能解决的了,必须通过工具或者程序进行处理,尤其海量的数据中,什么情况都可能存在,例如,数据中某处格式出了问题,尤其在程序处理时,前面还能正常处理,突然到了某个地方问题出现了,程序终止了。二、软硬件要求高,系统资源占用率高。对海量的数据进行处理,除了好的方法,最重要的就是合理使用工具,合理分配系统资源。一般情况,如果处理的数据过133级,小型机是要考虑的,普通的机子如果有好的方法可以考虑,不过也必须加大CPU和内存,就象面对着干军万马,光有勇气没有一兵一卒是很难取胜的。三、要求很高的处理方法和合理的规则。当然,企业间没有通用的处理方法,但有通用的原理和规则。处理数据离不开优秀的程序代码,尤其在进行复杂数据处理时,必须使用程2序。好的程序代码对数据的处理至关重要,这不仅仅是数据处理准确度的问题,更是数据处理效率的问题。良好的程序代码应该包含好的算法,包含好的处理流程,包含好的效率,包含好的异常处理机制等。起初我们用PERL和C抖设计了一套从收集到入数据库的完整web日志预处理系统,设计了自己的聚合规则。这在很大程度上减轻了数据库的负担,提高了数据生产和信息挖掘的效率。但随着不断增加的Log数据量和不断复杂的Log分析需求,导致了两个方面的问题,其一是Log分析的时间越来越长,动则几十分钟,甚至是数个小时,其二是计算复杂度直接导致对计算空间的需求,超过了单个机器的内存空间,导致计算数据量直接受到空间限制。当然当系统资源有限,内存提示不足,则可以靠增加虚拟内存来解决。比如针对18亿条的数据进行处理,内存为1GB,1个P42.4G的CPU,对这么大的数据量进行聚合操作是有问题的,提示内存不足,那么采用了加大虚拟内存的方法来解决,在6块磁盘分区上分别建立了6个4096M的磁盘分区,用于虚拟内存,这样虚拟的内存则增加为4096*6-I-1024=25600M,解决了数据处理中的内存不足问题。但这只是治表不治根,导致原先的数据预处理系统运行缓慢的真正原因是因为程序中有串行分量的存在,要改善整个系统的执行效率,最好是利用提高运算部分的并行负载量的方法,这种方法可以用在诸如用户查询词关联分析,路径跳转分析以及网站PV、Uv等这些求解规模可扩放、数据间相对孤立的问题中。通过提取出问题中存在的可并行工作的分量,然后用分布式模型来实现这些并行分量的并行执行,这样才能提高海量数据的处理速度。于是我们发起了这个课题研究,利用企业内部空闲的低负荷计算资源,在原有数据预处理系统上整合Hadoop,模仿MapReduce模型,组建一个集群计算环境,将Log分析任务切分开来,这样一方面可以扩展计算空间,另一方面还能成倍地提高Log分析速度。在以下的文章中,我们将以网站Web日志为例,探讨如何设计和实现基于Hadoop的海量数据处理模型,实现快速的数据预处理。1.1.2技术背景由于现代人类各个课题学科繁多,涉及面广,而分类又细。而当今的每个学科似乎都需要进行大量的计算。天文学研究组织需要计算机来分析太空脉冲(pulse),星位移动;生物学家需要计算机来模拟蛋白质的折叠(proteinfolding)过程;药物学家想要研制克服爱滋病(AIDS)或非典(SARS)的药物;数学家想计算最大的质数和圆周率的更精确值;经济学家要用计算机分析计算在几万种因素考虑下某个企必城市/国家的发展方向从而宏观调控。由此可见,人类未来的科学,时时刻刻离不开计算。现代科学研究具有连续性和协同性等方面的特征,对高性能计算能力和海量数据处理能力要求越来越高。因此,用网络技术把各种资源聚合起来,实现协同计算,是现代科学活动面临的一个迫切需求。而分布式计算(DistributedComputing),以其独特的优点——便宜、高效而越来越受到社会的关注。就目前来看,全球的各种分布式计算已有约百种,这些计算大多互无联系、独立管理、独立使用自己的一套软件。目前的这种分布式计算互相割据的格局很不利于发展的需要。比如,某个生物学研究机构需要利用世界各地志愿者的计算机来模拟蛋白质折叠的过程,那个生物学研究机构没有分布式计算方面的专业人才,但是社会上也并没有任何公司可以提供这样的服务,他们就不得不自己花费大量精力用于开发分布式计算的服务器、客户端。这样一来,原来可以用于研究生物的时间用在了别的地方。刚才提到的生物学研究机构就是美国斯坦福大学的PANDE小组。Hadoop原本由Lucene的子项目Nutch发展出来,成为Lucene的子项目,Hadoop是GooSe的GFS和MapReduce的一个java实现,用于大规模分布式计算。最近Hadoop被提升为Apache的顶级项目,还有Yahoo一直的支持,可见Hadoop的前途相当光明。MapReduce是一种简化的分布式编程模式,让程序自动分布到一个由普通机器组成的超大集群上并发执行。就如同iava程序员可以不考虑内存泄露一样,MapReduee的run-time系统会解决输入数据的分布细节,跨越机器集群的程序执行调度,处理机器的失效,并且管理机器之间的通讯请求。这样的模式允许程序员可以不需要有什么并发处理或者分布式系统的经验,就可以处理超大的分布式系统得资源。这样的优势使得hadoop在众多分布式存储和计算技术中脱颖而出,hadoop的各方面都比较切合我们的项目需求,这使其成为我们最后确定的基础研究技术方向。1.2主要研究内容本课题的主要研究目的是在异构、分布、动态、自主管理条件下对各种计算资源进行分布式整合,满足处理日志时对资源同构化、位置无关化、确定化、以及共享化的需求。本课题将从以下几个方面开展研究:(1)目前的分布式存储和计算技术研究及比较;(2)Hadoop的整体框架和核心技术;(3)设计海量数据处理模型选用的程序语言和网络计算环境中服务的开发、部署、调试机制与支持工具;(4)支持海量数据交换的数据存储、访问与传输机制;4(5)计算资源的性能评价和可改进点。1.3课题研究目标在明了项目背景和确定研究内容后,本课题提出了5个基本目标和3个高级目标。随后根据目标安排研究步骤。1.3.1基本目标1.掌握目前较流行几种分布式存储和计算方案,并比较选择切合公司实际物理集群的进行测试。2.熟悉Hadoop分布式集群的整体构架,包括其存储模式和计算模型。3.定制强大的清洗规则和出错处理机制,定义和实现数据接口。海量数据中存在着不一致性,极有可能出现某处的瑕疵。例如,同样的数据中的时间字段,有的可能为非标准的时间,出现的原因可能为应用程序的错误,系统的错误等,这是在进行数据处理时,必须制定强大的数据清洗规则和出错处理机制。4.耦合原有数据预处理系统的ETL和Hadoop,解决目前研究小组面临的最大问题和技术挑战。5.将现有的日志分析处理方案整合到hadoop分布式集群中,并部署测试方案,同时与原有方案进行性能上的比较。5.3.1高级目标对于一个企业而言,高效率、低成本和易维护一直都是他们的追求目标,能够把许多不同的分布式计算项目联系起来统一管理,并对计算机资源进行统一分配是一个更高的要求。本课题在完成基本目标的基础上将进一步完善系统,向高级目标迈进:1.改进简化规则2.设定多任务的优先级3.优化网络负载平衡算法,改善容错报警机制。1.4论文结构本论文共分为七章:5第一章对课题的研究背景、研究内容和研究目标进行了简要的说明,重点介绍了课题的项目背景和技术背景,指出THadoop的国内外研究现状和热点话题。第二章介绍了分布式系统的关机技术,包括分布式存储的现有模型和算法。第三章阐述THadoop的基本理论,详细介绍了Badoop的分布式文件系统HDFS和它的核心分布式计算思想:MapReduce并行编程模型。第四章给出了基于Hadoop的海量数据处理模型的设计思路和实现方式,并摘录了部分核心代码,同时给出了我们对设计模型的改进和优化技术点。第五章介绍了该模型的部署实例和应用方向。第六章给出了海量数据处理模型的部分实验结果,并进行了分析。第七章总结了本课题的研究成果,指出了需要进一步改进的方面。6第2章分布式系统关键技术2.1分布式系统模型简介在本文中分布式系统主要指的是分布式软件系统(DistributedSoftwareSystems),支持分布式处理的软件系统。与并行系统类似的是,分布式系统的设计目的也是为了将计算复杂的大任务划分为若干个计算量稍小的任务进行处理,然后通过一系列调度算法汇总得到最终的计算结果。但与并行计算不同的是,分布式系统要处理的任务相互之间有独立性,上一个任务包的结果未返回或者是结果处理错误,对下一个任务包的处理几乎没有什么影响。因此,分布式的实时性要求不高,而且允许存在计算错误。分布式系统包括分布式操作系统、分布式程序设计语言及其编译(解释)系统、分布式文件系统和分布式数据库系统等。本小节将对现有的一些比较有影响力的分布式系统或分布式计算应用逐一进行介绍。2.1.1.Google的GFSGoogle文件系统(GoogleFileSystem.GFS)被设计用来满足Google迅速增长的数据处理需求。GFS与过去的分布式文件系统拥有许多相同的目标,例如性能,可伸缩性,可靠性以及可用性。然而,Google在设计并实现其GFS时所考虑的目标和以往的分布式文件系统又有着一些不同的地方,具体表现在【2】:首先,组件失效不再被认为是意外,而被看作是正常的现象。这个文件系统包括几百甚至几千台普通廉价部件构成的存储机器,又被相应数量的客户机访问。组件的庞大数量和参差不齐的质量状况使得在任何给定时间,某些组件无法工作,而某些组件无法从他们的目前的失效状态恢复是常见的情况。除此之外,应用程序bug造成的问题,操作系统bug造成的问题,人为原因造成的问题,甚至硬盘、内存、连接器、网络以及电源失效造成的问题都是需要考虑的组件失效问题。所以,常量监视器,错误侦测,容错以及自动恢复系统必须集成在系统中。其次,按照传统的标准来看,单就Google网页搜索来看其存储的文件就已经非常巨大。数G的文件非常寻常。每个文件通常包含许多应用程序对象,比如web文档。传统情况下快速增长的数据集在容量达到数T,对象数达到数亿的时候,即使文件系统支持,处理数据集的方式也就是笨拙地管理数亿KB尺寸的小文件。所以,设计预期和参数,例如I/O操作和块尺寸都要重新考虑。7第三,在Goo酉e大部分文件的修改,不是覆盖原有数据,而是在文件尾追加新数据。对文件的随机写是几乎不存在的。一般写入后,文件就只会被读,而且通常是按顺序读。很多种数据都有这些特性。有些数据构成数据仓库供数据分析程序扫描,有些数据是运行的程序连续生成的数据流,有些是存档的数据。有些数据是在一台机器生成,在另外一台机器处理的中间数据。对于这类巨大文件的访问模式,客户端对数据块缓存失去了意义,追加操作成为性能优化和原子性保证的焦点。第四,应用程序和文件系统API的协同设计提高了整个系统的灵活性。例如,GFS的设计者放松了对GFS一致性模型的要求,这样不用加重应用程序的负担,就大大的规约了文件系统的设计。我们还引入了原子性的追加操作,这样多个客户端同时进行追加的时候,就不需要额外的同步操作了。论文后面还会对这些问题的细节进行讨论。为了不同的应用,Google已经部署了许多GFS集群。最大的一个,拥有超过1000个存储节点,超过300T的硬盘空间,被不同机器上的数百个客户端连续不断的频繁访问着。一个GFS集群包含一个主服务器和多个块服务器,被多个客户端访问,如图2.1。这些机器通常都是普通的Linux机器,运行着一个基于用户层的服务进程。如果机器的资源允许,而且运行多个程序带来的低稳定性是可以接受的话,可以很简单的把块服务器和客户端运行在同一台机器。2.1.2.Apache的Hadoop图2-16FS的架构Hadoop最早是作为一个开源搜索引擎项目Nutch的基础平台而开发的,后来随着项目的进展,Hadoop被作为一个单独的丌源项目进行开发,目前的最新版本已经是O.16.O【31。Hadoop作为一个开源的软件平台使得编写和运行用于处理海量数据的应用程序更加容易。Hadoop是MapReduce的实现,它使用了Hadoop分布式文件系统(HDFS,见图2.2)。MapReduce将应用切分为许多小任务块去执行。出于保证可靠性的考虑,HDFS会为数据块创建多个副本,并放置在群的计算节点中,MapReduce就在数据副本存放的地方进行处理。Hadoop是由Java编写的,该项目已到得Yahoo的全面支持,项目的领袖DougCutting从2006年一月开始已经被Yahoo全职雇用于此项目中。作为一个分布式系统平台,Hadoop具有以下一些优势:·可扩展性:Hadoop可以可靠的存储和处理petabyt铭级别的数据。·经济性:Hadoop将数据分布到由廉价PC机组成的集群中进行处理,这些集群可以由成千上万个节点组成。●有效性:通过数据分发,Hadoop可以在不同的节点上并行处理数据。这使得数据处理过程大大提速。·可靠性:Hadoop自动维护一份数据的多个拷贝并自动将失败的计算任务进行重新部署。妇data笔datad△/田出b迸S一一吐I协d呦da怕d蕾jdL,口一一妇u№Dk:=:篙:忿嚣ld出datad|‘-d出d■b节罾匾自一迅辈.卜◆爨’*‘“。4。*“’l1瞳j协da情怕妇d藕日dj‘-抽d.ud.【.d●u抽d峨山口datad妇t‘m幽岫d蝴datad蝴幽日、岫d—■幽协d勘岫’\d●慵山伯·Ij怕d■o畦l稿\迎眦¨函恤也“datad●¨‘‘a¨2.1.3.Memcached图2-2HDFS架构示意图Memcached[4】是高性能的,分布式的内存对象缓存系统,用于在动态应用中减少数据库负载,提升访问速度。Memcached由DangaInteractive开发,用于提升Live/oumal.com访问速度的。U每秒动态页面访问量几千次,用户700万。Memcached将数据库负载大幅度降低,更好的分配资源,更快速访问。Memcached由服务器端和客户端两个基本组成部分。memcached是以守护程序方式运行于一个或多个服务器中,随时接受客户端的连接操作,客户端可以由各种语言编写,目前已知的客户端API包括Perl/PHP/Python/Ruby/Java/C#/C等等。PHP等客户端在与memcached服务建立连接之后,接下来的事情就是存9取对象了,每个被存取的对象都有一个唯一的标识符key,存取操作均通过这个key进行,保存到memcached中的对象实际上是放置内存中的,并不是保存在cache文件中的,这也是为什么memcached能够如此高效快速的原因。注意,这些对象并不是持久的,服务停止之后,里边的数据就会丢失。在Memcached出现之前,最初的缓存做法是在线程内对对象进行缓存,但这样进程间就无法共享缓存,命中率非常低,导致缓存效率极低。后来出现了共享内存的缓存,多个进程或者线程共享同一块缓存,但毕竟还是只能局限在一台机器上,多台机器做相同的缓存同样是一种资源的浪费,而且命中率也比较低。MemcachedServer和Clients共同工作,实现跨服务器分布式的全局的缓存。并且可以与WebServer共同工作,WebServer对CPU要求高,对内存要求低,MemcachedServer对CPU要求低,对内存要求高,所以可以搭配使用。通过在内存里维护一个统一的巨大的hash表,Memcached能够用来存储各种格式的数据,包括图像、视频、文件以及数据库检索的结果等。Memcached的缓存是一种分布式的,可以让不同主机上的多个用户同时访问,因此解决了共享内存只能单机应用的局限,更不会出现使用数据库做类似事情的时候,磁盘开销和阻塞的发生。Memcached是“分布式”的内存对象缓存系统,那么就是说,那些不需要“分布”的,不需要共享的,或者干脆规模小到只有一台服务器的应用,memcached不会带来任何好处,相反还会拖慢系统效率,因为网络连接同样需要资源,即使是UNIX本地连接也一样。在我之前的测试数据中显示,memcached本地读写速度要比直接PHP内存数组慢几十倍,而APC、共享内存方式都和直接数组差不多。可见,如果只是本地级缓存,使用memcached是非常不划算的。Memcached在很多时候都是作为数据库前端cache使用的。因为它比数据库少了很多SQL解析、磁盘操作等开销,而且它是使用内存来管理数据的,所以它可以提供比直接读取数据库更好的性能,在大型系统中,访问同样的数据是很频繁的,memcached可以大大降低数据库压力,使系统执行效率提升。另外,memcached也经常作为服务器之间数据共享的存储媒介,例如在SSO系统中保存系统单点登陆状态的数据就可以保存在memcached中,被多个应用共享。需要注意的是,memcached使用内存管理数据,所以它是易失的,当服务器重启,或者memcached进程中止,数据便会丢失,所以memcached不能用来持久保存数据。很多人的错误理解,memcached的性能非常好,好到了内存和硬盘的对比程度,其实memcached使用内存并不会得到成百上千的读写速度提高,它的实际瓶颈在于网络连接,它和使用磁盘的数据库系统相比,好处在于它本身非常“轻”,因为没有过多的开销和直接的读写方式,它可以轻松应付非常大的数lO据交换量,所以经常会出现两条干兆网络带宽都满负荷了,memcached进程本身并不占用多少CPU资源的情况。2.1.4.mogiIeFSMogileFS是一套高效的文件自动备份组件【5】,由Sixapart开发,广泛应用在包括LiveJournal等W曲2.0站点上。MogileFS由3个部分组成:·第1个部分是server端,包括mogilefsd和mogstored两个程序。前者即是mogilefsd的tracker,它将一些全局信息保存在数据库里,例如站点domain.class.host等。后者即是存储节点(storenode),它其实是个HTTP守护进程,默认侦听在7500端口,接受客户端的文件备份请求。在安装完后,要运行mogadm工具将所有的storenode注册到mogilefsd的数据库里,mo西lefsd会对这些节点进行管理和监控。·第2个部分是utils(T_具集),主要是MogileFS的一些管理工具,例如mogadm世{宇。·第3个部分是客户端API,目前只有PerlAPI(MogileFS.pm),用这个模块可以编写客户端程序,实现文件的备份管理功能。2.1.5.Amazon的SimpIoDB在软件行业中云计算(CloudComputing)的领域在近几年的发展相当迅速。Amazon于2007年底推出了SimpleDB的Beta版【61,这是一个对结构化数据进行实时查询的Web服务。SimpleDB是对Amazon其他计算服务如S3和EC2的补充。S3解决海量数据(非结构化)托管问题,EC2解决企业计算问题,SimpleDB则针对结构化数据查询的解决方案,目前已经能够提供数据库的一些核心功能。就在Amazon推出SimpleDB不到一个月前IBM也公布了他们的BlueCloud的雏形。对于将一些软件应用从实用私有的基础设施转换到利用通用的计算资源,两者都可能会起到很大的作用。SimpleDB不是一个关系型数据库。它是建立在一种类似于散列表的模型上的。它提供了CRUD(Create,Read,Update,Delete,即我们常说的“增、删、改、查”)操作和~种查询语言。对普通用户来说,你不再需要针对数据库的复杂的维护工作,也就是可以不用数据库管理员(DBA)了。SimpleDB针对的用户是那些只需用简单的关系型数据的Web项目,传统的RDBMS功能复杂,但是很多小项目其实只是用到一些核心的功能(CRUD)而已。SimpleDB作为一个基于WebService的“在线”数据库,具有以下一些特点:·使用简单AmazonSimpleDB规约了传统的通过关系型数据库集群才能达到的查找和查询功能访问,同时去除了其他的一些复杂性和无用的数据库操作。SimpleDB服务通过一系列简单的API调用实现快速的数据的添加、获取和编辑操作。通过WebService的方式来实现上述的这些功能也消除了维护和扩展这些操作的复杂性。●灵活性借助于AmazonSimpleDB,无需为存储数据进行预先的数据格式定义,在需要时间但添加新属性到自己的AmazonSimpleDB数据集即可,SimpleDB系统会自动索引存储的数据。这种无序事先定义存储策略的能力给开发人员在开发应用程序时提供了极大的灵活性。●可扩展性AmazonSimpleDB通过添加“域”的方式方便的适应数据存储或访问量的增长。在SimpleDB的Beta版本发布时,一个单独的域被限制在10GB的容量大小,一个用户最多允许创建不超过100个域。随着SimpleDB的不断发展,在今后的版本中这个限制也将逐渐得到放宽。●快速AmazonSimpleDB为Web应用程序提供了快速、高效的数据存储和访问。●可靠为了防止数据丢失或无法访问的情况发生,所有的已被索引的数据都采取冗余存储在多个不同的服务器和数据中心的方案。2.1.6.IBM的BIueCloud同样是在2007年底,比Amazon推出SimpleDB之前1个月,IBM推出了“蓝云(BlueCloud)”计划川,为客户带来即可使用的云计算(CloudComputing)。它包括一系列的云计算产品,使计算不仅仅局限在本地机器或远程ServerFarms,通过架构一个分布的、可全球访问的资源结构,使数据中心在类似互联网的环境下运行计算。“蓝云”基于IBMAlmaden研究中心(Almad朗ResearchCenter)的云基础架构,包括Xen和PowerVM虚拟Linux操作系统映像以及Hadoop并行工作负载安排。“蓝云”由IBMTivoli软件支持,通过管理服务器来确保基于需求的最佳性能。这包括通过能够跨越多服务器实时分配资源的软件,为客户带来一种无缝体验,加速性能并确保在最苛刻的环境下的稳定性。12所谓的云计算可以被看成是网格计算和虚拟化技术的融合:即利用网格分布式计算处理的能力,将IT资源构筑成一个资源池,再加上成熟的服务器虚拟化、存储虚拟化技术,以便用户可以实时地监控和调配资源。虽然云计算环境也可通过快速提供可以运行网格应用的物理和虚拟服务器,来支持网格计算,但是二者还是有很多区别。网格计算需要将一个大型的任务分解为多个小任务,并且以并行方式运行在不同的服务器上,并且通常使用很多计算机,一般是数千台;而云计算也支持非网格环境,比如标准的三层Web架构或Web2.0应用。最重要的是,云不仅仅是计算机资源的简单汇集,更提供了一种管理机制。2.1.7.Peer"coPeer80年代以前的计算机是众多用户共享一个主机,计算资源是集中的,80年代以后PC机出现,计算资源从集中走向分布。互联网本身的是分布的、自治的,结点是对等的。WWW网出现,引进客户机-月艮务器结构,客户机结点使用浏览器访问存储的网站上服务器中的内容,出现了不对等的模式。对等连接peertopeer(P2P)模式的出现,互联网重新回归本性,集中的服务器业务模型再次变成分布的,每一个用户终端既是客户机又是服务器。对于分布式系统的研究者来说,对P2P网络的拓扑结构以及基于P2P的一些典型应用的分析和研究,可以从中借鉴P2P在网络拓扑和资源存储、调度上的一些设计精髓。P2P是一种分布式网络,网络的参与者共享他们所拥有的一部分硬件资源(处理能力、存储能力、网络连接能力、打印机等),这些共享资源需要由网络提供服务和内容,能被其它对等节点(Peer)直接访问而无需经过中间实体。在此网络中的参与者既是资源(服务和内容)提供者(Server),又是资源(服务和内容)获取者(Client)。P2P系统一般要构造一个非集中式的拓扑结构,在构造过程中需要解决系统中所包含的大量结点如何命名、组织以及确定结点的加入/离开方式、出错恢复等问题。根据拓扑结构的关系可以将P2P研究分为4种形式【8】:中心化拓扑(CentralizedTopology)、全分布式非结构化拓扑(DecentralizedUnstructuredTopology)、全分布式结构化拓扑(DecentralizedStructuredTopology,也称作DHT网络)和半分布式拓扑(PartiallyDecentralizedTopology)。其中,中心化拓扑最大的优点是维护简单发现效率高。由于资源的发现依赖中心化的目录系统,发现算法灵活高效并能够实现复杂查询。最大的问题与传统客户机/服务器结构类似,容易造成单点故障,访问的“热点”现象和法律等相关问题,这是第一代P2P网络采用的结构模式。值得注意的是,Hadoop的底层分布式文件系统所用的HDFS(HadoopDistributedFileSystem)从网络拓扑的角度来看,非常类似于P2P网络中的中心化拓扑结构——HDFS采用主/从结构。关于HDFS的细节讨论将在第3章进行。P2P技术的特点体现在以下几个方面:·非中心化(Decentralization):网络中的资源和服务分散在所有结点上,信息的传输和服务的实现都直接在结点之间进行,可以无需中间环节和服务器的介入,避免了可能的瓶颈。P2P的非中心化基本特点,带来了其在可扩展性、健壮性等方面的优势。·可扩展性(Scalability):在P2P网络中,随着用户的加入,不仅服务的需求增加了,系统整体的资源和服务能力也在同步地扩充,始终能较容易地满足用户的需要。整个体系是全分布的,不存在瓶颈。理论上其可扩展性几乎可以认为是无限的。●健壮性(Robustness):P2P架构天生具有耐攻击、高容错的优点。由于服务是分散在各个结点之间进行的,部分结点或网络遭到破坏对其它部分的影响很小。P2P网络一般在部分结点失效时能够自动调整整体拓扑,保持其它结点的连通性。P2P网络通常都是以自组织的方式建立起来的,并允许结点自由地加入和离开。P2P网络还能够根据网络带宽、结点数、负载等变化不断地做自适应式的调整。●高性能/价格比(Performance):性能优势是P2P被广泛关注的一个重要原因。随着硬件技术的发展,个人计算机的计算和存储能力以及网络带宽等性能依照摩尔定理高速增长。采用P2P架构可以有效地利用互联网中散布的大量普通结点,将计算任务或存储资料分布到所有结点上。利用其中闲置的计算能力或存储空间,达到高性能计算和海量存储的目的。通过利用网络中的大量空闲资源,可以用更低的成本提供更高的计算和存储能力。◆隐私保护(Privacyprotect):在P2P网络中,由于信息的传输分散在各节点之间进行而无需经过某个集中环节,用户的隐私信息被窃听和泄漏的可能性大大缩小。此外,目前解决Internet隐私问题主要采用中继转发的技术方法,从而将通信的参与者隐藏在众多的网络实体之中。在传统的一些匿名通信系统中,实现这一机制依赖于某些中继服务器节点。而在P2P中,所有参与者都可以提供中继转发的功能,因而大大提高了匿名通讯的灵活性和可靠性,能够为用户提供更好的隐私保护。·负载均衡(Loadbalance):P2P网络环境下由于每个节点既是服务器又是客14户机,减少了对传统C/S结构服务器计算能力、存储能力的要求,同时因为资源分布在多个节点,更好的实现了整个网络的负载均衡。在现有的P2P网络中比较有特点的具有分布式计算支持的模型有2个,一个是JXTA,另一个则是Kademlia。1.J文TAJXTA是为了构建P2P网络而制订的一组协议,是处理构建P2P网络所碰到的问题的解决方法,JXTA标准协议规耐9】介绍如下:‘'JXTA由六个协议组成,这些协议是专为特定的、分布式的、对等的网络计算而设计的。使用这些协议,Peer可以互相合作来建立自我组织、自我管理的对等组,而不必关心它们在网络中所处的位置(在网络边缘或者防火墙的后面),并且也不需要集中的管理机构。”因此JXTA的核心是六个协议,其次,JXTA是P2P应用程序开发的运行平台;目前JXTA首先推出了基于Java的参考实现,提供了支持六个协议的JavaAPI,JXTA还将推出包括C语言在内的其他编程语言的API,JXTA在设计时有如下几个目标【10】:>操作系统无关>语言无关>为P2P应用提供服务和基础从本质上讲,JXTA的目标是希望在任何设备,从台式机到PDA、汽车、洗衣机等设备都可以支持P2P编程。所以JXTA被设计成企业可以接受的、容易维护的、健壮的,并且能够满足任何P2P应用的概念。2.KademliaKadeIlllia【11】是个PetarMaymounkov与DavidMazi&es所设计的点对点(P2P)重叠网络,以达成非集中式的点对点(P2F)计算机网络。它制定了网络的结构及规范了节点间的通讯和交换信息的方式。Kademlia节点间使用UDP协议进行通信。Kademlia节点通过实现分布式Hash表(DHT,distributedhashtable)来储存资料。通过已有的局域网/广域网(LANAVAN),一个新的虚拟网络或是重叠网络被建立起来。每个网络节点都是以一组数字(“节点ID”)来识别。这组数字不但作为识别之用,Kademlia算法还会用来做其他用途。非集中式的结构提供了更大的优势,并很明显地增加了对拒绝服务攻击的抵抗。即使一系列的节点被阻塞,也不会对网络可用度造成太多影响,最后网络会通过绕过这些“洞”而自我修复。需要注意的是,Kademlia主要被用于文件共享网络,对于本课题的海量数据处理需求并不合适。2.2分布式系统基本算法2.2.1.存储算法分布式系统的一个基本功能就是能够对海量的数据在物理上进行分布式的存储,而在逻辑上提供一个透明、一致的文件系统操作接口,存储算法提出的目的就是为了实现这个分布式存储的目的。不同的分布式系统在存储算法的设计和实现形式上各有差异,本小节主要是介绍和比较现有的多种分布式系统中的存储算法的特点。2.2.1.1.GoogIo的BigTabIeBigTable(BT)是设计来分布存储大规模结构化数据的【12】,从设计上它可以扩展到上250字节,分布存储在几千个普通服务器上。Google的很多项目使用BT来存储数据,包括网页查询,googleearth和google金融。这些应用程序对BT的要求各不相同:数据大小(从URL到网页到卫星图象)不同,反应速度不同(从后端的大批处理到实时数据服务)。对于不同的要求,BT都成功的提供了灵活高效的服务。BT的设计使它能够管理250bytes(petabyt嚣)数据,并可以部署到上千台机器上。BT完成了以下目标:应用广泛,可扩展,高性能和高可用性。包括googleanalytics,googlefinance,orkut,personalizedsearch,writely和googlecarth在内的60多个项目都使用BT。这些应用对BT的要求各不相同,有的需要高吞吐量的批处理,有的需要快速反应给用户数据。它们使用的BT集群也各不相同,有的只有几台机器,有的有上千台,能够存储240字节(terabytes)数据。BT在很多地方和数据库很类似:它使用了很多数据库的实现策略。并行数据库和内存数据库有可扩展性和高性能,但是BT的接口不同。BT不支持完全的关系数据模型;而是为客户提供了简单的数据模型,让客户来动态控制数据的分布和格式,并允许客户推断底层存储数据的局部性。数据下标是行和列的名字,数据本身可以是任何字串。BT的数据是字串,没有解释。客户会在把各种结构或者半结构化的数据串行化到数据中。通过仔细选择数据表示,客户可以控制数据的局部化。最后,可以使用BT模式来控制数据是放在内存里还是在硬盘上。2.2.1.2.NFSNFS(NaFileSystem)由Sunmicrosystems公司开发,是第一个作为产品设16计的分布式文件服务,其设计目标是对硬件和操作系统异构性提供高度支持,适用范围包括局域网和内部网。目前NFS已经形成了因特网标准——NFS协议[13】(RFC1813),通信采用RPC方式。通过使用NFS,用户和程序可以像访问本地文件一样访问远端系统上的文件。NFS的系统结构图2.3所示:2.2.1.3.AFS图2-3NFS结构图Andrew文件系统(AFS)[14J结构与NFS相似,由卡内基·梅隆大学信息技术中心(ITC)开发、现由前ITC职员组成的Trallsarc公司负责开发和销售。AFS较NFS有所增强。其设计目标主要是为了提高系统的可伸缩性,支持更多用户和热点文件访问。分布式文件系统(DFS)也是由AFS发展而来,作为开放软件基金会(OpenSoftwareFoundation,OSF)的分布式计算环境(Distributedcomputingenvironment,DCE)中的文件系统部分。本文的重点研究课题Hadoop所使用的分布式存储系统HDFS则是在DFS的基础上发展而来。AFS的系统结构【I5J如图2.4所示:谯.辨图2-4AFS结构图为了更好的比较AFS和NFS,下面通过表格的方式将AFS和NFS进行对比。表2-1NFS和AFS特点对比不同点NFSAFS缓存方式临时持久客户缓存一致性轮询回调适用范围局域网局域网和广域网有/无状态无状态有状态副本不支持副本更新只读复制相同点基于路径的访问基于UNIX内核的修改2.2.2.MapReduce算法MapReduce不仪是Google的一项重要技术,它更是一个编程模型[16|,用以进行大数据量的计算。对于大数据量的计算,通常采用的处理手法就是并行计算。至少现阶段而言,对yf:多丌发人员来说,并行计算还是一个比较遥远的东西。MapReduce就是一种简化并行计算的编程模型,它让那些没有多少并行计算经验的丌发人员也可以丌发并行应用。在我看来,这也就是MapReduce的价值所在,通过简化编程模型,降低了丌发并行应用的入门门槛。相对于现在普通的丌发而者‘,并行计算需要更多的-t。业知识,有了MapReduce,并行计算就可以得到更J。泛的应用。MapReduce的名字源于这个模型中的两项核心操作:Map和Reduce。也许熟悉函数式编程(FunctionalProgramming)的人见到这两个词会倍感亲切。简单的说来,Map是把一组数据一对一的映射为另外的一组数据,其映射的规则由一个函数来指定,比如对[1,2,3,4】进行乘2的映射就变成T[2,4,6,8】。Reduce是对一组数据进行归约,这个归约的规则由一个函数指定,比如对[1,2,3,4】进行求和的归约得到结果是10,而对它进行求积的归约结果是24。Map操作是独立的对每个元素进行操作,在函数式编程中,操作是没有副作用的,换句话说,Map操作将产生一组全新的数据,而原来的数据保持不变。因此,它是高度并行的。Reduce操作虽然不如M印操作并行性那么好,但是它总会得到一个相对简单的结果,大规模运算也相对独立,因此也是比较适合并行的。无论是Map还是Reduce都是以另外的函数作为参数,在函数式编程中,这样的函数被称为高阶函数(Ili曲.orderfunction)。正是因为它们可以同其它函数相结合,所以,我们只要把Map和Reduce这两个高阶函数进行并行化处理,而无需面面俱到的把所有的函数全部考虑到。这样便形成了一个以Map和Reduce为基础的框架,具体应用相关代码写在用户代码中,之后与MapReduce结合获得并行处理的能力。当然,这么做的前提是按照这个框架的要求,把计算归结为Map和Reduce操作。为什么是Map和Reducc?从前面的内容我们可以看出,在Map过程中,我们将数据并行,也就是将数据分开,而Reduce则把分开的数据合到了一起,换句话说,Map是一个分的过程,Reducc则对应着合,这一分一合便在不知不觉中完成了计算。所以,站在计算的两端来看,与我们通常熟悉的串行计算没有任何差别,所有的复杂性都在中间隐藏了。所有这些并行化能力的获得都与函数式编程有着密不可分的关系。事实上,不仅仅是MapReduee从FP中获得了灵感,其它一些并行编程模型也走上了同样的道路。函数式编程中有很多的好东西,比如自动内存管理,比如动态类型。在遥远的年代里,因为机器性能的原因,它们无法得到广泛应用,当机器性能不再是瓶颈,这些东西便逐渐复活了。前面提到过,并行计算对于普通开发人员来说,有一个比较高的门槛。从前我们或许可以不理会并行计算,但是随着Intel开始将多核带入人们的日常生活,并行计算将会变得更加平民化,毕竟谁也不希望自己机器里面的多核只有一个在干活。现在的许多操作系统会把多核视为多处理器,但那也得有多任务才能在CPU处多分得一杯羹。对于服务器端应用来说,拥有多任务的能力是一个正常的现象。但对于很多桌面应用来说,一条道跑到黑的情况比较多见。而且,多任务并非为并行计算专门准备的,所以,控制粒度是很大的。如果需要更细粒度的19并行计算,至少从表达能力上来说,多任务就有些麻烦了。并行计算进入日常开发的难度就在于编程模型,太复杂的东西会被人唾弃的,CORBA在这方面已经是个反面教材了。MapReduce已经为我们演示了一种可以接受的编程模型。关于MapReduce并行编程模型在Hadoop中的具体实现将在3.3节进行详细阐述。2.3本章小结本章介绍了几种目前的主流分布式系统模型和应用,通过比较这几种分布式系统的设计和实现,重点分析了其中共同的关键技术,包括分布式系统中广泛采用的存储算法、MapReduce算法。在这几种分布式在深入的比较了现有的几种分布式系统模型并结合研究项目实际之后,决定采用Hadoop作为本论文中所涉及的研究项目的海量数据处理模型基础。第3章Hadoop的整体构架3.1Hadoop核心组件概述3.1.1.HadoopMap/Reduce3.1.1.1.编程模型和运行框架Map/Reduce是一个将大型分布式计算表达为一个对数据键/值对集合进行串行化分布式操作的编程模型。HadoopMap/Reduce框架借助于一个计算机集群,将用户定义的Map瓜educe任务分散到集群中的节点计算机上进行执行。一个Map/Reduce计算包括两个阶段,map阶段和reduce阶段。计算的输入是一个键/值对数据集合。在map阶段,Map/Reduce框架将输入数据结合拆分为大量的数据片段,并将每一个数据片段分配给一个map任务。Map/Reduce框架还会将这些map任务分配到集群中的运行中的节点。每一个map任务会将其分配到的键/值对数据经过计算生成一个中间结果键/值对集合。对于每一个输入键/值对(KⅥ,map任务会调用一个用户定义的map函数用于将输入键值对变形为一个不同的键值对(K’,V’)。接下来,Map瓜educe框架会将中间结果键值对进行排序然后产生一个新的二元组(K’,V’·)集合,在这个集合中,所有对应相同键的值被归类在一起。这个过程还会将二元组集合划分出和reduce任务数量相同的片段数。在reduce阶段,每一个reduce任务会将被分配到的二元组(K’,V’·)集合的片段作为输入。对于每一个这样的二元组都会调用一个用户定义的reduce函数来将二元组变形为一个输出的键/值对(KⅥ。Map/Reduce框架会再一次将这些集群中的节点上的reduce任务进行分发然后将这些中间结果数据片段再次分配到每一个reduce任务进行处理。每个阶段的任务执行都是支持容错的,如果任一个或多个节点在计算过程中出现错误都会将任务自动重新分配到集群中的其他节点。同时运行多个map和reduce任务提供了很好的负载均衡并且保证了运行时失败的任务被重新运行的代价降到尽可能的小。213.1.1.2.Map/Reduce基本架构HadoopMap/Reduce框架是一个主/从架构。它包括一个单独的主服务器或称为iobtracker和若干从服务器或称为tasktracker(集群中每个节点都有一个tasktracker)。Jobtracker是用户和Map/Reduce框架之间的交互点。用户将map/reduce任务提交到jobtracker,然后由jobtracker负责将任务添加到待执行任务队列中,任务执行顺序遵从先到先服务原则。Jobtracker负责将map和reduce任务的分配到tasktracker。Tasktracker按照jobtracker的指令执行任务并处理map阶段到reduce阶段的数据转移。3.1.2.HadoopDFSHadoop的分布式文件系统被设计为将海量文件遍布存储在一个大集群的多台计算机上。HDFS的设计是受到了GFS的启发。HDFS将每一个文件以分块序列的形式进行存储,一个文件的所有分块除去最后一个分块外都是等大小的。为了实现容错将文件分块进行自动复制。文件分块的块大小和复制比例都是可以按照单个文件进行配置的。HDFS中的所有文件都是“只写一次”并且严格限定在任何时候只有一个写文件操作者。和HadoopMap/Reduce类似,HDFS也是主/从架构。一个安装好的HDFS包括一个单独的名称节点,一个主服务器用于文件系统命名空间管理和客户端的文件访问管理。除此之外,还有很多个数据节点,在集群中的每个节点都有一个数据节点用于存储该节点运行时的数据。名称节点通过RPC接口支持文件系统命名空间中文件和目录的打开、关闭和重命名等操作。它也决定了数据块和数据节点的映射关系。数据节点负责提供文件系统客户端的读写请求,除此之外也提供来自名称节点的数据块创建、删除和复制指令。3.2Hadoop分布式文件系统(HDFS)本节将主要对HDFS的整体架构和设计上的一些思路进行研究和分析,对HDFS在实现上的优缺点进行深入的探讨。设计依据部分来源于Hadoop的官方站点上的文档【171。3.2.1.假设和目标3.2⋯11硬件错误硬件错误是正常的而非异常事件。一个HDFS实例有时会包含成百上千台服务器,每个服务器都存储有文件系统的部分数据。事实上集群中组件的数量是庞大的,并且每个组件出现无法工作的概率都是不可忽略的。因而,快速的检测到硬件错误并且自动的从中恢复是HDFS的核心架构目标。3.2⋯12流式数据访问运行在HDFS上的应用程序需要能够获得对其数据的流式访问。这些应用程序不是运行在普通文件系统上的普通应用程序。HDFS被设计用于批处理而非交互式应用。HDFS的重点是提供高数据吞吐量而不是低数据访问延迟。POSIX标准中的许多限制对于运行在HDFS上的应用程序来说是不适合的。POSIX的一些关键性规范要求被修改以获得在HDFS上更高的数据吞吐速率。3.2.1.3.海量数据支持运行在HDFS上的应用程序一般需要处理海量数据。在HDFS中一个典型的文件大小是GB甚至TB级别。因而,HDFS是被优化来支持大文件。它应该能提供集中式的高数据带宽并且能够扩展到单个集群支持上百个节点。在一个单独的HDFS实例中应能支持数千万的文件。3.2⋯14简单一致模型HDFS应用程序需要一个“只写一次,读取多次”的文件访问模型。一个文件一旦被创建、写入、关闭后就不应再被修改。这个假设简化了数据一致性问题因而保证了高数据访问吞吐量。一个MapReduce应用程序或者一个Web爬虫程序都能够很好的适应这个模型。3.2.1.5.移动计算而非移动数据一个应用程序的一次计算请求如果在操作数据的本地附近执行将会更加的有效率,这在待操作数据数量庞大时尤为正确。这种设计可以有效的减轻网络拥塞增加系统的总数据吞吐量。这个假设等效于在待处理数据“最近处”进行计算总是优于将待处理数据移动到应用程序处计算。HDFS提供一个将应用程序自身移动到数据附近进行计算的接口。3.2.1.6.可移植于异构硬件和软件平台HDFS已经被设计为可以简单的从一个平台移植到另一个平台。这促进了HDFS在更多应用程序平台的普及。3.2.2.名称节点和数据节点在3.1.2节已经介绍过HDFS的主/从结构特点,其中名称节点和数据节点实际上是设计用于在普通廉价PC机上运行的软件。这些PC机一般运行着一个GNU/Linux操作系统。HDFS本身采用Java语言丌发,任何支持Java运行环境的机器都可以运行名称节点或数据节点软件。使用高度可移植的Java语言作为HDFS的开发语言意味着HDFS可以被部署到多种类型的平台和机器。一个典型的部署情况是一个专门的机器仅仅用于运行名称节点软件。集群中的其他机器则分别运行一个数据节点软件。这种架构也不排除在同一台机器上同时运行多个数据节点软件只是在实际的部署中很少会遇到这种部署案例。在一个集群中只有一个名称节点服务器可以极大的简化系统架构。名称节点服务器既是仲裁者也是HDFS所有元数据的仓库。HDFS被设计为任何数据都不会流经名称节点。下图是HDFS架构中名称节点和数据节点之间的运行时关系图。24tlDFS架构图3-1HDFS架构中名称节点和数据节点之间的运行时关系3.2.3.文件系统命名空间HDFS支持传统的层次化文件操作。用户或应用程序可以创建目录并将文件存储在目录中。文件系统的命名空间层次类似于现有的大多数文件系统,支持创建和删除文件,将文件从一个目录移动到另一个目录,或者重命名一个文件。HDFS目前还未实现用户磁盘限额配置或者访问权限控制。HDFS不支持文件的硬链接或软链接。名称节点负责维护文件系统的命名空间。任何对文件系统命名空间或者属性的改动都会被命名节点所记录。应用程序可以指定一个文件应用被HDFS维护的复制数。一个文件的复制数被称为这个文件的复制因子。这个信息被存储在名称节点。3.2.4.数据复制HDFS被设计用于可靠的存储海量文件遍布于一个大集群中的计算机。每个文件在HDFS中都是以一个数据块串序列的形式存储,单个文件中的所有数据块除去最后一个数据块之外都是大小相同的。出于容错性考虑一个文件中的数据块会被复制。数据块大小和复制因为都是可以按单个文件进行配置。复制因为既可以在文件创建时指定也可以在以后修改。HDFS中的文件是严格的只写一次并且在任何时候只有一个写文件操作者。名称节点决定数据块复制相关所有操作,它还会周期性的从集群中的每个数据节点收到一个1心跳”回应和一个“块报告”。收到一个1心跳”回应表示数据节点当前运行正常。“块报告”包含当前数据节点上的所有数据块的一个列表。下图是一个“块报告”的结构示意图。块复制名称节点(文件名.复制块数,block—ids,⋯)/users/abc/data/part一0,r:2,f1,3),⋯/users/abc/data/part—J,r:3,(2,4,5},⋯3.2⋯41复制点选择数据节点图3-2“块报告”示意图在何处进行复制操作对于HDFS的稳定性和性能是一个关键的影响【悖】。优化复制操作点位置是HDFS区别于现有的其他分布式系统之处。这是一个需要大量的调整和经验的特性。使用机架式感知复制策略的目的是为了提高数据可靠性、可用性和网络带宽利用率。大的HDFS实例通常运行在一个遍布多个机架组成的计算机集群。不同机架上的两个节点之间的通信需要经过交换机。在绝大多数的情况下,在同一个机架上的不同计算机之间的网络带宽要大于在不同机架上的不同计算机之间的网络带宽。在系统启动时,每个数据节点会探测其属于的机架并将机架id在注册时通知名称节点。HDFS提供了一个用于简化可插拔模块用于探测机器的机架id的API。一个简单但并不是最优的策略是在单独的机架上进行复制操作。这避免了整个机架故障时的数据丢失并且在读取数据时充分利用了多个机架的网络带宽。这个策略均匀的将复制内容分布到集群中从而使得在部件故障时能够负载均衡。尽管如此,由于写操作需要将数据块转移到多个机架使得这个策略增加了写操作的代价最常见的是复制因子为3的情况,在这种条件下,HDFS复制点选择策略会将一份数据拷贝放在本地机架中的一个节点,另一份拷贝存储在本地机架的另一个不同的节点,而最后一份拷贝存储在不同机架上的一个节点上。这个策略减小了机架间的写操作所带来的网络流量从而在整体上提高了写操作的性能。机架故障的几率要远小于节点故障的几率。这个策略不会影响到数据的可靠性和可用性保证。然而,这种策略会降低读数据时的汇总网络带宽,这是因为数据是放在两个不同的机架中而不是三个不同的机架中。在这种策略条件下,一个文件的复制也不是平均分布在不同的机架中。三分之一的拷贝存储在一个节点上,三分之二的拷贝存储在一个机架上,剩下的三分之一拷贝均匀分布在剩余的机架中。这个策略在改善了写操作的性能的同时并没有牺牲数据的可靠性或者读取操作的性能。3.2⋯42复制对象选择为了减小全局带宽消耗和读取延迟,HDFS会使用离读请求的发起者最近处的复制块内容去响应。读请求所在机架上的复制块会被优先用于响应,如果一个HDFS集群跨越多个数据中心,则本地数据中心的复制块内容会被优先考虑用于响应。3.2.4.3.安全模式HDFS在启动时,名称节点会进入一个称为“安全模式”的特殊状态。当名称节点处于“安全模式”时,数据块的复制不会发生。名称节点接收数据节点的“心跳”响应和“块报告”消息。一个“块报告"消息包含当前运行的一个数据节点上的数据块的列表。每个数据块都有一个最小的被复制块数值。只有当数据块的最小被复制块数值达到了之后,这个数据块才会被认为是“已安全的被复制"。当一定比例(可配置大小)的“已安全的被复制’’数据块被名称节点服务器检查到后,名称节点就会退出安全模式状态。然后名称节点服务器会让那些没有达到“已安全的被复制"状态的数据块继续被复制到剩下的数据节点。3.2.5.持久化文件系统元数据HDFS命名空间是被名称节点所存储。名称节点使用一个被称为EditLog的事务日志去记录文件系统元数据所发生的每一次改变。例如,在HDFS中创建一个新文件会导致名称节点插入一条记录到EditLog来对应。类似的,改变复制因子的值也会产生一个新记录被插入到EditLog中。名称节点使用本地主机操作系统中的一个文件来存储EditLog。整个文件系统命名空间,包括数据块到文件的27映射和文件系统属性,都存储在一个叫做Fslmage的文件中。Fslmage也存储在名称节点服务器上的一个本地文件系统的文件中。名称节点在内存中保留整个文件系统命名空间的镜像和文件Blockmap。关键元数据在设计上是紧凑的,因而一个拥有4GB内存的名称节点就足够支持海量的文件和目录。当名称节点服务器启动时,名称节点会读取磁盘上的Fslmage和EditLog,将EditLog中的所有事务应用到内存中的Fslmage对象,并将新的Fslmage对象的内容更新到磁盘上的新Fslmage对象。旧的EditLog文件在随后会被清除掉因为事务变更已经更新到持久化的Fslmage对象。这个过程被称为一个“检查点”。在当前的HDFS实现中,一个检查点只会在名称节点启动时创建。在未来版本的HDFS中将会支持周期性的检查点。数据节点在其本地文件系统中存储HDFS的数据。数据节点对HDFS文件一无所知。它将HDFS数据的数据块存储在一个单独的文件中保存在其本地文件系统中。数据节点不会在一个相同的目录创建所有的文件,而是使用一个启发式算法去确定每个文件夹的最佳文件个数,然后依此去创建子目录。不在一个相同的文件夹中创建所有的本地文件是因为本地文件系统有可能无法有效的支持在单独一个文件央中存储数量过大的文件。当数据节点启动时,它会遍历其本地文件系统,产生一个包含所有HDFS数据分块对应其本地文件的列表,并将这个列表以报告的形式发送到名称节点——这个报告就是“块报告”。3.2.6.通信协议所有的HDFS通信协议都位于TCP/IP协议层之上。客户端建立一个到名称节点服务器的可配置的TCP端口的连接。它使用客户端协议与名城节点通信。数据节点和名称节点之间的通信使用数据节点协议。一个远程过程调用(RPC)抽象打包了这两个协议。从设计的角度来说,名称节点从来不会初始化任何的RPC连接。它只会响应数据节点或者客户端的RPC请求。3.2.7.健壮性HDFS的主要目标是即使在出现故障的情况下仍然能够可靠的存储数据。三个常见的故障类型【171包括:名称节点故障,数据节点故障和网络故障。3.2.7.1.磁盘数据损坏,在线状态和重试复制每个数据节点都会周期性的发送~心跳”响应消息到名称节点。网络故障会引起部分数据节点失去与名称节点服务器的连接。名称节点能够通过没有接收到1心跳”响应检测到这种情形的发生。名称节点会将近期没有收到“心跳”响应消息的数据节点标记为“死亡”然后不会将任何新的FO请求转发给它们。被标记为“死亡”的数据节点服务器上的数据对于HDFS来说就是不再可用的了。数据节点的死亡会导致部分数据块的复制因子下降到低于指定值。名称节点会定时的追踪到这些数据块并随时进行复制操作。重新开始复制操作有如下几种可能:一个数据节点可能变为不可用状态,一个复制操作可能会失败,数据节点上的硬盘可能会故障,或者一个文件的复制因子变大。3.2⋯72二次负载平衡HDFS架构是和数据的二次负载均衡策略兼容的。如果一个数据节点上的可用磁盘空间低于某个阈值时数据有可能自动的被策略调度从一个数据节点转移到另一个数据节点。当对某一个文件的请求数量突然增大时,也会有相应的策略动态的创建多个被请求资源的拷贝然后重新在集群中均衡分布这些拷贝。不过需要注意的是,上述这些类型的数据二次负载均衡策略在目前的HDFS中还未实现。3.2.7.3.数据完整性有可能一个已获取的数据块内容是已损坏的。这种损坏产生的原因有可能是存储设备故障,网络故障,软件bug等。HDFS客户端软件会校验HDFS文件内容的校验和。当一个客户端在创建一个HDFS文件的时候,它会计算这个文件的每个数据块内容的校验和并将这些校验和存储在一个单独的隐藏文件中并将这个隐藏文件存储在同样的HDFS命名空间中。当一个客户端获取到一个文件时会自动校验这个文件的校验和是否正确。如果出现校验失败,则会选择从其他的数据节点获取该文件的拷贝。3.2⋯74磁盘元数据损坏FsImage和EditLog是HDFS的核心数据结构。这些文件的损坏会导致HDFS实例无法工作。基于这个原因,名称节点可以被配置为支持维护多个FsImage和EditLog的拷贝。任何对这两个文件所发生的改动都会同步更新到拷贝文件。这种同步更新多个拷贝的操作会降低命名节点每秒支持的命名空间事务处理速率。尽管如此,这种性能降低是可以接受的,这是因为即使HDFS在本质上是数据为中心的,它们并未以元数据为中心。当名称节点重启时,它会选择最新的FsImage和EditLog来使用。名称节点服务器是HDFS集群中的一个单点故障点。如果名称节点服务器出现故障,就需要手动的干预。目前版本的HDFS还不支持自动的重启操作和故障转移到其他机器的名称节点软件。3.2⋯75快照快照功能支持在特定时间存储数据的一份拷贝。快照特性的一个用处是将一个损坏的HDFS实例回滚到一个之前时间点的已知功能正常的实例。HDFS目前不支持快照功能但在未来的版本中将会增加这一支持。3.2.8.数据组织3.2.8.1.数据块HDFS被设计用于支持海量文件。兼容于HDFS的应用程序就可以处理海量数据。这些应用程序只写一次数据但会读取一次或多次,读取请求需要满足流式速度。HDFS支持文件的写一次读取多次机制。HDFS使用的一个典型的数据块大小是64MB。因此,一个HDFS文件最多会被截短到64MB,如果有可能的话每个文件块都会存储在一个不同的数据节点。3.2.8.2.分段传送一个客户端创建文件的请求不会立刻到达名称节点。事实上,HDFS客户端会将文件数据缓存在一个临时的本地文件。应用程序的读操作会被透明的重定向到这个临时的本地文件。当本地文件累积的数据大小超过一个HDFS数据块大小时,客户端就会联系名称节点。名称节点将文件名插入到文件系统然后分配一个数据块给这个文件。名称节点把数据节点标识和目的数据块位置信息响应给客户端请求。然后客户端将数据块内容从本地临时文件转移到指定的数据节点。当一个文件关闭时,剩余的未写完的数据也会被转移到数据节点。客户端会在随后通知数据节点文件已关闭。这时,名称节点提交文件创建操作到一个持久化的存储。如果名称节点在文件关闭之前发生故障,这个文件就丢失了。上述这种方法在仔细的考虑了运行在HDFS上的目标应用程序之后已经被应用采纳。这些应用程序需要支持流式写到文件。如果一个客户端不通过客户端的缓冲直接写到远程文件,网络速度和网络拥塞会极大的影响到数据的吞吐量。这种方法不是没有先例。早期的分布式文件系统,例如AFS就是使用客户端的缓存去改善性能。一个POSIX规范也被降低了要求以达到更高的数据上传性能要求。3.2.8.3.复制操作管道化当一个客户端写数据到一个HDFS文件时,它的数据会像本节之前所说的那样首先会被写到一个本地文件。假设HDFS的文件复制因子等于3。当本地文件累积到一个完整的数据块大小时,客户端从名称节点获取到一个数据节点列表。这个列表包含了将要存储该数据块复制内容的数据节点。客户端然后会将数据块先写到列表中的第一个数据节点。第一个数据节点开始以很小的单元大4,(4KB)接收数据,把每个数据单元写到它本地的磁盘中并且将该数据单元传输到列表中的第二个数据节点。第二个数据节点,随后开始接收这个数据块的每个数据单元,写入本地磁盘然后将数据单元传输到列表中的第三个数据节点。最终,第三个数据节点将数据写入到其本地磁盘。因此,一个数据节点可以通过管道化的方式接收到之前数据节点的数据并在同时将数据传递到管线上的下一个数据节点。因而,数据是被管线化的从一个数据节点传输到另一个数据节点。3.2.9.空间回收3.2⋯91文件的删除和反删除当一个文件被用户或应用程序删除时,文件并没有立刻从HDFS中删除掉。与此相反的是,HDFS会先重命名该文件为/trash目录中的一个文件。只要该文件仍然在/trash目录中,它就可以被快速的还原。一个文件可以在/trash目录中存留一段可配置的时间长度。当时间过期之后,名称节点就会从HDFS命名空间中删除这个文件。一个文件的删除意味着与该文件关联的数据块会被释放。需要注意的是,在一个文件被用户删除到相应的HDFS剩余空间增长之间有一个可观的时间长度。用户可以在删除文件后反删除这个文件,只要这个文件仍然保留在/trash目录中。如果用户想反删除一个已经被删除的文件,用户可以直接浏览/trash目录并获取这个文件。/trash目录仅仅包含最近被删除文件的拷贝。/trash目录一个独特的特性是HDFS会应用策略自动从该目录删除文件。目前缺省的策略是删除/trash目录中6小时之前的文件。在未来的HDFS版本中,这个时间将通过一个设计好的接口来配置。3.2.9.2.减小复制因子当文件复制因为减小时,名称节点会选择可以被删除的拷贝。在下一个~心跳”响应时,这个信息会被传输到指定的数据节点。该数据节点就会删除相应的数据块然后释放集群中对应的磁盘空间。同样的,在setReplicationAPI执行结束和集群增加剩余空间之间会有一个时间延迟。3.3MapReduce并行编程模型在Hadoop中的实现3.3.1.映射(Map)由于映射操作是并行的,输入文件集合会先被划分为几个“文件片断”。如果单个文件的大小达到会影响搜索时间的程度会将这个文件也划分为几个“片段"。文件划分过程并不考虑输入文件的内部逻辑结构,例如一个按行记录的文本文件也会被按照二进制字节数大小进行片段划分。然后,每个“文件片段”将会对应的创建一个新的映射任务。当一个单独的map任务开始时对应的都会按照每个规约任务配置好的打开一个新的输出文件写操作者。然后映射任务会使用从指定的InputFormat类获得的ReeordReadel"类来读取它的FileSplit属性。InputFormat类负责解析输入和生成键/值对。InputFormat也需要处理达到FileSplit边界值的记录。例如TextlnputFormat会读取超过分割边界值的FileSplit的最后一行,当读取其他的非第一个FileSplit时,TextlnputFormat会忽略第一个新行以上部分的内容。对于InputFormat类来说,没有必要同时产生有意义的索引键和值。例如TextlnputFormat的默认输出包含以输入行为值以及以毫无意义的行在文件中的偏移量为索引键的内容。绝大多数的应用仅仅使用行内容而忽略行在文件中的偏移量。由于键值对是从RecordReader中读取到的【20】,它们会被传递给配置好的Mapper对象。用户提供的Mapper对象会按照定义好的规则去处理输入键值对然后调用OutputCollector.colleet方法选择键值对。输出结果必须使用一个key类和value类。这是因为映射过程的输出会写到一个SequenceFile类或继承SequenceFile的子类中以保持输出对象的类型一致性。映射过程的输入和输出键值对倒不必类型匹配或具有相同的基类。当Mapper对象的输出被收集齐之后将会对输出对象进行划分,也就是说输出的位置是由Partitioner对象指定的。默认的HashPartitioner对象使用hashcode函数作用于key类(这就意味着hashcode函数必须能够达到均衡规约任务负载的目的)。N个输入文件会产生M个待运行的映射任务,每个映射任务都会产生由系统配置好的规约任务数量相同的输出文件。每个输出文件对应一个规约任务,所有映射对象的输出键值对都会被路由以保证每一个给定的索引键的所有键值对会最终出现在指定的一个规约任务中。3.3.2.混合(Combine)当映射操作输出了它的键值对后它们就会在内存中驻留。由于效率的原因,有时需要充分利用这个事实的优点去提供一个执行规约类型功能的combiner类。如果使用了一个combiner类,则映射过程产生的键值对就不会立刻写到输出。与此相反的是,输出会先被收集到列表,每个索引键对应一个列表。当一定数量的键值对被写入时,这个缓冲区里的所有键值对会被清空转移到combiner类的reduce方法中,然后将合并操作产生的键值对像原有的映射操作一样输出。3.3.3.规约(Reduce)当一个规约任务开始时,它的输入来源于分散在多个节点上的映射任务所产生的许多文件。如果是规约过程是运行在分布式模式下的话,需要在拷贝阶段先将这些文件拷贝到规约任务所在节点的本地文件系统。一旦本地数据准备就绪所有的数据都会以追加到文件的方式运行在一个追加阶段。然后这个文件会被归并排序以保证给定一个索引键它的所有键值对是连续排列的(这个阶段称为排序阶段)。这使得实际的规约操作非常简单:文件被顺序读入然后输入文件中的一个索引键的所有对应值会被一个迭代器顺次传递给reduce方法直到下一个索引键开始。最后,每个执行的规约任务的输出都会包含一个输出文件。输出文件的格式由JobConf.setOutputFormat方法来指定。如果使用了SequentialOutputFormat类,则输出索引键和索引键对应值得类型都必须指定。3.3.4.MapReduce实现中的其他关键技术1.管理机数据结构管理机存储多种数据结构【2l】,对于每一个映射和规约任务,管理机存储其状态(空闲,运行或完成)和每台工作站的标识。对于每一个已经完成映射任务,管理机存储着由其产生的R个中间数据文件的位置和大小信息。每当映射任务完成,位置以及大小信息将被修改。这些信息将被传送到正在执行规约任务的工作站上。2.容错机制a)工作站错误管理机周期性的向工作站发送探测命令。如果在一定的时间间隔内没有从工作站收到反馈,管理机就认为该工作站失效。任何在该工作站完成的映射任务状态将重新被置为空闲,这样这些映射任务获取了在其他工作站安排执行的资格。同样的,正在运行映射或是规约任务的工作中失效,它的状态也将被设置成空闲,等待安排工作站重新执行。已经完成的映射任务被重新执行是因为它们的输出被存储在本地磁盘,而执行它的工作站已经失效,数据无法访问。工作站中已经完成的规约任务不必重新执行,因为它们的数据已经被存储到全局的文件系统。b)管理机失效管理机定期的存储记录下的它的数据结构作为一个检查点,这是很容易实现的。如果管理机任务执行失败,在上一个检查点上,一个新的任务拷贝将被启动。3.本地化面对海量数据的处理,分布式的计算方式会导致网络间大量频繁的数据交换,在这种情况下网络带宽相对属于稀缺资源。输入的数据存储在集群中机器的本地磁盘,这样对有限的带宽来说是有利的。系统按照一个的大小划分数据段,原始文件被划分到哦各个数据段中。对每个数据段进行备份,分布在不同的机器上。管理机存储这些文件的位置信息,并安排处理这些文件或文件副本的映射任务。如果操作失败,管理机将重新安排映射任务给包含原始文件副本的工作执行。当在集群的工作站运行大型的MapReduee操作时,大部分输入数据都可以在本地读取,这样减小了对网络带宽的占用。4.任务备份当某些工作站在执行某项任务的时候,由于某些因素的影响,执行任务的时间可能会异常的增加。例如,一个磁盘上的错误可能会导致机器频繁的修复这个错误,从而文件的读取速度将急剧下降。而管理机可能还会安排其他的任务到这台机器执行,由于对CPU,内存,磁盘或者贷款的竞争会导致MapReduee代码执行效率非常低。为了减少这种现象对MapReduee操作的影响,当MapReduce操作完成fj{『,管理机复制J下在执行的任务到其他空闲工作站备份执行任务,一旦有一个任务完成管理机就把该任务标识为己完成。5.任务粒度把映射任务分为M块,规约任务分为R块。R和M应大于工作站机器的数量。每一个工作站执行不同的任务以改善动态负载均衡,工作站失效时,将映射任务通过其他工作站分布式完成。3.3.5.MapReduce执行流程图3-3展示了MapReduce的系统执行流程,下面将对照该图详细讲解每个步骤的详情。输入文件映射阶段(1黼)规约阶段输出文件图3-3Map/Reduce执行流程(1)fbrk首先,将众多文件分成大小不等的若干小块数据,数据块大小由用户给定参数控制,然后启动机器集群中的众多程序拷贝。(2)指派映射/规约任务在众多程序拷贝中有一个管理机(master)的主程序,其他的均为工作站(worker)程序,工作站程序有管理机指派任务。主程序指派空闲的工作站程序执行映射任务或是规约任务。(3)读取被指派执行映射任务的工作站读取相关的数据块,从原始数据中解析出键/值对,经过映射函数处理,得到中间键值时,存入内存缓冲区。(4)本地写入35内存中的数据组被划分函数周期性的划分到R个区域写入本地磁盘。这些在本地磁盘的数据数列的存放位置信息被送回管理机,管理机负责将这些位置信息传送到执行规约任务的工作站。(5)远程读取当执行规约任务的工作站被告知这些数据的位置,它通过远程方式读取执行映射任务的工作站中的本地缓冲数据。规约工作站读取完所有中间数据后,通过中间关键字对数据进行排列,把具有相同关键字的数据分为一类。排序操作是必须的,因为具有不同的关键字映射后会进行相同的规约操作。如果中间数据的数量太大不适合存入内存,就启用外部存储。(6)写到输出文件规约工作站对每一个由唯一的中间关键字对应的中间数据进行排列,它发送关键字和相对应的中间值给用户的规约函数。规约函数的输出结果将被添加到最后的输出文件中。当所有的映射任务和规约任务完成,管理机(名称节点)唤醒用户程序继续之前的程序执行。3.4HadoopMapReduce模型调度和容错机制分析1.HadoopMapReduce的调度机制1)master选择空闲的worker,然后分配给他们每个一个map任务或者一个reduce任务。2)map阶段:mapworker从输入数据中解析key/value对,传给用户定义的Map函数产生中间key/value对,然后将中间key/value对写入本地磁盘并将其散布在由分割函数指定的R个区域中,最后将这些缓存对在局部磁盘的具体位置传回给master。3)reduce阶段:reduceworker先从master得到中间key/value对在mapworker局部磁盘上的位置信息,并使用远程过程调用从mapworker的局部磁盘中读取数据。读取完所有数据之后,reduceworker按照中间key进行排序,reduceworker遍历排好序的中间数据,将把key和与它对应的中间value传给用户提供的Reduce函数,最后将Reduce函数的输出写到与这个reduce对应的最终输出文件中。4)当所有的map和reduce任务被完成之后,master唤醒用户程序。于是MapRedUCC调用返回到用户代码。2.容错机制Master周期性的ping各个worker,检测worker的状态。当一段时间之后没36有n16j应,master将认为worker已经出现故障。在该worker上J下在处理的map或reduce任务将被设置为空闲状态,以便重新调度。完成的map任务需要重新执行,那是因为它们的输出是存储在出现故障机器上的本地磁盘,而导致不可访问。完成的reduce任务输出结果是存储在全局文件系统而不存在这个问题。3.5本章小结本章重点分析了Hadoop系统中的Hadoop分布式文件系统HDFS和并行编程模型MapReduee的实现,在本章的最后分析了Hadoop的MapReduce模型在调度和容错机制上的一些特点。在对HDFS的分析和研究过程中,既分析了现有HDFS相比于其他分布式文件系统的一些优点,也指出了目前版本的HDFS在功能上和性能上的一些不足之处,如不支持磁盘限额管理和二次负载均衡,在结构上由于一个HDFS实例只有一个名称节点,存在单点故障隐患,并且不支持自动的名称节点故障修复功能,仍然需要人工的发现和修复。尽管HDFS目前仍然不尽完善,但对于笔者的研究和具体项目需求来说,这些缺陷和不足之处并不会真正影响到具体项目的成功实施。对于MapReduce并行编程模型的探讨主要是从编程实现的角度出发,探讨了一个使用HadoopMapReduce编程模型的应用程序在编程实现时的具体细节过程。并在此基础上,分析了HadoopMapReduce的系统运行和执行流程细节,并对运行和执行过程中所涉及的一些关键技术细节进行了剖析。最后从抽象的角度,总结了MapReduce模型在调度和容错机制上的实施过程和可能存在的问题。374.1需求分析第4章海量数据处理模型设计在项目背景中提到发起本课题研究的原因,即解决某企业数据挖掘小组所面临的数据预处理中的问题:(1)ETL处理能力下降,信息价值的削弱。(2)随着业务的增长,企业每天的Web日志越来越大,ETL处理起来速度变慢,超出了可忍受范围。可用信息产出的时间被延误,一定程度上也等于信息价值的削弱。(3)数据源格式多样化,原有系统无法满足。(4)随着业务类型的增加,定制的日志格式开始多样化,原有的ETL逻辑不适应这种需求,然而,在众多繁复的ETL中重新修订程序来适应新的数据规则会消耗过多的人力,而且没有从根本上智能化解决数据源格式不统一这个问题。(5)可定制性要求变高,希望能有优先级设定。(6)要求数据的存储和计算能合理利用廉价的集群环境,降低成本。(7)容错机制要求提高,避免因隐藏的不利因素干扰每日的数据预处理及依赖于此的后续工作。(8)工作小组的着力点在于不同产品的规则设计和关联数据分析,所以希望设计出来的海量数据处理模型易维护和易扩展,而不要求维护人员技术上必须对分布式系统了如指掌。4.2设计思想为了满足上述的需求,我们提出了拆分、重构和融合的设计思想.同时为了快速建立模型系统,我们设立了尽量简单的原则,在保持足够扩展性前提下,暂时不为性能做太多的折中,极力保持整个系统的简单、易部署和实用性,这样做避免为了细节的性能问题投入太多精力对整体构建产生负面影响。事实证明保持简单的原则保证了整个研究项目的顺利发展,同时为后期的性能优化节约了很多宝贵的时间。4.2.1拆分先来了解一下原来的处理系统,见图4.1:I:靶P2ETL’3:DBH.3H/0’r譬ilE产孓.‘,1Y毳?;:1.. :{∥晶。A/毋既,t。叠LOCALij.jH。≤ETLs,一..曼,,6L.卵l、,t《&?ii晨fscP)/’i一:-J:i7飞“”¨%j..Vx;》I一‘_。I.:●J1.:/丽厄/i么I;}{I;{.;l{/奠ir—彳⋯、ii.。{’。i1一’11⋯一;。:¨;;.。。;i:1曝碾口·薛,日哪i分为3一条轻时13■;《;;:;1刍置iI盥曲倥:{;}。’;;J口咿h帕’队裳’:‘;14hours,;1证蔚存储,数据;{;80~IOO(3文作,::;一秘为31条耗时6';I馓约80G厂350G;{;势!l枉--i3hotas*--6,÷·卜.Thours一:;·声‘卜一图4-1原始系统处理流程在分析讨论之后,我们将该系统的数据预处理部分进行了拆分,变为:数据格式转换,数据清洗,数据规则计算,数据结果标准化4大部分。4.2.2重构包含3个方面:1)SCP部分应该使用DGH还是Hadoop。2)ETL主要考虑几个方面:(1)出错控制,比如因为apache配置不一致带来的日志格式不一样,或者有业务需求带来的增删字段等,在这些情况下程序该如何灵活调整。(2)规划空间,至少可存储一天的日志,并可供调度,预计(1G*2)/天,当然还需要考虑到定制计算需要的空间。(3)用户格式化同志,包括汇总计算、监控、和定制计算。(4)读出标准输出数据入外部表。3)DB部分将考虑在现有的基础上抽出部分逻辑,归入数据预处理的Hadoop规则计算中,简化数据库的计算负担。在这个模型设计和部署中除了涉及Hadoop的框架技术外,还涉及到别的技术知识,在此我们仅讨论重点的技术难点,从设计角度出发,而不是实例操作角度。391)如何在SCP部分使得hadoop的配置易操作2)舰则分析部分如何高效运行(可考虑使用java的:J:J一模式)3)如何抽离定制计算中的逻辑考虑到收集文件和并行分配的瓶颈问题,SCP部分应该使用原有PERLETL还足Hadoop,我们进行了比较,结果如下:PERLETLHadoop1.本身存在bug1.分job收集2.集成到Hadoop中调度不易控制2.收集时直接存入DFS3.没有自恢复功能3.空闲时刻读入NFS备份4.自我恢复,执行失败时可自分配所以如何让将格式化好的海蕈口。占SCP入DFS以方便配置计算是一个人关键融合点。4.3模型框架综合上述没计思想,借鉴第3章中研究讨论的Hadoop分前i式模型设计方法,我们最终的海量数据处理模型l,J.视化描述如图4.2:图4-2海量数据处理模型整体框架404.4功能模块该模型中主要包括以下7个功能模块,鉴于篇幅的限制,在论文中我们仅重点介绍规则计算模块,它是整个数据预处理的核心和Hadoop分布式计算的思想体现。4.4.1日志收集该模块主要负责从各产品的前端机上收集获取原始的Web访问日志。考虑即使一个并不繁忙的服务器,其日志文件的信息量也会很大,一般每10000个请求,访问同志就会增加1MB或更多。这就有必要定期滚动同志文件。由于Apache会保持日志文件的打开,并持续写入信息,因此服务器运行期间不能执行滚动操作。移动或者删除日志文件以后,必须重新启动服务器才能让它打开新的日志文件。用优雅的(graceful)方法重新启动,可以使服务器启用新的日志文件,而不丢失原来尚未写入的信息。为此,有必要等待一段时间,让服务器完成正在处理的请求,并将记录写入到原来的日志文件。一般日志的轮转时间设置在每天的O点、6点和18点,故而,我们的日志收集模块也配合设置了轮转机制,每天l点、7点和19点会自动启动远程SCP程序,以期避开不同产品一天日志同一时间收集造成网路堵塞,耗时较高的现象。另外,在该模块中,我们还添加了收集信息自动配置功能。将需要收集的前端机日志相关信息存入数据库中,这样易维护和可扩展性高,同时还方便查询,这在有着众多服务和应用的大型企业比较重要。因为这些技术都不是难点,关键在于这个思想的启用。这些前端机日志收集相关信息包括:前端机机器名称、端口号、应用服务类别、日志文件位置、日志文件前缀名、日志文件后缀名。4.4.2格式清洗这里的格式清洗有别于4.4.4节的规则计算。格式清洗主要指的是对原始日志中多种产品不同的配置格式进行统一,包括定义每个字段的含义和位置以及统一分隔符,同时还会去掉一些记录不完全的坏数据。保证数据的格式统一,信息完整。举例说明一下。通用日志格式(CLF)包括发送请求到服务器的客户的IP地址、客户端identd判断的RFCl413身份、H下rP认证系统得到的访问该网页的客户名称、服务器完成对请求的处理时的时间、客户发出的包含了许多有用信息的请求内容、服务41器返回给客户端的状态码、返回给客户端的不包括响应头的字节数。它的在同志文件中记录如下:127.0.0.1一frank【10/Oct/2000:13:55:36—0700】”GET/apache_pb.gifHTTP/1.0”2002326当然,对不同的产品,他们关心的用户行为是不一样的,所以Apache是允许个性配置的,这就引入了原始日志的记录不统一问题。比如,一条目志还可以记录如下:127.0.0.1一frank【10/Oct/2000:13:55:36—0700]”GET/apache_pb.gifHTTP/I.0”2002326”http://www.example.com/start.html””Mozilla/4.08【en](Win987IjNav)”其中,多出来的项是:”http://www.example.com/start.html”(\”%(Referer}i\”)此项指明了该请求是从被哪个网页提交过来的,这个网页应该包含有/apache_pb.百f或者其连接。”Mozilla/4.08【en】(Win98;I;Nav)”(\”%fUser-agent’i\”)此项是客户浏览器提供的浏览器识别信息。这个模块的作用就是根据外部定制的格式信息来过滤原始日志,比如只保留ip、时间、ud、用户浏览器信息、状态码等,从某个字段中再提取用户信息,比如从URL里面提取出用户查询的关键词、COOKIE和页面位置等。对于这个模块,我们目前选用的是C++语言来实现。它的性能比P甜要好很多。4.4.3导入DFS这是启动Hadoop规则计算的前提必要工作。在3.2的研究中,我们详细介绍了Hadoop的分布式文件系统HDFS的存储原理和备份机制和各节点间的数据通信方式等,同时也探讨了它的优缺点,所以在此就不赘述了。值得一提的是对于不清楚分布式文件系统的程序员来说,这个操作也相当简单。只要启动hadoopdis-put命令即可。比如:${HadoopBin}hadoopdfs-put${LogDir}/search—com/${Date}/dataATM/search/${Date}另外,HDFS中的名称节点、数据节点以及数据备份数目等都是可以配置的。这个我们会在第5章的运行实例中给读者一个直观感受。424.4.4规则计算该模块是MapReduce计算模型的核心,主要完成事务逻辑的规则设计和计算功能。MapReduce的并行编程模型在3.3中已经讨论得很清楚了,它用来处理web同志关联规则计算很方便高效,很容易实现相关的统计事务。不同的事务有不同的统计规则,然而它们的实现原理都是一样的,其流程如下:1.根据输入路径,先用FileSplit把输入的文件剁碎,根据InputFormat(读入资料的格式)内含的RecordReader把资料读入成一组(key,value)对,然后按mappercount平均分给不同的Mapper处理。(这段因为没看过源码,还有点模糊)2.Mapper进行Map操作::(InitialKey,IntialValue)》[(InterKey,InterValue)】从Inuptkey,value产生中间数据集。3.Reducer进行Reduce操作::(Interkey,InterValueslterator)->[(InterKey,InterValue)】,Reducer遍历所有节点取得需要的中间数据集,再对其进行去重、过滤等后期处理,得到结果。4.最后由OutputFormat类(输出资料的格式)内含的RecordWriter,将最终结果输出。结果输出可以是文件,也可以是其他形式,比如Nutch的Indexer,output时并不是去写文件,而是调用Lucene的IndexWriter将作为中间数据集的LuceneDocument存盘。说明一点,在整个并行编程模型中是否启用combiner取决于需要处理的事务逻辑的负责程度和数据的规模大小。一般在事务逻辑不是很复杂,数据规模不是很大的情况下,不建议启用combiner。下面我们以实际应用的一个事务处理过程来介绍一下这个并行编程模型。1、定义Mapper,处理输入的Key-Value对,输出中间结果。publi=staticclassMapClassexten如MapReduceBaseimplementsMapper{privatefinalstatioIntWritableone—newIntWritable(1);privateTextword=newText();privateString【】fieldIndice={”logip”,”logtime”,”referer”,”bcookie”,”urlquery”’j//needmoreprivateTreeMapfieldHash皇newTreeMap();privateStringkeyl;publicvoidconfigure(JobConfJob){for(inti=O;ibcookieset=newHashSet()芦while(values.hasNext())(sum++;bcookieset.add(values.next().toString());l//Stringquery=key.toString();output.collect(key,newGBKText(String.valueOf(sum)+"\u0001”+String.valueDf(bcookieset.size())));}}3、定义InputFormat和OutputFormat,可选,InputFormat将每行输入文件的内容转换为Java类供Mapper函数使用,不定义时默认为String。拆进</field></field></field></field></field></field></field></field></field></field></field></field></field></field></field></schema>:‘.~+4、定义main函数,创建JobConf,定义输入输出文件目录,最后把Job提交给JobTracker,等待Job结束。鲫blicstatic如idmain(String【】args)throwsIOException{if(args.1ength<3)鞫tu翻睡荔StringJobnamezargs[0】,Stringinpathstr—args【1】;Stringoutpathstr=args【2】,JobConfconf=newJobConf(PVUVCount.class);conf.setJobName(jobname);conf.setInputFormat(GBKTextInputFormat·class);conf.setOutputFormat(GBKTextOutputFormat·class);//thekeysarewords(strings)conf.setOutputKeyClass(GBKText·class);//thevaluesarecounts(ints)conf.se七Outpu七ValueClass(GBKText.class);conf.setMapOutputValueClass(GBKText·class);conf.setMapOutputKeyClass(GBKText·class);45conf.setMapperClass(MapClass-class)歹//conf.setCombinerClass(Reduce.class);conf.setReducerClass(Reduce.class);Listotherargs=newArrayList();for(inti=3;i;第二组:5台服务器,89G日志文件,3个产品,仅统计;第三组:5台服务器,89G日志文件,3个产品,统计<,pV>;第四组:5台服务器,97G日志文件,4个产品,统计<,pV>;表5-3新旧系统测试比较结果数据表,组名原来ETL方案Hadoop框架方案节约时间16小时34分5小时10分1小时24分钟24小时46分2小时37分2小时9分37小时42分5小时18分2小时24分48小时12分5小时24分2小时48分此外,我们还单独抽取了120M的日志数据文件来单独运行PerlETL和Hadoop的规则关联计算。惊奇的发现Hadoop在这种情况下,性能反而不及PerlETL。那么,从以上对比测试数据中,排除网络偶然性稳定影响,我们可以得出这样的结论:在海量日志预处理中引入Hadoop框架,确实性能优于原有的处理模式。当然,Hadoop并不是万用灵丹,这取决于文件的大小和数量,处理的复杂度以及群集机器的数量,当以上三者并不大时,hadoop优势并不明显。5.3本章小结本章将模型设计应用于实际业务当中,用实际数据来求证整个模型框架的实用性和高效性。用实践来验证理论的正确性。在5.1节中分别简单讲述了整个实例部署的硬件环境、软件环境和配置过程中一些重要的信息项。它们的J下确配置,是制约Hadoop框架是否能成功运行的关键:同时它们的合理配置也是制约Hadoop在不同的集群环境中能否达到性能的平衡点的关键。最后在5.2节中,我们通过比较不同试验条件下的试验结果数据,给出了自己的分析结果。6.1结论第6章结论和展望本文主要对分布式系统关键技术进行了研究,并把Hadoop分布式存储和计算模型运用于海量数据处理当中,对Web日志预处理过程进行了重构和优化,而且利用该系统对某企业是网页、音乐和图片3大产品进行了模拟部署测试,通过对规则计算试验结果的分析,表明重组数据处理模型和把Hadoop的分布式框架运用于企业的海量日志数据预处理当中,可以有效提高数据处理的速度和质量,尤其对于大数据集和大集群这种优化的效果更加明显。另外,由于融ATHadoop框架思想,一旦初次部署成功,则在修改业务逻辑和在集群中添加新的资源都变得简单易行。该模型超过了预期的基本目的,实现了我们期待的高级目标。另外研究过程中还与传统的处理模式进行了对比实验,进一步证明了系统模型的实用性。在整个研究和、设计和部署运行过程中得到了以下一些结论:(1)必须充分理解求解问题的定义。对于数据预处理的过程要有清晰的理解,在整个过程中数据的清洗和规则计算必须符合问题的定义,而且应该进行全面合理的选取,数据关联规则不当会导致结果无法理解。在本系统中,对于项目背景和需求细节的理解是系统得到合理结果的关键。(2)MepReduce编程模型很容易被应用,即使对于一个没有并行的分布是系统开发经验的程序员来说也是一样的。对程序员而言,Hadoop系统并行、容错、本地优化和负载平衡的细节都是透明的。由于部署实际Hadoop应用时涉及的配置参数较多,必须谨慎处理这些参数,不同的参数配置得到的性能结果不尽相同。需要我们多次尝试,小心求证才能确定。(3)本系统对于大数据集运行的结果精度比小数据集要好,对于逻辑规则较复杂的结果精度比简单逻辑规则要好,充分体现了该模型对于复杂数据的强大处理能力。但是数据集过大,处理逻辑规则过于复杂,系统运行的速度势必会受到一定的影响。所以该模型的性能必然要受到客观环境的影响,比如集群机器的数量和网口速度等硬件条件都是影响Hadoop集群性能的重要技术指标。(4)本系统采用了模块化的设计方法,采用面向对象的Java语言进行设计,在MapReduce编程模式下,很容易对不同的问题定义进行表述、修改和实验,体现了Java语言和的MapReduce编程模式强大。556.2展望本模型成功地借鉴Hadoop分布式框架实现了海量w曲日志进行了数据预处理,取得了较好的结果。同时这套模型可应用的范围还是很大的,可以应用于Web日志数据挖掘、搜索引擎系统中的网页搜索和机器学习等方面,前景广阔。但是由于海量数据的多样、异构、动态变化等特性,模型对于不同结构和高复杂度的数据处数据理能力还不够强,在今后的研究工作中要进一步提高模型对于异构数据的处理能力;另外目前模型还没能对残缺数据进行处理,缺少对于残缺数据进行处理的策略和方法,以后应在这方面加强探索;还有在Map容错机制方面还有待优化,在本模型中我们已经讨论了超时重发策略【l刀的可行性,但是还没有实现到模型当中。当然海量数据的分布式处理是一个涉及面非常广的技术,要设计一套比较好的系统必须掌握比较多的知识,而且要多种技术进行结合,因此以后还应提高对其他分布式存储和计算技术的使用能力,还有很多路要走。参考文献【I】RobertCooley,BamshadMobasher,andJaideepSrivastavaDataPreparationforMining.WorldWideWebBrowsingPatterns【2】SanjayGhemawat,How孤dGobioff,Shun-TakLeung坠曼鱼鲤g!曼毯!曼墨强!星班Proceedingsofthe19thACMSymposiumonOperatingSystemsPrinciples,2003,PP.20-43.【3】http://wild.apache.org/hadoop/FAOlastaccessedby2008-02-15【4】http://www.danga.com/memcached/lastaccessedby2008m2-15【5】http://www.danga.com/mogilefs/lastaccessedby2008-02-15【6】AmazonSimpleDBTM-LimitedBetahttp://www.amazon.com/b?ie=UTF8&node=342335011.1astaccessedby2008-02-15【7】IBMIntroducesReady-t0一UseCloudComputinghttp://www-03.ibm.com/press/us/en/pressrelease/22613.wsslastaccessedby2008-02-15【8】Dcj趾S.Milojicic,VanaKalogeraki,RajahLukose,etc.Peer-to-PeerComputingHPLaboratodesPalo舢t0HP【广2002-57(&1)July3rd,2003【9】9DanielBrookshicr,NavaneethKrishnan,DarrenGovoni,etc.—JXTAPr—otocolsJⅪrA:JavaP2PProgrammingChap.3June2002【10】http://maunet.org./papers/jxtawhitep_a_t跫r._txlf【ll】P.MaymounkovandD.Mazicres..Kademlia:Apcerto-peerinformationSystembasedon—thexor—metricInProceedingsofIPTPS02,Cambridge,UsA,March2002.[12】FayChang,JeffreyDean,SanjayGhen!awat,e缸Bigtable:ADistributedStorageSystem.f..o...r........S....t..r..u....c...t..u...r...e...d.........D......a...t—a—7thUSENIXSymposiumonOperatingSystemsDesignandImplementation(OSDI),2006,PP.205.2l8.【13】B.Callagh锄,B.Pawlowski,EStaubachRFC1813-NFSVersion3ProtocolSpecificationJune1995【14】http://www.openafs.org/last∞cessedby2008-02-15【15】TheAndrewFileSystemhttp://www._mc.edu/general/filesys/afs/afs.html2008-02.15【16】JeffreyDean,sanjayGhemawat.MapRednce:SimplifiedDataProcessingonLarge—Clus—tersCommunicationsoftheACM,v01.51,110.1(2008),PP.107-113.【17】TheHad00pDistributedFileSystem:ArchitectureandDesignhttp://hadoop.apache.org/core/docs/r0.16.0/hdfsdesign.htmllastaccessedby2008-·02··15【18】ChristopherFrost,MikeMammarella,EddieKohlcr,etc.GeneralizedFileSystemDependenciesProc.SOSP’07,2007.【19】MikeBurrowsTheChubbylockserviceforloosely-coupleddistributedsystems7thUSENIXSymposiumonOpcmtingSystemsDesignandImplementation(OSDI),2006.【20】JeffreyDeanExperienceswithMapReduce,anabstractionforlarge-scalecomputationProc.15thInternationalConference011ParallelArchitecturesandCompilationTechniques,2006,PP.1.【21】JeffreyDean,SanjayGhemawat.DistributedProgrammingwithMapReduceBeautifulCode,2007,Chapter23.【22】孙广中肖锋熊曦,{MapReduce模型的调度及容错机制研究》,微电子学与计算机,2007,57第24卷第9期58附录索引函数的配置9</reducenum>/dataATM/search</inpath>/dataATM/seareh/totalPVUVCount</outpath></job>5</reducenum>/dataATM/musie</inpath>/dataATM/musie/totalPVUVCount</outpath></job>6</reducenum>/dataATM/image</inpath>/dataATM/image/totalPVUVCount</outpath></job>//querypvuvoutput.collect(neWGBKText(”0#"+fields[queryindex].trimO),newText(fields[beookieindex]));//querysourcepvuvoutput.collect(newGBKText(”l妒’+fields[queryindex].trim0+”\u0001”+fields[soureeindex]).newText(fields[bcookieindex]));//queryridoutput.collect(newGBKText(”2群”+fields[queryindex].trim()+’~000l”+fields[fidindex]),newText(fields[beookieindex]));//querylpoutput.collect(newGBKText(”3撑”+fields[queryindex].trim0+”\u0001”+fields[1pindex]),newText(fields[bcookieindex]));//queryrefoutput.collect(newGBKText(”4#"+fields[queryindex].trim()+’.\u0001‘'+fields[refindex]),newText(fields[beookieindex]));//querypidoutput.collect(newGBKText(”5#"+fields[queryindex].trim()+’.\u0001”+fields[pidindex]),newText(fields[beookieindex]));//sourcepvuvoutput.collect(newGBKText(”6妒'+fields[soureeindex].trim()),Text(fields[bcookieindex]));//sourcequeryoutput.collect(newGBKText(”7撑”+fields[sourceindex].trim()+”\u0001”+fields[queryindex]),Text(fields[bcookieindex]));new//referrerpvuvoutput.collect(newGBKText(”8稃”+fields[refindex].trimO),newText(fields[bcookieindex]));致谢首先诚挚的感谢我的导师胡正名教授两年多来对我的言传身教使我感受颇深,胡老师对学问的严谨和热爱更是我辈学习的典范。同时感谢我的指导教授钮心忻教授及杨义先教授,两位老师总能在我迷惘时为我解惑,不厌其烦的指出我研究中的缺失和工作上的错误,他们悉心的教导和不时的讨论并指点我正确的方向,使我在这些年中获益匪浅。这种亦师亦友的帮助和支持我铭感在心,这种情感也是支持我研究生生涯一路走来的精神力量。另外,本论文的完成亦得感谢我的负责老师辛阳博士给我创造的研究机会和我的项目经理姜蕾、主管张茂森的大力协助。因为有他们的信任和支持,使得我的研究能顺利进行,从而使本论文能够更完整而严谨。两年多的研究生生活中,少不了朋友们的欢歌笑语,学术上的讨论、言不及义的闲扯、让人又爱又怕的宵夜、赶作业的革命情感、因为睡太晚而一起睡过,因为他们的鼓励和关心让两年多的研究生活变得绚丽多彩!男朋友黄玮在背后的默默支持和陪伴使得我每天都在进步。如果没有他,相信这两年多的生活将是很不一样的光景。所以,再次感谢大家。最后,谨以此文献给我挚爱的双亲161攻读硕士学位期间发表的学术论文目录[1】朱珠基于smarty架构的数据监控系统的设计与实现中国科技论文在线收录http://www.paper.edu.cn/paper.php?serialnumber=200706-702007.6.05.62基于Hadoop的海量数据处理模型研究和应用 作者: 朱珠 学位授予单位: 北京邮电大学 相似文献(2条) 1.学位论文 田艳霞 基于DCOM的分布式网络地理信息系统的设计及其在客户端的实现 2003 基于DCOM的分布式WebGIS,是由一组分布式服务器协同为Internet客户提供地理信息服务的网络地理信息系统.空间数据存储在多个站点上,服务器分 析客户端的请求后,确定用户请求的数据的位置,然后获取相应的数据返回给客户端.分布式网络地理信息系统扩大了传统网络地理信息系统的数据访问能 力和系统服务器的规模,所以在系统的数据处理能力和与用户的交互性方面有明显的改善,系统的功能也得到增强.组件技术可以被封装成能实现与具体任 务最紧密相关的功能模块,方便地进行组装和嵌入,有效地支持GIS在网络上的应用和二次开发.利用组件技术的分布式WebGIS是GIS的一大发展趋势,该文 基于DCOM技术,实现了一个分布式的WebGIS系统. 2.学位论文 杨卫东 iEAI服务器的设计及实现 2004 现代软件的开发过程中,体系结构设计越来越得到重视。软件体系结构不仅指导软件开发的各个过程,也能作用于开发后的软件生命周期阶段,尤 其是降低软件维护与演化的高难度与高成本。本文主要针对长春理想科技有限公司iEAI服务器系统,提出了基于iEAI内核的iEAI服务器体系结构设计方 案。 本文首先分析了iEAI服务器的功能需求。分析了客户端与服务器间的远程通信方式。分析了远程通信中涉及的数据处理功能,包括数据的编码解码 、数据的安全以及通信时的通信负载处理。接着根据功能划分,本文分析了iEAI服务器的其他部分功能服务。在分析过程中,本文采用UML对需求进行了 分析和建模。 分析了iEAI服务器需求后,本文介绍了四个重要的系统体系结构模式Layer、MVC、Broker和MicroKernel,分别介绍了它们的实现特点,分析了它们 的优点。接着,根据iEAI服务器的特点,参考了四个体系结构模式的设计思路,本文提出了iEAI服务器的体系结构设计方案,即基于iEAI内核的iEAI服 务器体系结构设计方案。 该方案将iEAI服务器分解为iEAI内核、系统通信服务、分布式服务器集群管理、消息服务、安全服务、存储服务、工作流引擎、Web服务、日志服务 等若干组件,每个服务组件都有自己的对外接口。 在通常情况下,组件与组件之间的通信都是通过函数调用的方式进行。在本文的体系结构设计方案中,组件与组件之间的通信不是采用直接的函数 调用方式,而是采用基于iEAI内核的服务/响应协调方式。在服务器启动之初,服务器上的所有组件均须在iEAI内核中注册。一个组件需要另一个组件提 供服务时,它将需要的服务打成Request请求包交给iEAI内核,再由iEAI内核转发给相应的服务组件。服务组件接收到Request请求后,执行相应的服务 ,生成Response响应包发给iEAI内核,再由iEAI内核将响应包转发给服务请求的发出者。与函数调用这种组件间通信方式不同的是,本文采用的组件间 通信方式松散了服务器组件间的耦合度,提高了系统的可维护性和组件的可重用性。由于每个组件在提交服务请求时并不需要知道提供服务的组件的位 置,它只需要知道iEAI内核的存在,因此,这种组件间通信方式也实现了组件间的位置无关性,使得更易于搭建分布式运行环境。 iEAI内核除了协调组件间的通信外,它还负责iEAI服务器的启动、初始化、停止等,负责管理服务器中的各服务组件,包括各组件的装载、启动、 初始化、停止等。当需要为iEAI服务器增加或者裁减某个功能服务时,只需修改iEAI内核少量代码即可完成对组件的加载和卸载,这种修改不会影响到 被加载和被卸载的组件以及其他服务组件。因此,这种体系结构也在一定程度上提高了iEAI服务器的可伸缩性。 在介绍了iEAI服务器的体系结构设计后,本文接着给出了iEAI服务器部分组件的设计和实现。 最后,本文给出了需要进一步完善的工作,包括设计更高效的编码解码算法和研究组件的动态替换和升级。 本文链接:http://d.g.wanfangdata.com.cn/Thesis_Y1317202.aspx 授权使用:东南大学图书馆(wfdndx),授权号:627fb47c-d7dc-4a64-a9d6-9e1b01309792 下载时间:2010年10月26日
还剩67页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 20 金币 [ 分享pdf获得金币 ] 3 人已下载

下载pdf