hdfs 的分布式缓存

DistributedCache是Hadoop提供的文件缓存工具,它能够自动将指定的文件分发到各个节点上,缓存到本地,供用户程序读取使用。。它具有以下几个特点:缓存的文件是只读的,修改这些文件内容没有意义;用户可以调整文件可见范围(比如只能用户自己使用,所有用户都可以使用等),进而防止重复拷贝现象;按需拷贝,文件是通过HDFS作为共享数据中心分发到各节点的,且只发给任务被调度到的节点。

DistributeCache的命令方式:
[list]
[*] (1)-files:将指定的本地/hdfs文件分发到各个Task的工作目录下,不对文件进行任何处理;
[*] (2)-archives:将指定文件分发到各个Task的工作目录下,并对名称后缀为“.jar”、“.zip”,“.tar.gz”、“.tgz”的文件自动解压,默认情况下,解压后的内容存放到工作目录下名称为解压前文件名的目录中,比如压缩包为dict.zip,则解压后内容存放到目录dict.zip中。为此,你可以给文件起个别名/软链接,比如dict.zip#dict,这样,压 缩包会被解压到目录dict中。
[*] (3)-libjars:指定待分发的jar包,Hadoop将这些jar包分发到各个节点上后,会将其自动添加到任务的CLASSPATH环境变量中。
[/list]

自己在写MAR/REDUCE代码时,遇到了一个问题,一个大数据文件和一个小数据文件匹配计算,但是小数据文件太小,所以想采用HIVE的MAP JOIN的方式,把小数据文件放到直接大数据文件map的datanode的内存中,这样少了MR代码的1对N的数据文件关联。

实现这个的最佳方案就是利用distributed cache。HIVE的MAP JOIN也是利用这个技术。

首先简要介绍一下distributed cache是如何使用的,然后总结下自己在使用distributed cache遇到的问题,这些问题网上也有人遇到,但是没有给出明确的解释。希望能够帮助同样遇到此类问题的朋友。

distributed cache至少有如下的两类类应用:

[list]
[*] MAP、REDUCE本身和之间共享的较大数据量的数据
[*] 布置第三方JAR包,可以避免集群的删减导致部分依赖的机器的JAR包的丢失
[/list]


distributed cache使用的流程总结如下:

[list]
[*]1.在HDFS上准备好要共享的数据(text、archive、jar)
[*]2.在distributed cache中添加文件
[*]3.在mapper或者reducer类中获取数据
[*]4.在map或者reduce函数中使用数据
[/list]

[color=red]1.数据本来就在HDFS上,所以省去了流程中的第一步[/color]
可以使用hadoop fs -copyFromLocal把本地文件cp到HDFS上
[color=red]2.在distributed cache中添加文件[/color]


public static void disCache(String dimDir, JobConf conf) throws IOException {
FileSystem fs = FileSystem.get(URI.create(dimDir), conf);
FileStatus[] fileDir = fs.listStatus(new Path(dimDir));
for (FileStatus file : fileDir) {
DistributedCache.addCacheFile(URI.create(file.getPath().toString()), conf);
}
}


因为我利用的数据是HIVE脚本生成的,所以无法指定具体的文件路径,采用这种方式把一张HIVE表的所有数据都加载到cache中。如果能直接明确知道文件名称就简单很多了,例如:

DistributedCache.addCacheFile(URI.create(“/mytestfile/file.txt”), conf);


[color=red]3.在mapper或者reducer中获取数据[/color]


public void configure(JobConf job) {
try {
urlFile = DistributedCache.getLocalCacheFiles(job);
seoUrlFile = "file://" + urlFile[0].toString();
allUrlFile = "file://" + urlFile[1].toString();
FileReader reader = new FileReader(seoUrlFile );
BufferedReader br = new BufferedReader(reader);
System.out.println("this is OK");
String s1 = null;

int i=0;

while((s1 = br.readLine())!=null){
String[] word = s1.split("\\|");

//do something you want
}
}

br.close();
reader.close();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}


我在流程2中添加了两个文件,通过DistributedCache.getLocalCacheFiles(job)获取Path[],针对不同文件调用getData,把文件数据放在不同的List中seoUrlDim,allUrlDim
如此一来,distributed cache的过程就结束了,接下来就在map()或者reduce()中使用这些数据就OK了。

[color=red]4.在map或者reduce函数中使用数据[/color]
一定要区分流程3和4,3是获取数据,4是使用数据。我就是在前期没弄明白这个的差异,导致内存溢出。

虽说好像挺简单的,但是在实现这个代码的过程中有如下几个问题困扰了我好久,网上也没找到很好的解决方案,后来在兄弟的帮助下搞定

[list]
[*]1.FileNotFoundException
[*]2.java.lang.OutOfMemoryError: GC overhead limit exceeded
[/list]

1.FileNotFoundException
这个问题涉及到DistributedCache.getLocalCacheFiles(job) 这个函数,此函数返回的Path[]是执行map或者reduce的datanode的本地文件系统中路径,但是我在getData中利用的SequenceFile.Reader的默认filesystem是hdfs,这就导致获取数据时是从hdfs上找文件,但是这个文件是在本地文件系统中,所以就会报出这个错误FileNotFoundException。
例如,DistributedCache.getLocalCacheFiles(job)返回的PATH路径是:/home/dwapp/hugh.wangp/mytestfile/file.txt,在默认文件系统是hdfs时,获取数据时会读hdfs://hdpnn:9000/home/dwapp/hugh.wangp/mytestfile/file.txt,但是我们是在本地文件系统,为了避免数据获取函数选择"错误"的文件系统,我们在/home/dwapp/hugh.wangp/mytestfile/file.txt前加上"file://",这样就会从本地文件系统中读取数据了。就像我例子中的seoUrlFile = "file://" + urlFile[0].toString();

2.java.lang.OutOfMemoryError: GC overhead limit exceeded
这个问题是我在没搞明白如何使用distributed cache时犯下的错误,也就是我没弄明白流程3和4的区别。我把流程3中说的获取数据的过程放在map函数中,而在map函数中其实是使用数据的过程。这个错误因为使每用一个map就要获取一下数据,也就是初始化一个list容器,使一个datanode上起N个map,就要获取N个list容器,内容溢出也就是自然而然的事情了。
我们一定要把获取数据的过程放在mapper或reducer类的configure()函数中,这样对应一个datanode就只有一份数据,N个map可以共享着一份数据。


内容单薄,望志同道合之士互相学习。

原文:[url]http://hugh-wangp.iteye.com/blog/1468989[/url]

你可能感兴趣的:(hdfs)