关于这个问题，最令人沮丧的部分是显而易见的答案是“修复源表！”-不幸的是，我不能这样做（这是由另一个拒绝帮助的团队管理和维护的）。
因此，我正在寻找一种技术解决方案，在不更改源表的情况下执行此操作。
情况是这样的：我有一个源表，我正试图编写一个配置单元查询来创建一个新表。查询最终需要花费数小时才能完成，原因是这项工作被限制在单个减速机中。
当我跟随源表到它在hdfs上的位置时，我注意到有1009个部件文件。其中1008个是0字节，1个是400 gb。
这就解释了为什么1 reducer需要这么长时间，因为所有的数据都包含在一个文件中。
我尝试添加以下设置，试图将工作分解为多个减速器。

set hive.merge.mapfiles=true; 
set hive.merge.mapredfiles=true;
set hive.merge.smallfiles.avgsize=134217728;
set hive.merge.size.per.task=134217728;
set mapred.max.split.size=134217728;
set mapred.min.split.size=134217728;
set hive.exec.reducers.bytes.per.reducer=134217728;

所有的尝试都以我的新表看起来和源表一模一样结束，有大量的0字节文件，还有一个包含所有数据的文件。我可以控制减速器，它控制文件的总数。。。但是我不能控制数据使结果均匀分布。
关于如何“修复”生成的表以使文件均匀分布，有什么想法吗？如果我能在查询过程中解决这个问题的话，我的减速机上的负载会更大，查询速度会更快。
源表如下所示：

CREATE TABLE `source_tbl`(
 `col1` varchar(16)
, `col2` smallint
, `col3` varchar(5),
... many more cols ...
`col20000` int) 
ROW FORMAT SERDE 
'org.apache.hadoop.hive.ql.io.orc.OrcSerde' 
STORED AS INPUTFORMAT 
'org.apache.hadoop.hive.ql.io.orc.OrcInputFormat' 
OUTPUTFORMAT 
'org.apache.hadoop.hive.ql.io.orc.OrcOutputFormat' 
LOCATION 
'hdfs://cluster/user/hive/warehouse/schema.db/source_tbl' 
TBLPROPERTIES ( 
'COLUMN_STATS_ACCURATE'='true', 
'numFiles'='1009', 
'numRows'='19187489', 
'rawDataSize'='2972053294998', 
'totalSize'='50796390931', 
'transient_lastDdlTime'='1501859524')

我的问题是：

create table schema.dest_tbl as select * from schema.source_tbl;