共计 2423 个字符，预计需要花费 7 分钟才能阅读完成。
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 性能优化及监控方面的实际连载。
