如何提高hadoop上传文件时中Short-Circuit Local Reads时的性能及安全性

hadoop上传文件时的一大基本原则是移動计算的开销要比移动数据的开销小因此,hadoop上传文件时通常是尽量移动计算到拥有数据的节点上这就使得hadoop上传文件时中读取数据的客戶端DFSClient和提供数据的Datanode经常是在一个节点上,也就造成了很多“Local Reads” 最初设计的时候,这种Local

Socket发送到客户端所谓的“short-circuit”是绕开DataNode,允许客户端直接读一个文件明显地,当客户端与数据在同一地点时可能会出现这种情况Short-circuit为很多应用提供了巨大的性能提升。 Configuration 为了配置

hadoop上传文件时的一大基本原则是移動计算的开销要比移动数据的开销小因此,hadoop上传文件时通常是尽量移动计算到拥有数据的节点上这就使得hadoop上传文件时中读取数

hadoop上传文件时的一大基本原则是移动的开销要比移动数据的开销小。因此hadoop上传文件时通常是尽量移动计算到拥有数据的节点上。这就使得hadoop上传文件时中读取数据的客户端DFSClient和提供数据的Datanode经常是在一个节点上也就造成了很多“Local Reads”。

最初设计的时候这种Local Reads和Remote Reads(DFSClient和Datanode不在同一个节点)的处悝方式都是一样的,也就是都是先由Datanode读取数据然后再通过RPC把数据传给DFSClient。这样处理是比较简单的但是性能会受到一些影响,因为需要Datanode在Φ间做一次中转本文将介绍针对这个问题的一些优化。

既然DFSClient和数据是在一个机器上面那么很自然的想法,就是让DFSClient绕开Datanode自己去读取数据在具体实现上有如下两种方案。 HDFS-2246

在这个JIRA中工程师们的想法是既然读取数据DFSClient和数据在同一台机器上,那么Datanode就把数据在文件系统中的路径从什么地方开始读(offset)和需要读取多少(length)等信息告诉DFSClient,然后DFSClient去打开文件自己读取想法很好,问题在于配置复杂以及安全问题

首先是配置问題,因为是让DFSClient自己打开文件读取数据那么就需要配置一个白名单,定义哪些用户拥有访问Datanode的数据目录权限如果有新用户加入,那么就嘚修改白名单需要注意的是,这里是允许客户端访问Datanode的数据目录也就意味着,任何用户拥有了这个权限就可以访问目录下其他数据,从而导致了安全漏洞因此,这个实现已经不建议使用了 HDFS-347

在Linux中,有个技术叫做Unix Domain SocketUnix Domain Socket是一种进程间的通讯方式,它使得同一个机器上的两個进程能以Socket的方式通讯它带来的另一大好处是,利用它两个进程除了可以传递普通数据外还可以在进程间传递文件描述符。

假设机器仩的两个用户A和BA拥有访问某个文件的权限而B没有,而B又需要访问这个文件借助Unix Domain Socket,可以让A打开文件得到一个文件描述符然后把文件描述符传递给B,B就能读取文件里面的内容了即使它没有相应的权限在HDFS的场景里面,A就是DatanodeB就是DFSClient,需要读取的文件就是Datanode数据目录中的某个文件

这个方案在安全上就比上一个方案上好一些,至少它只允许DFSClient读取它需要的文件

按照上面的配置,如何确认从HDFS读取数据的时候Short Circuit Local Reads真的起作用了。有两个途径: 查看Datanode的日志

在Datanode的启动日志中也可以看到如下相关的日志表明Unix Domain Socket被启用了。

现在我把该文件拷贝到本地


  

以上是云栖社区小编为您精心准备的的内容在云栖社区的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮進行搜索hadoop上传文件时 以便于您获取更多的相关知识。

我要回帖

更多关于 hadoop上传文件时 的文章

 

随机推荐