hadoop应用案例.docx
《hadoop应用案例.docx》由会员分享，可在线阅读，更多相关《hadoop应用案例.docx（23页珍藏版）》请在冰豆网上搜索。
hadoop应用案例
Hadoop是GoogleMapReduce的一个Java实现。
MapReduce是一种简化的分布式编程模式，让程序自动分布到一个由普通机器组成的超大集群上并发执行。
就如同java程序员可以不考虑内存泄露一样，MapReduce的run-time系统会解决输入数据的分布细节，跨越机器集群的程序执行调度，处理机器的失效，并且管理机器之间的通讯请求。
这样的模式允许程序员可以不需要有什么并发处理或者分布式系统的经验，就可以处理超大的分布式系统得资源。
一、概论
作为Hadoop程序员，他要做的事情就是：
1、定义Mapper，处理输入的Key-Value对，输出中间结果。
2、定义Reducer，可选，对中间结果进行规约，输出最终结果。
3、定义InputFormat和OutputFormat，可选，InputFormat将每行输入文件的内容转换为Java类供Mapper函数使用，不定义时默认为String。
4、定义main函数，在里面定义一个Job并运行它。
然后的事情就交给系统了。
1.基本概念：
Hadoop的HDFS实现了google的GFS文件系统，NameNode作为文件系统的负责调度运行在master，DataNode运行在每个机器上。
同时Hadoop实现了Google的MapReduce，JobTracker作为MapReduce的总调度运行在master，TaskTracker则运行在每个机器上执行Task。
2.main（）函数，创建JobConf，定义Mapper，Reducer，Input/OutputFormat和输入输出文件目录，最后把Job提交給JobTracker，等待Job结束。
3.JobTracker，创建一个InputFormat的实例，调用它的getSplits（）方法，把输入目录的文件拆分成FileSplist作为Mappertask的输入，生成Mappertask加入Queue。
4.TaskTracker向JobTracker索求下一个Map/Reduce。
MapperTask先从InputFormat创建RecordReader，循环读入FileSplits的内容生成Key与Value，传给Mapper函数，处理完后中间结果写成SequenceFile.
ReducerTask从运行Mapper的TaskTracker的Jetty上使用http协议获取所需的中间内容（33%），Sort/Merge后（66%），执行Reducer函数，最后按照OutputFormat写入结果目录。
TaskTracker每10秒向JobTracker报告一次运行情况，每完成一个Task10秒后，就会向JobTracker索求下一个Task。
Nutch项目的全部数据处理都构建在Hadoop之上，详见ScalableComputingwithHadoop。
二、程序员编写的代码
（可以查看hadoop-examples-0.20.203.0.jar,里面也有一个类grep）
我们做一个简单的分布式的Grep，简单对输入文件进行逐行的正则匹配，如果符合就将该行打印到输出文件。
因为是简单的全部输出，所以我们只要写Mapper函数，不用写Reducer函数，也不用定义Input/OutputFormat。
[java]
1.packagedemo.hadoop
2.publicclassHadoopGrep{
3.publicstaticclassRegMapperextendsMapReduceBaseimplementsMapper{
4.privatePatternpattern;
5.publicvoidconfigure（JobConfjob）{
6.pattern=Ppile（job.get（"mapred.mapper.regex"））;
7.}
8.publicvoidmap（WritableComparablekey,Writablevalue,OutputCollectoroutput,Reporterreporter）
9.throwsIOException{
10.Stringtext=（（Text）value）.toString（）;
11.Matchermatcher=pattern.matcher（text）;
12.if（matcher.find（））{
13.output.collect（key,value）;
14.}
15.}
16.}
17.
18.privateHadoopGrep（）{
19.}//singleton
20.
21.publicstaticvoidmain（String[]args）throwsException{
22.JobConfgrepJob=newJobConf（HadoopGrep.class）;
23.grepJob.setJobName（"grep-search"）;
24.grepJob.set（"mapred.mapper.regex",args[2]）;
25.
26.grepJob.setInputPath（newPath（args[0]））;
27.grepJob.setOutputPath（newPath（args[1]））;
28.grepJob.setMapperClass（RegMapper.class）;
29.grepJob.setReducerClass（IdentityReducer.class）;
30.JobClient.runJob（grepJob）;
31.}
32.}
RegMapper类的configure（）函数接受由main函数传入的查找字符串，map（）函数进行正则匹配，key是行数，value是文件行的内容，符合的文件行放入中间结果。
main（）函数定义由命令行参数传入的输入输出目录和匹配字符串，Mapper函数为RegMapper类，Reduce函数是什么都不做，直接把中间结果输出到最终结果的的IdentityReducer类，运行Job。
整个代码非常简单，丝毫没有分布式编程的任何细节。
本篇文章来源于Linux公社网站（）原文链接：
Hadoop实例：
二度人脉与好友推荐
2013-01-0502:
37intergretintergret的博客我要评论（0）字号：
T|T
在新浪微博、人人网等社交网站上，为了使用户在网络上认识更多的朋友，社交网站往往提供类似“你可能感兴趣的人”、“间接关注推荐”等好友推荐的功能。
一直很好奇这个功能是怎么实现的。
AD：
2013云计算架构师峰会课程资料下载
在新浪微博、人人网等社交网站上，为了使用户在网络上认识更多的朋友，社交网站往往提供类似“你可能感兴趣的人”、“间接关注推荐”等好友推荐的功能。
一直很好奇这个功能是怎么实现的。
其实，社交网站上的各个用户以及用户之间的相互关注可以抽象为一个图。
以下图为例：
顶点A、B、C到I分别是社交网站的用户，两顶点之间的边表示两顶点代表的用户之间相互关注。
那么如何根据用户之间相互关注所构成的图，来向每个用户推荐好友呢？
可能大家都听说过六度人脉的说法，所谓六度人脉是指：
地球上所有的人都可以通过五层以内的熟人链和任何其他人联系起来。
通俗地讲：
“你和任何一个陌生人之间所间隔的人不会超过六个，也就是说，最多通过六个人你就能够认识任何一个陌生人。
”这个理论在社交网络中同样成立。
现在我们以上图为例，介绍下如何利用用户之间相互关注所构成的图，来向每个用户推荐好友。
首先我们不得不假设的是如果两用户之间相互关注，那么我们认为他们认识或者说是现实中的好友，至少应该认识。
假设我们现在需要向用户I推荐好友，我们发现用户I的好友有H、G、C。
其中H的好友还有A，G的好友还有F，C的好友还有B、F。
那么用户I、H、G、C、A、B、F极有可能是同一个圈子里的人。
我们应该把用户A、B、F推荐给用户I认识。
进一步的想，用户F跟两位I的好友C、G是好友，而用户A、B都分别只跟一位I的好友是好友，那么相对于A、B来说，F当然更应该推荐给用户I认识。
可能你会发现，在上面的分析中，我们使用了用户I的二度人脉作为他的推荐好友，而且我们对用户I的每个二度人脉进行了投票处理，选举出最优推荐。
其实，我觉得，二度人脉的结果只能看看某个用户的在社交网站上的人际关系链，而基于投票选举产生的二度人脉才是好友推荐功能中所需要的好友。
另外你也可能已经认识到所谓的N度人脉，其实就是图算法里面的宽度优先搜索。
宽度优先搜索的主要思想是FromCenterToOuter，我们以用户I为起点，在相互关注所构成的图上往外不退回地走N步所能到的顶点，就是用户I的N度好友。
下面是Python写的N度人脉的算法，可以输出某个用户的N度好友,代码详见这里。
下面几点是其与宽度优先搜索的不同之处：
1.宽度优先搜索搜索的是起始顶点可达的所有顶点，N度人脉不需要，它只需要向外走N步，走到N步的顶点处便停止，不需要再往外走了。
2.走过N步之后，结果中包含起始顶点往外走1、2……N-1步所能到达的所有顶点，返回结果之前需将这些点删除。
3.变量pathLenFromStart记录这N步具体的走法。
上诉的算法看似可行，其实在实际中并不适用。
社交网站上的用户量至少是千万级别的，不可能把所有用户之间相互关注的关系图放进内存中，这个时候就可以依赖Hadoop了。
下面的实例中，我们的输入是deg2friend.txt，保存用户之间相互关注的信息。
每行有两个用户ID，以逗号分割，表示这两个用户之间相互关注即认识。
二度好友的计算需要两轮的MapReduce。
第一轮MapReduce的Map中，如果输入是“H，I”，我们的输出是key=H，value=“H，I”跟key=I，value=“H，I”两条结果。
前者表示I可以通过H去发现他的二度好友，后者表示H可以通过I去发现他的二度好友。
根据第一轮MapReduce的Map，第一轮MapReduce的Reduce的输入是例如key=I，value={“H，I”、“C，I”、“G，I”}。
其实Reduce的输入是所有与Key代表的结点相互关注的人。
如果H、C、G是与I相互关注的好友，那么H、C、G就可能是二度好友的关系，如果他们之间不是相互关注的。
对应最上面的图，H与C是二度好友，G与C是二度好友，但G与H不是二度好友，因为他们是相互关注的。
第一轮MapReduce的Reduce的处理就是把相互关注的好友对标记为一度好友（“deg1friend”）并输出，把有可能是二度好友的好友对标记为二度好友（“deg2friend”）并输出。
第二轮MapReduce则需要根据第一轮MapReduce的输出，即每个好友对之间是否是一度好友（“deg1friend”），是否有可能是二度好友（“deg2friend”）的关系，确认他们之间是不是真正的二度好友关系。
如果他们有deg1friend的标签，那么不可能是二度好友的关系；如果有deg2friend的标签、没有deg1friend的标签，那么他们就是二度好友的关系。
另外，特别可以利用的是，某好友对deg2friend标签的个数就是他们成为二度好友的支持数，即他们之间可以通过多少个都相互关注的好友认识。
两轮MapReduce的代码，详见这里。
根据上述两轮的MapReduce的方法，我以部分微博的数据进行了测试，测试的部分结果如下：
通过与我（@Intergret）相互关注的138位好友，两轮的MapReduce向我推荐的二度好友前三位是：
2010963993（@可乐要改变），2022127621（@琥珀露珠）和2572979357（@赵鸿泽），他们都是我本科的同学，有很多共同的好友，但我跟他们三目前尚未相互关注，所以推荐结果还算靠谱。
大数据案例分析：
电信业Hadoop应用分析
2012-09-0510:
21佚名中关村在线字号：
T|T
联通采用了Hadoop、HBase，这里面还有用户管理员信息等等。
目前，在客服使用当中感觉也是非常非常好的，更重要的是利用这个系统可以做深入的数据挖掘工作。
AD：
2013云计算架构师峰会课程资料下载
随着国内3G网络的发展，或者移动通信网络的发展，中国联通（600050，股吧）目前运营着世界上最大的CDMA网络，流量运营是中国联通一个重要特点。
中国联通3G套餐当中流量占比非常非常大，中国联通3G用户流量使用情况也是非常可观的。
而目前中国联通遇到一个世纪问题：
随着流量的增长，3G流量的争议也迅速的增加。
现在3G业务在流量方面的投诉达到了投诉的7-10%，并且最近这半年还在成迅猛的上升趋势，各个省份已经达到了20%。
投诉来源于哪儿呢？
一些用户，特别是一些移动智能手机用户，联通研究院处长王志军以自己为例说明。
如我的安卓手机，前一阵子谷歌安卓4.0出来之后发布了新的版本，我的手机在某一天下午某一个时刻进行了自动更新，基本有200兆大小的流量的产生。
如果是普通的3G用户，中国联通资费0.3元/兆，当套餐用光了之后，这次更新可能花费60元，这种更新是在不自觉情况下发生的，用户毫不知情。
所以，最终致使用户到中国联通进行投诉：
用户认为自己没有使用这个流量，向联通要证据。
目前，电信计费系统流量话单在GGSN设备上产生，是网关设备。
这个设备产生流量话单的时候是根据一个流量依据而产生：
第一，达到一定时间，例如2个小时。
第二，达到一定流量大小，比如5兆。
这个流量话单相当于一段时间之内使用流量总合的话单，没有说访问哪个目标的IP地质，没有访问的目的地，只告诉你这个时刻产生了这样的话单，用户当然不愿意，用户说我那天没有使用过手机，没有产生这个流量，这样情况下用户要求退费，或者双倍赔偿，GSN设备，无论是中国联通也好，还是其他运营商也好，采用设备可能来子华为、阿尔卡特，这些设备在全球商用了，GGSN产生的话单在一定意义上之上，出现这种问题是微乎其微的，说不清流量到哪儿去了，运营商作为弱势群体，只能退费或者双倍赔偿。
运营商的难言之隐
联通研究院处长王志军以一个案例进行说明，2011年，中国联通一个用户在0点到4点之间产生巨额流量费用，他认为中国联通既然拿不出证据，以涉嫌欺诈消费者为由向法院提起了诉讼，影响是两方面的。
对用户而言，他也是想知道流量到底什么时候发生的，如果手机的问题，他也知道怎么进行防范，这样就不会发生类似问题，根据客户部门提供的数据，可能因为无法提供商网流量详单造成退费和赔付，会影响到运营商流量计费商务模式，所以我们建立这种系统意义非常大，第一，我们的系统供联通客服人员使用，提供快速查询服务，解决流量投诉的问题，另外，我们也准备向最终用户提供异常的大流量查询服务。
再一个问题，上网记录数据本身是数据的金矿，我们可以通过获取上网数据记录对流量进行统计。
海量数据的应对之策
对于以上这些问题该如何应对呢？
联通研究院处长王志军分析处理问题的难点：
上网记录数据是海量数据，经过我们的系统可以分析到，用户每个用上网记录基本几万到几十万，有的用户五六十万，我们现在采用的方案是在网关所有用户流量必经地方采集，分析流量数据，然后上成上网记录话单，话单量非常大。
联通研究院处长王志军表示，例如用移动手机访问新浪网首页，对流量采集设备基本能生成20条左右上网记录话单，如果点iPad新闻链接，恐怕会产生180条上网记录，如果访问淘宝网首页，会产生60条请求和回应，在手机上网记录当中有大量DNS查询和推送服务。
以中国联通某一个中等省份公司为例，日均上网记录达到10亿条，每个月的数据接近9T，整个移动互联网也在快速发展。
根据中国联通统计，每隔6个月中国联通用户整体上网流量会翻一番，去年平均3G每用户的流量一年之内翻一番，整个流量增长非常迅速，也带来了上网记录的量非常非常大。
传统IOE方式，IBM小型机，思科数据库存储，EMC存储，思科数据库存储这么大上网记录时候已经不可能了，所以，联想采用开源的Hadoop解决，Hadoop本身是系统架构，也是开源项目，由Apache基金会开发，Hadoop本身最底层是分布式文件系统，这个分布式文件系统叫HDFL，在它之上有分布式处理框架，基于Hadoop整个开源项目，上面构建了结构化的访问数据库，在这之上又提供了类似的数据挖掘工具，另外也提供了一些分布式同步，以及远程调用和序列化工具。
Hadoop伴随大数据一同火爆起来。
现如今，Hadoop已经无人不知无人不晓。
Hadoop从它一诞生的那天开始就与大数据深深地关联到了一起。
众所周知，大数据多是出现在这些领域，包括金融、电信、保险以及一些大型互联网企业等。
以电信行业为例，Hadoop在这些领域的应用情况是怎么样的呢？
Hadoop+HBase+MapReduce
对于Hadoop分布式文件系统本身来说，重要的出发点在于硬件故障是常态，不是非异常的状态，我们可以摒弃采用IBM小型机方案，Hadoop中数据可以自动复制，一份数据可以复制成三份，第一份在一台服务器上，第二份数据在另外一台机架的另外一台服务器上，第三份数据可能在另外一台机架的另外一台服务器上，作为分布式文件系统，每次请求写入的磁盘和服务器物理地点可能不一样，可以带来高并发的读写请求。
MapReduce框架分成很多数据级，最后再合并处理。
HBase分布式数据库是分布式存储系统，主要特点在正它是四维存储系统，传统的数据库是二维表的结构，有行、有列，对它来说，除了有行之外，有列的概念，在列和行之间又可以存放多个版本，在这种情况下相当于四维表结构，好处在于可以灵活的表格结构，每个列组里面的列后来都可以随机应变，我们的采集系统现在在采集一些字段，未来的发展过程中，为了数据挖掘的需要，会采集更多的字段，方便我们在一个结构之下进行更多信息的存储以及后续的处理工作。
HBase本身利用自动复制机制保证Hbase本身存储的高可靠性。
我们会做一些数据挖掘工作，除了采用MapReduce技术之外，还采用数据仓库技术，针对海量数据进行高性能查询和分析工作。
中国联通已经构建了一个全国集中的一级架构海量数据存储和查询系统，第一，是一级架构，全国所有用户所有上网记录数据都放北京数据中心里，在国内电信行业当中也是首创的方式。
另外一个方式，首先将开源Hadoop、Hbase技术应用商用电信服务系统中来，开源的软件架构基本上没有商用系统的，但是这次是商用系统，系统的构成，包括数据采集、数据入库、数据存储、数据查询和数据分析技术，基本技术采用Hadoop，目前上网记录数据存储一般不小于30分钟，30分钟之前的上网记录现在可以通过我们系统查询到。
在实际使用过程中，联通发现约10分钟的记录可以查到，用HBase处理这么海量的数据时候，入库速度非常非常迅速，另外查询速度也非常非常迅速。
另外系统的存储不少于6个月原始上网记录能力，中间的统计报表会保存不少于5年，现在的数据查询速度，查询一个用户上网记录，比如有几万条记录，在几千亿条记录当中检索的时间小于一秒钟，当然，这个时间不包括查询页面的时间。
这是上网记录详单内容，存储了很多用户上网记录信息，随着系统的发展，为了数据挖掘的需要，联通会进一步提取更多信息存到上网记录系统当中来。
Hadoop三节点控制数据
整个系统部署情况是这样的，我们采用普通PC服务器部署这个系统，Hadoop本身有三个节点，一个是数据存储节点，现在有178个数据存储节点，每个数据存储节点有14T的容量，集群的监控节点有一台，入库服务节点24台，Web查询应用服务节点20台，在同一个机架上的数据交换采用千兆交换机。
这是查询系统的界面，用户详细信息都可以通过这个系统查询出来。
在目前情况下，现在已经部署完成了4个省份，北京、黑龙江、浙江、重庆，四个省份所有用户上网记录都可以上来，每天入库条数超过42亿条用户上网数据记录，每天入库数据量超过1.2T，在这种数据量的情况下，现在已经保存了几个月的上网记录数据，在这种情况下，上网记录数据保存在一张表当中，保存4个省的数据，一个月可能超过1200亿条的数据，在这种情况下，在1200亿条数据当中检索一个用户数据会达到不小于一秒，目前1200亿条只用到15个数据节点，随着178个数据节点上线之后，保存全国31省的数据以及进行快速入库、查询和检索我们认为都没有问题。
现在预估，31省上线之后，每个月用户上网记录超过8千亿条，我们系统明年6月份才可能考虑到下一期扩容工程，在这种情况下，我们相信每个月会有1万亿条数据，保存6个月用户数据，原始数据量会超过6万亿条，目前每条上网记录基本上在300个字节，随着我们把更多的字段加入进来之后，可能平均每条用户上网记录的长度还会增加，可能达到400字节，对整个集群的要求会更高。
联通研究院处长王志军表示，联通第一次采用了开源技术，在此之前，在电信行业当中比较少见。
联通采用了Hadoop、HBase，这里面还有用户管理员信息等等。
目前，在客服使用当中感觉也是非常非常好的，更重要的是利用这个系统可以做深入的数据挖掘工作。
中国联通在查询用户上网记录之前会征得用户的同意，有可能通过口服开头同意，如果客服后台查询的话，我们可能会通知用户有人要查询其上网记录，在安全方面联通做了考虑。
3.3 Hadoop在XX的应用
2011-10-2020:
40陆嘉恒机械工业出版社我要评论（0）字号：
T|T
《Hadoop实战》第3章Hadoop应用案例分析，本章主要介绍了Hadoop的具体使用案例，我们选取了Yahoo!
、XX、Facebook、eBay和海量数据排序为例进行说明，主要介绍了商业公司如何使用Hadoop来增强自己的服务，以及它们在使用Hadoop中遇到的各种问题和改进的方法。
本节为大家介绍Hadoop在XX的应用。
AD：
2013云计算架构师峰会课程资料下载
3.3 Hadoop在XX的应用
XX作为全球最大的中文搜索引擎公司，提供基于搜索引擎的各种产品，包括以网络搜索为主的功能性搜索；以贴吧为主的社区搜索；针对区域、行业的垂直搜索、MP3音乐搜索，以及百科等，几乎覆盖了中文网络世界中所有的搜索需求。
XX对海量数据处理的要求是比较高的，要在线下对数据进行分析，还要在规定的时间内处理完并反馈到平台上。
XX在互联网领域的平台需求如图3-3所示，这里就需要通过性能较好的云平台进行处理了，Hadoop就是很好的选择。
在XX，Hadoop主要应用于以下几个方面：
日志的存储和统计；
网页数据的分析和挖掘；
商业分析，如用户的行为和广告关注度等；
在线数据的反馈，及时得到在线广告的点击情况；
用户网页的聚类，分析用户的推荐度及用户之间的关联度。
MapReduce主要是一种思想，不能解决所有领域内与计算有关的问题，XX的研究人员认为比较好的模型应该如图3-4所示，HDFS实现共享存储，一些计算使用MapReduce解决，一些计算使用MPI解决，而还有一些计算需要通过两者来共同处理。
因为MapReduce适合处理数据很大且适合划分的数据，所以在处理这
升级会员 