前言
null在数据中是一个很特殊的存在,我们实际经历多起生产事故,而且直接就带来直接的经济损失,这个值在实际使用的时候很容易被用错,今天我们来盘点一下null带来的坑吧。
对常见几种空的理解
比较结果错误
首先还是准备数据
create table tmp_null_test as select id,col from
values(1,null)
,(2,'v2')
,(3,'v3')
,(null,'v4')
t(id,col);
select * from tmp_null_test;
id col
1 \N
2 v2
3 v3
\N v4
最常见的就是我们期望获取null的值,比如我们很自然的想到列=null的情况
select * from tmp_null_test where col=null;
这个结果很诡异,实际上是查询不到结果的,我们直接看一下如果col=null是怎样的结果:
select id,col,col=null as pk from tmp_null_test;
id col pk
1 \N \N
2 v2 \N
3 v3 \N
\N v4 \N
特别的神奇,pk结果清一色\N,这样告诉我们获取null这样子是会错误的,null和任何结果比较其实都是无意义的。
怎么办呢?一般有下面些办法:
1、使用 is null
select id,col,col is null as pk from tmp_null_test;
id col pk
1 \N true
2 v2 false
3 v3 false
\N v4 false
2、使用 COALESCE/nvl函数把null转化掉,再进行过滤
select id,col,COALESCE(col,'')='' from tmp_null_test;
id col _c2
1 \N true
2 v2 false
3 v3 false
\N v4 false
select id,col,nvl(col,'')='' from tmp_null_test;
id col _c2
1 \N true
2 v2 false
3 v3 false
\N v4 false
大量null导致倾斜
null带来的倾斜主要有两种,一种是明确告诉你有null,再join我们倒是比较好发现,还一种是在隐式转换的时候带来了null这种很难发现,这个就是null阳谋和阴谋,不管那种情况,在数据体量比较大的时候,其实都会带来极差的性能。
阳谋
一般在数据内部有null的时候,我们直接用来做join,数据量大的时候就是很慢,甚至运行不出来,这种时候也是null的问题,这种情况需要看业务场景是否需要转化掉
阴谋
有一种情况存在,如下面图中的id,左边是字符串类型,右边其实是double类型,这种时候在做join的时候取值a,b的时候并不能转化成double,这个时候也会产生null
这种时候产生的null还不是直接产生的,是在做隐式转换的时候发生的,这个时候会导致异常,这种情况很难发现,我记得我们排查了大半年。后面发现问题之后,是需要提前把右边id转换成String类型,再做join。配上sql来说明:
第一次的样子:
select t1.id,t1.name,t2.name from table1 t1 join table2 t2 on t1.id=t2.id
实际转换路径如下:
要注意的是这个操作是隐式的,可以在日志上面看到,但是一般人不感知,这种时候会造成null
解决办法:
select t1.id,t1.name,t2.name from table1 join
(selec cast(id as string) as id,name from table2) t2 on t1.id=t2.id
这种方式是主动把原来是double类型的id主动转换成字符串,带来的是下面的效果:
null占空间极小,改变了分发策略
在orc格式的存储时代,大量null的数据存在在一个很小的空间中,通过测试发现一个2M的文件,可以存储2亿行的数据,这种时候2m引擎会认为你是小文件,从而直接进行广播,结构就是导致Driver端的OOM,这种时候出现了很多起事故。
怎么解决呢?发现了直接禁止掉了广播了
后记
null需要小心使用,否则~