Google Chrome 32.0.1653.0
Windows 7 x64 Edition谢谢，说得这么详细，写一篇这样的内容出来要查很多的资料才行。
电子邮件 *
博文浏览排名
- 228,340 views - 200,188 views - 97,848 views - 87,893 views - 86,518 views - 65,064 views - 57,760 views - 55,942 views - 55,284 views - 54,664 views
2016年十一月
78910111213
14151617181920
21222324252627Hadoop运维记录
&&&& 日期：&&&&浏览次数：出处：实践检验真理
周末去了趟外地，受托给某省移动公司做了一下Hadoop集群故障分析和性能调优，把一些问题点记录下来。
该系统用于运营商的信令数据，大约每天1T多数据量，20台Hadoop服务器，赞叹一下运营商乃真土豪，256G内存，32核CPU，却挂了6块2T硬盘。还有10台左右的服务器是64G内存，32核CPU，4~6块硬盘，据用户反馈，跑数据很慢，而且会有失败，重跑一下就好了。
软件环境是RedHat 6.2，CDH Hadoop 4.2.1。
总容量260多TB，已使用200多T。
首先，这硬件配置属于倒挂，内存CPU和硬盘不匹配，因为作为Hadoop来说，注重的是磁盘的高吞吐量，而并发读写磁盘个数决定了吞吐量的大小。对于Hadoop来说，硬盘数量多比单盘容量大更具有优势。举例说明，假设一块硬盘的读写速度是210MB每秒，一块硬盘3TB，那么全部扫描一遍大概需要4小时左右。而1TB的硬盘扫描一遍大概只需要一个多小时。Hadoop最好的硬盘挂载方式是JBOD，也就是直接插主板不做raid。那么如果同时10块硬盘读写，得到的吞吐量是2.1G左右。20块就是4G左右。所以，对于Hadoop来说，30块1TB硬盘的性能要绝对优于10块3TB的硬盘。但是目前来说，性价比最高的还是2TB的硬盘。
还好只有20台服务器，可以挨个手工上去查一下，如果是200台，挨个查我就死在移动了。除了硬件配置不合理外，还查出几个比较重要的问题。
一、20台机器没有做机架感知，而且复制份数是2，因为受集群总存储能力限制，目前只能复制两备份，这个没辙了，以后扩服务器再说吧。
二、配置不合理，且没有为异构硬件搭配不同的Hadoop配置项&&& 1. 因为采用CDH 4，所以实际是在YARN上跑MRv1，256G内存的服务器配置的map槽位数是150个，reduce槽位数是130个，其实是很大程度上超出了32核CPU的计算能力，绝大部分的CPU时间消耗在了MR Java进程之间的切换上。大量的Java进程用strace跟踪看都是在互斥锁上等待(FUTEX_WAIT)。所以，跑任务的时候服务器的System CPU很高，真正用于MR的User CPU很少。
&&& 2. 256G跟64G内存的服务器，Hadoop配置文件一样，64G也是150 map slots, 130 reduce slots，mapred.map(reduce).child.java.opt内存也没改，没发生OOM真是奇迹...MR槽位数不是越大越好，要跟CPU和内存数量搭配着算才好，至于2.0，更简单一些，只要配置vcore数量就行了，但是也不是vcore配的越大就越好。而且，据说搭建集群之前有公司给他们培训过Hadoop，居然告诉他们map,reduce槽位数的配置项没用，不用管，这培训也太坑人了吧。
&&& 3. 没有做磁盘保留空间，我到了现场以后没多久一台NodeManager就挂了，我以为是我神威所致，服务器害怕了，上去一看是硬盘100%了...
三、Linux系统层面没有做优化。&&& 1. 没有开启TCP回收和TCP复用
&&& 2. 没有设置文件打开句柄数
&&& 3. 还有三台服务器没有关闭SELinux
&&& 4. 没有自动化运维，20台Hadoop服务器都是tar包解压缩手工装的。
&&& 5. 没有监控，据说是我去之前几天才装的Ganglia...监控数据采集了MR和HBASE，没有HDFS
&&& 6. 没有做数据压缩。
&&& 7. 小文件太多，块数量380万，文件数量360万。分块大小设定128M，上去看很多文件都达不到，基本都是40~80兆左右。
四、业务层面太过复杂。&&& 1. 数据清洗依赖Hive进行，而没有采用编写MR的方式，Hive开发速度快，但是执行效率是真低啊。
&&& 2. 单个查询Join太多，并开启了Hive的并行查询，引发大量的Stage任务，占用太多MR槽位。
&&& 3. 同时并发计算太多，没有做Job分解和规划调度。
&&& 4. 清洗后的数据使用snappy压缩，这玩意计算读取的时候不分块的，只能1map读取。
总的来说，基本还是由于硬件配置不合理和对Hadoop底层不熟悉导致的性能较低，这个不是我这个层面能解决的问题了。
当然，这不是我见过的配置最不合理的硬件，记得去年年初中软国际卖某部委的Hadoop服务器，找我给配置，128G内存，64核CPU，4块2T盘。当时我看着这服务器是真不知道该怎么配才合适。当时说给钱，到现在也没给，赖账了这帮孙子...
其实搞hadoop，不仅仅只是搭起来能跑那么简单，传统运营商基本还是拿传统的思维观念在看待这些新生的开源事物，认为单个机器CPU足够多，内存足够大，就不需要很多台机器了。如果只是这样简单的话，就不需要开发Hadoop了，谷歌只要弄个牛逼配置的大型机，继续用Oracle就好了。Hadoop也好，Spark也好，更多的是蚂蚁啃大象的思路，虽然单个机器烂，但是只要足够多，也可以解决大问题。
云服务也好，大数据也罢，真正注重的是运维的能力，运维强则数据强君，已阅读到文档的结尾了呢~~
hadoop面试题答案,hadoop面试题,信用社面试题及答案,java面试题及答案,spring面试题及答案,安卓面试题及答案,ios面试题及答案,php面试题及答案,.net面试题及答案,oracle面试题及答案,sql面试题及答案
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
hadoop面试题答案
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口Slots是Hadoop的一个重要概念。然而在Hadoop相关论文，slots的阐述难以理解。网上关于slots的概念介绍也很少，而对于一个有经验的Hadoop来说，他们可能脑子里已经理解了slots的真正含义，但却难以清楚地表达出来，Hadoop初学者听了还是云里雾里。我来尝试讲解一下，以期抛砖引玉。
首先，slot不是CPU的Core，也不是memory&chip，它是一个逻辑概念，一个节点的slot的数量用来表示某个节点的资源的容量或者说是能力的大小，因而slot是&Hadoop的资源单位。
&Hadoop利用slots来管理分配节点的资源。每个Job申请资源以slots为单位，每个节点会确定自己的计算能力以及memory确定自己包含的slots总量。当某个Job要开始执行时，先向JobTracker申请slots，JobTracker分配空闲的slots，Job再占用slots，Job结束后，归还slots。
&每个TaskTracker定期（例如Hadoop心跳周期是5s）通过心跳(hearbeat)与Jobtracker通信，一方面汇报自己当前工作状态，JobTracker得够某个TaskTracker是否Alive；同时汇报自身空闲slots数量。JobTracker利用某个调度规则，如Hadoop默认调度器FIFO或者Capacity&Scheduler、FairScheduler等。（注：淘宝Hadoop使用云梯调度器YuntiScheuler，它是基于Fair&Scheduler进行修改的，具体针对哪些点进行了修改，下次再介绍）。
Hadoop里有两种slots,&map&slots和reduce&slots，map&task使用map&slots，一一对应，reduce&task使用reduce&slots。注：现在越来越多的观点认为应该打破map&slots与&reduce&slots的界限，应该被视为统一的资源池，they&are&all&resource，从而提高资源的利用率。区分map&slots和reduce&slots，容易导致某一种资源紧张，而另一个资源却有空闲。在Hadoop的下一代框架MapR中，已经取消了map&slots与reduce&slots的概念，并将Jobtracker的功能一分为二，用ResourceManager来管理节点资源，用ApplicationMaster来监控与调度作业。ApplicationMaster是每个Application都有一个单独的实例，application是用户提交的一组任务，它可以是一个或多个job的任务组成。
Hadoop中通常每个tasktracker会包含多个slots，Job的一个task均对应于tasktracker中的一个slot。系统中map&slots总数与reducer&slots总数的计算公式如下：
Map&slots总数=集群节点数&mapred.tasktracker.map.tasks.maximum
&Reducer&slots总数=集群节点数&mapred.tasktracker.reduce.tasks.maximum
最后，如何确定一个集群map&slots以及reduce&slots？
请参考&hadoop&mapreduce&tutorial
http://hadoop.apache.org/common/docs/current/mapred_tutorial.html&经典版的MapReduce
所谓的经典版本的MapReduce框架，也是Hadoop第一版成熟的商用框架，简单易用是它的特点，来看一幅图架构图：
上面的这幅图我们暂且可以称谓Hadoop的V1.0版本，思路很清晰，各个Client提交Job给一个统一的Job Tracker，然后Job Tracker将Job拆分成N个Task,然后进行分发到各个节点（Node）进行并行协同运行，然后再将各自的运行结果反馈至Job Tracker,进而输出结果。
但是，这种框架有它自身的限制性和局限，我们来简单的分析几点：
1、单点故障，首先，单点故障也是最致命的一点，从上图中可以看到所有的Job的完成都得益于JobTracker的调度和分配，一旦此节点宕机就意味着整个平台的瘫痪，当然，在实际中大部分通过一个JobTracker slaver来解决。但是，在一个以分布式运算为特性的框架中，将这种核心的计算集中与一台机器不是一个最优的方案。
2、可扩展性，同样，在上面的架构图中可以看到，Job Tracker不但承载着Client所提供的Job和分发和调度，还需要管理所有的Job的失败、重启，监视每个Node的资源利用情况，实现原理无非就是Heartbeat(心跳检测)，随着Node的数量的增加，Job Tracker的任务就会变得越来愈大，在疲于应付各个子节点运行检测的同时，还要进行新的Job的分发，所以这种框架官方给出了限制节点数（&4000 节点）。
3、资料浪费，在传统的架构中，每一个Job的分配，是通过Node资源的数量进行分配的方式，显然这种分配方式不能动态的实现负载均衡，比如，两个大的内存消耗的task调度到了一个Node上，这也就意味着状态机器压力很大，而相应的某些节点就比较轻松，显然在分布式计算中这是一种很大的资源浪费。
4、版本耦合，其实这一点也是影响一个平台做大的致命缺陷，以上的架构中，MapReduce框架有着任何的或者不重要的变更（比如BUG修复、性能提升或某些特性），都会强制进行系统级别的升级更新。而且，不管用户是否同意，都得强制让分布式系统的每一个用户端进行更新。
以上四点，是V1.0框架之上所带来的局限性，总结的来看，问题主要是集中在中间节的主线程Job tracker上面，所以解决这个线程的问题，基本也就解决了上面所提到的性能浪费和扩展性等诸多问题。
下面我们再详细的分析下Job Track在MapReduce中的详细职责，解决扩张性的问题无非就是责任解耦，我们来看一下：
1、管理集群中的计算资源，涉及到维护活动节点列表，可用和占用的Map和Reduce Slots列表。以及依据所选的调度策略可用的Slots分配给合适的作用和任务
2、协调集群中运行的任务，这涉及到指导Task Tracker启动Map和Reduce任务，监视任务的运行状态，重新启动执行失败任务，推测性能运行缓慢的任务，计算作业计数器值的总和，等等。
看看，JobTrack是不是很累.....这样的安排放在一个进程中会导致重大的伸缩性问题，尤其是在较大的集群上面，JobTracker必须不断的跟踪数千个TaskTracker、数百个作业，以及数以万计的Map和Reduce任务，下面来个图看看：
上图中显示了一台比较忙的Job Tracker在忙碌的分配着任务.....
所以，分析到此，似乎解决问题的方式已经呼之欲出了：减少单个JobTracker的职责！
既然减少JobTracker的职责，也就意味着需要将不属于他的职责分配给别人去干，经过上面的简述，我们基本上可以将JobTracker的职责分为两大部分：集群资源管理和任务协调。
这两大任务之间，显然集群管理的任务要更重要，它意味着整个平台的性能的健壮和平台的扩展性，而相比较，任务协调之类的事情就可以分配到某一个下属的Node来干，并且由于每一个Client所提到的Job分配过程和执行过程而言，分配过程显得短暂并且灵活。
通俗一点的讲：就是将上面架构中的JobTracker责任进行剥离，让它就负责整个平台的资源管理就可以了，至于任务的分配和协调就交给属下（Node）来干就好了。就好比一个公司来个活，大Boss只负责整个公司的资源管理，而这个活就扔给相应的部分就可以了。
经过上面的分析，好像基本下一个版本的架构优化方式也基本明确，我们来接着分析Hadoop的新一版的架构。
新一代的架构设计YARN
来看一下官方的定义：
Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
经过第一部分的分析，我们基本已经确认了将以前的JobTracker这个主线程的责任更改为整个集群的资源管理和分配。从这一点讲这里如果这个线程的命名还是JobTracker显然就不合适了。
所以在新一般的架构图中他的名字变成了ResourceManager(资源管理)，然后这个名字更适合它的职责。
我们先来一幅图看看
哈，长得基本和上一代的架构图一样，只是责任有了明显的分离，我们来分析一下，首先来确定一下图中的名词：
1、ResourceManager(RM)全局群集资源管理器
2、ApplicationMaster(AM)专用的JobTracker,途中可以看出，目前已经将JobTracker的职责分离到了Node中了。
3、NodeManage（NM）管理各个子节点，代替以前的TaskTracker,不过功能基本类似，只不过添加了一个每个节点的的自管理功能，也是对RM的责任分担。
4、Containers,用Application来提到以前的MapReduce作业，而承载Application的容器就为Container,目的是为了更多应用能运行在Hadoop平台下，为了以后的扩充。
我们来简述一下，整个框架的运行流程。
在YARN构架中，一个全局的ResourceManager主要是以一个后台进程的形式运行。它一般分配在一个独有的机器上，在各种竞争的应用程序之间独裁可用的集群资源。ResourceManageer会追踪集群中有多少可用的活动节点和资源，协调用户提交的那些应用程序在何时获取这些资源。
ResourceManager是唯一拥有此信息的进程，所以它可通过某种共享的，安全的，多租户的方式制定分配（或者调度）决策（例如，依据应用程序的优先级，队列容量，ACLs,数据位置等）
在用户提交一个应用程序时，一个称为ApplicationMaster的轻量级进程实例会启动协调应用程序内的所有任务的执行。包括监视任务，重新启动失败的任务，推测的运行缓慢的任务，以及计算应用程序计数值的总和。这些职责以前就是JobTracker.现在已经独立出来，并且运行在NodeManager控制的资源容器中运行。
NodeManager是TaskTracker的一种更加普通和高效的版本，NodeManager拥有许多动态创建的资源容器，容器的大小取决于所包含的资源量，比如：内存、CPU、磁盘和网络IO.但是目前仅支持内存和CPU(YARN-3).其实这里平台提供的一个接口，方便后续的扩展，未来可使用cgroups来控制磁盘和网络IO.
其实，简单点讲，NodeManager是一个高度自治的内在节点，包括节点内的JobTracker.
我们再来看另外一幅图，来详细的看一下，YARN内新的Job内在流程在各个节点（Node）中的流转：
从这幅图中可以看到，和之前的第一版的架构图相比，是多了后面节点之间的交互，因为，在新的结构图中我们将JobTracker的职责下放到NodeManager中的ApplicationMaster中了，也就是会在ApplicationMaster中进行传统的Map-Redurce的分发，所以会造成各个不同的Noder之间发生交互。
当然，这所有的过程都会他们的老大ResourceManager进行调度和管理。
以上的架构，在Hadoop版本中称之为MRv2.
我们来总结一下，这个架构所解决的问题：
1、更高的集群利用率，一个框架未使用的资源可由另一个框架进行使用，充分的避免资源浪费
2、很高的扩展性，采用了这种责任下方的架构思路，已经解决了第一版4000node的限制，到目前可以充分的扩展资源。
3、在新的Yarn中，通过加入ApplicationMaster是一个可变更的部分，用户可以针对不同的编程模型编写自己的AppMst,让更多的编程模型运行在Hadoop集群中。
4、在上一版框架中，JobTracker一个很大的负担就是监控Job的tasks运行情况，现在，这个部分下放到了ApplicationMaster中。
除了上面几点之外，我们特别来分析以下，在新版框架中的ResouceManager的功能亮点。
上个图看看：
当一个Client提交应用程序的时候，首先进去的就是ResourceManager，它维护着集群上运行的应用程序列表，以及每个活动的NodeManager上的可用资源列表。ResourceManager首先要确定就是那个应用程序可以运行此Job,会存放到相应的Container中去，当然这里会分配一部分的集群资源，这一部分资源的选择会受到许多的限制，比如：队列容量，ACL和公平性。下一步就是另外一个可插拔的组件Scheduler来下发任务（这里不是分发！），Scheduler近执行调度，不会对应用程序内的执行过程有任何监视，Scheduler就好比秘书一样，将大Boss(RM)分配的任务传递到相应的部门。
然后，就是部门的领导（ApplicationMaster）来分配任务给员工（DataNode）了，而这个分发的过程就是Map-Redure，所以在这个过程中，ApplicationMaster负责此应用程序的整个周期，当然在运行过程中，它可以跟老大（RM）进行一些相应的资源需求，比如：
1、一定量的硬件资源，比如内存量和CPU份额。
2、一个首选的位置，比如某台Node，通常需要制定主机名、机架名等。
3、Task分配后的优先级。
然后，找到相应的资源之后，就开始甩开膀子进行任务的完成，而这些跑批则发生在（Node）中,但是Node中也有它自己的小队长（NodeManager）,它负责监视自己node种的资源使用情况，比如，自己的任务比当初分配的少，提前完成了，它会结束该容器，释放资源。
而在上面的过程中，ApplicationMaster会竭尽全力协调容器，自动所需要的任务来完成它的应用程序，他会监视应用程序的进度，重新启动失败的任务，以及向Client提交应用程序的报告进度。应用程序完成后，ApplicationMaster会关闭自己并释放自己的容器。
当然，这个过程之中，如果ApplicationMaster自己挂掉了，这时候ResouceManager会重新重新找一个领导（新的容器中启动它），直至整个程序完成。
Hadoop是一个非常牛掰的分布式架构平台，它的优越性我想不需要我跟大家分享，很多成功的案例都已经在暗示着我们，未来所谓的大数据，所谓的互联网+，所谓的云....都会找到它的立脚点。
百度百科：
，这是对一个 JARN 集群的重要技术细节的不错介绍。
Hadoop官网 。
阅读(...) 评论()