distcp集群迁移问题总结

distcp集群迁移问题总结

一：环境准备

1.源集群准备一台用于提交数据拷贝任务的机器，要求可以连接目标大数据集群且安装json命令
寻找：datanode的机器 且验证一下上面安装了json的命令

2.打通源集群到目标集群的公网网址，把目标集群所有节点的公网地址和域名配置到源集群hosts文件下面

二：验证集群互通

hdfs dfs -Dipc.client.fallback-to-simple-auth-allowed=true -ls hdfs://namenode网址:8020/
访问的是重庆的集群，客户端模式（动态配置）
也可以访问hdfs上面
hdfs dfs -ls hdfs://namenode网址:8020/

互通之后，自己又创建了一个文件夹hello
放入一定量的数据，先进行传输，看是都正常，会有哪些问题

登录到的机器上面，
执行：hdfs dfsadmin -allowSnapshot /user/hadoop/hello
你会发现，这个命令dfsadmin -allowSnapshot不可以 你需要用这台机器的root权限去做
ddp-dn-034:~ # hdfs dfsadmin -allowSnapshot /user/hadoop/hello
这个命令如果你的上级文件目录执行，后面的都不需要执行了

Allowing snaphot on /user/hadoop/hello succeeded

命令执行者要用

manage@ddp-dn-034:~> klist
Ticket cache: FILE:/tmp/krb5cc_1009
Default principal: hive@CMDMP.COM

hadoop distcp -update -skipcrccheck -delete -m 26 -Dipc.client.fallback-to-simple-auth-allowed=true -strategy dynamic -bandwidth 100 /user/hadoop/hello hdfs://n1003.dm.migu.cn:8020/user/hadoop/hello
你会发现传输成功的 

三：注意问题

1.传输数据量巨大的问题

我们之前试验的hello文件夹，肯定是没有实际的数据量多的
如果要传输的数据量达到300万以上，甚至更大的时候
300万，如果你们的client jvm heap size只有2g的话，会oom
是调节client jvm heap size的大小，还是减少数据量的传输
都可以。

相对而言，调节client jvm heap size大小更快。

300万，调节多少为合适
5g 左右。
（这个是经验值 ）

这个只需要调整你要传输的台机器就而已
hadoop-env.sh 文件下添加为5g

/etc/hadoop/conf/hadoop-env.sh
export HADOOP_HEAPSIZE="5120"

2.参数调整

hdfs dfs -createSnapshot /user/hadoop/ods  s20200206

hadoop distcp -Ddfs.client.use.datanode.hostname=true -Dipc.client.fallback-to-simple-auth-allowed=true -update -skipcrccheck -delete -m 50 -strategy dynamic  /user/hadoop/ods/.snapshot/s20200206 hdfs://n1003.dm.migu.cn:8020/user/hadoop/ods

这里会设计到网速的传播速度是不够的
map这个数量可以提升
-bandwidth：带宽也可以去掉
增加参数：-Ddistcp.dynamic.max.chunks.tolerable=10000
map在增大的时候，要加上以上的参数

查看数据大小

hdfs dfs -Dipc.client.fallback-to-simple-auth-allowed=true -du -s -h hdfs://n1003.dm.migu.cn:8020/user/hadoop/hello

其实这里也发现一个问题

hdfs dfs -du -s -h /user/hadoop/hello

当你对你的原路径使用快照的时候， 在做du操作的时候， 会报错
也查找了很多地方，问题是，快照有损害所导致的
可以直接count 然后在转换，这样也更准确，如果有更高的方法，请留言

数据传输到后面，有一些map很长时间，速度也很慢，就要删掉-strategy dynamic

以上问题：整体做一个目录的传输

hdfs dfsadmin -allowSnapshot /user/hive/warehouse/dwd_kesheng.db

hdfs dfs -createSnapshot /user/hive/warehouse/dwd_kesheng.db s20200210

hadoop distcp -Ddfs.client.use.datanode.hostname=true -Dipc.client.fallback-to-simple-auth-allowed=true -Ddistcp.dynamic.max.chunks.tolerable=10000 -update -skipcrccheck -delete -m 500 /user/hive/warehouse/dwd_kesheng.db/.snapshot/s20200210 hdfs://n1003.dm.migu.cn:8020/user/hive/warehouse/dwd_kesheng.db

查询数据量
hdfs dfs -Dipc.client.fallback-to-simple-auth-allowed=true -du -s -h hdfs://n1003.dm.migu.cn:8020/user/hive/warehouse/dwd_kesheng.db

hdfs dfs -du -s -h /user/hive/warehouse/dwd_kesheng.db

ods层数据迁移完成
删除快照
hdfs dfs -deleteSnapshot /user/hadoop/ods  s20200206

不允许创建目录的快照。 在禁用快照之前，必须删除目录的所有快照。
hdfs dfsadmin -disallowSnapshot /user/hadoop/ods

这里由于数据量传输比较庞大，需要的时间也是很漫长的，这里需要做一个监控的脚本，实时监控传输的进程问题，

需要注意2点：
1）是监控脚本设计的时间，由于数据量很大，所以在启动的时候，需要很长的时间(1个小时)那么你有对应的脚本就需要1.5h或者2h，并且我在传输中发现，随着你的你数据的传输，你启动的时间也会越来越长 随之你的脚本时间也要调整
2）后期仅仅剩几个map的时候，这里传输速度就降下来了，这里速度慢下来是正常现象，当然也可以有解决方法，后面介绍
你的监控脚本就可以停止了，防止再次启动，为什么，因为你的map是相当大的，一旦多起动几个，你的资源池受不了的

3.传输文件夹嵌入问题

对warehouse进行传输的时候

这里涉及一个问题是什么呢
我之前传输的dwd文件在这个warehouse的里面
这里涉及一个问题，在上次传输过成中，元数据层dwd删除掉了，在进行上次的命令操作时，
元数据会把目标数据的数据也会删除掉，在开会过程中，及时发现了，任务跑完之后，对比会删除，没有发现被删除，是因为任务没有跑完
然后重启进行这样的操作去掉delete

4.目标数据变化的问题

在我传输过程中，他们对目标数据进行了操作，小文件合并
导致我这边快照的时候，mop增加，之前合并的小文件，又重新传输的问题

下次在考虑的时候，要设计很多的问题
由于数据量传输巨大，时间耗费长，定期合并脚本时间短，
解决方法：肯定是合并脚本时间拉长，等我这边传输完在做

5.数仓拉链表一类的覆盖数据问题

我做的快照时间 是固定的
随着时间的推移，目标路径有些数仓的的数据是覆盖的这种类型
一旦我传输的数据没有了，那肯定是会在传输的
这样就会导致目标路径下面的数据混乱问题，
解决方法：
在传输的这个过程中数据一定是有一点问题的
如果这个部分数据出一些报表的话，数据如果想要更加准确
在这个之前多加几部操作，去重和拉时间最新的时间
去做报表，数据相对来说更准确一些
后期快照解除，拉链表这类的覆盖性质的表，在updata

6.优化（小聪明）

因为集群打通了，可以使用scp传输一些关键的文件 （只要 你知道目标机器的密码）
还有在最后剩下的几个map的时候，怎么可以开始传完
其实在这里，你可以看大yarn他map对应cp的数据文件
在启动一个distcp 不做快照，针对对应的文件夹
也是使用这种方法进行后期数据的补充

7.把握的原则

快照固定的数据正常传输，之后又新增的数据，备份2份，目标路径和源路径各一份，出报表时候，先用源路径，保证数据的准确，
快照把握的原则是不能mv和del