hive16条优化

 优化点：从底向上
    1）压缩
        选型：不同场景（空间、解压速度、splitable）
        好处：
    2）Storage Format
        行式 vs 列式（olap 90%+）
        SQL on hadoop：
            textfile、sequencefile
            rcfile： 行+列
            orc、parquet ： bigdata
    3）分区
    4）SQL：数据倾斜
                groupby |    hive.map.aggr ===>true & hive.groupby.skewindata ===>true(把一个作业分成两个
                    第一个job：把map输出随机分到reduce，在每个reduce中做部分聚合
                    第二个job：把上一部的结果按照相同的key分到一个reduce上处理
                )
                join: 拆。    mapjoin／smbjoin sql改造
                count(distinct xx)
                window functions: row_num、first
                    topn   domain+url  domain top100 url
                   .... over partition by xxx  order by ...
    5）复杂+繁琐
    6）order/sort/distribute/cluster by
    7) hive作业
    8）UDF整合到Hive源码  <== 体现修改的能力
    9）执行计划
    10）stage 美团有一篇文章
    11）裁剪：字段裁剪、分区裁剪
    12）ppd： predicate push down + 列式存储
        参数：hive...ppd = true
    13) 共享
    14） metastore  uml
    15）推测执行：
        a.code bug
        b.数据倾斜
        ==>90%task跑完了，10%没跑完
        如task100慢了，超过一定时间，他会把这个作业在其他节点重新启动一份，此时就有多个相同的作业，此时就有多个相同的作业，谁先跑完就用谁的结果。
        好处：尽可能快地跑完task
        坏处：资源消耗（用更多的资源换取时间的优化机制，如果集群资源非常匮乏，那么。。。）
        hive默认是开启的
    16）控制reduce数量（输出文件的数量）
        reduce过多：输出文件数过多，很多小文件，开启／销毁jvm
        reduce过少：耗时出现数据倾斜
        如何设置reduce个数？
        mapred.reduce.tasks
        hadoop fs -du +路径==>通过文件大小计算出来 除以 每个reduce能够处理数据的大小
        什么场景下只有一个reduce：order by
    17)jvm重用：mr是进城级别，一个maptask和rtask都对应一个 jvm。想在一个jvm中运行多个task，mapred.job.reuse.jvm.num.tasks默认为1。修改他的值就行了。
    18）优化中间结果集
        多次查询同一张表同一分区，可以把前几次查询的结果创建成中间表，后面的查询直接查询这个中间表。
    sparksql：
        1）依赖hive：hql解析，metastore，serde
        sql翻译成ast===>sqarksql接管（catalyst）
        2）不依赖hive
    发布版本：spark1.0