Hive是大数据畛域罕用的组件之一，次要是大数据离线数仓的运算，对于Hive的性能调优在日常工作和面试中是常常波及的的一个点，因而把握一些Hive调优是必不可少的一项技能。影响Hive效率的次要有数据歪斜、数据冗余、job的IO以及不同底层引擎配置状况和Hive自身参数和HiveSQL的执行等因素。本文次要结合实际业务状况，在应用Spark作为底层引擎时，通过一些常见的配置参数对报错工作进行调整优化。
上面从两个方面对简单工作的优化：
Spark资源参数优化
次要针对Spark运行过程中各个应用资源的中央，通过调节资源相干参数，来优化资源应用的效率，从而晋升Spark作业的执行性能。例如：num-executors、executor-memory、executor-cores等。
Shuffle相干参数调优
次要针对spark运行过程中的shuffle，通过调节参数，进步shuffle的执行效率，从而晋升spark作业的执行性能。例如：spark.shuffle.memoryFraction,spark.sql.shuffle.partitions等。
案例1
简单工作执行失败，大概有400行sql，较为简单，join聚合函数操作较多。手动重试工作后依然报错。
查看工作报错日志
剖析要害信息
Exception in thread "broadcast-exchange-0" java.lang.OutOfMemoryError: Not enough memory to build and broadcast the table to all worker nodes. As a workaround, you can either disable broadcast by setting
spark.sql.autoBroadcastJoinThreshold to -1 or increase the spark driver memory by setting spark.driver.memory to a higher value得出结论
以后所有的工作节点均没有足够的内存去build并且播送表，倡议解决办法：将播送置为有效或者减少spark的driver memory。
优化成果
通过比照测试验证，在同时调大excutor内存和driver内存后，工作能够胜利运行。独自调大driver或excutor内存，工作运行仍然失败。
Q1：什么状况下应将播送设置为有效？
依据官网文档对该参数的形容可知：其默认值为10M，意味着执行join时，这张表字节大小在10M内能够主动播送到所有工作节点。将表播送到其余工作节点，会缩小shuffle的过程，晋升效率。如果在内存足够并且数据量过多的状况下，能够将适当进步该参数值作为一种优化伎俩。如果在表都很大的状况下，倡议将主动播送参数置为有效。将参数值设置为-1时会禁用主动播送。
案例2
某个工作曾经运行了40多个小时，主动重试了3次，始终处于阻塞状态。
查看异样工作SQL
发现工作中由10多个SQL语句形成，一个语句大略有200+行，union all、join、sum操作较多。
查看工作报错日志
剖析要害信息
org.apache.spark.shuffle.MetadataFetchFailedException:
Missing an output location for shuffle 433得出结论
个别工作有大量shuffle操作的时候，咱们能够从shuffle数据量及shuffle分区数的角度对工作进行优化调整。
优化成果
只采取调大executor内存的形式进行优化，工作能够运行胜利，但工作执行耗时依然需20+分钟，执行效率与优化前相比无显著变动。起因在于工作执行中产生了较多的task，此时能够通过调整分区参数进行深刻优化。分区参数spark.sql.shuffle.partitions是Spark SQL专用的设置，将该参数的值由200（默认值）调小为50，工作运行胜利，执行耗时缩小50%，约10分钟；持续将该参数调小为10，工作运行胜利，执行耗时缩小70%，约6分钟，优化实现。
**Q2：spark.default.parallelism参数与
spark.sql.shuffle.partitions参数有什么区别？**
尽管这两个参数较为类似，但default.parallelism只在解决RDD时才会起作用，对Spark SQL有效。其值设置为【num- executors * executor-cores】的2~3倍较为正当。能够参考官网的定义阐明：
延长拓展
1.shuffle分为shuffle write和shuffle read两局部。
2.shuffle write的分区数由上一阶段的RDD分区数管制，shuffle read的分区数则是由Spark提供的一些参数管制。
3.shuffle write能够简略了解为相似于saveAsLocalDiskFile的操作，将计算的两头后果按某种规定长期放到各个executor所在的本地磁盘上。
4.shuffle read时数据的分区数则是由spark提供的一些参数管制。如果这个参数值设置的很小，同时shuffle read的量很大，那么将会导致一个task须要解决的数据十分大，容易引发JVM crash。如果这个参数值设置的很大，可能会导致task的数量过多，工作执行速度过慢。
job和stage以及task的关系如下图所示，job的划分是action操作造成的，Stage是job通过依赖关系划分进去的，一个Stage对应一个TaskSet，一个Task对应一个rdd分区。同时大量应用shuffle操作也会使task数量变多。
本次优化次要是结合实际优化案例，对底层引擎spark的参数进行调优。如何通过优化晋升工作执行效率？如何利用监控剖析将被动运维转为被动运维？请关注后续Hive性能优化及监控方面的实际连载。