如何hadoop distcp ftp目录中部分文件

发布网友发布时间：2022-04-30 11:08

共2个回答

懂视网时间：2022-05-06 09:49

背景：公司在线上使用了CDH5集群，一开始由于疏忽，忘记了在计划任务中定期执行Balancer来平衡各节点的数据。后来，在引入大量的Job之后，数据增长非常迅猛，有很多节点开始出现利用率超过99.9%的情况，部分Job甚至开始Failed。于是我们便执行Balancer来

背景：
公司在线上使用了CDH5集群，一开始由于疏忽，忘记了在计划任务中定期执行Balancer来平衡各节点的数据。
后来，在引入大量的Job之后，数据增长非常迅猛，有很多节点开始出现利用率超过99.9%的情况，部分Job甚至开始Failed。

于是我们便执行Balancer来清理数据，结果发现有26T的数据需要平衡，而Balancer每次只移动50G的数据，并且耗时30分钟，而集群每个小时新写入的数据会导致又有40-60G的数据需要平衡。这样一来，Balancer就根本无法胜任了。

14/10/14 20:31:11 INFO balancer.Balancer: Need to move 26.49 TB to make the cluster balanced.
14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.10:50010 to 10.100.1.60:50010
14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.20:50010 to 10.100.1.70:50010
14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.30:50010 to 10.100.1.80:50010
14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.40:50010 to 10.100.1.90:50010
14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.50:50010 to 10.100.1.100:50010
14/10/14 20:31:11 INFO balancer.Balancer: Will move 50 GB in this iteration
...

解决办法：
1. 增加Balancer可操作的带宽
我们思考，是否是因为Balancer的默认带宽太小，所以效率低下，于是我们尝试将Balancer的带宽扩容到了500M/s：

hadoop dfsadmin -setBalancerBandwidth 524288000

但问题并没有得到太大的改善。

2. 强行对节点进行Decommission
我们发现，当对一些节点进行Decommission操作时，上面的数据虽然有10-30T甚至更多，但总能在1天内全部Copy到其它的节点上，这里面由于默认集群副本数为3的原因，应该只有1/3的数据被复制了，但数据是完整的，并且被复制出去的数据也是平均分配到各个节点上的。那么我们何不使用它来作为一个类似Balancer的功能来解决一些磁盘用量超过99.9%的节点呢？
事实证明，这个方法非常可行，我们针对线上8个节点进行了Decommission操作（注意要尽量一台一台进行），在完成下线之后再立刻格式化数据磁盘，并重新添加回集群，新的数据也会非常快的平衡过来。比较完美的解决了之前头疼的问题，并且只花费了不到4天的时间。

3. Hadoop对LVM磁盘卷的支持问题
在解决Balancer的问题时，我们还发现，Hadoop对LVM磁盘卷的支持不是很好，表现在如果在一块磁盘上创建了逻辑卷/根分区等，再创建了逻辑卷/data1分区，Hadoop会一直将/data1写到100%，然后导致一些Job提示没有空间写入。我们猜想Hadoop应该是物理卷为单位来控制用量的。因此，我们不得不将这些包含了逻辑卷数据磁盘的主机重新安装，并分配单独的物理卷，如/dev/sda3作为/data1挂载，便再也没有以上问题。

原文地址：Hadoop运维笔记之 Balancer难以在快速增长的集群上平衡大量的数据, 感谢原作者分享。

热心网友时间：2022-05-06 06:57

　　hadoop中有一个叫做distcp（分布式复制）的有用程序，能从hadoop的文件系统并行复制大量数据。

　　distcp一般用于在两个HDFS集群中传输数据。如果集群在hadoop的同一版本上运行，就适合使用hdfs方案：

　　% hadoop distcp hdfs://namenode1/foo hdfs://namenode2/bar
　　这将从第一个集群中复制/foo目录（和它的内容）到第二个集群中的/bar目录下，所以第二个集群会有/bar/foo目录结构。如果/bar不存在，则会新建一个。可以指定多个源路径，并且所有的都会被复制到目标路径。源路径必须是绝对路径。

　　默认情况下，distcp会跳过目标路径已经有的文件，但可以通过提供的-overwrite选项进行覆盖，也可以用-update选项来选择只更新那些修改过的文件。

　　

　　第一个集群的子树/foo下的一个文件与第二个集群的改变进行同步。

　　% hadoop distcp -update hdfs://namenode1/foo hdfs://namenode2/bar/foo
　　distcp是作为一个MapRece作业执行的，复制工作由集群中并行运行的map来完成。这里没有recer。每个文件都由一个单一的map进行复制，并且distcp通过将文件分成大致相等的文件来为每个map数量大致相同的数据。

　　map的数量确定：

　　通过让每一个map复制数量合理的数据以最小化任务建立所涉及的开销，是一个很好的想法，所以每个map的副本至少为256MB。例如，1GB的文件被分成4个map任务。如果数据很大，为*带宽和集群的使用而*映射的数据就变得很有必要。map默认的最大数量是每个集群节点（tasktracker）有20个。例如，复制1000GB的文件到一个100个节点的集群，会分配2000个map（每个节点20个map），所以平均每个会复制512MB。通过对distcp指定-m参数，会减少映射的分配数量。例如，-m 1000会分配1000个map，平均每个复制1GB。

　　如果想在两个运行着不同版本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工具继续改善集群中块的分布。