Hadoop 2.6.5 FileSystem和Configuration两个对象的探究

Posted 2020-09-28 北京尚学堂旗下-云数学院

Hadoop 2.6.5 FileSystem和Configuration两个对象的探究

 

版权声明：本文为yunshuxueyuan原创文章，如需转载，请标明出处。【http://www.cnblogs.com/sxt-zkys/】
QQ技术交流群：299142667

 

 (结论)

通过尚学堂旗下云数学院大数据周老师的讲解可以得到以下结论：用相同的地址获取的FileSystem对象是同一个; 第一次获取对象后会有类似于缓存的机制, 即使改变了configuration参数, 只要地址没有发生变化, 获取的FileSystem 对象不会改变.

[从bug开始]

在测试上传数据到HDFS集群时, 想更改blocksize的大小来测试小文件分块的情况, 使用了如下代码(为了便于阅读, 删去了JUNIT的注解):

 

Configuration conf = null; FileSystem fs = null; 

 //初始化fs对象 

 conf = new Configuration(true); 

 fs = FileSystem.get(conf);

 //更改blocksize大小 

 conf.set("dfs.blocksize", "1048576"); 

 fs = FileSystem.get(conf); 

 //上传文件

 Path srcPath = new Path("d:\\\\testup.txt");

 Path dstPath = new Path("/user/root/test03.txt");

 fs.copyFromLocalFile(srcPath, dstPath);

 

 

从结果来看, 生成的文件大小并没有改变:

 

那我们重新定义一个FileSystem来尝试一下:

于是接着上段代码, 有了如下代码:

 

//初始化fs2对象 

 Configuration conf2 = new Configuration(true);

 conf2.set("dfs.blocksize", "1048576"); 

 FileSystem fs2 = FileSystem.get(conf2); 

 //上传文件 

 Path dstPath2 = new Path("/user/root/test04.txt");

 fs2.copyFromLocalFile(srcPath, dstPath2);

 

然而结果并不乐观:

此时其他的小伙伴@2元店主 已经完成了测试, 上传文件成功, 并且设置分块大小也没有问题, 他的代码如下:

//初始化fs对象 

 Path srcPath = new Path("d:\\\\testup.txt"); 

 Path dstPath = new Path("/user/root/test07.txt"); 

Configuration confnew = new Configuration(true);

 confnew.set("dfs.blocksize", "1048576"); 

 FileSystem fsnew = FileSystem.get(confnew); 

 //上传文件 

 fsnew.copyFromLocalFile(srcPath, dstPath);

 

对比可以发现, 其中的核心代码并没有什么差异, 那么是什么问题引起的blocksize改变不成功呢?

经过尚学堂同班同学的大力协助, 我们确定了差异点, 在我的测试代码中, 先从配置(conf)生成过了一次FileSystem对象, 更改的blocksize后再次生成FileSystem对象. 可能是这个过程出现了问题.

如果是这个问题, 那么我的第二次测试的代码也失效根本说不过去, 因为我是全新的对象, 与之前对象并无关联.

到了这里, 我们对bug的产生有了一些思路.

 

[进一步测试]

为了明确具体的问题所在, 有了如下代码:

因为下面的代码长得我都不想仔细读, 所以在这里说一下大概思路:

测试代码两两一组, 每组获取FileSystem对象用的地址是相同的;

第一组读取本地配置文件, 先生成FileSystem对象后更改blocksize配置, 再次生成FileSystem对象

第二组不读取本地配置文件, 地址是node01, 先更改blocksize为1M, 生成FileSystem对象, 改变blocksize为128M, 再次生成FileSystem对象

第三组不读取本地配置文件, 地址是192.168的具体地址, 先更改blocksize为128M, 生成FileSystem对象, 改变blocksize为1M, 再次生成FileSystem对象

最后, 输出所有的FileSystem对象toString方法

 

//第一组 

 Configuration confa = new Configuration(true); 

FileSystem fsa = FileSystem.get(confa);

