Hive的parquet表导入多分区时OOM问题

场景

有一个parquet的表table_A，然后创建一个多分区表table_B
A表的数据大小大约是1.21G（parquet压缩之后的大小，数据记录大概有270W条。Table_B的分区是根据年、月、日三个条件进行分区的。

insert overwrite table table_B partition (year,month,day) select id,name,... B_year as year,B_month as month,B_day as day from table_A.

hive中默认会走mapreduce（Hive 1.2.2）
如果是hive的（2.3.2的版本的话，会出现一句提示说使用hive on spark,tez不建议使用mr之类的信息）
我使用的就是mapreduce,然后就会走yarn的资源调度
接下来就会报类似这样的错误：
查看yarn的执行日志的时候会发现有几个map的任务会fail，然后总结了一下有如下的错误

报错1:GC limit over ....
报错2:java heap space
报错3:memory over limit xxx G  actually use xxx G

这个我通过百度之后有博客（文章末尾）是这么说的：
因为这个单纯的进行多分区的操作的时候是只有map任务的，不存在reduce的任务。在对于parquet的表进行多分区的操作的时候，每个分区都要创建一个filewrite对象，然后当分区的数量一多的话，就会容易OOM，虽然数据量才1.21个G但是，数据记录多的话，就会容易产生多个对象，然后这些产生的对象填满了java的堆，填满了之后，java就要进行GC的操作。就会报出上述的错误了。（这样上面的内容是我通过文末的文章链接里面总结的，详细的内容可以移步到文末的链接查看）

解决方案：
1.可以增加map端的内存,这个比较简单粗暴（这个我试过了，有一定的作用，但是数据量太大了也不太好用）

set mapreduce.map.java.opts=-Xmx4096m;

2.开启自动排序参数，产生reduce任务（这个操作会有reduce的过程，当时解决了我的需求，并且加快了执行速度）

hive.optimize.sort.dynamic.partition =true;

3.优化查询，减少每个map查询的分区数目（这个方式我没有尝试过，请见下文链接）

https://cloud.tencent.com/developer/article/1079007

最后

如果阅读文章的你，有什么更好的建议可看法，可以随时向我留言，大家共同学习，共同进步