hadoop之 distcp（分布式拷贝）

浅浅的花香味﹌ 2021-12-20 13:53 404阅读 0赞

## 概述 ##

distcp（分布式拷贝）是用于大规模集群内部和集群之间拷贝的工具。 它使用Map/Reduce实现文件分发，错误处理和恢复，以及报告生成。 它把文件和目录的列表作为map任务的输入，每个任务会完成源列表中部分文件的拷贝。 由于使用了Map/Reduce方法，这个工具在语义和执行上都会有特殊的地方。 这篇文档会为常用distcp操作提供指南并阐述它的工作模型。

### 基本使用方法 ###

distcp最常用在集群之间的拷贝：

hadoop distcp hdfs://master1:8020/foo/bar hdfs://master2:8020/bar/foo

这条命令会把master集群的/foo/bar目录下的所有文件或目录名展开并存储到一个临时文件中，这些文件内容的拷贝工作被分配给多个map任务， 然后每个TaskTracker分别执行从master1到master2的拷贝操作。注意distcp使用绝对路径进行操作。

命令行中可以指定多个源目录：

hadoop distcp hdfs://master1:8020/foo/a hdfs://master1:8020/foo/b hdfs://master2:8020/bar/foo

或者使用\-f选项，从文件里获得多个源：  
 hadoop distcp -f hdfs://master1:8020/srclist hdfs://master2:8020/bar/foo

其中srclist 的内容是  
 hdfs://master1:8020/foo/a  
 hdfs://master1:8020/foo/b

当从多个源拷贝时，如果两个源冲突，distcp会停止拷贝并提示出错信息， 如果在目的位置发生冲突，会根据选项设置解决。 默认情况会跳过已经存在的目标文件（比如不用源文件做替换操作）。每次操作结束时 都会报告跳过的文件数目，但是如果某些拷贝操作失败了，但在之后的尝试成功了， 那么报告的信息可能不够精确。

每个TaskTracker必须都能够与源端和目的端文件系统进行访问和交互。 对于HDFS来说，源和目的端要运行相同版本的协议或者使用向下兼容的协议。

拷贝完成后，建议生成源端和目的端文件的列表，并交叉检查，来确认拷贝真正成功。 因为distcp使用Map/Reduce和文件系统API进行操作，所以这三者或它们之间有任何问题 都会影响拷贝操作。一些distcp命令的成功执行可以通过再次执行带-update参数的该命令来完成， 但用户在如此操作之前应该对该命令的语法很熟悉。

值得注意的是，当另一个客户端同时在向源文件写入时，拷贝很有可能会失败。 尝试覆盖HDFS上正在被写入的文件的操作也会失败。 如果一个源文件在拷贝之前被移动或删除了，拷贝失败同时输出异常 FileNotFoundException

### 选项 ###

#### 选项索引 ####

<table> 
 <tbody> 
 <tr> 
 <th colspan="1">标识</th> 
 <th colspan="1">描述</th> 
 <th colspan="1">备注</th> 
 </tr> 
 <tr> 
 <td colspan="1">-p[rbugp]</td> 
 <td colspan="1">Preserve &nbsp;&nbsp;r: replication number &nbsp;&nbsp;b: block size &nbsp;&nbsp;u: user &nbsp;&nbsp;g: group &nbsp;&nbsp;p: permission</td> 
 <td colspan="1">修改次数不会被保留。并且当指定&nbsp;-update&nbsp;时，更新的状态不会 被同步，除非文件大小不同（比如文件被重新创建）。</td> 
 </tr> 
 <tr> 
 <td colspan="1">-i</td> 
 <td colspan="1">忽略失败</td> 
 <td colspan="1">就像在 附录中提到的，这个选项会比默认情况提供关于拷贝的更精确的统计， 同时它还将保留失败拷贝操作的日志，这些日志信息可以用于调试。最后，如果一个map失败了，但并没完成所有分块任务的尝试，这不会导致整个作业的失败。</td> 
 </tr> 
 <tr> 
 <td colspan="1">-log &lt;logdir&gt;</td> 
 <td colspan="1">记录日志到 &lt;logdir&gt;</td> 
 <td colspan="1">DistCp为每个文件的每次尝试拷贝操作都记录日志，并把日志作为map的输出。 如果一个map失败了，当重新执行时这个日志不会被保留。</td> 
 </tr> 
 <tr> 
 <td colspan="1">-m &lt;num_maps&gt;</td> 
 <td colspan="1">同时拷贝的最大数目</td> 
 <td colspan="1">指定了拷贝数据时map的数目。请注意并不是map数越多吞吐量越大。</td> 
 </tr> 
 <tr> 
 <td colspan="1">-overwrite</td> 
 <td colspan="1">覆盖目标</td> 
 <td colspan="1">如果一个map失败并且没有使用-i选项，不仅仅那些拷贝失败的文件，这个分块任务中的所有文件都会被重新拷贝。 就像<a href="http://hadoop.apache.org/docs/r1.0.4/cn/distcp.html#uo" rel="nofollow">下面</a>提到的，它会改变生成目标路径的语义，所以 用户要小心使用这个选项。</td> 
 </tr> 
 <tr> 
 <td colspan="1">-update</td> 
 <td colspan="1">如果源和目标的大小不一样则进行覆盖</td> 
 <td colspan="1">像之前提到的，这不是"同步"操作。 执行覆盖的唯一标准是源文件和目标文件大小是否相同；如果不同，则源文件替换目标文件。 像&nbsp;<a href="http://hadoop.apache.org/docs/r1.0.4/cn/distcp.html#uo" rel="nofollow">下面</a>提到的，它也改变生成目标路径的语义， 用户使用要小心。</td> 
 </tr> 
 <tr> 
 <td colspan="1">-f &lt;urilist_uri&gt;</td> 
 <td colspan="1">使用&lt;urilist_uri&gt; 作为源文件列表</td> 
 <td colspan="1">这等价于把所有文件名列在命令行中。&nbsp;urilist_uri&nbsp;列表应该是完整合法的URI。</td> 
 </tr> 
 </tbody> 
