十、作业执行及环境:
MRAppMaster 执行Mapper、Reducer作业时,会将task作为它的子进程,运行在独立的jvm中。
child-task 继承MRAppMaster 的运行环境。用户可以通过
mapreduce.{map|reduce}.java.opts 给
child-jvm 指定额外的设置项和在Job中设置参数(如:运行时连接器(
run-time linker ) 用不标准路径(通过
-Djava.library.path=<> 来定义,如果定义中包括
@taskid@ 标志,那么它将被修改为MapReduce task的
taskid ),去搜索共享库。)
下面的例子是一个具有多参数和替换的例子,展示了JVM的GC(垃圾回收)日志,并启动一个JVM JMK的代理密码,以便它能连接Jconsole,以查看clild的内存,线程和获取线程垃圾。还设置了map和reduce child JVM 的最大
heap-size(堆)的大小分别为512MB和1024MB。还为child-jvm添加一个额外的路径:
java.library.path 。(mapreduce-site.xml文件)
<property>
<name>mapreduce.map.java.opts</name>
<value>
-Xmx512M -Djava.library.path=/home/mycompany/lib -verbose:gc -Xloggc:/tmp/@
taskid@.gc
-Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
</value>
</property>
<property>
<name>mapreduce.reduce.java.opts</name>
<value>
-Xmx1024M -Djava.library.path=/home/mycompany/lib -verbose:gc -Xloggc:/tmp/@
taskid@.gc
-Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
</value>
</property>
|
十一、内存管理:
用户或管理员可以指定child-task启动的最大虚拟内存,和任何su-process(子进程)启动递归,用
mapreduce.{map|reduce}.memory.mb 进行设置,请注意,这里设置的值,是对每个进程的限制。
mapreduce.{map|reduce}.memory.mb 应该指定为MB。还有,它的值必须大于等于Jvm的
-Xmx 值,否则VM有可能无法启动。
注:
mapreduce.{map|reduce}.java.opts 仅用于对从
MRAppMaster 启动的
child tasks 的
配置。而守护进行的内存配置选项,是记录在Hadoop守护进程的环境配置。
框架的某些部件的有效内存也可以配置,在map和reduce任务中,通过调整参数,影响并发操作和磁盘的数据命中率,从而影响整体性能。对文件系统的作业的Counters(总计汇报设备)进行详细监测,特别是对于从map到reduce的 byte counts(字节统计)的详细监测, 这种监测对于调整参数是非常有用的。
十二、Map的相关参数:
由map产生的
记录,将被序列化后,写入
buffer
,
metadata
则将被写入到
accounting buffers
。如下列选项所描述,当序列化缓冲区或元数据超过一个阈值时,缓冲区中的内容将被分类并写入到磁盘中,同时map继续输出记录。如果在溢出过程中完全填充缓冲区,则该map线程将阻塞。当map执行完毕后,任何剩余的记录都将被写入到磁盘,所有的磁盘片段被合并为一个单独的文件。把溢出到磁盘的数量减到最小,可以减少map的执行时间,但是,更大的缓冲区同样也减少了mapper的可用内存。
参数名称
|
参数类型
|
描述
|
mapreduce.task.io.sort.mb
|
int
| map产生的序列化,总计缓存的存储记录的累计大小,以MB为单位。 |
mapreduce.map.sort.spill.percent
|
float
|
序列化缓冲区中的软限制。一旦达到,线程将开台将内容溢出到后台磁盘中。
|
其他说明:
如果超过溢出阈值或者正在溢出了,收集器将继续工作,直到溢出结束。例如,如果
mapreduce.map.sort.spill.percent
设置为0.33,当溢出开始,缓冲区的剩余部分将被填满,接下来,溢出将包括所有已收集到的记录;或者缓冲区设置为0.66,将不会产生额外的溢出。换句话说,阈值是定义触发器,而不是阻塞。
大于序列化缓冲区的记录将首先触发溢出,然后被溢出到一个单独的文件。这是因为,它不明确这个记录是否第一时间传递给combiner中。
十三、Shuffle、Reduce的相关参数:
如前面所述,每个reduce通过内存中Http,获取由分区器(Partitioner)指定的output,定期的将这些output进行合并,然后写入到磁盘中。如果开启了对map的output进行中间记录压缩,每个Output被解压到内存中。下列的设置项,对在reduce之前,将outputs合并到磁盘中的频率产生影响,以及对map output 到 reduce间的内存
分配产生影响。
参数名称
|
参数类型
|
描述
|
mapreduce.task.io.soft.factor | int | 指定同一时间,合并磁盘上分段的数量。在合并执行期间,它限制了打开文件的数量及压缩解码器的数量。如果文件的数量超过这个限制,合并器将在几个途径中继续。虽然这限制同样适用于map,但大多数jobs都应该配置,以使这个限制不可能达到。 |
mapreduce.reduce.merge.inmem.thresholds
|
int
|
在map outputs合并到磁盘前,提取map outputs分类到内存中的数量。像前面说的溢出阈值一样,不是定义一个分区,而是定义一个触发器。在实践中,这通常会设置得比较高(默认值1000)或者禁用(设置为0),因为在内存中合并比在磁盘中合并的代价高得多(详见本表下面的说明)。这个设置的阈值,仅对于shuffle过程中的合并频率产生影响。
|
mapreduce.reduce.shuffle.merge.percent
|
float
|
在内存中开始合并map outputs之前,取出map outputs的内存阈值,表示为分配给map outputs分类的内存在内存中的百分比。因为,map outputs不适合在内存中滞留,因此,设置较高的阈值,可能会降低获取和合并的并行操作。相反,高达1的阈值,对reduces的内存输入更加有效。
这个设置的阈值,仅对于shuffle过程中的合并频率产生影响。
|
mapreduce.reduce.shuffle.input.buffer.percent
|
float
| 内存百分比,相对于在 mapreduce.reduce.java.opts中指定的最大的块大小,在shuffle过程中,能分配给map outputs的分组内存。虽然应该为框架预留一些内存,一般来说,该参数设置得足够高,去存储大量数据和大量的map outputs是有利的。 |
mapreduce.reduce.input.buffer.percent
|
float
|
内存百分比,
相对于map outputs到reduce之间最大的块大小。当reduce开始运行时, map outputs将被合并到磁盘,直到这些记录在这个定义的资源限制以下为止。默认情况下,在reduce开始运行之前,所有的map outputs都将合并到磁盘,这样可以使reduce有最大的可用内存。内存密集型的reduces,应该调大这个值,避免读写磁盘。
|
其他说明:
- 如果一个map output大于分配给复制所有map outputs的内存25%以上,那么,它将直接被写入磁盘,而不需要经过内存。
- Combiner运行时,关于高合并阈值和大缓存区的推理可能不成立。所有map outputs被取出之前,合并就已经开始了,Combiner当溢出到磁盘的时候,才开始运行。在某些情况下,通过占用资源的合并map outputs 而制造出小的溢出,好过去增大缓冲区的大小,更能达到最优reduce时间。
- 当合并开始,内存中的map outputs写到磁盘同时开始reduce运行,如果中间的合并是必须的,因为存在溢出段和mapreduce.task.io.sort.factor定义的段至少会被写入磁盘,在内存中的map outputs将被合并到中间数据集中。
十四、参数配置:
下列属性被定位于每个任务运行的作业配置。
参数名称
|
参数类型
|
描述
|
mapreduce.job.id | String | 作业的id |
mapreduce.job.jar
|
String
|
job.jar的工作目录
|
mapreduce.job.local.dir
|
String
|
job指定的共享活动空间
|
mapreduce.task.id
|
String
| 任务id |
mapreduce.task.attempt.id
|
String
| 尝试任务id |
mapreduce.task.is.map
|
boolean
|
该任务是否为map任务
|
mapreduce.task.partition
|
int
| 作业中,任务的id |
mapreduce.map.input.file
|
String
|
map方法正在读取的文件名
|
mapreduce.map.input.start
|
long
|
map分割input的偏移量
|
mapreduce.map.input.length
|
long
|
map分割input的字节数
|
mapreduce.task.output.dir
|
String
|
任务的临时输出目录
|
说明:
一个流作业(streaming job)执行过程中,名称中有“mapreduce”的参数会被改变。点(.)会被变成下划线(_)。比如:mapreduce.job.id 会变成 mapreduce_job_id ,还有 mapreduce.job.jar 会变成 mapreduce_job_jar 。在流作业的mapper或reducer中,要通过带有下划线的参数名才能获取到值。
十五、Task的日志:
task的标准输出、错误输出和系统日志,可以通过NodeManager 进行读取和直接写入到
${HADOOP_LOG_DIR}/userlogs 路径下。
十六、Distributing Libraries(分布式库):
DistributedCache 也能被分布在jars和本地库之间,用到map或reduce任务中。child-jvm总是有自己的当前工作目录,这目录被添加到 java.library.path and LD_LIBRARY_PATH 。因此,缓存库可以通过
system.loadlibrary 或
system.load 进行加载。如何通过分布式缓存加载共享库的详细信息,被记录在:
Native Libraries 。
十七、作业的提交及监测:
Job是用户作业与
ResourceManager (资源管理器)主要接口。Job提供一个装置,用来提交作业,追踪作业执行情况,使用组件进行报告和写日志,获取MapReduce客户端机器的状态信息等等。
作业提交过程包括:
- 检查Job指定的输入和输出格式;
- 运算Job的InputSplit的值;
- 必要时,为Job的 DistributedCache 设置必须的统计信息;
- 复制Job的jar包到文件系统中MapReduce系统目录中;
- 提交作业给 ResourceManager 和随机监测它的状态。
Job的历史文件也会被记录在用户指定的目录:mapreduce.jobhistory.intermediate-done-dir 和 mapreduce.jobhistory.done-dir ,作为Job的默认输出目录。
用户可以用下面的命令行查看指定目录中的历史日志的概要信息:(
未试成功)
$ mapred job -history output.jhist
该命令将打印作业的详情,作业失败和死亡的提示详情。
作业的更多详情,如执行成功的任务和为每个任务的尝试,可以通过下面的命令来查看:(
未试成功)
$ mapred job -history all output.jhist
一般情况下,用户利用Job来创建应用程序,描述Job的各个方面,提交Job,并监测其执行情况。
十八、Job Control:
用户可能需要连接多个MapReduce Job 一起来完成一系列复杂的任务。这是相当容易的,因为Job的输出一般都存储在分布式文件系统中,反过来说,Job的output可以作下个任务的输入。
那么,这也意见着,每个客户机器,都需要确保Job已经执行完毕(不管是成功或者失败)。作业的控制方式有如下两种:
- Job.submit() : 将作业提交给集群,并立即返回。
- Job.waitForCompletion(boolean) : 将作业提交给集群,并等待作业完成。
十九、Job Input:
InputFormat 描述了一个MapReduce作业的输入规范。MapReduce框架依赖于InputFormat进行工作:
- 校验输入是否规范;
- 将输入文件进行逐一的拆分成,拆分成符合框架逻辑的InputSplit实例,然后每一个InputSplit实例都被分配到一个独立的Mapper。
- RecordReader 实现了从符合框架逻辑的InputSplit实例收集输入的记录,提供给Mapper进行处理。
InputFormat的默认实现,通常是FileInputFormat的子类,对输入的文件(以byte为单位)进行分割,分割为符合框架逻辑的InputSplit实例。以文件系统的block大小,作为输入文件的分割界线。如果分隔线以下的文件,要进行分割,则可以通过mapreduce.input.fileinputformat.split.minsize 进行设置。
显然,遵守记录边界,基于输入文件的大小进行逻辑分割,是不以支持许多应用程序的。在这种情况下,应用程序应该实现RecordReader ,负责关联记录边界和提出一个面向记录逻辑分割的视图给每个任务。
TextInputFormat是默认的InputFormat。
如果Job的InputFormat是由TextInputFormat提供的,框架检查文件是.gz的扩展名文件,则会自动使用合适的CompressionCodec,对文件进行自动解压。然而,需要特别指明的是,.gz的压缩文件,是不能进行分割的,每个压缩文件只能由一个Mapper进行处理。
19.1 InputSplit:
InputSplit代表一个Mapper对数据进行处理。
通常情况下,InputSplit提供了一个面向字节的输入,负责对RecordReader 进行处理,并提出一个面向记录的视图。
FileSplit是默认的InputSplit。它把输入的文件路径设置到mapreduce.map.input.file ,用于进行逻辑分割。
19.2 RecordReader:
RecordReader从一个InputSplit中读取<key,value>。
通常RecordReader把input转换成面向字节的输入,然后提供给InputSplit,再提供一个面向记录的输入给Mapper实例进行处理。从而RecordReader承担起从记录中提取键值对的任务。
二十、Job Output:
OutputFormat 描述了MapReduce作业的输出规范。
框架依赖OutputFormat进行工作的格式为:
- 输出规范性校验;例如:检查输出目录是否存在。(输出目录不能存在)
- 提供RecordWriter实例,将Job的结果写到outputs文件中,并存放到分布式文件系统中;
TextOutputFormat是默认的 OutputFormat.
20.1 OutputCommitter:
OutputCommitter描述一个已提交的MapReduce作业的任务输出。
MapReduce框架job依赖的OutputCommitter,可以用来:
- 在初始化过程中,设置Job。例如,在job初始化过程中,为Job创建临时输出目录。当Job处于预备(PREP)状态和所有的task都初始化完毕后,通过一个单独的task来配置Job。一旦配置job的task执行完成,则Job的状态会变为运行中(RUNNING)。
- Job执行完毕,清理Job。例如,Job执行完毕后,删除掉为Job创建的临时输出目录。Job清理是由一个单独的task来执行的,在job结束后被执行。Job宣告执行完毕的状态有(SUCCEDED,FAILED,KILLED),然后完成Job的清理工作。
- 设置task的临时输出。task初始化期间,task配置将作为相同任务的一部分,在初始化过程中完成task设置。
- 检查task是否需要进行提交。这样是为了避免无用的提交。如果一个task不需要提交,那 就不提交。
- 提交task的输出。task一旦完成,如果有输出的,那么task会提交输出。
- 放弃提交任务。如果task被标志为:failed,killed,那么task的输出将被清理掉。如果task清除失败(发生异常块),那么将会启动一个单独的task(具有相同的尝试ID),继续完成task的清理工作。
FileOutputCommitter 是默认的 OutputCommitter。在NodeManager中,Job的设置和清除都会占用map或reduce的容器,不管是哪一个都是有用的。JobCleanup task TaskCleanup task JobSetup task 拥有最高的优先级,他们三个的优化级,按照该顺序。
20.2 Task Side-Effect(副作用) Files :
一些应用程序,任务组件需要创建或写入数据到站点中的目录,而这个目录与最终job的输出目录又一样。两个相同实例的Mapper,Reducer同时运行(例如:推测作业),它们可能打开或写入分布式文件系统中的相同目录,在这种情况下可能会出现问题。因此,应用程序不得不为每一个尝试作业定义一个唯一的名称(
使用attemptid,则表示为: attempt_200709221812_0001_m_ 000000 _0
),而不是为每个作业。
框架为了避免这种问题,当OutputCommitter是FileOutputCommitter的时候,保持一个特殊的输出${mapreduce.output.fileoutputformat.outputdir}/_temporary/_${taskid},子目录可以通过${mapreduce.task.output.dir}为每个尝试作业在文件系统中建立其对应的输出目录。在成功完成尝试任务后 ,在${mapreduce.output.fileoutputformat.outputdir}/_temporary/_${taskid}中的文件将被移到${mapreduce.output.fileoutputformat.outputdir}目录中。当然,框架会丢弃掉执行失败的尝试作业其对应目录中的文件,这个过程对于应用程序是完全透明的。
在task执行过程中,通过FileOutputFormat.getWorkOutputPath(Conext),应用程序的application-writer,能够利用这个特性,在${mapreduce.task.output.dir} 目录下面,创建任务需要的任何side-files。框架将促使他们完成尝试任务,从而消除需要为每个尝试任务指定一个唯一目录的需要。
注意事项:
特定的尝试任务执行期间的${mapreduce.task.output.dir}的值,事实上是${mapreduce.output.fileoutputformat.outputdir}/_temporary/_{$taskid}值,这个值是由框架来设置的。所以,刚刚通过FileOutputFormat.getWorkOutputPath(Conext)返回目录来创建的任何一个side-files,都是从MapReduce 作业利用这一特性而得来的。
整个讨论过程,适用于没有Reducer的Maps的输出,在这情况下,将直接写入到HDFS中。
18.3 RecordWriter:
RecordWriter写入<key,value>键值对到输出文件中。
RecordWriter实现将Job的导出写到文件系统中。
二十一、Other Useful Features(其他有用的特性):
21.1 Submitting Jobs to Queues (提交Job到队列中):
用户可以把Job提交到队列(Queues)中。Queues,是一个Job集合,允许系统提供特别的功能。例如,Queues用ACLs来控制,哪些用户可以向它提交作业。Queues期待被作为Hadoop的主要调度器。Hadoop配置了一个叫“default”的强制queue。Queue的名称定义在mapreduce.job.queuename 直接下层property 节点中(Hadoop site configuration文件中)。有些作业调度器支持多个Queues,如Capacity Scheduler(容量调度器)。
一个Job要定义queue,它通过mapreduce.job.queuename属性来提交,或者通过Configuration.set(MRJobConfig.QUEUE_NAME, String)应用程序接口进行提交。设置Queue的名称是可选的。如果一个作业被提交时没有指定queue名称,那么该Job将被提交到“default”queue。
21.2 Counters :
Counters 代表全局的计数器,由MapReduce框架或应用程序自行定义。每个Counter可以是任何的枚举类型。某个枚举类型的都在Counters.Group这个类型组中。在map、reduce方法中,应用程序可以通过Counters.incrCounter(Enum, long) 或者Counters.incrCounter(String, String, long) 来定义任意计数器(任意枚举型的计数器)和更新计数器。这些Counter作为全局计数器被框架进行汇总。
21.3 DistributedCache :
DistributedCache 使分发应用程序指定的,大的,只读的文件更有效。
DistributedCache 是一个由MapReduce框架提供的设备,用于缓存应用程序需要的文件(text,archives,jars等等)。
在Job中,应用程序可以通过Url(hdfs://)指定需要被缓存的文件。DistributedCache 会假定该文件已存在文件系统中。在Job任务在节点上运行之前,框架将会把task所需的文件复制到该slave节点中。它的功效源于一个事实,在slave节点中,每个job只能复制一次文件,它能缓存未归档的文件。DistributedCache会跟踪文件修改的时间
戳。显示,在Job运行过程中,缓存文件不应该被应用程序及外部修改。
DistributedCache能够被用于分发简单的,只读的数据或者文本文件和其他复杂类型的文件,如:archives,jars等等。在slave节点中,archives(zip,tar,tgz,tar.gz文件)都是未归档文件。文件具有执行权限集。
通过设置mapreduce.job.cache.{files|archives}属性,files或者archives能进行分布缓存。如果有多个文件或者归档文件想进行分布缓存,可能通过“,”逗号分隔字符串路径来指定。也可以通过应用程序接口: Job.addCacheFile(URI)/ Job.addCacheArchive(URI) and Job.setCacheFiles(URI[])/ Job.setCacheArchives(URI[]) 来设置,这里面的URI为 hdfs://host:port/absolute-path#link-name。在流作业中,还可以通过命令行:-cacheFile/-cacheArchive来设置。
DistributedCache也可以作为一种基本的软件分发机制,用于map、reduce作业中。它能被用于jar包和本地库。Job.addArchiveToClassPath(Path) 、Job.addFileToClassPath(Path) 应用程序接口,能用于缓存文件或者Jar包,也可以向child-jvm的classpath 添加。同样也可以通过配置文件 mapreduce.job.classpath.{files|archives}实现。同样的缓存文件,被系统连接到task的工作目录,能被用于分布本地库和加载。
23.3.1 Private and Public DistributedCache Files:
DistributedCache文件可以是公有的,也可以是私有的,这决定了这些文件如何在slave节点间共享。
- 私有的:DistributedCache文件被缓存在本地目录中,供私人的Job使用。这些文件共享仅给指定用户的所有的task和jobs,并不能供slaves上的其他用户使用。借用文件系统的权限来把文件变成私有的文件,这个文件系统一般为HDFS。
- 公有的:DistributedCache文件被缓存在全局的目录中,文件对于所有用户都是公开的,可见的。这些文件能供slaves上所有用户的task,job使用。借用文件系统的权限来把文件变成公有的文件,这个文件系统一般为HDFS。如果用户打算使一个文件变为公有的,那么文件权限设置为word readable,而且目录必须设置为executable。
23.4 Profiling(分析器):
分析器一个通用的程序,以获取一个有代表性的(2或3个)样本,为maps和reduces的样本而内置的java工具。用户可以指定系统是否需要为一些任务收集探测信息,可以通过配置文件属性来指定:mapreduce.task.profile。这个值也可以通过应用程序API来设置:Configuration.set(MRJobConfig.TASK_PROFILE, boolean)。如果设置为ture,作业启用分析器,探查信息存储在用户日志目录中。默认情况下,作业不启用分析器。
一旦用户启用分析器,就可以通过mapreduce.task.profile.{maps|reduces}属性,来设置分析器的分析范围。这个值也可以通过应用程序API来设置:Configuration.set(MRJobConfig.NUM_{MAP|REDUCE}_PROFILES, String)。
默认情况下,指定的范围是0-2。
用户可以指定分析器的参数,通过配置属性:mapreduce.task.profile.params。这个值也可以通过应用程序API来设置:Configuration.set(MRJobConfig.TASK_PROFILE_PARAMS, String)。如果该字符串包含"
%s",则将在任务运行时替换分析输出文件的名称。这些参数将被传递给task child JV 命令行上。分析器参数的默认值是:-agentlib:hprof=cpu=samples,heap=sites,force=n,thread=y,verbose=n,file=%s。
23.5 Debugging:
MapReduce框架提供一个设备用于运行用户提供调试的脚本。以处理任务日志为例,当一个task运行失败时,用户可以运行一下调试脚本。脚本是获得任务的stdout和stderr输出,系统日志和jobconf。从调试脚本的stdout和stderr输出显示在控制台诊断器上,也被视为Job的UI的一部分。下面的章节,接讨论用户如何提交一个调试脚本。脚本文件需要分发并提交给框架。
如何分发脚本文件:
用户需要使用distributedcache分发和使用脚本文件。
如何提交脚本:
提交调试脚本的快速方法是为属性设置值:mapreduce.map.debug.script 和 mapreduce.reduce.debug.script ,分别用于调试map和reduce。这些属性也可以通过应用程序接口来设置:Configuration.set(MRJobConfig.MAP_DEBUG_SCRIPT, String) 和Configuration.set(MRJobConfig.REDUCE_DEBUG_SCRIPT, String)。如果在流工作中,也可以通过命令行来设置:-mapdebug 和 -reducedebug 。
脚本的参数是任务的stdout,stderr,syslog和jobconf文件。
调试命令,运行在MapReduce任务失败的节点,是:
$script $stdout $stderr $syslog $jobconf
23.6 Data Compression(数据压缩):
Hadoop MapReduce为application-writer提供了一个为map-outputs和job-outputs指定压缩算法的设备。框架还附带了CompressionCodec实现的一个zlib压缩算法。gzip, bzip2, snappy, and lz4 格式的文件都支持。
Intermediate Outputs:
通过应用程序API:Configuration.set(MRJobConfig.MAP_OUTPUT_COMPRESS, boolean),应用程序可以控制对map-outputs进行压缩,通过应用程序API:Configuration.set(MRJobConfig.MAP_OUTPUT_COMPRESS_CODEC, Class) ,启用压缩算法CompressionCodec。
Job Outputs:
通过应用程序API:FileOutputFormat.setCompressOutput(Job, boolean),应用程序可以控制对 job-outputs进行压缩。通过应用程序API:FileOutputFormat.setOutputCompressorClass(Job, Class),可以启用压缩算法:
CompressionCodec。
如果Job-outputs存储在 SequenceFileOutputFormat中,则需要通过应用程序API:SequenceFileOutputFormat.setOutputCompressionType(Job, SequenceFile.CompressionType),指定SequenceFile.CompressionType (i.e. RECORD / BLOCK - defaults to RECORD)。
Skipping Bad Records(跳过不良计录):
Hadoop 提供一个设置项,明确的设置了不良的输入记录,当map处理输入记录时,这些不良的输入记录将被跳过。应用程序可以通过SkipBadRecords类,来控制这个特性。此特性可以用于在明确map任务遇到损坏的输入记录的时候。这通常是由于map方法中有bug所导致的。通常情况下,用户必须修复这些bug。然而,这些bug有时候是无法修复的。例如,有些bug存在于第三方代码库,第三方代码库的代码是无法修改的。在这种情况下,task失败是必须的,即使是多次的尝试,job最终还是失败。用了这个特性,仅仅是丢弃一小部分的不良数据,对一个应用程序来讲是可以忽略的(对非常大的数据进行统计的情况下)。
默认情况下该特性是开启的。要开启,需要指定: SkipBadRecords.setMapperMaxSkipRecords(Configuration, long) 和 SkipBadRecords.setReducerMaxSkipGroups(Configuration, long)。启用这个特性,框架会在一定数量的map task失败后,进入“跳跃模式”。更多的详情见:SkipBadRecords.setAttemptsToStartSkipping(Configuration, int)。在“跳跃模式”下,map任务,将保持对其范围内的数据的处理。要做到这一点,该框架要依靠Counter(计数器)的处理结果。可以查看:SkipBadRecords.COUNTER_MAP_PROCESSED_RECORDS 和SkipBadRecords.COUNTER_REDUCE_PROCESSED_GROUPS 了解更多详情。这个Counter可以令框架知道有多少记录处理成功,多少范围的记录处理失败。再进一步尝试后,这些范围的记录就会被丢弃。
被丢弃的记录的数量依据应用程序的Counter频繁的处理记录。推荐,Counter在每个记录被处理完成后,再进行增加计数。在一些批处理应用程序中,有可能不会出现这种情况。在这种情况下,框架可以跳过
不良记录周围的记录。用户可控制跳过记录的数量:SkipBadRecords.setMapperMaxSkipRecords(Configuration, long) 和SkipBadRecords.setReducerMaxSkipGroups(Configuration, long) 设置。框架将通过折半搜索,尝试缩小跳过的记录的数量。跳过过的记录被分为两半,先执行一半。在失败后,框架就能知道哪一半包含不良记录。这个任务将被重复执行,直到不良记录被找到或所有
尝试任务都耗尽。想要增加尝试任务的数量,可以设置: Job.setMaxMapAttempts(int) and Job.setMaxReduceAttempts(int)。
跳过的文件会被写到HDFS中的序列格式文件中,以便后来进行分析。存储位置可以设置:SkipBadRecords.setSkipOutputPath(JobConf, Path)。
23.7 实例 WordCount v2.0:
这个例子,应用了到目前为止,我们讨论过的框架的很多个特性。首先,HDFS需要启动,处于运行中。特别是对distributedcache相关特征。因此,它只适用于伪分布式或完全分布式的Hadoop的环境。