hadoop map-reduce中的文件并发操作

所属分类: 数据库 / 数据库其它 阅读数: 96
收藏 0 赞 0 分享

这样的操作在map端或者reduce端均可。下面以一个实际业务场景中的例子来简要说明。

问题简要描述:

假如reduce输入的key是Text(String),value是BytesWritable(byte[]),不同key的种类为100万个,value的大小平均为30k左右,每个key大概对应 100个value,要求对每一个key建立两个文件,一个用来不断添加value中的二进制数据,一个用来记录各个value在文件中的位置索引。(大量的小文件会影响HDFS的性能,所以最好对这些小文件进行拼接)

当文件数量较小时,可以考虑使用MultipleOutput来进行key-value的分流,可以按照key的不同,将其输出到不同的文件或者目录中。但是reduce的数量只能为1,不然每个reduce都会生成相同的目录或者文件,不能达到最终的目的。此外最重要的是,操作系统对每个进程打开的文件数量的限制,默认为1024,集群的各个datanode可能会配置更高的值,但最多在几万左右,仍然是一个限制因素。不能满足百万文件的需求。

reduce的主要目的是用来归并key-value并输出到HDFS上,我们当然也可以在reduce中进行其他的操作,比如文件读写。因为默认的partitioner保证同一个key的数据肯定会在同一个reduce中,所以在每个reduce中只用打开两个文件进行读写即可(一个索引文件,一个数据文件)。并发度由reduce数量决定,将reduce数量设为256,那我们就可以同时处理256个key的数据(partioner保证了不同reduce处理的key不同,不会引起文件读写冲突)。这样的并发度的效率是很客观的,可以在较短的时间内完成需求。

思路是这样,但同时由于hdfs的特性以及hadoop的任务调度,在文件读写过程中,仍有可能会出现很多问题,下面简要说些一些常见的会碰到的问题。

1.org.apache.hadoop.hdfs.protocol.AlreadyBeingCreatedException异常

这可能是最经常碰到的一个问题。可能的原因如下:

(1)文件流冲突。

一般创建文件时都会打开一个供写入的文件流。而我们希望是追加,所以如果使用了错误的API ,就有可能引起上述问题。以FileSystem类为例,如果使用create()方法之后再调用append()方法,就会抛出上述异常。所以最好使用createNewFile方法,只创建文件,不打开流。

(2)mapreduce推测执行机制

mapreduce 为了提高效率,会在一个任务启动之后,同时启动一些相同的任务(attempt),其中有一个attempt成功完成之后,视为整个task完成,其结果 作为最终结果,并且杀掉那些较慢的attempt。集群一般会开启此选项以优化性能(以空间换时间)。但在本问题环境下推测执行却不太合适。因为我们一般希望一个task 用来处理一个文件,但如果启动推测执行,会有几个attempt同时试图操作同一个文件,就会引发异常。所以最好关掉此选项,将 mapred.reduce.max.attempts 设为1,或者将mapred.reduce.tasks.speculative.execution设为false.

但此时仍有可能会出现问题。因为如果一个task的唯一attempt出现问题,在被kill掉之后,task仍会另起一个attempt,此时因为前一个attempt异常终止,仍有可能会影响到新起的attempt的文件操作,引发异常。所以最安全的方法是,借鉴推测执行的机制(每个attempt各自生成自己的结果,最终选择一个作为最终结果),以每个attempt的id号为后缀附加到所操作的文件上,同时捕获所有文件操作的异常并处理,这样可避免文件的读写冲突。Context可以用来获取运行时的一些上下文信息,可以很容易得到attempt的id号。注意,此时如果开启推测执行也可以,但是会生成很多相同的文件(每个attempt一份),仍然不是最好的解决方法。

同时,我们可以利用reduce的输出来记录运行“不正常的” key.这些task大多数是attempt_0被杀掉而重启了一个attempt_1,所以下面的文件一般为两份。可以对这些情况的key输出(文件异常或者attemptID > 0),并进行一些后续处理,比如文件重命名,或者紧对这些key重新写入。因为此种情况的key一般只占极少数,所以并不影响总体的效率。

2.文件异常处理

