sql看起来简单,还是有点东西的(不过还是很简单),很多时候数据有问题真的不是逻辑问题啥的,多半是你自己犯了一个愚蠢到无以复加的错误
以前觉得hive就是垃圾,太慢,sparksql支持的语法更全面而且更快,但实际上hive的稳定性远远好于sparksql,spark由于是内存计算,很容易崩,hive虽然慢但是能跑出来,但是只要hive跑不出来的东西,spark一定也跑不出来
语法
join on和join where的区别
left join中,on的条件除相当于where的加强版,where只会筛选出左=右的情况,而on相当于是where筛选出的记录+所有左记录
而inner join相当中on和where结果是一样的
union all select
sql中select的时候,列名是丝毫不重要的!只要对应位置的数据类型及总得列数相等就可以!神坑,select和union的时候很容易搞错,无论多久都会犯这个错误。
0除的问题
select 1/0不会报错,只会返回NULL,日了狗了
开窗函数:
grouping sets
sum(a) over(partition by b order)在hive下有的时候会有性能问题,hive跑了一个多小时根本没有进度,sparksql跑了两分钟(待查证)
hive中的变量和字符串一样,比如表达式exp的最终结果是123,则arr[exp]其实是arr[‘123’],需要arr[cast(exp as int)]
关键字如current是不能作为如with as的标识符的,否则会报错
优化
sql cache
会通过sql语句生成cache来缓存,这也是为什么要确立大小写规范的原因
mapjoin
针对小表join大表,将小表加载至内存,在大表的map端直接过滤,注意顺序不能乱,否则无法达到性能的提高(虽然不会报错)
最近发现with as很消耗硬盘io,不知道为啥,待查证,另外sparksql是否存在此问题?
数据倾斜
一直不太理解hive.groupby.skewindata这个参数到底是如何解决数据倾斜的,很多时候我感觉即使加了效果也不大,需要追根溯源到底distinct和count distinct为什么会引起数据倾斜?到底又是怎么解决的?
解决方法:
- 调整map和reduce的大小
两个参数:最大值和分片大小 - 数据倾斜
set hive.groupby.skewindata = true
针对count(distinct),限制条件https://blog.csdn.net/baidu_29843359/article/details/46967473,具体原理:两轮map:
set hive.auto.convert.join = true;
sql解析
logical plan->优化->physical plan->
感觉是和编译的过程类似?先优化生成中间语言,然后通过后端生成目标语言?看来也可以分编译器前端和后端