`
langyu
  • 浏览: 884457 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

HDFS:NameNode的Proxy该怎样做

    博客分类:
  • hdfs
阅读更多

    在上篇blog中提到了HDFS的功能扩展点:Service plugin,它存在于NameNode和DataNode中。HDFS赋予它们可以操作这两个大对象的能力,这也完全提供我们在HDFS上进行开发的机会。这些开发可以是对HDFS现有功能的补充与完善,也可以是基于HDFS之上的扩展。但server plugin可以知道当前用户正在操作哪些文件么?不知道

    现在我们有这样的需求:需要HDFS提供file notification - 也就是订阅方可以在HDFS上订阅监控某个文件或目录,如果文件或目录有更改,订阅方可以及时得到来自HDFS的通知。类似的功能需求在大部分应用系统都会支持,所以我们也会试着来完善HDFS的这个功能。

    所有与文件相关的操作都是来自client,这些操作通过NameNode提供的RPC接口进行数据处理。我们最先应该想到的是在哪里可以获得所有与client交互的请求呢?client端显然不现实:1. 它是临时的,不能长期提供服务; 2. 某个文件可被多个client操作,不能完全拦截用户操作。除client之外,NameNode肯定是可以完成需求的,但怎样修改是改动少,最稳妥的方式呢?我想到了NameNode端的RPC server,它持有NameNode instance,然后在每次RPC请求到达时,根据这个instance做方法调用,在这里我们就可以偷梁换柱,用我们想要的代理层来替代真实的NameNode,既可以做正常的方法调用转发,也可以实现我们的需求。





    在RPC server与NameNode之间加入这样一层“锲子”,它静态代理着所有对NameNode的请求(当然也有从DataNode来的请求,不过我们不处理它,因为我们想要的只要与HDFS文件或目录相关的操作),然后在背后把请求的参数拦截下来,做异步处理,尽量不要影响NameNode的处理效率。

    在NameNode中加入这个Proxy,RPC server就只会认为它是NameNode

//NameNode.java
NameNodeProxy nnProxy = new NameNodeProxy(this);
this.server = RPC.getServer(NamenodeProtocols.class, nnProxy,
                                socAddr.getHostName(), socAddr.getPort(),
                                handlerCount, false, conf, 
				namesystem.getDelegationTokenSecretManager());




    对于用户的这些文件操作请求,我们可以对它这样做。把请求代理到真正的NameNode,拦截请求参数,与订阅信息比对,如果匹配就通知订阅方

//NameNodeProxy.java
public void create(String src, 
          FsPermission masked,
          String clientName, 
          EnumSetWritable<CreateFlag> flag,
          boolean createParent,
          short replication,
          long blockSize) throws IOException {

    nameNode.create(src, masked, clientName, flag, createParent, replication, blockSize);
	  
    putRequestToQueue(src, "create");
}
  
private List<Operation> operationQueue;

private void putRequestToQueue(String src, String cmd) {
    Operation op = new Operation(src, cmd);
    operationQueue.add(op);
}

 

    这层代理同时也是一个契机,为我们分析用户操作打开一扇窗。你想分析下当前HDFS中哪些目录或哪些文件是热点文件/目录,那么你知道怎么做的。

    就简单说到这吧,上述的HDFS版本是0.21,用的代码是伪代码。大家有任何想法,欢迎提出,谢谢!
  • 大小: 50.4 KB
2
0
分享到:
评论
6 楼 edishf 2013-02-21  
edishf 写道
那我们实现NameNodeProxy的时候需要实现哪些protocol呢? ClientProtocol肯定是要的,其他的呢?

还有一点困惑的就是
NameNodeProxy nnProxy=new NameNodeProxy(this) 这句没看懂,把NameNode实例传入构造方法,有什么意义呢?

sorry,后面一个问题我傻了。。。
5 楼 edishf 2013-02-21  
那我们实现NameNodeProxy的时候需要实现哪些protocol呢? ClientProtocol肯定是要的,其他的呢?

还有一点困惑的就是
NameNodeProxy nnProxy=new NameNodeProxy(this) 这句没看懂,把NameNode实例传入构造方法,有什么意义呢?
4 楼 langyu 2011-09-06  
heiliguai 写道

就是说原来的RPC Server所实现的接口保持不变,将Proxy新增的功能作为新接口添加到RPC Server中,这样理解对吗?

你好,不能这样理解。Hadoop的RPC实现就是动态代理+二进制协议,RPC在这里只扮演着解析二进制协议,并且根据调用方法与方法参数反射调用NameNode的特定方法。RPC server在创建时需要明确传入的是NameNode对象,但我用一个NameNode的"兄弟"来代理NameNode的所有接口,这时候就能在NameNodeProxy里面拦截到用户请求。
3 楼 heiliguai 2011-09-06  
langyu 写道
heiliguai 写道
“当然也有从DataNode来的请求,不过我们不处理它”

这里没看懂:
1.RPC server可以区分请求是来自Client还是来自DataNode?
2.来自DataNode的请求是交给谁处理的?

不知道问题问得对不对,请不吝赐教。

你好,我们当前的需求是想要知道“用户是如何操作HDFS中的文件与目录”,有这样的需求就不用管DataNode的各种请求,因为DataNode请求是HDFS内部事务。

对于RPC server来说,来自内部或外部请求的区别只是调用着 NameNode不同的接口方法。
我们的业务是有需求背景的,这里没说清楚,不好意思。


就是说原来的RPC Server所实现的接口保持不变,将Proxy新增的功能作为新接口添加到RPC Server中,这样理解对吗?
2 楼 langyu 2011-09-06  
heiliguai 写道
“当然也有从DataNode来的请求,不过我们不处理它”

这里没看懂:
1.RPC server可以区分请求是来自Client还是来自DataNode?
2.来自DataNode的请求是交给谁处理的?

不知道问题问得对不对,请不吝赐教。

你好,我们当前的需求是想要知道“用户是如何操作HDFS中的文件与目录”,有这样的需求就不用管DataNode的各种请求,因为DataNode请求是HDFS内部事务。

对于RPC server来说,来自内部或外部请求的区别只是调用着 NameNode不同的接口方法。
我们的业务是有需求背景的,这里没说清楚,不好意思。
1 楼 heiliguai 2011-09-06  
“当然也有从DataNode来的请求,不过我们不处理它”

这里没看懂:
1.RPC server可以区分请求是来自Client还是来自DataNode?
2.来自DataNode的请求是交给谁处理的?

不知道问题问得对不对,请不吝赐教。

相关推荐

Global site tag (gtag.js) - Google Analytics