hive的调优： 第一个调优：fetch抓取，能够避免使用mr的，就尽量不要用mr，因为mr太慢了 set hive.fetch.task.conversion=more 表示我们的全局查找，字段查找，limit查找都不走mr 这个属性配置有三个取值 more minimal none 如果配置成none，所有的都要走mr程序 hive的本地模式： set hive.exec.mode.local.auto=true 开启本地模式，解决多个小文件输入的时候，分配资源时间超过数据的计算时间 set hive.exec.mode.local.auto.inputbytes.max=51234560; 设置输入的数据临界值，如果小于这值都认为是小任务模式，启动本地模式来执行 set hive.exec.mode.local.auto.input.files.max=10; 设置输入文件个数的临界值，如果小于这个数量，那么也认为是小任务模式 第二个优化：hive表的优化 去重的优化： select count(distinct s_id) from score;这种写法所有的去重数据都会在一个reduce当中去，造成数据处理比较慢 select count(1) from (select s_id from score group by s_id) bysid; 这种写法，使用了一个嵌套子查询，先对数据进行group by去重，然后再进行统计 尽量避免大sql，可以将一个很大的sql拆成多段，分步的去执行 大表join大表的优化： 空key的过滤 不过滤： INSERT OVERWRITE TABLE jointable SELECT a.* FROM nullidtable a JOIN ori b ON a.id = b.id; 结果： No rows affected (152.135 seconds)
过滤：过滤掉我们所有的为null的id，使得我们的输入数据量变少 INSERT OVERWRITE TABLE jointable SELECT a.* FROM (SELECT * FROM nullidtable WHERE id IS NOT NULL ) a JOIN ori b ON a.id = b.id; 结果： No rows affected (141.585 seconds)
空key的转换 如果规定这些空key过滤不调，那么我们可以对空key进行转换 SELECT a.* FROM nullidtable a LEFT JOIN ori b ON CASE WHEN a.id IS NULL THEN 'hive' ELSE a.id END = b.id; 如果空key比较多，那么就会将大量的空key转换成 hive，那么就会遇到一个问题，数据倾斜 数据倾斜的表现形式：有一个reduce处理的数据量远远比其他reduce处理的数据量要大，造成其他的reduce数据都处理完了，这个还没处理完 怎么发现的数据倾斜，如何出现的数据倾斜，怎么解决的数据倾斜 空key的打散 SELECT a.* FROM nullidtable a LEFT JOIN ori b ON CASE WHEN a.id IS NULL THEN concat('hive', rand()) ELSE a.id END = b.id; 通过将空key打散成不同的随记字符串，就可以解决我们hive的数据倾斜的问题
hive第三个优化：map端的join hive已经开启了自动的map端的join功能，不管是我们的大表join小表，还是小表join大表，都会将我们的小表加载到内存当中来 首先第一步：启动一个local的task，寻找哪个表的数据是小表数据 hive的group by优化：能在map端聚合的数据，就尽量在map端进行聚合 多加一层mr的程序，让我们的数据实现均衡的负载，避免数据的倾斜
count(distinct)的优化： 这种写法效率低下：SELECT count(DISTINCT id) FROM bigtable; 可以准换成这种写法：SELECT count(id) FROM (SELECT id FROM bigtable GROUP BY id) a;
笛卡尔积：任何时候都要避免笛卡尔积，避免无效的on条件 select from A left join B -- on A.id = B.id 使用分区裁剪，列裁剪： 分区裁剪：如果是我们的分区表，那么查询的时候，尽量带上我们的分区条件 列裁剪：尽量避免使用select * ,需要查询哪些列，就选择哪些列 动态分区调整： 分区表的数据加载两种方式： load data inpath '/export/xxx' into table xxx partition(month = 'xxx') insert overwrite table xxx partition (month = 'xxx') select xxx 使用动态分区动态的添加数据 如果要使用动态分区添加数据，最后一个字段一定要是我们的分区字段 INSERT overwrite TABLE ori_partitioned_target PARTITION (p_time) SELECT id, time, uid, keyword, url_rank, click_num, click_url, p_time FROM ori_partitioned;
数据的倾斜： 主要就是合理的控制我们的map个数以及reduce个数 第一个问题：maptask的个数怎么定的？？？与我们文件的block块相关，默认一个block块就是对应一个maptask 第二个问题：reduceTask的个数怎么定的？？？是我们自己手动设置的，爱设几个设几个，没人管你 第三个问题：是不是maptask的个数越多越好：不一定：有时候有些小文件，都要启动一个maptask，分配资源的时间超过了数据处理的时间 减少mapTask的个数：设置map端的小文件合并：使用combineHiveInputFormat来实现对我们小文件的合并，减少maptask的个数 或者使用本地模式也可以解决小文件的问题 增加maptask的个数：我们可以多设置几个reduce，然后使用distribte by将我们的数据打散 set mapreduce.job.reduces =10; create table a_1 as select * from a distribute by rand(123); 第四个问题：控制reduceTask的个数： reduce个数设置方法： （1）每个Reduce处理的数据量默认是256MB hive.exec.reducers.bytes.per.reducer=256123456 （2）每个任务最大的reduce数，默认为1009 hive.exec.reducers.max=1009 （3）计算reducer数的公式 N=min(参数2，总输入数据量/参数1)
直接凭感觉设置reduce的个数： set mapreduce.job.reduces = 15; 查看执行计划： explain extended select * from course; 并行执行：有时候有些sql之间是不相关的，可以并行的一起执行，那么就可以用并行执行
严格模式: 如果开启hive的严格模式，有以下三个限制 1、分区表需要带上分区字段 2、order by 必须使用limit 3、笛卡尔积不能执行
jvm的重用：我们的container的里面的任务执行完成之后，不要马上释放资源，留着资源给下一个任务执行 推测执行：maptask的推测执行以及reducetask的推测执行： 一般都直接关闭maptask以及reducetask的推测执行 set mapreduce.map.speculative=false;关闭map端的推测执行 set mapreduce.reduce.speculative=false; 关闭reduce端的推测执行 压缩与存储：压缩：snappy 源始数据存储：TextFile 处理之后的数据存储：ORC PARQUET