confa.set("dfs.blocksize", "1048576"); 

fsa = FileSystem.get(confa); 

System.out.println(fsa.getDefaultBlockSize()); 

Configuration confb = new Configuration(true); 

confb.set("dfs.blocksize", "1048576"); 

FileSystem fsb = FileSystem.get(confb); 

 System.out.println(fsb.getDefaultBlockSize());

 

//第二组

 Configuration confc = new Configuration(false); 

confc.set("fs.defaultFS", "hdfs://node01:8020"); 

 confc.set("dfs.blocksize", "1048576");

 FileSystem fsc = FileSystem.get(confc); 

 System.out.println(fsc.getDefaultBlockSize());

 Configuration confd = new Configuration(false);

 confd.set("fs.defaultFS", "hdfs://node01:8020"); 

 confd.set("dfs.blocksize", "134217728"); 

FileSystem fsd = FileSystem.get(confd);

 System.out.println(fsd.getDefaultBlockSize());

 

//第三组 

 Configuration confe = new Configuration(false); 

confe.set("fs.defaultFS", "hdfs://192.168.109.51:8020"); 

 confe.set("dfs.blocksize", "134217728"); 

FileSystem fse = FileSystem.get(confe); 

 System.out.println(fse.getDefaultBlockSize()); 

 Configuration conff = new Configuration(false);

 conff.set("fs.defaultFS", "hdfs://192.168.109.51:8020");

 conff.set("dfs.blocksize", "1048576");

 FileSystem fsf = FileSystem.get(conff);

 System.out.println(fsf.getDefaultBlockSize());

 

 

//输出 

 

System.out.println(fsa); 

 System.out.println(fsb); 

 System.out.println(fsc); 

 System.out.println(fsd); 

 System.out.println(fse); 

 System.out.println(fsf);

 

这次测试获得了预期的结果:

 

134217728 

134217728 

1048576

1048576

134217728 

134217728 

DFS[DFSClient[clientName=DFSClient_NONMAPREDUCE_1193042798_1, ugi=root (auth:SIMPLE)]] DFS[DFSClient[clientName=DFSClient_NONMAPREDUCE_1193042798_1, ugi=root (auth:SIMPLE)]] DFS[DFSClient[clientName=DFSClient_NONMAPREDUCE_-1041604824_1, ugi=root (auth:SIMPLE)]] DFS[DFSClient[clientName=DFSClient_NONMAPREDUCE_-1041604824_1, ugi=root (auth:SIMPLE)]] DFS[DFSClient[clientName=DFSClient_NONMAPREDUCE_-1719045568_1, ugi=root (auth:SIMPLE)]] DFS[DFSClient[clientName=DFSClient_NONMAPREDUCE_-1719045568_1, ugi=root (auth:SIMPLE)]]

 

 

从FileSystem对象的id可以看出, 相同地址获取的对象确实是同一对象, 至此, bug的产生已经可以解释的清楚了

 

[解决bug后的思考]

从最后的测试的结果可以看出, 源码的实现中有缓存处理, 当已经连接过一次之后, 再次获取FileSystem对象时并不会读取configuration中的参数, 只是根据地址与对象, 从类似于kv对的关系返回真实的FileSystem对象. 

 

在debug模式运行代码会发现, 第一次根据配置生成FileSystem对象时有大约10s的延时, 这应该是服务器通讯造成的, 因为服务器通讯的时间成本太高, 所以才会采取这种缓存的方式返回对象.

 

一般使用中并不会对配置参数做调整, 因此这种实现方式不能说有问题, 但是如果需要临时更改配置参数时, 则需对这个问题小心一些.

 

最后, 感谢 尚学堂周老师，在这次解决bug时提供的帮助与思路.

 

如需下载代码和hadoop安装文件下载：

http://www.bjsxt.com/2015/down_0526/41.html

 

版权声明：本文为yunshuxueyuan原创文章，如需转载，请标明出处。【http://www.cnblogs.com/sxt-zkys/】
QQ技术交流群：299142667