Hive与MR任务优化参数

Hive本身是个基于hdfs的结构化数据管理工具，虽然在后面的发展中允许底层接入其他的数据源，比如第三方数据服务这种基础架构，但是它从立意上来说，它不适合用来做高性能查询引擎，反而在传统离线数据仓库中它有着自身的优势

1.当你的查询数据量较大，此时spark等其他计算引擎会因为自身复杂的执行计划导致计算量很大，再加上计算中的硬性资源消耗，导致需要的资源使你无法接受，此时如果你可以接受较长时间的运行等待，建议使用hive，因为hive底层用的mr，任务分割截止到一次mr，没有那么大的消耗需求，你可以通俗的理解为hive只需要有你数据量大小和跑数据需要的进程类开销既可，它没有spark那种复杂的执行计划，因此它的使用成本是目前大数据计算引擎中最低的一个，效率也是最慢的，不过对于大任务的处理，更稳定

2.查询逻辑复杂，任务消耗资源较大，任务容易失败的情况下，建议使用hive，不过hive优势在于处理大数据，对于处理小数据没有优势，因为hive的执行延迟比较高。

这里给大家附带hive和mr的官方可用配置文档，把官方文档放在这里有两个目的，一是官方文档里面参数很全，就导致里面不止有可用来任务优化的参数，还有偏集群用的配置，二是我下面写的都是我在工作中会用到的，以及一些使用经验，并且官方文档里那么多参数工作都不可能都用，你想用也记不住啊，同时大家在看其他文献时，遇到不认识的参数可以去找找看，官方文档里有参数的开始生效版本(hive看官方文档的Added In，hadoop的需要你点击不同版本的mr配置文件下面的链接打开时最新版hadoop的)，找不到的话就说明，参数不正确或者apache版本的已经删除了相关配置

hive-》https://hive.apache.org/docs/latest/user/configuration-properties/
Hadoop-MR任务-》https://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/mapred-default.xml

由于Hive的底层就是MR，很多参数是共用的，所以总结这些参数就放在同一个博文里面了。两个架构有一些同能力的参数名称会不一样，这种参数就各用各的。如果hive没有，MR有，那么这个参数hive可以直接用，反过来hive有很多自己的策略参数MR就不能直接用了。但是注意hive直接使用MR的参数，随着版本不同，确实会偶尔有不生效的情况发生，但是发生的概率很小，因此下列的参数，会额外说明是谁的，具体使用的时候要注意mr的配置只能直接写在代码的配置对象里面，没有额外的命令行参数，如果你有自己想法，可以自己改造一下，或者写一个工具类获取并装载配置

下列列出的参数不会很多，因为mr自己的任务参数本身就不算多，和hive或者spark哪些没得比，自然能用来优化执行效率的就更少了，其次是hive自己的优化策略，很多都是默认打开且自动均衡的，毕竟和presto是兄弟，且有着不需要频繁变动的各项默认值

不过话说回来，mr真的很少有人使用，除非是10年以上的老项目，旧屎山代码，不然直接写mr相当难受的，比如一个最常见的问题，上游数据快确实倾斜了，就是需要控制map数量来提高任务效率，但是mr自己只能重写setup，并且在任务的执行中必须重写合理的自定义分组，不然shuffle的时候必然还回有中间文件以及热键问题，一个把控不好不只任务自己会炸，而且还影响下游。而且在这个ai时代很多人可以说是啥也不会，别说Java了，能用hadoop streaming 配合 python写个最基本的mr就了不得了，调参数和写代码控制计算的数据快大小等等这些问题，对于老鸟都需要带脑子写，更别说其他人了，所以能用hive就给自己省点事吧，生活不能只有牛马的IT，还要省点时间去看看诗和远方

看实际操作参数调优之前，应当看一眼MR任务的大盘Counters，和spark的taskset状态指标一样调优的大方向也是来着Counters，如果你在用Hive那就比较不便，因为一个Hive任务会有多个MR，默认架构下一次MR是一次Shuffle，2.x的Hive可以用Tez，不过总体的方向是差不多的

在大盘中，首先要看的是Map-Reduce Framework部分，这部分是最终要的

Map input records ：是 Map 阶段截至当前读取的记录数 ，用来反应输入数据量的统计，在MR大盘上只能看到偏向最终读出的记录数和字节大小，和spark的taskset数据块读取5个分布大小不一样，所以考虑任务资源时适当的预留一些，不要扣的太死，在数据读取上MR用的是自己的正/反系列化相关类库Text这些，而不是Java的String，所以GC相关的影响不是很大
Map output records ：Map 输出的记录数，和输入数相互观察，可以判断 map 阶段数据膨胀率有多少
Reduce input records ：Reduce 输入记录数，通常应与 Map output records 一致
Reduce output records ：Reduce 输出记录数，最终输出数据量
Spilled Records ：map和reduce阶段溢出到磁盘的记录数，正常情况下不会和输入差的很多，如果过高说明内存不足
Failed Shuffles ：Shuffle 失败次数，少量失败通常因为网络或磁盘问题，一遍也不会很高，大部分时候是0
Merged Map outputs ：shuffle 阶段合并Map输出结果的次数，开启Combine、设置任务数据块大小下限、更改shuffle时mapreduce.task.io.sort.factor操作的文件个数都会影响该值，通俗的讲，可以理解成如下逻辑

# 假设一个作业有：
# - 100个Map任务
# - 每个Map产生3个spill文件
# - 2个Reducer

实际文件情况：
Map端总共产生：100 Maps × 3 spills = 300个中间文件

# 在Reduce端的Merge过程：
Reducer1：从50个Map拉取 → 150个文件
          合并策略：每次合并10个文件
          需要合并次数：⌈150/10⌉ = 15次
          Merged Map outputs计数器：+15

Reducer2：从50个Map拉取 → 150个文件
          合并次数：15次
          Merged Map outputs计数器：+15

总计：Merged Map outputs = 30

Combine input records和Combine output records ：这两个指标用来观察 Combine 是否起效，当Combine 的输入输出差值在30%以上时，说明Combine 是有必要的
CPU time spent (ms) ：CPU刨除IO等待等其他时间之后，正在为了跑数据而执行的时间
GC time elapsed (ms) ：进入垃圾回收的时间
Input split bytes : 切片大小，在任务规划阶段确定，理论上一个健康的大小在70-128M之间，如果超出这个范围，就应当使用Combine 、任务数据块大小下限等手段来影响
Peak Map Physical memory (bytes)：单个map任务的容器物理内存使用峰值，判断资源是否浪费的直接指标，如果它离你设置的容器内存很近，一般GC就也会有明显变化
Peak Map Virtual memory (bytes)：单个map任务的容器虚拟内存使用峰值，MR这点和spark不一样，spark直接监控的是一个总的taskset执行内存峰值，MR是分开监控的，如果你不知道虚拟内存在yarn调度中是什么样的未知，可以看-》yarn集群资源规划注意点
Peak Reduce Physical memory (bytes) 和 Peak Reduce Virtual memory (bytes) ：同上
Physical memory (bytes) snapshot 和 Virtual memory (bytes) snapshot : 这个是所有mapreduce执行task时，两个内存指标的峰值快照，一般直接看map和reduce各自的峰值就行
Reduce input groups：reduce收到的key数量，同总数据量可以判断是否数据倾斜，或者和其他指标一起分析任务复杂度
Reduce shuffle bytes ：reduce收到的shuffle结果