</table>

#### 更新和覆盖 ####

这里给出一些 \-update和 \-overwrite的例子。 考虑一个从/foo/a 和 /foo/b 到 /bar/foo的拷贝，源路径包括：

hdfs://master1:8020/foo/a  
 hdfs://master1:8020/foo/a/aa  
 hdfs://master1:8020/foo/a/ab  
 hdfs://master1:8020/foo/b  
 hdfs://master1:8020/foo/b/ba  
 hdfs://master1:8020/foo/b/ab

如果没设置\-update或 \-overwrite选项， 那么两个源都会映射到目标端的 /bar/foo/ab。 如果设置了这两个选项，每个源目录的内容都会和目标目录的 **内容** 做比较。distcp碰到这类冲突的情况会终止操作并退出。

默认情况下，/bar/foo/a 和 /bar/foo/b 目录都会被创建，所以并不会有冲突。

现在考虑一个使用\-update合法的操作:  
distcp -update hdfs://master1:8020/foo/a \\  
 hdfs://master1:8020/foo/b \\  
 hdfs://master2:8020/bar

其中源路径/大小:

hdfs://master1:8020/foo/a  
 hdfs://master1:8020/foo/a/aa 32  
 hdfs://master1:8020/foo/a/ab 32  
 hdfs://master1:8020/foo/b  
 hdfs://master1:8020/foo/b/ba 64  
 hdfs://master1:8020/foo/b/bb 32

和目的路径/大小:

hdfs://master2:8020/bar  
 hdfs://master2:8020/bar/aa 32  
 hdfs://master2:8020/bar/ba 32  
 hdfs://master2:8020/bar/bb 64

会产生:

hdfs://master2:8020/bar  
 hdfs://master2:8020/bar/aa 32  
 hdfs://master2:8020/bar/ab 32  
 hdfs://master2:8020/bar/ba 64  
 hdfs://master2:8020/bar/bb 32

只有master2的aa文件没有被覆盖。如果指定了 \-overwrite选项，所有文件都会被覆盖。

## 附录 ##

### Map数目 ###

distcp会尝试着均分需要拷贝的内容，这样每个map拷贝差不多相等大小的内容。 但因为文件是最小的拷贝粒度，所以配置增加同时拷贝（如map）的数目不一定会增加实际同时拷贝的数目以及总吞吐量。

如果没使用\-m选项，distcp会尝试在调度工作时指定map的数目 为 min (total\_bytes / bytes.per.map, 20 \* num\_task\_trackers)， 其中bytes.per.map默认是256MB。

建议对于长时间运行或定期运行的作业，根据源和目标集群大小、拷贝数量大小以及带宽调整map的数目。

hadoop distcp -Ddistcp.bytes.per.map=1073741824 -Ddfs.client.socket-timeout=240000000 -Dipc.client.connect.timeout=40000000 -i -update hdfs://master1:8020/foo/a hdfs://master1:8020/foo/b hdfs://master2:8020/bar/foo

### 不同HDFS版本间的拷贝 ###

对于不同Hadoop版本间的拷贝，用户应该使用HftpFileSystem。 这是一个只读文件系统，所以distcp必须运行在目标端集群上（更确切的说是在能够写入目标集群的TaskTracker上）。 源的格式是 hftp://<dfs.http.address>/<path> （默认情况dfs.http.address是 <namenode>:50070）。

### Map/Reduce和副效应 ###

像前面提到的，map拷贝输入文件失败时，会带来一些副效应。

*  除非使用了\-i，任务产生的日志会被新的尝试替换掉。
 *  除非使用了\-overwrite，文件被之前的map成功拷贝后当又一次执行拷贝时会被标记为 "被忽略"。
 *  如果map失败了mapred.map.max.attempts次，剩下的map任务会被终止（除非使用了\-i)。
 *  如果mapred.speculative.execution被设置为 final和true，则拷贝的结果是未定义的。

source： [http://blog.csdn.net/stark\_summer/article/details/45869945][http_blog.csdn.net_stark_summer_article_details_45869945]

转载于:https://www.cnblogs.com/andy6/p/7490599.html

[http_blog.csdn.net_stark_summer_article_details_45869945]: http://blog.csdn.net/stark_summer/article/details/45869945