最好能将mapreduce中的所有文件操作都设置好异常处理。不然一个文件异常就有可能会使整个job失败。所以从效率来讲,最好是在文件发生异常时将其key作为reduce的输出以进行记录。因为同时mapreduce会重启一个task attempts重新进行文件读写,可保证我们得到最终的数据,最后所需的只是对那些异常的key进行一些简单的文件重命名操作即可。

3.多目录以及文件拼接

如果我们将key的种类设为1000万,上述方法会生成太多的小文件从而影响hdfs的性能,另外,因为所有文件都在同一个目录下,会导致同一个目录下文件数目过多而影响访问效率。

在创建文件的同时建立多个子目录,一个有用的方法是以reduce的taskid来建立子目录。这样有多少个reduce就可以建立多少个子目录,不会有文件冲突。同一个reduce处理的key都会在同一个目录下。

文件拼接要考虑的一个索引的问题。为了将文件索引建立的尽量简单,应该尽量保证同一个key的所有数据都在同一个大文件中。这可以利用key的hashCode来实现。如果我们想在每个目录下建立1000个文件,只需将hashCode对1000取余即可。

更多精彩内容其他人还在看

sql注入之新手入门示例详解

这篇文章仅仅是对SQL注入进行了一个简单的入门知识的讲解,是sql注入的基础篇,有个好的开头能够帮助大家对SQL注入有一个具体清晰的了解和认识。下面来一起看看吧,有需要的可以参考借鉴。
收藏 0 赞 0 分享

sql注入之手工注入示例详解

之前和大家分享了基本的SQL注入的知识,这一篇讲的就是在得知注入点的之后,如何有效地进行脱裤。文章通过示例介绍的很详细,对大家的理解和学习很有帮助,下面来一起看看吧。
收藏 0 赞 0 分享

SQL注入之基于布尔的盲注详解

首先说明的盲注是注入的一种,指的是在不知道数据库返回值的情况下对数据中的内容进行猜测,实施SQL注入。盲注一般分为布尔盲注和基于时间的盲注。这篇文章主要讲解的是基于布尔的盲注。下面来一起看看吧。
收藏 0 赞 0 分享

node-mysql中防止SQL注入的方法总结

大家都知道SQL注入对于网站或者服务器来讲都是一个非常危险的问题,如果这一方面没处理好的话网站可能随时给注入了,所以这篇文章就给大家总结了node-mysql中防止SQL注入的几种常用做法,有需要的朋友们可以参考借鉴。
收藏 0 赞 0 分享

SQL中Having与Where的区别及注意

这篇文章给大家详细的介绍了SQL中Having与Where的区别,以及这两者的注意事项,文中还分享了Having与Where的示例代码,相信对大家的理解和学习很有帮助,感兴趣的朋友们可以参考借鉴,有需要的朋友们可以一起学习学习。
收藏 0 赞 0 分享

浅析sql server 公共表达式的简单应用

本文主要对sql server 公共表达式的简单应用进行介绍,具有一定的参考价值,有需要的可以看下
收藏 0 赞 0 分享

Mybatis查询延迟加载详解及实例

这篇文章主要介绍了Mybatis查询延迟加载详解及实例的相关资料,Mybatis的延迟加载默认是关闭的,即默认是一次就将所有的嵌套SQL一并查了将对象所有的信息都查询出来。开启延迟加载有两种方式,需要的朋友可以参考下
收藏 0 赞 0 分享

SQL注入详解(扫盲篇)

刚进公司的时候,研究的主要是SQL注入,因为之前没有搞过安全,所有费了好长一段时间对SQL注入基本知识进行了解。所以这篇文章并不是什么很深入的技术博客,或许应该叫它‘ SQL注入扫盲 ’有需要的朋友可以参考学习,下面来一起看看吧。
收藏 0 赞 0 分享

SQL注入绕过的技巧总结

这篇文章主要给大家总结了一些关于SQL注入绕过的技巧,其中包括引号绕过、逗号绕过以及比较符(<,>)绕过,文中给出了详细的介绍和示例代码,相信对大家具有一定的参考价值,需要的朋友们下面来一起看看吧。
收藏 0 赞 0 分享

利用reverse索引优化like语句的方法详解

这篇文章主要介绍了关于利用reverse索引优化like语句的方法,文中通过图文介绍的很详细,相信对大家具有一定的参考价值,需要的朋友们下面来一起看看吧。
收藏 0 赞 0 分享
查看更多