通过distcp进行并行复制
前面的HDFS访问模型都集中于单线程的访问。例如通过指定文件通配，我们可以对一部分文件进行处理，但是为了高效，对这些文件的并行处理需要新写一个程序。Hadoop有一个叫distcp(分布式复制)的有用程序，能从Hadoop的文件系统并行复制大量数据。
distcp一般用于在两个HDFS集群中传输数据。如果集群在Hadoop的同一版本上运行，就适合使用hdfs方案：
% hadoop distcp hdfs://namenode1/foo hdfs://namenode2/bar
这将从第一个集群中复制/foo目录(和它的内容)到第二个集群中的/bar目录下，所以第二个集群会有/bar/foo目录结构。如果/bar不存在，则新建一个。我们可以指定多个源路径，并且所有的都会被复制到目标路径。源路径必须是绝对路径。
默认情况下，distcp会跳过目标路径已经有的文件，但可以通过提供的-overwrite选项进行覆盖。也可以用-update选项来选择只更新那些修改过的文件。
注意：使用-overwrite和-update中任意一个(或两个)选项会改变源路径和目标路径的含义。这可以用一个例子清楚说明。如果改变先前例子中第一个集群的子树/foo下的一个文件，就能通过运行对第二个集群的改变进行同步：
% hadoop distcp -update hdfs://namenode1/foo hdfs://namenode2/bar/foo
目标路径需要末尾这个额外的子目录/foo，因为源目录下的内容已被复制到目标目录下。(如果熟悉rsync，你可以想像-overwrite或-update项对源路径而言，如同添加一个隐含的斜杠。)
如果对discp操作不是很确定，最好先对一个小的测试目录树进行尝试。
有很多选项可以控制分布式复制行为，包括预留文件属性，忽略故障和限制复制的文件或总数据的数量。运行时不带任何选项，可以看到使用说明。
distcp是作为一个MapReduce作业执行的，复制工作由集群中并行运行的map来完成。这里并没有reducer。每个文件都由一个单一的map进行复制，并且distcp通过将文件分成大致相等的文件来为每个map数量大致相同的数据。
map的数量是这样确定的。通过让每一个map复制数量合理的数据以最小化任务建立所涉及的开销，是一个很好的想法，所以每个map的副本至少为256 MB。(除非输入的总大小较少，否则一个map就足以操控全局。)例如，1 GB的文件会被分成4个map任务。如果数据很大，为限制带宽和集群的使用而限制映射的数量就变得很有必要。map默认的最大数量是每个集群节点(tasktracker)有20个。例如，复制1000 GB的文件到一个100个节点的集群，会分配2000个map(每个节点20个map)，所以平均每个会复制512 MB。通过对distcp指定-m参数，会减少映射的分配数量。例如，-m 1000会分配1000个map，平均每个复制1 GB。
如果想在两个运行着不同版本HDFS的集群上利用distcp，使用hdfs协议是会失败的，因为RPC系统是不兼容的。想要弥补这种情况，可以使用基于HTTP的HFTP文件系统从源中进行读取。这个作业必须运行在目标集群上，使得HDFS RPC版本是兼容的。使用HFTP重复前面的例子：
% hadoop distcp hftp://namenode1:50070/foo hdfs://namenode2/bar
注意，需要在URI源中指定名称节点的Web端口。这是由dfs.http.address的属性决定的，默认值为50070。
保持HDFS集群的平衡
向HDFS复制数据时，考虑集群的平衡相当重要。文件块在集群中均匀地分布时，HDFS能达到最佳工作状态。回顾前面1000 GB数据的例子，通过指定-m选项为1，即由一个单一的map执行复制工作，它的意思是，不考虑速度变慢和未充分利用集群资源，每个块的第一个副本会存储在运行map的节点上(直到磁盘被填满)。第二和第三个副本分散在集群中，但这一个节点并不会平衡。通过让map的数量多于集群中节点的数量，我们便可避免这个问题。鉴于此，最好首先就用默认的每个节点20个map这个默认设置来运行distcp。
然而，这也并不总能阻止一个集群变得不平衡。也许想限制map的数量以便一些节点可以被其他作业使用。若是这样，可以使用balancer工具(参见第10章)继续改善集群中块的分布
前面的HDFS访问模型都集中于单线程的访问。例如通过指定文件通配，我们可以对一部分文件进行处理，但是为了高效，对这些文件的并行处理需要新写一个程序。Hadoop有一个叫distcp(分布式复制)的有用程序，能从Hadoop的文件系统并行复制大量数据。
distcp一般用于在两个HDFS集群中传输数据。如果集群在Hadoop的同一版本上运行，就适合使用hdfs方案：
% hadoop distcp hdfs://namenode1/foo hdfs://namenode2/bar
这将从第一个集群中复制/foo目录(和它的内容)到第二个集群中的/bar目录下，所以第二个集群会有/bar/foo目录结构。如果/bar不存在，则新建一个。我们可以指定多个源路径，并且所有的都会被复制到目标路径。源路径必须是绝对路径。
默认情况下，distcp会跳过目标路径已经有的文件，但可以通过提供的-overwrite选项进行覆盖。也可以用-update选项来选择只更新那些修改过的文件。
注意：使用-overwrite和-update中任意一个(或两个)选项会改变源路径和目标路径的含义。这可以用一个例子清楚说明。如果改变先前例子中第一个集群的子树/foo下的一个文件，就能通过运行对第二个集群的改变进行同步：
% hadoop distcp -update hdfs://namenode1/foo hdfs://namenode2/bar/foo
目标路径需要末尾这个额外的子目录/foo，因为源目录下的内容已被复制到目标目录下。(如果熟悉rsync，你可以想像-overwrite或-update项对源路径而言，如同添加一个隐含的斜杠。)
如果对discp操作不是很确定，最好先对一个小的测试目录树进行尝试。
有很多选项可以控制分布式复制行为，包括预留文件属性，忽略故障和限制复制的文件或总数据的数量。运行时不带任何选项，可以看到使用说明。
distcp是作为一个MapReduce作业执行的，复制工作由集群中并行运行的map来完成。这里并没有reducer。每个文件都由一个单一的map进行复制，并且distcp通过将文件分成大致相等的文件来为每个map数量大致相同的数据。
map的数量是这样确定的。通过让每一个map复制数量合理的数据以最小化任务建立所涉及的开销，是一个很好的想法，所以每个map的副本至少为256 MB。(除非输入的总大小较少，否则一个map就足以操控全局。)例如，1 GB的文件会被分成4个map任务。如果数据很大，为限制带宽和集群的使用而限制映射的数量就变得很有必要。map默认的最大数量是每个集群节点(tasktracker)有20个。例如，复制1000 GB的文件到一个100个节点的集群，会分配2000个map(每个节点20个map)，所以平均每个会复制512 MB。通过对distcp指定-m参数，会减少映射的分配数量。例如，-m 1000会分配1000个map，平均每个复制1 GB。
如果想在两个运行着不同版本HDFS的集群上利用distcp，使用hdfs协议是会失败的，因为RPC系统是不兼容的。想要弥补这种情况，可以使用基于HTTP的HFTP文件系统从源中进行读取。这个作业必须运行在目标集群上，使得HDFS RPC版本是兼容的。使用HFTP重复前面的例子：
% hadoop distcp hftp://namenode1:50070/foo hdfs://namenode2/bar
注意，需要在URI源中指定名称节点的Web端口。这是由dfs.http.address的属性决定的，默认值为50070。
保持HDFS集群的平衡
向HDFS复制数据时，考虑集群的平衡相当重要。文件块在集群中均匀地分布时，HDFS能达到最佳工作状态。回顾前面1000 GB数据的例子，通过指定-m选项为1，即由一个单一的map执行复制工作，它的意思是，不考虑速度变慢和未充分利用集群资源，每个块的第一个副本会存储在运行map的节点上(直到磁盘被填满)。第二和第三个副本分散在集群中，但这一个节点并不会平衡。通过让map的数量多于集群中节点的数量，我们便可避免这个问题。鉴于此，最好首先就用默认的每个节点20个map这个默认设置来运行distcp。
然而，这也并不总能阻止一个集群变得不平衡。也许想限制map的数量以便一些节点可以被其他作业使用。若是这样，可以使用balancer工具(参见第10章)继续改善集群中块的分布