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

发布了212 篇原创文章 · 获赞 86 · 访问量 9万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 技术黑板 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览