Hadoop的调度器总结
随着MapReduce的流行，其开源实现Hadoop也变得越来越受推崇。在Hadoop系统中，有一个组件非常重要，那就是调度器，它的作用是 将系统中空闲的资源按一定策略分配给作业。在Hadoop中，调度器是一个可插拔的模块，用户可以根据自己的实际应用要求设计调度器。Hadoop中常见 的调度器有三种，分别为：
（1）默认的调度器FIFO
Hadoop中默认的调度器，它先按照作业的优先级高低，再按照到达时间的先后选择被执行的作业。
（2） 计算能力调度器Capacity Scheduler
支持多个队列，每个队列可配置一定的资源量，每个队列采用FIFO调度策略，为了防止同一个用户的作业独占队列中的资源，该调度器会对同一用户提交 的作业所占资源量进行限定。调度时，首先按以下策略选择一个合适队列：计算每个队列中正在运行的任务数与其应该分得的计算资源之间的比值，选择一个该比值 最小的队列；然后按以下策略选择该队列中一个作业：按照作业优先级和提交时间顺序选择，同时考虑用户资源量限制和内存限制。但是不可剥夺式。
（3）公平调度器Fair Scheduler
同计算能力调度器类似，支持多队列多用户，每个队列中的资源量可以配置，同一队列中的作业公平共享队列中所有资源，具体算法参见我的博文《Hadoop公平调度器算法解析》
非抢占式
实际上，Hadoop的调度器远不止以上三种，最近，出现了很多针对新型应用的Hadoop调度器。
（4）适用于异构集群的调度器LATE
现有的Hadoop调度器都是建立在同构集群的假设前提下，具体假设如下：
1）集群中各个节点的性能完全一样
2）对于reduce task，它的三个阶段：copy、sort和reduce，用时各占1/3
3）同一job的同类型的task是一批一批完成的，他们用时基本一样。 现有的Hadoop调度器存在较大缺陷，主要体现在探测落后任务的算法上：如果一个task的进度落后于同类型task进度的20%，则把该 task当做落后任务(这
种任务决定了job的完成时间，需尽量缩短它的执行时间)，从而为它启动一个备份任务（speculative task）。如果集群异构的，对于同一个task，即使是在相同节点上的执行时间也会有较大差别，因而在异构集群中很容易产生大量的备份任务。
LATE（Longest Approximate Time to End，参考资料[4]）调度器从某种程度上解决了现有调度器的问题，它定义三个阈值：1. SpeculativeCap，系统中最大同时执行的 speculative task数目（作者推荐值为总slot数的10%）； 2. SlowNodeThreshold（作者推荐值为25%）：得分（分数计算方法见论文）低于该阈值的node（快节点）上不会启动 speculative task；3. SlowTaskThreshold（作者推荐值为25%）：当task进度低于同批同类task的平均进度的
SlowTaskThreshold时，会为该task启动speculative task。它的调度策略是：当一个节点出现空闲资源且系统中总的备份任务数小于SpeculativeCap时，（1）如果该节点是快节点（节点得分高于 SlowNodeThreshold），则忽略这个请求。
（2）对当前正在运行的task按估算的剩余完成时间排序 （3）选择剩余完成时间最大且进度低于SlowTaskThreshold的task，为该task启动备份任务。
（5）适用于实时作业的调度器Deadline Scheduler和Constraint-based Scheduler
这种调度器主要用于有时间限制的作业（Deadline Job），即给作业一个deadline时间，让它在该时间内完成。实际上，这类调度器分为两种，软实时（允许作业有一定的超时）作业调度器和硬实时（作业必须严格按时完成）作业调度器。 Deadline Scheduler（参考资料[5]）主要针对的是软实时作业，该调度器根据作业的运行进度和剩余时间动态调整作业获得的资源量，以便作业尽可能的在deadline时间内完成。
Constraint-based Scheduler（参考资料[6]）主要针对的是硬实时作业，该调度器根据作业的deadline和当前系统中的实时作业运行情况，预测新提交的实时作业能不能在deadline时间内完成，如果不能，则将作业反馈给用户，让他重调整作业的deadline。
————————————————————————————————————————–
参考资料：
【1】 Capacity Scheduler 介绍：http://hadoop.apache.org/common/docs/r0.19.2/capacity_scheduler.html 下载：http://hadoop.apache.org/common/docs/r0.20.0/capacity_scheduler.pdf
【2】 Fair Scheduler 介绍：http://hadoop.apache.org/common/docs/r0.20.2/fair_scheduler.html 下载：http://svn.apache.org/repos/asf/hadoop/mapreduce/trunk/src/contrib/fairscheduler/designdoc/fair_scheduler_design_doc.pdf
【3】 Fair Scheduler 论文：M. Zaharia, D. Borthakur, J. S. Sarma, K. Elmeleegy, S. Shenker, and I. Stoica, “Job scheduling for multi-user mapreduce clusters,” EECS Department, University of California, Berkeley, Tech. Rep., Apr 20xx.
【4】 C. Tian, H. Zhou, Y. He, and L. Zha, “A dynamic mapreduce scheduler for heterogeneous workloads,” in Proceedings of the 20xx Eighth International Conference on Grid and Cooperative Computing, ser. GCC ’09. Washington, DC, USA: IEEE Computer Society, 20xx, pp.218–224.
[Online]. Available: http://dx.doi.org/10.1109/GCC.20xx.19
【5】 Deadline Scheduler 论文：J. Polo, D. Carrera, Y. Becerra, J. Torres, E. Ayguade and, M. Steinder, and I. Whalley, “Performance-driven task co-scheduling for mapreduce environments,” in Network Operations and Management Symposium (NOMS), 20xx IEEE, 20xx, pp. 373 –380.
【6】 Constraint-based Scheduler 论文K. Kc and K. Anyanwu, “Scheduling hadoop jobs to meet deadlines,” in 2nd IEEE International Conference on Cloud Computing Technology and Science (CloudCom), 20xx, pp. 388 –392.
第二篇：Hadoop常见错误总结
Hadoop常见错误总结
20xx-12-30 13:55
错误1：bin/hadoop dfs 不能正常启动，持续提示：
INFO ipc.Client: Retrying connect to server: localhost/127.0.0.1:9000. Already tried 0 time(s).
原因：由于 dfs 的部分文件默认保存在tmp文件夹，在系统重启时被删除。 解决：修改core-site.xml 的 hadoop.tmp.dir配置文件路径：
/home/hadoop/tmp。
错误2：hadoop出现了一些问题。用$ bin/hadoop dfsadmin -report 测试的时候，发现dfs没有加载。
显示如下：
Configured Capacity: 0 (0 KB)
Present Capacity: 0 (0 KB)
DFS Remaining: 0 (0 KB)
DFS Used: 0 (0 KB)
DFS Used%: ?%
Under replicated blocks: 0
Blocks with corrupt replicas: 0
Missing blocks: 0
查看日志：
ERROR org.apache.hadoop.hdfs.server.datanode.DataNode:
java.io.IOException: Incompatible namespaceIDs in /home/hadoop/data: namenode namespaceID = 2033006627; datanode namespaceID = 1589898341
经分析，是由于namenode namespaceID = 2033006627;和datanode namespaceID = 1589898341 不一致造成原因。
修改了namenode namespaceID = 1589898341 可以使用，但是重启之后，又不可以用了。
最后解决方案：删除hadoop用户下的name文件夹，data文件夹，tmp文件夹，temp文件里的内容，然后重新执行namenode命令。
重启电脑之后，正常。
错误3：File /home/hadoop/tmp/mapred/system/jobtracker.info could only be replicated to 0 nodes, instead of 1
出现此错误，一般发生在datanode与namenode还没有进行连接，就开始往hdfs系统上put数据了。稍等待一会，就可以了。
也可以使用：hadoop dfsadmin –report命令查看集群的状态。
错误4：
每次启动总有部分datanade不能去全部启动，查看日志文件，显示为： ERROR org.apache.hadoop.hdfs.server.datanode.DataNode:
java.net.UnknownHostException: zgchen-ubutun: zgchen-ubutun at java.net.InetAddress.getLocalHost(InetAddress.java:1426)。
分析：这是由于datanode 找不到服务host引起的。
解决：通过查找/etc/hostname 找到hostname；比如：ubuntu。
然后找到/etc/hosts ，添加：127.0.1.1 ubuntu
错误5：
java.lang.OutOfMemoryError: GC overhead limit exceeded
分析：这个是JDK6新添的错误类型。是发生在GC占用大量时间为释放很小空间的时候发生的，是一种保护机制。解决方案是，关闭该功能，可以添加JVM的启动参数来限制使用内存： -XX:-UseGCOverheadLimit
添加位置是：mapred-site.xml 里新增项：mapred.child.java.opts 内容：-XX:-UseGCOverheadLimit
java.lang.OutOfMemoryError: Java heap space
出现这种异常，明显是jvm内存不够得原因，要修改所有的datanode的jvm内存大小。
Java -Xms1024m -Xmx4096m
一般jvm的最大内存使用应该为总内存大小的一半，我们使用的8G内存，所以设置为4096m，这一值可能依旧不是最优的值。（其实对于最好设置为真实物理内存大小的0.8）
错误6：Too many fetch-failures
Answer:
出现这个问题主要是结点间的连通不够全面。
1) 检查 、/etc/hosts
要求本机ip 对应 服务器名
要求要包含所有的服务器ip + 服务器名
2) 检查 .ssh/authorized_keys
要求包含所有服务器（包括其自身）的public key
错误7：处理速度特别的慢 出现map很快 但是reduce很慢 而且反复出现 reduce=0%
Answer:
结合第二点，然后修改可用内存大小。
conf/hadoop-env.sh 中的export HADOOP_HEAPSIZE=4000
错误8：能够启动datanode，但无法访问，也无法结束的错误
在重新格式化一个新的分布式文件时，需要将你NameNode上所配置的
dfs.name.dir这一namenode用来存放NameNode 持久存储名字空间及事务日志的本地文件系统路径删除，同时将各DataNode上的dfs.data.dir的路径 DataNode 存放块数据的本地文件系统路径的目录也删除。如本此配置就是在NameNode上删除/home/hadoop/NameData，在DataNode上删除
/home/hadoop/DataNode1和/home/hadoop/DataNode2。这是因为Hadoop在格式化一个新的分布式文件系统时，每个存储的名字空间都对应了建立时间的那个版本（可以查看/home/hadoop /NameData/current目录下的VERSION文件，上面记录了版本信息），在重新格式化新的分布式系统文件时，最好先删除NameData
目录。必须删除各DataNode的dfs.data.dir。这样才可以使namedode和datanode记录的信息版本对应。
注意：删除是个很危险的动作，不能确认的情况下不能删除！！做好删除的文件等通通备份！！
错误9：java.io.IOException: Could not obtain block:
blk_194219614024901469_1100
file=/user/hive/warehouse/src_20xx0924_log/src_20xx0924_log 出现这种情况大多是结点断了，没有连接上。或者
mapred.tasktracker.map.tasks.maximum 的设置 超过 cpu cores数目，导致出现获取不到文件。
错误10：Task Id : attempt_20xx10291615_0001_m_000234_0, Status : FAILED Error: java.io.IOException: No space left on device
Task Id : attempt_20xx10291615_0001_m_000240_0, Status : FAILED java.io.IOException: Spill failed
磁盘空间不够，应该分析磁盘空间df -h 检查是否还存在磁盘空间。
错误11:Task Id : attempt_20xx11011336_0007_m_000001_0, Status : FAILED org.apache.hadoop.hbase.client.RegionOfflineException: region offline: lm,,1288597709144
网上说，将/hbase删除；重启hbase后，可以正常应用了。但是我找不到/hbase目录，只好自己重新删除掉一些hadoop文件，重新生成文件管理系统。
还有一个可能是，配置错了/hbase/conf/hbase-env.sh的HBASE_CLASSPATH，这个默认是不配置的，所以可以不配置。
错误12：org.apache.hadoop.hbase.TableNotFoundException:
org.apache.hadoop.hbase.TableNotFoundException: lm
找不到表，hbase启动了，检查一下是否存在需要的Htable。