百TB级数据拷贝distcp性能调优
背景
配合集群迁移,需要迁移6PB数据
迁移安排在当天天任务完成之后开启操作,9点-10点
需要在晚上17点之前完成当天增量数据迁移(5-8小时完成120TB数据同步)
拷贝方式
全量数据约6PB,全量拷贝一次,耗时近两个星期(业务每日高峰期需要停止拷贝作业)
这里主要测试每天的增量同步速度(6PB全量基础上的增量,每天数量在120TB左右,不含副本数)
拷贝方式,按照业务项目数仓路径单独作业。对于超大项目,子目录划分为独立作业
速度问题
拷贝数据过程中,发现distcp存在以下比较慢的问题,包含不限于以下
启动慢
大作业的AM做filelist操作,任务切分耗时较长
同步慢
默认的map设置和速度设置较低,例如针对大项目默认限速设置100MB过小
收尾慢
因为CRC校验,收尾相对较慢。考虑skipcrccheck。改用从nn的fsimage校验方式,出于数据安全性考虑,最后还是接受这个时间代价】
调优措施
慢启动问题
- 开启多个线程filelist操作,numListstatusThreads
- 减少AM切分工作量,提前移走大项目部分历史数据,拷贝完成移回来
- insert overwrite个别hive小文件数特别多的目录
- 大项目分二级目录,独立作业
distcp参数调优
- 单个map带宽限制设置为1000MB(默认值10倍,相当于不限制)
- 根据项目大小设置maps数量和AM的内存限制
数据倾斜问题
distcp按照文件FileList划分路径组。会导致每日新增部分落到少量map上面,所以增量同步的时候,性能很差。
同时默认限速过小出现数据倾斜问题会导致大项目拖尾严重(有项目表每天上千个10G级别的文件)
调优措施
- 提前同步一次当天的分区
专门为大表当天分区做一次同步(在正式业务迁移开始之前开展一次) - distcp.dynamic.split.ratio
dynamic倾斜率,允许拷贝比较快的map分到更多的任务,默认为2,改为4
The new DistCp also provides a strategy to “dynamically” size maps, allowing faster data-nodes to copy more bytes than slower nodes. Using -strategy dynamic (explained in the Architecture), rather than to assign a fixed set of source-files to each map-task, files are instead split into several sets. The number of sets exceeds the number of maps, usually by a factor of 2-3. Each map picks up and copies all files listed in a chunk. When a chunk is exhausted, a new chunk is acquired and processed, until no more chunks remain.
慢节点问题
- 在IO比较高的情况下,集群存在Slow ReadProcessor read fields现象,导致copyfilelist很慢
- 解决方案, 检测日志,发现并重启慢节点datanode
机房带宽问题
机房层面设置QOS保障
实时业务设置为高优先级队列,保障带宽打满时候的高优先级任务
其它
- 关掉集群balance
- 客户端并发内存瓶颈,拷贝作业调度在多个机器上
实际测试
6小时完成所有120TB文件增量拷贝工作