Hadoop map与reduce数量
2016-05-15 14:59
246 查看
MapReduce框架将文件分为多个splits,并为每个splits创建一个Mapper,所以Mappers的个数直接由splits的数目决定。而Reducers的数目可以通过job.setNumReduceTasks()函数设置,默认情况只有一个Reducer。在真正的集群环境下,如果默认,那么所有的中间数据会发送给唯一的Reducer,导致任务变得非常缓慢。究竟设多少个Reducers合适呢?为了解决这个问题,首先来了解一下slots的概念。
slots有点类似一个资源池,每个任务(map和reduce)执行时都必须获得一个slot才能继续,否则只能等待。当一个任务完成后,该任务就归还slot,这个过程有点类似释放资源到资源池中。显然,每一个获得资源的任务都可以立即执行,无需等待。另一方面,mapreduce的任务由tasktracker节点负责执行的,所以slots可进一步理解为tasktrackers能够并发执行多个任务。slots分为mapper slots和reducer slots,分别对应最大可并行执行的mapper和reducer数。用户可以通过修改mapred-site.xml配置文件的mapred.tasktracker.map.tasks.maxmum来设置slots的值,默认为2.
集群中可用rducer slots 的总数等于集群中的总结点数诚意每个节点有多少个slots。reducers 数目的最佳值和reducer slots的总数有关,通常情况下,让reducers的数目略小于reducer slots的总数,这样的目的:首先reducers可以并行执行,减少排队时间;其次对于未执行reducer的slots可以在其他reducer发生故障时,立即分配给新创建的reducer,不会明显 加长任务总时间。
如果出现reducers》mappers的情况就不合理了,这样有些mappers会工作消耗资源开销,但是对任务没有任何帮助。
每个reduce输出一个结果文件,有多少reduce就会有多少输出文件,然后会有一些其他文件。不会合并的,导出的时候可以用命令行进行合并
hadoop fs -getmerge将数据导出时可以将结果文件合并成一个 。通常情况下你可以你可以启动另一个MR来合并,第一次MR产生多个文件,第二个MR设定一个REDUCE只是简单的合并不做任何数据处理,通常也会很快。
Hadoop的mapreduce 的作业在运行过程中常常碰到一些这样的情况:
每一个map或者reduce只有30-40秒钟就结束
超大规模的job 时,通常会需要大量的map和reduce的slots 支持,但是job运行起来后,running的map和reduce并没有沾满集群的可用slots
当几乎所有的map和 reducers都在调度系统 中运行着,此时却有一个或者两个pending的map或者reduce,一直不跑,使得job一直无法正常结束。
对一个job的map数和reduce数的设定对一个job的运行是非常重要的,并且非常简单。以下是一些设置 这几个值的经验总结:
如果job的每个map或者 reduce task的运行时间都只有30-40秒钟,那么就减少该job的map或者reduce数,每一个task(map|reduce)的setup和加入到调度器中进行调度,这个中间的过程可能都要花费几秒钟,所以如果每个task都非常快就跑完了,就会在task的开始和结束的时候浪费太多的时间。JVM 的reuse方式也可以解决 这个问题。
如果某个input的文件 非常的大,比如 1TB,可以考虑将hdfs上的每个block size设大,比如设成256MB或者512MB,这样map和reduce的数据 可以减小。而且用户还可以通过命令 :hadoop distcp -Ddfs.block.size=$[256*1024*1024] /path/to/inputdata /path/to/inputdata-with-largeblocks的方式来将已经存在咋hdfs上的数据进行大块化。然后删除掉原先的文件。
只要每个task都运行至少30-40秒钟,就可以考虑将mapper数扩大,比如集群的map slots为100个,那么就不要将一个job的mapper设成101,这样前100个map能够并行完成,而最后一个map要在前100个 mapper结束后才开始,因此在reduce开始运行前,map阶段的时间几乎就要翻倍。
尽量不要运行太多的reduce task。对大多数job来说,最好rduce的个数最多和集群中的reduce持平,或者比集群的 reduce slots小。这个对于小集群而言,尤其重要。
测试对比:
调整运行参数( -Dmapred.max.split.size=$[16*1024*1024] ),或者在配置文件中对将 mapred.max.split.size设置成$[16*1024*1024] ,hadoop 中的wordcount任务的mapper数就会受到用户控制。当运行这种配置的任务时,每个task都会在10秒钟之内运行完,而从 jobtracker的webui上可以看到cluster的总体情况和job的情况,其中可以看到,running的map数频繁的在0-24之间波动。整个job17分52秒完成,比使用原始配置的job的运行时间的两倍还多。
转自http://www.linuxidc.com/Linux/2012-05/60782.htm
http://www.2cto.com/os/201312/263998.html
slots有点类似一个资源池,每个任务(map和reduce)执行时都必须获得一个slot才能继续,否则只能等待。当一个任务完成后,该任务就归还slot,这个过程有点类似释放资源到资源池中。显然,每一个获得资源的任务都可以立即执行,无需等待。另一方面,mapreduce的任务由tasktracker节点负责执行的,所以slots可进一步理解为tasktrackers能够并发执行多个任务。slots分为mapper slots和reducer slots,分别对应最大可并行执行的mapper和reducer数。用户可以通过修改mapred-site.xml配置文件的mapred.tasktracker.map.tasks.maxmum来设置slots的值,默认为2.
集群中可用rducer slots 的总数等于集群中的总结点数诚意每个节点有多少个slots。reducers 数目的最佳值和reducer slots的总数有关,通常情况下,让reducers的数目略小于reducer slots的总数,这样的目的:首先reducers可以并行执行,减少排队时间;其次对于未执行reducer的slots可以在其他reducer发生故障时,立即分配给新创建的reducer,不会明显 加长任务总时间。
如果出现reducers》mappers的情况就不合理了,这样有些mappers会工作消耗资源开销,但是对任务没有任何帮助。
每个reduce输出一个结果文件,有多少reduce就会有多少输出文件,然后会有一些其他文件。不会合并的,导出的时候可以用命令行进行合并
hadoop fs -getmerge将数据导出时可以将结果文件合并成一个 。通常情况下你可以你可以启动另一个MR来合并,第一次MR产生多个文件,第二个MR设定一个REDUCE只是简单的合并不做任何数据处理,通常也会很快。
Hadoop的mapreduce 的作业在运行过程中常常碰到一些这样的情况:
每一个map或者reduce只有30-40秒钟就结束
超大规模的job 时,通常会需要大量的map和reduce的slots 支持,但是job运行起来后,running的map和reduce并没有沾满集群的可用slots
当几乎所有的map和 reducers都在调度系统 中运行着,此时却有一个或者两个pending的map或者reduce,一直不跑,使得job一直无法正常结束。
对一个job的map数和reduce数的设定对一个job的运行是非常重要的,并且非常简单。以下是一些设置 这几个值的经验总结:
如果job的每个map或者 reduce task的运行时间都只有30-40秒钟,那么就减少该job的map或者reduce数,每一个task(map|reduce)的setup和加入到调度器中进行调度,这个中间的过程可能都要花费几秒钟,所以如果每个task都非常快就跑完了,就会在task的开始和结束的时候浪费太多的时间。JVM 的reuse方式也可以解决 这个问题。
如果某个input的文件 非常的大,比如 1TB,可以考虑将hdfs上的每个block size设大,比如设成256MB或者512MB,这样map和reduce的数据 可以减小。而且用户还可以通过命令 :hadoop distcp -Ddfs.block.size=$[256*1024*1024] /path/to/inputdata /path/to/inputdata-with-largeblocks的方式来将已经存在咋hdfs上的数据进行大块化。然后删除掉原先的文件。
只要每个task都运行至少30-40秒钟,就可以考虑将mapper数扩大,比如集群的map slots为100个,那么就不要将一个job的mapper设成101,这样前100个map能够并行完成,而最后一个map要在前100个 mapper结束后才开始,因此在reduce开始运行前,map阶段的时间几乎就要翻倍。
尽量不要运行太多的reduce task。对大多数job来说,最好rduce的个数最多和集群中的reduce持平,或者比集群的 reduce slots小。这个对于小集群而言,尤其重要。
测试对比:
调整运行参数( -Dmapred.max.split.size=$[16*1024*1024] ),或者在配置文件中对将 mapred.max.split.size设置成$[16*1024*1024] ,hadoop 中的wordcount任务的mapper数就会受到用户控制。当运行这种配置的任务时,每个task都会在10秒钟之内运行完,而从 jobtracker的webui上可以看到cluster的总体情况和job的情况,其中可以看到,running的map数频繁的在0-24之间波动。整个job17分52秒完成,比使用原始配置的job的运行时间的两倍还多。
转自http://www.linuxidc.com/Linux/2012-05/60782.htm
http://www.2cto.com/os/201312/263998.html
相关文章推荐
- Centos6.5 安装JDK
- Dubbo学习之目录
- Linux下卸载OpenJDK并安装Sun JDK的详细步骤
- apache基于端口的虚拟主机配置
- 初识linux 上
- linux下交叉编译jrtplib-3.9.1
- Hive学习
- linux 16进制编辑器
- 程序猿开发必会的Linux命令
- IT_linux_command--dstat
- Linux发行版 CentOS6.5 禁用防火墙步骤
- 虚拟机里面安装Openfiler 2.99
- Centos下kafka 单机配置部署详解
- tomcat配置虚拟目录和虚拟主机
- Poj 2186 Popular Cows
- Linux:前期总结
- [架构设计]第一讲:什么是架构
- Linux发行版 CentOS6.5 修改默认主机名
- linux下编译jrtplib-3.9.1
- KNN Hadoop MapReduce