我们使用配置单元进行即席查询，并且有一个配置单元表，该表被划分为两个字段 (date,id) .
现在每个日期都有大约1400个id，因此在一天中添加了许多分区。实际数据驻留在s3中。现在我们面临的问题是假设我们 select count(*) 从表开始的一个月内，启动map reduce作业需要相当长的时间（大约：1小时52分钟）。
当我在hive-verbose模式下运行查询时，我可以看到它实际上花费了这段时间来决定要生成多少Map程序（计算拆分）。有什么方法可以减少map reduce作业启动的延迟时间吗？
这是在此延迟时间内记录的日志消息之一：
13/11/19 07:11:06 INFO mapred.FileInputFormat: Total input paths to process : 1
13/11/19 07:11:06 WARN httpclient.RestS3Service: Response '/Analyze%2F2013%2F10%2F03%2F465' - Unexpected response code 404, expected 200
1条答案
按热度按时间oxcyiej71#
这可能是因为对于过度分区的表，查询规划阶段需要很长时间。更糟糕的是，查询计划阶段本身可能比查询执行阶段花费更长的时间。
解决这个问题的一种方法是调整元存储。但是更好的解决方案是设计一个有效的模式，去掉不必要的分区。相信我，你真的不需要太多的小分区。
另外，您也可以尝试在发出查询之前将hive.input.format设置为org.apache.hadoop.hive.ql.io.combinehiveinputformat。
hth公司