数据仓库-Hive的调优

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