1

这个问题最令人沮丧的部分是，显而易见的答案是“修复源表！” - 不幸的是我做不到（这是由另一个拒绝提供帮助的工作团队管理和维护的）。

所以我正在寻找一种技术解决方案来做到这一点而不改变源表。

情况是这样的：我有一个源表，我正在尝试编写一个配置单元查询来创建一个新表。查询最终需要花费数小时才能完成，原因是工作在单个 reducer 中遇到了瓶颈。

当我沿着源表找到它在 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;
4

0 回答 0