作者：周维
出版社：清华大学出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Hadoop 2.0-YARN核心技术实践试读：
前言
随着计算机、互联网技术的发展，很多以前只能在单机上运行的程序现在越来越呈现出分布化、网络化的特点，近几年来，云计算、大数据更成为炙手可热的社会关注重心。在当前信息爆炸的时代，每天都在产生大量的信息数据，而如何高效地对这些信息进行处理成为计算机研发人员必须面对的挑战。虽然陆续提出过并行计算、网格计算等方案，但是在面临大规模，高效应用需求时都不是很理想。Hadoop的诞生，很好地契合了当前全球计算机技术发展的潮流，由于其稳定性、可扩展性、开源性，Hadoop成为国内外公司在云计算时代的首选支撑平台。
作者从事分布式教学与研究十余年，在同国内外顶尖公司的交流中，我们发现Hadoop很适合作为一个分布式课程教学实践与研究平台，因为Hadoop既包含了独立组件的运行，也包含了分布化的不同组件之间的通信，还包含了分布式系统的架构设计等，Hadoop事实上成为一个集大成的分布式系统。最为难能可贵的是，Hadoop是完全开源的系统，这使得我们有机会深入其中进行分析、研究。因此，近年来，作者逐步在分布式教学与研究中引入Hadoop系统，取得了明显的效果。在对Hadoop进行分析调研的基础上，我们认识到当前Hadoop书籍还存在一些不满意的地方，例如：①由于Hadoop 2.0-YARN在2013年11月才发布稳定版，因此，对YARN的公开研究资料还不多，目前可查询到的YARN中文版书籍还比较少，这些书籍虽然也不错，但是更适合一个Hadoop从业人员作为技术手册，对于广大普通读者来说，入门门槛过高，而且看过后基本还是不会编写YARN程序。②虽然网络上也有不少这方面的资料，但是由于网络写作的随意性，资料很零散且存在很多错误，因此让初学者和普通开发人员很难快速入手。
基于此，作者着手编著一本针对Hadoop 2.0-YARN的书籍。本书在写作过程中注重实践教学，因此配备有很多实际例程，这样读者可以边看书、边安装、边调试，因此降低学习难度，加快学习进度，同时，本书对YARN中的一些核心内容的剖析也很有价值，如①出租车Storm on YARN实时处理实例；②YARN状态机信息捕捉；③YARN调度模拟器——SLS分析，并与Google第三代调度器Omega进行对比分析。这些资料都既有文字说明，又有实际代码。基于我们长期的实践，有些内容是首次披露，网络上也没有的，所以对读者会有很大的吸引力。本书在写作工程中，也力求和公司的工程项目结合起来，因此，部分案例直接选自BAT中的工程实例，这使得本书更具有实战性。
作为广大的本科和研究生同学，可以参照本书实例进行研究或修改，为他们进行分布式、云计算平台学习，专业课项目设计或毕业论文提供参考。本书也可作为业界研发人员的工程实践提供参考。
本书第1~6章由周维老师主要负责编写，第7章由薛岗老师主要负责编写。另外来自阿里的杨辉先生，袁硕同学，以及在百度实习过的刘笠熙同学、周可人同学都提出了宝贵意见并设计了部分案例。此外，还要特别感谢很多参与代码调试的研究生同学，这其中包括麦超、刘建坤、刘长春、范航凯、傅央、张浩、向文坤、魏征、孙淋川、罗洁等。没有大家的帮助，这本书也不可能这么快写完，在此对所有支持本书编著的人表示衷心的感谢。
由于时间仓促，本书难免存在不妥之处，请读者批评指正。编者2015年4月第1章YARN的前世今生1.1 Hadoop基本情况回顾
当Doug Cuting决定发起Hadoop项目的时候，他肯定没有想到，不到十年的时间里，Hadoop会成为一股席卷全球的铺天盖地的洪流。由于Hadoop的稳定性、可扩展性，最主要是其开源性，如今，它已成为众多公司，如Yahoo、Twitter、FaceBook、IBM，还有国内的百度、腾讯、阿里等的业务平台。在当今移动互联网、云计算的大背景下，Hadoop似乎成为不可或缺的一部分。那么为什么Hadoop会受到如此重视，首先让我们从Hadoop的起源讲起。
随着人类社会信息技术的进步，特别是互联网的发展，每天都在产生大量的信息数据。然而如何高效地对这些信息进行处理一直困扰着计算机研发人员。虽然已经提出了并行计算、分布式计算、网格计算等方案，但是效果都不是很理想。这种情况对那些站在科技发展尖端的企业，如Google，表现得特别明显。作为全球最大的搜索引擎企业，Google公司需要对全球的海量网页进行及时的处理，然而当时（2000年）的技术手段却显得有点力不从心。因此，这种业务需求促使Google的工程师设想开发一种全新的系统。2003、2004年，Google相继发表了两篇文章论述了他们为应对海量数据而开发的两项新技术GFS和MapReduce，这在当时引起了广泛热议，使得许多正为数据急剧膨胀而头痛不已的企业看到了希望。与此同时，作为开源项目Nutch（Web搜索引擎）的创始人，Doug Cutting正在为Nutch架构无法扩展到支撑拥有数十亿网页的网络感到头疼。他敏锐地意识到，他和他的团队可以利用GFS和MapReduce的原理来开发一个新的框架，可以极大地提高Nutch的承载能力。2006年2月，他们从Nutch转移出来成为一个独立的Lucene子项目，被正式命名为Hadoop。在Yahoo的大力支持下，Hadoop项目日益活跃并受到广泛关注。2008年1月，Hadoop成为Apache下的顶级项目。在2008年2月，雅虎宣布其搜索引擎产品部署在一个拥有1万个节点的Hadoop集群上。随着Hadoop项目取得的巨大成功，Doug Cutting在2010年9月被选为Apache软件基金会（Apache Software Foundation）主席。
Hadoop最初设计的时候是为了搜索引擎业务服务的（如Yahoo、Google等公司）。然而始料不及的是，由于Hadoop的良好特性，Hadoop被应用到了各行各业。那么，Hadoop真的能解决这些业务需求吗？随着Hadoop应用的深入，人们发现Hadoop在一些特定业务领域并不能很好发挥，学术界和工业界都活跃起来，希望通过各种改进来提高Hadoop的性能。因此下一代Hadoop的研发被提上日程，在Hadoop 0.23的版本中，引入了革命性的、全面的更新，这个版本被正式命名为YARN（或MRv2）。
下面我们用一个直观的图来展示Hadoop的发展历程，如图1-1所示。图1-1 Hadoop的发展历程1.2 为什么我们需要YARN
由于Hadoop 1.0的良好特性，Hadoop 1.0被应用到了各行各业。各大著名公司都相继采用，如Facebook、Yahoo、Twitter、百度、腾讯、阿里等。随着Hadoop 1.0应用的日益丰富，原先Hadoop 1.0设计中存在的一些问题显露出来，主要表现在以下几方面。（1）存在单点故障、影响可扩展性、稳定性。
Hadoop 1.0中Namenode和JobTracker设计成单一节点，一旦该节点出现故障，对整个系统有致命性影响。这个节点是整个系统的单点故障源（SPOF），严重制约了整个Hadoop的可扩展性和可靠性。Datanode定期向Namenode发送Block Report，这些数据是占用内存空间的，随着Hadoop集群存储空间的增多，这些Block Report也会越来越多，因此，Namenode的内存容量成为制约Hadoop集群规模的一个重要因素。JobTracker也存在同样的问题，由于随着JobTracker业务的增长，处理的任务也随之增长，从而造成内存消耗过大，同时任务失败的概率也随之增加。（2）计算模式比较单一，只支持MapReduce模式。
Hadoop 1.0中对计算模式的支持比较单一，只支持MapReduce模式。然而，实现业务处理却存在多种需求。例如需要对实时业务进行及时处理，于是产生了Storm，Spark系统；需要对具有工作流性质的业务进行处理，于是产生了Tez项目，能够提供更底层的DAG编程接口；需要基于图业务性质进行处理，于是产生了Giraph图计算项目。这些系统的产生是对MapReduce模式的有效补充，然而，如何将这些系统和Hadoop有效整合起来成为一个亟待解决的问题。（3）Map和Reduce模式绑定太死，不灵活。
在Hadoop 1.0最初设计的时候，Map和Reduce是作为一个整体来提供给用户使用的。然后，并不是每个业务都同时需要这两个操作，有的时候只需要其中之一。然而，现有机制中TaskTracker会把任务分成Map Task Slot和Reduce Task Slot，如果当前节点仅存在Map Task或者Reduce Task，则会造成资源浪费。（4）资源管理方案不灵活。
Hadoop 1.0中采用静态slot资源分配策略，在节点启动前为每个节点配置好slot总数，一旦启动后，就不能动态更改。此外，Hadoop 1.0中将slot分为Map slot和Reduce slot两种，且不允许交换共享。而节点在真实运行情况下往往是Map slot紧张而Reduce slot空闲，或者反之。在任务紧张的时候很大地阻碍了Hadoop的性能。再者，Hadoop默认情况下是按照2GB内存和1个CPU来为每个slot分配资源，如果task使用内存过多（如5G），则很可能把这个节点撑爆。如果task使用内存过小（如1G），又可能造成资源浪费。而且对资源的描述比较单一，只是从CPU和内存数量进行描述，实际上影响任务的资源还有很多，例如带宽、传输速度、存储空间等。
上述几点只是列举了Hadoop 1.0在实际运行过程中存在的一些主要问题，虽然科学家和软件工程人员已经从各方面着手来解决这些问题，但是始终缺乏一个完整的，能够和Hadoop 1.0紧密整合在一起的解决方案，这样说来，大家也就能够理解为什么新一代Hadoop-YARN的研发工作呼之欲出了。1.3 YARN和Hadoop 1.0对比分析
随着Hadoop 1.0应用的日益丰富，原先Hadoop 1.0设计中存在的一些问题显露出来，针对这些问题，Hadoop开发团队的研究与工程技术人员深入讨论，在充分收集各方提出的意见，经过长时间准备和开发后，设计出了YARN，Hadoop 1.0中存在的一些主要问题在YARN中都得到了很好地回应，下面我们来进行对比分析。1.3.1 体系结构对比
图1-2是Hadoop 1.0的体系结构图，在Hadoop 1.0中Namenode和JobTracker设计成单一节点，一旦出现故障，对整个系统有致命性影响。该节点是整个系统的单点故障源（SPOF），严重制约了整个Hadoop的可扩展性和可靠性。随着JobTracker业务的增长，处理的任务也随之增长，从而造成内存消耗过大，同时任务失败的概率也随之增加。举一个直观的例子，假设Hadoop 1.0同时运行有10个job，每个job又有1000个task，假设这些task都运行在不同的机器上，那么，我们有10000个节点（Datanode）在同时运行，如果每个Datanode每隔5分钟定期向JobTracker发送信息，那么JobTracker的工作压力会很大，所以正常情况下Hadoop 1.0的集群管理规模只能达到4000台左右。这也是造成Hadoop 1.0存在单点故障的直接原因，影响了Hadoop 1.0的可扩展性、稳定性。图1-2 Hadoop 1.0的体系结构
JobTracker任务过重是造成Hadoop 1.0单点故障和可扩展性差的主要原因，在Hadoop 1.0中JobTracker主要完成两大任务：资源的管理和作业控制。由于需要对集群中几千台机器的资源进行管理，并对运行在集群上的各种作业进行调度控制，JobTracker显得有些穷于应付。因此，在YARN的设计中，资源的管理和作业控制是被分离开的。如图1-3所示，资源的管理由ResourceManager来处理，而作业控制则由ApplicationMaster来处理。为了便于说明，我们还是举Hadoop 1.0的那个例子来说明。假设YARN同时运行有10个job，每个job又有1000个task，假设这些task都运行在不同的机器上，那么，我们有10000个节点（Datanode）在同时运行，同时每个Datanode每隔5分钟定期发送信息。那么，在YARN中会给每个job分配一个ApplicationMaster来负责管理其下运行的1000个task。这1000个节点只会向对应的ApplicationMaster汇报情况，只有一些精简的汇总信息才会通过这10个ApplicationMaster和ResourceManager通信。因此，对ResourceManager来说，它只会收到10个ApplicationMaster的信息，相对于Hadoop 1.0中JobTracker需要处理10000个节点（Datanode）的信息而言，ResourceManager可以更专注于整个集群的资源管理。需要注意的是，每个job分配的ApplicationMaster可以在同一台机器上，也可以在不同机器上，这样整个集群的作业控制负载相对均衡，不会集中在一个中心点。将作业控制分离出来的结果是ResourceManager的负担减轻，可以专注于整个集群的资源管理。这种体系结构上的变更解决了Hadoop 1.0的单点故障问题，整个集群也可以轻松扩展到上万台机器。图1-3 YARN的体系结构1.3.2 运算框架对比
Hadoop 1.0设计的时候并没有预料到它会应用得如此广泛。Hadoop 1.0中对计算模式的支持比较单一，只支持MapReduce模式。然而，各类公司的业务处理却存在多种需求。例如需要对实时业务进行及时处理，于是产生了Storm、Spark系统；需要对具有工作流性质的业务进行处理，于是产生了Tez项目，能够提供更底层的DAG编程接口；需要基于图业务性质进行处理，于是产生了Giraph图计算项目。这些系统的产生是对MapReduce模式的有效补充，然而，如何将这些系统和Hadoop有效整合起来成为一个亟待解决的问题。
在Hadoop 2.0中，将计算框架MapReduce和HDFS分离开来，用YARN进行集群的资源管理，这样，在YARN上可以运行不同的计算框架，而MapReduce只是其中一个选项。其他的如Storm、Spark、Tez等都可以在YARN上运行，这极大地丰富了YARN的应用场景。
总地来说，YARN还是Master/Slave的架构，不同于Hadoop 1.0的是，在整个资源管理框架中，ResourceManager充当了Master的角色，NodeManeger则充当了Slave的角色。ResourceManager的职责是对多个NodeManager的资源进行统一管理和调度。
如图1-4所示为Hadoop 2.0的框架结构，YARN是这种双层架构中的第二层，这种将资源管理相关的功能与应用程序相关的功能分开的做法，使得Hadoop能够轻易支持多种计算框架。它使得Hadoop不再仅限于支持MapReduce这种单一的计算模型，而是极大地扩充了其生态圈。图1-4 Hadoop 2.0的框架结构1.4 Hadoop生态系统
由于其稳定性、可扩展性，开源性，Hadoop已成为众多公司，如Yahoo、Twitter、FaceBook、IBM，还有国内的百度、腾讯、阿里等的业务平台。从底层到上层，围绕Hadoop衍生出众多的服务商，提供不同种类的技术支持。
图1-5描述了整个Hadoop完善的生态系统。“Hadoop即服务”为基础架构和不同的应用分析场景提供了强大而广泛的支撑；同时，在大规模数据分析和处理上，Hadoop也能直接作为应用平台，通过基础数据库和各种编程语言为其开发相应的应用程序。Hadoop具有很强的灵活性和可扩展性。Hadoop 2.0之后的版本引入了YARN作为其资源管理与调度系统，但也可采用其他的第三方管理平台（如Mesos）作为Hadoop的资源管理与调度系统。图1-5 Hadoop生态系统1.5 小结
总结下来，YARN框架相对于老的Hadoop 1.0框架具有很多优势，具体表现在以下几方面。（1）将Hadoop 1.0中JobTracker的两大任务（资源的管理和作业控制）分离开，分别由YARN中的ResourceManager和ApplicationMaster来进行管理。这样使得YARN能够承载更多的业务，同时稳定性也大大提升。由于JobTracker和Namenode的限制，Hadoop 1.0一般只能管理4000~8000台机器，不能对上万台机器服务进行有效管理。为了突破这个瓶颈，一些顶尖的大业务公司（例如百度等）通过修改Hadoop 1.0，用三个Namenode来代替原来的一个Namenode，这样提升整个Hadoop 1.0的业务承载能力。在YARN中，上述问题通过ResourceManager和ApplicationMaster的分离得到很好的解决，因此YARN对集群的管理能力得到极大提升。（2）支持多计算框架。YARN改变了Hadoop 1.0中只支持MapReduce计算框架的问题，将计算框架和底层存储和调度分离开，不但支持离线的batch MapReduce计算，同时对其他计算框架Storm、Spark、Giraph等都能很好地支持，丰富了应用场景。第2章YARN基本框架2.1 YARN基本框架
在1.2节中，我们列举了Hadoop 1.0设计中存在的主要不足，包括存在单点故障、计算模式比较单一等。这些问题都成为YARN设计中重点需要解决的问题。在Hadoop 2.0-YARN中，将计算框架MapReduce和HDFS分离开来，用YARN进行集群的资源管理，这极大地丰富了YARN的应用场景。
如图2-1所示，YARN上可以运行不同的计算框架，而MapReduce只是其中一个选项。其他的如Storm、Spark、Tez等都可以在YARN上运行。图2-1 YARN框架
YARN作为资源管理、任务调度的一个框架，主要包含三大模块，即ResourceManager（RM）、NodeManager、ApplicationMaster（AM）。这其中，ResourceManager全局负责所有资源的监控、分配和管理；ApplicationMaster负责每一个具体应用程序的调度和协调；NodeManager负责每一个节点的维护。几个模块之间的关系如图2-2所示。图2-2 三个模块间的关系
相对于Hadoop 1.0，YARN最重要的变化是将资源的管理和作业控制分离开（即将Hadoop 1.0中JobTracker两个最重要的功能，即资源管理和作业调度与监控拆分开），分别由全局的ResourceManager负责资源管理、ApplicationMaster负责作业调度和监控。对于所有的applications，RM拥有绝对的控制权和对资源的分配权。而每个AM则会和RM协商资源，同时和NodeManager通信来执行和监控task。2.2 ResourceManager
ResourceManager在Hadoop第二代框架YARN中负责整个集群的资源管理和分配，是一个全局的资源管理系统。它包含多个组件，其中包括ApplicationMasterService、NodeListManager、ContainerAllocatioin等，它们分别负责Application管理、状态机管理等，如图2-3所示。图2-3 ResourceManager框架图
与Hadoop 1.0不同的是ResourceManager仅仅从NodeManager上接收资源汇报，对于具体的资源处理则交给NodeManager自己处理。YARN中NodeManager通过心跳线的方式定期向ResourceManager汇报本机的资源使用状况（目前主要是有关CPU和内存的占用情况），因此，ResourceManager对整个集群资源（CPU、内存等）有一个整体的视图。当有应用程序提交任务请求时，ResourceManager会按照一定的策略分配给应用。ResourceManager中与用户交互的最重要的组件就是调度（Scheduler）和应用程序管理（ApplicationMaster，AM）。
与Hadoop 1.0相比，Yarn Scheduler仅仅根据application的请求为其分配资源。不负责application job的监控、追踪、运行状态反馈，也不负责重新启动等任何与失败有关的工作。因此，Yarn Scheduler里的调度是真正意义上的“调度”，一旦资源分配完成后，将不再参与与Application有关的后续管理工作（如启动、运行、异常处理等）。为了方便用户扩展，YARN调度器被设计成一个可插拔组件，用户可以将自己设计的调度器放在ResourceManager中，这样便于用户根据自身需求做出调整。保证框架的灵活性。
应用程序管理器则负责整个集群中所有的应用程序的提交，与ResourceManager中的调度器协商资源、请求资源，同时监控ApplicationMaster的运行状态。2.3 NodeManager
YARN集群每一台机器都运行一个NodeManager，它相当于管理这个机器的代理，负责本台机器的程序运行，并对本机资源进行管理和监控。每个NodeManager负责定时地向ResourceManager汇报本节点上的资源（CPU、内存）使用情况和Container的运行状态，在紧急情况下，如果ResourceManager出现了宕机，那么NodeManager会立即连接备用RM（由管理员指定的RM备份机）。NodeManager的结构框架图如图2-4所示。图2-4 NodeManager框架图
从上述框架结构图中可以看出，NodeManager相当于是驻留在每个节点上的代理，通过RPC Service与ResourceManager和ApplicationMaster等其他组件进行交互。NodeManager监控本机的资源使用情况（CPU、内存、硬盘、网络）并且向ResourceManager汇报。此外，NodeManager是执行应用程序的容器，当某个application job启动时，在NodeManager中的ContainerManager组件会触发MLauncherEventType.LAUNCH事件，并被ResourceManager中ApplicationMasterLauncher捕获，之后将首先创建一个AMluncher对象，接着AMluncher对象会调用AMLauncher.launch()函数，在AMLauncher.launch()函数内部会调用ContainerManager.startContainer()函数来启动该Container。
NodeManager有一个关键的功能组件是NodeHealthCheckServer（自身节点的健康状况检测），通过该机制每个节点上的NodeManager掌握自己的监控状况，并且及时汇报给ResourceManager。RM根据NM反馈的健康状况，及时地调整分配到每个节点的任务数量，当NM的健康状况为“亚健康”时，反馈状态给RM以后，RM可以不再为其分配任务，待NM再次反馈“健康”状态时再次分配任务。通过这样的方式，减轻集群主节点的管理压力，防止集群宕机等问题。2.4 ApplicationMaster
用户每次提交一个应用便产生一个ApplicationMaster，AM常驻在NodeManager中，每个AM都需要与NodeManager进行资源协商，将获得的资源（Container）用于Task的运行，监控Task的运行状况，如果Task运行失败需重新为其申请资源和启动任务。AM的启动、注册、运行状态监控都需要RM的参与，它们之间的关系可以用图2-5进行描述。图2-5 AM和RM的关系
图2-5中描述的6个步骤解释如下。（1）ApplicationMasterLaucher与对应的NodeManager联系，启动ApplicationMaster。（2）ApplicationMasterLivenessMonitor添加监控列表，启动对ApplicationMaster的监控。（3）ApplicationMaster启动后，向ApplicationMasterService注册，公布自己的URL、访问接口等。（4）ApplicationMaster定期向ApplicationMasterService发送心跳，及时更新自己的信息，便于RM进行管理。（5）当application job执行完毕后，ApplicationMaster向ApplicationMaster Service报告执行完成。（6）ApplicationMaster Service通知ApplicationMaster LivenessMonitor从监控列表中删除ApplicationMaster，释放资源。2.5 YARN中应用程序的运行过程
YARN中一个应用程序的具体运行过程如下，如图2-6所示。图2-6 YARN中应用程序的运行过程（1）用户通过Client向YARN提交作业。（2）RM根据用户的请求和集群现在资源的状况，并根据调度的策略，为AM分配第一个Container，并请求NM在这个Container中启动AM。（3）AM到RM注册，从RM中请求分配资源。（4）一旦AM申请到资源后，便与对应的NM通信，要求它启动任务。NM为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。AM保持与NM的心跳，启动、控制，并管理在NM上运行的任务。（5）各个任务通过某个RPC协议向AM汇报自己的状态和进度，与AM保持心跳，更新状态。第3章YARN编程初步3.1 YARN安装与配置3.1.1 环境准备
1．操作系统
由于Linux的开源性、安全性等因素，现有的Hadoop集群多为Linux平台，在这里采用适合个人安装的Linux Ubuntu版本实现Hadoop伪分布式平台。若采用Windows系统不能使开发者更好地体验Hadoop框架的优越性能和其高效的性能。对于不同的Linux系统，例如Redhat、Ubuntu、Debian、Gentoo、SuSE、Mandriva等的安装基本相同。
2．Java环境
在这里采用Ubuntu上所推荐的openjdk-7-jdk。若采用sun公司的jdk，则需要向系统添加环境，这里不再进行赘述。安装命令如下： sudo apt-get install openjdk-7-jdk
输入java–version检查是否安装成功。
3．SSH
在Hadoop平台上，需要涉及ResourceManager与NodeManager之间的通信、Appmaster与Container之间的通信、用户数据之间的通信等，所以需要安装SSH服务。安装命令如下： sudo apt-get install openssh-server
输入ssh–v检查是否安装成功。
4．Hadoop 2.6.0
本书采用的是目前最新的Hadoop版本——Hadoop 2.6.0，需要事先到官方网站（http://hadoop.apache.org/releases.html#Download）下载Hadoop 2.6.0的压缩包Hadoop-2.6.0. tar.gz。官方网站上名为Hadoop-2.6.0-src.tar.gz的文件是Hadoop 2.6.0的源码压缩包，如果你的计算机是64位机器，建议你下载此源代码。然后按照下一节中的方法进行编译安装。
关于Hadoop的安装，下面我们将介绍两种方式：伪分布式安装和完全分布式安装。3.1.2 伪分布式安装
1．添加用户和用户组（1）增加Hadoop用户组的命令如下： sudo groupadd Hadoop（2）增加Hadoop用户并将其加入到Hadoop用户组的命令如下： sudo adduser Hadoop –g Hadoop （3）将Hadoop加入到root权限组。
给用户Hadoop加入root权限（如果在Ubuntu安装过程中管理员用户名称设定为Hadoop，可以跳过此步）需要在控制台输入如下命令： sudo vi /etc/sudoers
在root下添加Hadoop的权限的命令如下，如图3-1所示。 Hadoop ALL=(ALL:ALL) ALL图3-1 添加Hadoop权限
2．配置SSH无密码访问
配置无密码访问后就不需要用户不停地输入访问密码了，控制台命令如下。（1）创建ssh-key，采用通用的rsa加密方式，命令如下： ssh–keygen –t rsa
多次回车后会在~/.ssh/下生成两个文件，即id_rsa和id_rsa.pub，这两个文件是成对出现的。（2）进入到~/.ssh目录下，命令如下： cd ~/.ssh（3）将id_rsa.pub追加到authorized_keys授权文件中，命令如下。开始是没有authorized_keys文件的。 cat id_rsa.pub >> authorized_keys（4）输入如下命令，测试是否配置成功。 ssh localhost
出现图3-2即配置成功。图3-2 配置成功信息
3．Hadoop安装与配置（1）将下载好的hadoop-2.6.0.tar.gz解压到/home/Hadoop/，会在/home/Hadoop目录下生成一个hadoop-2.6.0的子目录，进入此目录，命令如下。 tar –zxvf hadoop-2.6.0.tar.gz –C /home/Hadoop/ cd hadoop-2.6.0
打开/home/Hadoop/.profile，命令如下。 sudo vi ~/.profile
添加如下内容： export HADOOP_HOME=/home/Hadoop/hadoop-2.6.0 export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin（2）hadoop-env.sh配置。
打开etc/hadoop/hadoop-env.sh，添加JAVA_HOME环境变量，命令如下。 vi etc/hadoop/hadoop-env.sh export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-i386（3）core-site.xml配置。
打开etc/hadoop/core-site.xml，命令如下。 vi etc/hadoop/core-site.xml
添加如下文本：
打开etc/hadoop/hdfs-site.xml，命令如下。 vi etc/hadoop/hdfs-site.xml
添加如下文本：
在etc/hadoop目录中有一份名为mapred-site.xml.template的模板文件，复制一份到同一目录并改名为mapred-site.xml，命令如下。 cp etc/hadoop/mapred-site.xml.template etc/hadoop/mapred-site.xml
打开etc/hadoop/mapred-site.xml，命令如下。 vi etc/hadoop/mapred-site.xml
添加如下文本：
打开etc/hadoop/yarn-site.xml，命令如下。 vi etc/hadoop/yarn-site.xml
添加如下文本：
经过以上配置，Hadoop已经基本配置完成了，这一步需要格式化hdfs，命令如下： bin/hdfs namenode -format
在sbin目录下提供了多种启动集群的脚本，下面是启动方式。（1）启动hdfs： sbin/start-dfs.sh（2）启动YARN： sbin/start-yarn.sh（3）利用全部启动的命令启动： sbin/start-all.sh
若处出现启动错误，则需要去查找log日志，log日志位于hadoop-2.6.0/log目录下，YARN将Namenode、Datanode、NodeManager、ResourceManager分别记录于不同的日志中，方便用户的查找。
输入jps后若出现以下命令则安装成功。图3-3 安装成功
在浏览器中输入http://localhost:8088测试是否启动成功，若已成功启动，则会显示如图3-4所示的界面。图3-4 成功启动
测试HDFS端口是否正常的方法是：在浏览器中输入http://localhost:50070，出现如图3-5所示的界面。图3-5 测试HDFS端口是否正常
经过以上配置并且在测试成功后，我们的Hadoop第二代平台（伪分布式）就全部安装完成了。接下来我们可以利用它去做许多有趣的事情了。3.1.3 完全分布式安装
本小节介绍Hadoop完全分布式的搭建方式。我们以最简单的两台计算机为例，搭建一个简单的Hadoop集群。该安装过程适用于虚拟机安装和实机安装，对于Hadoop 2.0.X的版本均通用。
1．集群机器准备（1）为两台计算机分别安装Ubuntu系统（过程略）。（2）为两台计算机分别新建用户，名字为Hadoop，赋予root权限，注销当前用户进入Hadoop用户。（3）配置两台计算机的主机名与IP。为了保证Hadoop的稳定运行，我们必须为每台计算机分配固定IP。如果是VMware虚拟机，可以通过设置网络适配器为自定义vmnet8(NAT模式)，实体机的话可以在路由器中给每台计算机分配静态IP。我们这里给两台计算机分别设置主机名Hadoop-master和Hadoop-slave，同时给它们设置主机名与IP绑定。（4）IP和主机名绑定的命令如下。 sudo gedit /etc/hosts
添加如下两行： 192.168.153.129 Hadoop-master 192.168.153.130 Hadoop-slave
此处IP根据实际情况修改。需格外注意，Hadoop对于主机名不支持下划线，例如Hadoop_master是无法正常启动Hadoop的。（5）主机名修改，输入如下命令。 sudo gedit /etc/hostname
在两台计算机上分别修改主机名为Hadoop-master与Hadoop-slave，保存文件，退出后重启或者注销计算机，让设置生效。
2．配置SSH无密码访问（1）每台机器上都需要配置SSH无密码访问，单机配置参考3.1.2节中的SSH配置。（2）为了使得Hadoop-master对Hadoop-slave能实现免密码登录，我们必须拷贝Hadoop-master的公匙到Hadoop-slave，具体操作如下，此操作在Hadoop-master上完成。 cd ~/.ssh scp ./id_rsa.pub Hadoop-slave:~/.ssh/id_master.pub ssh Hadoop-slave cd ~/.ssh cat id_master.pub >> authorized_keys（3）测试能否免密码登录，输入如下命令： ssh Hadoop-slave
如果有多个节点，依次操作让mater节点能免密码登录slave节点即可，本例子中由于把master节点也算作一个计算节点故添加了本机的免密码访问。
3．Hadoop安装与配置
下面配置需要在每个机器上进行，这里以master为例。（1）完全分布式与伪分布式安装步骤很相似，只是完全分布式的一些xml配置稍有不同，关于安装文件下载、环境变量配置可参考3.1.2节，这里不再介绍，下面介绍不同的配置。（2）修改core-site.xml文件为如下内容。
fs.default.name为Namenode节点的URL，格式为hdfs://主机名。
Hadoop.tmp.dir为设置Hadoop运行时临时文件的存放位置。如果不设置Hadoop将默认把该文件夹放置到/tmp目录下，修改该目录是为了防止系统开机关机后临时文件丢失导致Hadoop启动失败。（3）修改hdfs-site.xml文件为如下内容。
此处主要设置了Namenode和Datanode在运行中产生的文件存储位置，并启用网页监控。（4）复制mapred-site.xml.template为mapred-site.xml，修改其中内容为如下内容。
该参数设置决定了Hadoop的运行模式，如果不设置将会默认启用单机模式，设置成YARN表示使用YARN框架来管理MapReduce程序。（5）修改slaves文件为： Hadoop-master Hadoop-slave
此处设置了该Hadoop集群有哪些节点。（6）修改yarn-site.xml文件为如下内容。
此处主要设置了YARN监控进程所要监视的URL。（7）配置slave节点。由于Hadoop每个节点的配置其实是完全一样的，故在slave计算机上重复上面的步骤即可。不过也有更方便的办法，我们可以通过远程拷贝直接复制整个Hadoop文件夹到slave计算机，这样就省去了配置的工作量，同时也减少了出错的可能，具体实现需在Hadoop-master上执行如下命令。 scp -r /home/Hadoop/hadoop-2.6.0 Hadoop-slave:/home/Hadoop/（8）启动Hadoop。启动之前，我们首先要格式化hdfs文件系统，在Hadoop-master上执行，命令如下： bin/hdfs namenode –format
启动namenode和datanode服务，命令如下： sbin/start-dfs.sh
如果启动成功，在slave上输入jps你会看到图3-6所示的内容。图3-6 启动成功
Hadoop-master上运行的服务如图3-7所示。图3-7 master上运行的服务
启动YARN，命令如下： sbin/start-yarn.sh
启动完成后，slave上运行的服务如图3-8所示。图3-8 slave上运行的服务
Master上运行的服务如图3-9所示。图3-9 Master上运行的服务
由于我们把mater也作为运算节点了，故目前运行的服务和伪分布式安装启动的服务一样。3.2 源码阅读及编译
本节内容主要是给那些需要修改部分Hadoop源代码的读者，或碰到在64位机器上无法正常运行Hadoop的读者，你们需要掌握如何把源代码导入IDE（如Eclipse）进行阅读和开发、如何编译源代码和如何解决编译过程中遇到的错误。如果只是在32位机器上运用Hadoop，可以跳过这部分内容。3.2.1 Maven的介绍及安装
1．什么是Maven
Apache Maven是一款跨平台的项目管理及自动构建工具，由Apache软件基金会提供。基于项目对象模型（POM），Maven利用一个中央信息片断管理一个项目的构建、报告和文档等步骤。
2．Maven的安装（1）到Apache Maven官网（http://maven.apache.org）下载最新版本的Maven二进制文件，如apache-maven-3.3.1-bin.tar.gz。安装Maven前，需要先配置好JDK，Maven 3.3需要JDK 1.7或更高版本，Maven 3.2需要JDK 1.6或更高版本。（2）将下载好的压缩包解压到想要安装Maven的目录（例如/usr/local/apache-maven），解压后会在该目录下生成apache-maven-3.3.1的子目录。（3）修改/etc/profile，配置环境变量，命令如下。 export MAVEN_HOME=/usr/local/apache-maven /apache-maven-3.3.1 export PATH=$PATH:$MAVEN_HOME/bin（4）执行“source/etc/profile”使配置生效。（5）执行“mvn–version”来验证是否安装成功，若正常显示版本，说明Maven安装成功。（6）常用的Maven编译命令如表3-1所示。表3-1 常用的Maven命令mvn命令含义mvn clean清理编译结果mvn compile [-Pnative]编译源代码mvn test [-Pnative]运行测试程序mvn package创建JAR包mvn compile findbugs:findbugs运行findbugsmvn compile checkstyle:checkstyle运行checkstyle（检查编程规范）mvn install将JAR部署到Maven仓库中mvn deploy将JAR包放到M2缓存中mvn package [-Pdist][-Pdocs][-构建发布版Psrc][-Pnative][-Dtar]mvn versions:set-修改版本DnewVersion=NEWVERSION3.2.2 编译前准备
在Linux系统下编译Hadoop源代码，除了前面章节提到的JDK和Maven，还需要有以下几点支持。（1）ProtocolBuffer 2.5.0；（2）CMake 2.6或更新版本（可选，如果要编译native code则安装）；（3）Findbugs 1.3.9（可选，如果需要运行findbugs则安装）；（4）第一次编译的话，需要连接到互联网（下载Maven和Hadoop的依赖包）。
1．ProtocolBuffer的下载安装（1）首先安装g++，在命令行中执行sudo apt-get install g++。（2）下载protobuf-2.5.0，将protobuf解压到指定目录（例如/usr/local/protobuf-2.5.0），并配置好环境变量。命令如下： export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib（3）进入protobuf-2.5.0目录，执行如下操作。 sudo ./configure sudo make
试读结束[说明：试读内容隐藏了图片]