问题排查--Impala查询Decimal数据为NULL,Hive查询正常

目前,线上反馈一个问题:同一张表,使用Hive查询正常,但是使用Impala查询,返回的数据中,部分字段值为NULL。
我们使用impala执行了invalidate metadata xxx,排查了元数据不一致的问题,同时查看源文件,也排除了数据本身的问题。最终,通过在Impalad的web页面上查看该SQL的profile发现,其中存在如下的Errors:
impala_decimal_01
通过查询相关的错误,我们发现官方对于这块有相应地解释:
For text-based formats (text, RCFile, and SequenceFile tables), you can issue an ALTER TABLE … REPLACE COLUMNS statement to change the precision and scale of an existing DECIMAL column. As long as the values in the column fit within the new precision and scale, they are returned correctly by a query. Any values that do not fit within the new precision and scale are returned as NULL, and Impala reports the conversion error. Leading zeros do not count against the precision value, but trailing zeros after the decimal point do.
这段话主要的意思就是,如果通过alter table操作,修改了DECIMAL类型的precision和scale,如果实际值和新设置的DECIMAL不匹配的话,那么就会返回NULL。例如:如果数据是1.234,column定义是DECIMAL(4, 2),那么就会返回NULL。
我们可以通过如下的SQL进行简单的测试验证:

create table text_decimals (x string);
insert into text_decimals values ("1"), ("2"), ("99.99"), ("1.234"), ("000001"), ("1.000000000");
alter table text_decimals replace columns (x decimal(4,2));
select * from text_decimals;

如果用Impala执行最后一行,那么返回的记录中,第四行和第六行都是NULL;如果用Hive执行,则第四行和第六行分别是1.23和1.00。感兴趣的同事可以自行测试一下。
目前Impala还没有提供参数项配置,可以像Hive一样返回一个四舍五入的近似值,因此我们需要保证在定义的时候,不会出现这种情况。但是在实际测试的过程中我们发现,对于1.234,如果column定义是DECIMAL(4, 5),那么查询可以正常返回1.234,这意味着Impala是不允许精度丢失。值得注意的是,如果我们先执行set abort_on_error=1,再执行select查询,那么SQL会直接返回失败,而不是NULL,如下所示:
impala_decimal_02
官方链接参考:https://docs.cloudera.com/documentation/enterprise/5-16-x/topics/impala_decimal.html#decimal

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值