千万级数据通过sqoop从hive orc分区表导出到mysql的提速经验

背景

数仓算好的数据需要导出到MySQL，但现有的操作流程导出千万级的数据耗时近2小时，2小时的导出速度无法忍耐，且失败成本较高，故急需优化提速。

• Hive表为orc格式，按月分区，数据每月通过spark任务执行，并且insert 命令后会带上distribute by语句，保证每个月分区内只有一个文件
• MySQL环境为开发环境，硬件配置极低

思路

正常我们执行sqoop命令导出数据时，都有固有的模板，类似：

sqoop export \
  --connect "${conn_info}" \
  --username ${username} \
  --password ${password} \
  --table ${target_table_name} \
  --hcatalog-database ${from_database_name} \
  --hcatalog-table ${from_table_name} \
  --hcatalog-partition-keys ${partition_key} \
  --hcatalog-partition-values "${partition_value}" \
  --columns "xxx,xxx,xxx,xxx,xxx" \
  --mapreduce-job-name ${your_mr_job_name} \
  -m 1

1.首先想到的方式发增大-m参数的值，想通过增加并行度的方式来提升导出速度，随后我将值改到8执行，但在yarn界面上始终看到只有一个map在跑，也就是说-m参数配置没生效，后来测试了配置为4和2，都只有一个map在运行，导致速度很慢。

2.后来查看了这张hive表的底层存储路径，才发现了问题所在。由于每月跑任务用了distribute by语句，导致最终每个分区只有一个文件，所以当我无脑增大-m的配置时是不会生效的。

实施

想明白以后，我通过spark重新insert overwrite了这张表，并且去掉了distribute by语句，使每个分区分成默认数量个文件，然后重新提交了sqoop命令，并且将-m直接成了20，后来在yarn界面中查看该任务时，发现-m的配置生效了，可以看到20个map任务并行执行。

效果

速度从最开始的120min提速到15min，提速近87.5%。

总结

经验证，sqoop -m值越大，导出越快，同时占用资源越多，根据自身需求取舍就好。