一次impala查询详细错误记录和分析

前言

impala集群出错的一次记录和解决方法以及解决思路。

错误记录

错误信息

Memory limit exceeded Cannot perform hash aggregation. Partitioned input data too many times. This could mean there is too much skew in the data or the memory limit is set too low.

Query信息

就是个这么长的Query语句,Query需要join十多张的表,各种的字段。这只是很多sql中的其中一个。

create TABLE test.cp_ag_info ASSELECT a1.id cid, hr_num, position_num, available_po_num, rs_num, auto_filter_num, read_num, see_num, manual_refuse_num, it_num, auto_refuse_num, forward_num, get_rs_po_num, get_read_rs_po_num, get_see_rs_po_num, get_it_rs_po_num
FROM mysql.cp a1
LEFT JOIN (
SELECT cid, COUNT(DISTINCT uid) hr_num
FROM (
SELECT id uid, testid cid
FROM mysql.dante_user

......

UNION
SELECT a1.user_id uid, a2.dante_cp_id cid
FROM mds.t_cp_user a1
LEFT JOIN mds.t_cp a2
ON a1.cp_id=a2.id
WHERE a1.is_del='false' AND a2.is_del='false') f
GROUP BY cid) a6
ON CAST(a1.id AS STRING)= a6.cid
LEFT JOIN (
SELECT testid cid, COUNT(1) position_num, COUNT(CASE WHEN isenable!=0 AND isexpired!=1 

......

COUNT(CASE WHEN a1.DELIVER_AUTO_FILTER=1 THEN a1.orderid END) auto_filter_num,
COUNT(CASE WHEN a1.READ_rs=1 THEN a1.orderid END) read_num,
COUNT(CASE WHEN a1.READ_CONTACT=1 THEN a1.orderid END) see_num,
COUNT(CASE WHEN a1.MANUAL_REFUSE=1 THEN a1.orderid END) manual_refuse_num,
COUNT(CASE WHEN a1.ONLINE_it=1 OR a1.OFFLINE_it=1 THEN a1.orderid END) it_num,
COUNT(CASE WHEN a1.AUTO_REFUSE=1 THEN orderid END) auto_refuse_num,
COUNT(CASE WHEN a1.AUTO_FORWARD=1 OR a1.MANUAL_FORWARD=1 THEN orderid END) forward_num
FROM test.ur a1
GROUP BY a1.testid) a8
ON a1.id=a8.cid
LEFT JOIN (
SELECT a1.testid cid,

......

a1.READ_rs=1 THEN a1.positionid END) get_read_rs_po_num
FROM test.ur a1
GROUP BY testid) a10
ON a1.id=a10.cid
LEFT JOIN (
SELECT a1.testid cid,
COUNT(DISTINCT CASE WHEN a1.READ_CONTACT=1 THEN a1.positionid END) get_see_rs_po_num
FROM test.ur a1
GROUP BY testid) a11
ON a1.id=a11.cid
LEFT JOIN (
SELECT a1.testid cid,
COUNT(DISTINCT CASE WHEN a1.ONLINE_it=1 OR a1.OFFLINE_it=1 THEN a1.positionid END) 
......

ON a1.id=a12.cid

错误现象和解决方法

出现这个错误的原因非常奇葩,根据猜测是因为今天在给进群添加资源管理Llama时出现的,开启Llama然后关闭,它会修改impalad的资源上限,之前是32G的,结果被修改成了8G,而我还不知道被改了,也是看了很久才发现的。

今天在线上测试Llama后,因为感觉不太合适就关掉了,然后就开始出现各种的Memory Limit的错误,之前的正常运行的大Query今天集群失败,以前是没有错误的。定位后,修改一下大小就行了。

这个问题出现后,还出现过一次其它的问题,但是只出现了一次,不明白是什么原因,因为没有复现,所以没再处理。

Memory limit exceeded The memory limit is set too low initialize the spilling operator. The minimum required memory to spill this operator is 528.00 MB.

2016-04-07 19:53:00

转载于:https://www.cnblogs.com/dantezhao/p/5365118.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
当使用Impala查询Hive表时,Impala可以利用Hive的元数据信息来分析查询的分区扫描范围。这样可以避免不必要的全表扫描,提高查询性能。下面是结合Hive元数据分析Impala查询分区扫描范围的一般步骤: 1. 确保Impala和Hive之间的元数据同步:Impala和Hive共享相同的元数据存储,通常是Hive Metastore。确保Impala和Hive之间的元数据是同步的,可以使用`INVALIDATE METADATA`语句来刷新Impala的元数据缓存。 2. 创建分区表并加载数据:在Hive中创建一个分区表,并加载数据到分区中。例如,使用Hive的`CREATE TABLE`和`LOAD DATA`语句来创建和加载表。 3. 分析表的元数据:在Impala中,使用`COMPUTE STATS`语句来分析表的元数据。这将更新Impala的统计信息,包括每个分区的行数、最小值、最大值等。 ```sql COMPUTE STATS your_table; ``` 4. 按条件查询分区:在Impala中,编写带有分区谓词的查询语句。Impala会利用Hive的元数据信息来分析查询的分区扫描范围,并只扫描符合条件的分区。 ```sql SELECT * FROM your_table WHERE partition_column = 'value'; ``` 在执行查询时,Impala会根据Hive的元数据信息确定查询的分区扫描范围,并仅扫描相关的分区。这样可以避免扫描整个表,提高查询性能。 请注意,确保Impala和Hive之间的元数据同步非常重要,以确保Impala能够正确地利用Hive的元数据信息进行查询优化。另外,Impala还提供了其他工具和语句,如`SHOW PARTITIONS`和`DESCRIBE FORMATTED`等,可用于查看表的分区信息和元数据详情。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值