hive调优----查询条件

数据处理中，不怕数据量大，就怕数据倾斜

1、慎重使用count(distinct col)

distinct会将col列所有数据保存在内存中，形成一个类似hash的结构，速度很快；但是在大数据背景下，因为col列所有值都会形成以key值，极有可能发生OOM(内存用完）

解决方案：

可以考虑使用Group By 或者 ROW_NUMBER() OVER(PARTITION BY col)方式代替COUNT(DISTINCT col)

2、小文件会造成资源的多度占用，影响查询效率

原因：

1>小文件在HDFS存储中会占用过多的内存空间，在MP查询过程中，过多的小文件会造成启动过多的Mapper Task ,每个Mapper 都是一个线程后台，会占用JVM的空间

2>动态分区会造成在插入数据过程中，生成过多零碎的小文件

3>不合理的Reducer Task数量的设置也会造成小文件的生成，因为最终Reducer是将数据落地到HDFS中的

解决方案：

在数据源头HDFS中控制小文件产生的个数

~1采用Sequencefile作为表存储格式，不要用textfile，在一定程度上可以减少小文件（常见于在流计算的时候采用Sequencefile格式进行存储）

~2减少reduce的数量(可以使用参数进行控制)

~3慎重使用动态分区，最好在分区中指定分区字段的val值

~4做好数据的校验工作，比如通过脚本方式检测hive表的文件数量，并进行文件合并

~5合并多个文件数据到一个文件中，重新构建表

3、慎重使用select * 

原因：

大数据量多字段的表中，使用 SELECT * 方式去查询数据，会造成很多无效数据处理，会占用程序资源，造成资源浪费

解决方案：

查询数据表时，指定所需的待查字段名，而非使用 * 号

4、不要在表关联后面加where条件

比如以下语句：

SELE