上一篇我们介绍了关系型数据库SQL的优化主要是索引和减少数据量,本文以大家常用的HIVE SQL为基础来介绍如何优化SQL的运行速度。
下面是本次分享的逻辑和顺序:
HIVE SQL优化的核心
数据倾斜
大家知道大数据的核心之一就是数据量大,所以数据量很大对于大数据本身不是挑战,否则就不叫大数据了。大数据最怕的就是数据倾斜,所谓的倾斜就是所有的task都放到一个节点(暂且理解为一台机器)去这性,这样大数据的大(分布式集群)的优势就无法发挥出来。就想下面这整图,看着是一堆处理器,实际干活的却只有一个。
为什么会产生数据倾斜呢?接触过大数据的都知道,大数据任务的执行通常来说都是分阶段执行,上一个阶段执行完产生中间结果,然后下一个阶段拉取上个阶段的执行结果,而大数据又是分布式、多任务并行的,那么每个任务如何拉取自己需要的那份数据呢?这通常使用的是hash算法,在这种算法下,如果数据中数据key(hash分组依赖的健)分布不均匀的话就会造成大量的数据分到一个节点上,而极少的数据分给另外的节点。分配的不公平自然也就造成了计算时间的不一致,数据少的几点很快执行完但是必须要等到分配数据多的节点执行完才能输出最终结果。这就是数据倾斜的通俗解释。
减少数据量
虽然我们说了大数据并不畏惧超大量数据,但是站在优化的角度来说如果能减少不必要的参与计算的数据还是具有重要的意义的。减少数据量能从两个方面来优化,首先是减少磁盘IO,尤其是对于MR这种计算框架中间临时计算结果是要写到磁盘的,磁盘的速度要比内存慢很多。其次减少数据量还可以减少网络IO,我们知道大数据都是集群式部署的,不同节点之间要进行数据的交换必要要通过网卡,网卡相比磁盘有慢了不少。所以,单从以上两个方面来说减少数据量同样是优化中不可或缺的。
从两个维度来谈如何优化
HIVE SQL书写层面上的优化
1、使用group by 代替count(distin