hiveonspark（hiveonspark和sparkonhive）

本篇文章给大家谈谈hiveonspark，以及hiveonspark和sparkonhive对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、什么是Hive on Spark
• 2、hive on spark僵死问题分析
• 3、Hive on Spark
• 4、Spark应用 | Hive On Spark性能调优

什么是Hive on Spark

hive默认计算引顷拦扰擎雀旦衡做是mapreduce，hive on spark是搞hive的开发者将计算引擎换成spark

对应的有spark sql，这是spark的开发者写的访问hive数据的sql引擎。两者开发者不同。

如果你搞hive的话，建议可以再了解下hive on tez，又叫Stinger

[img]

hive on spark僵死问题分析

背景：

最近大数据平台为租户经分系统提供运算及存储能力，经分的资源需求如下

Memory:  6T

CPU:     1600 c

存储：   600T

文件系统：HDFS

运算组件: hive on spark

权限管理：sentry

问题描述：

       为经分系统分配完租户在运行SPARK作业的时候，会重现任力僵死的情况，后台hiveserver2登录，一直卡在登录命令行，查看hive日志发现过多的GC 等待

  通过jstat  查看FGC记录（ 注，这是更改后的图，更改前的GC图未保存，当时FGC 一分钟达到200多次,E,O区一直在100% ）。

再通过jmap 查看下heap信息（此图也是更改后的图，当时原图未保留，原MaxHeapSize=512M）。

通过以上分析可以定们到JVM的堆信息太小，但当时部历稿署时更改了hive-env.sh中的JVM信息了

但我袜悔们通过jmap查看只分到了512M内存，问题在哪儿呢。

通过jinfo看下加载的命令信息。

看到加载了xmx=512M,但为何是512M呢，经分析，是hive做为hadoop的客户端加载hadoop的配置文件，hadoop-env.sh,如下图

[

在hivesiver2加载的时候会先加载hive-env.sh再加载hadoop-env.sh 的客户端参数HADOOP_CLIENT_OPTS，即然我们知道是加载的HADOOP_CLIENT_OPTS参数。我们只要更改hive-env.sh

增加如下配置。

重启hiveserver2可以看到hiveserver2的heap大小已变为8192M,前肢好孝台作业及hive

on spark作业正常（经15天的运行再未出出僵死的情况。）

Hive on Spark

版本： 2.3.3

Hive on Spark为Hive提供了 Apache Spark 作为执行引擎。

set hive.execution.engine=spark;

Hive 1.1+以上版本提供Hive on Spark 。它在“ spark ”和“spark2”分支中仍处于发展阶段，并且定期合并到Hive的“主”分支中。

参见 HIVE-7292 及其子任务和相关问题。

Hive on Spark仅用特定版本的Spark进行测试，因此给定版本的Hive只能保证与Spark的特定版本兼容。Spark的其他版本可能与给定版本的Hive一起使用，但不能保证。以下是Hive版本及其相应兼容Spark版本的列表。

按照说明安装Spark：

YARN模式： http : //spark.apache.org/docs/latest/running-on-yarn.html

独立模式： https ： //spark.apache.org/docs/latest/spark-standalone.html

Hive on Spark 默认支持 Spark on YARN 模式。

对于安装执行以下任务：

在Spark 2.0.0之前：

从Spark 2.0.0起：

由Spark 2.3.0起：

公平调度程序 是必需的，而不是 容量调度 程序 。这在YARN集群中公平地分配了相同份额的资源。

有关配置Hive和远程Spark驱动程序的其他属性，请参阅 Hive配置属性 的 Spark部分 。

设置执行程序的内存大小要比简单地设置为尽可能大要复杂。有几件事情需要考虑：

以下设置需要针对群集进行调整，这些设置也可能适用于在Spark之外的Hive上提交Spark作业：

在Spark on YARN 时， 我们通常建议将spark.executor.cores设置 为5,6或7，具体取决于可以被节点整除。例如，如果 yarn.nodemanager.resource.cpu-vcores是19，那么6是更好的选择（所有执行者只能拥有相同数量的内核，如果我们选择5，那么每个执行者只能获得3个内核;如果我们选择了7，那么只有2个执行者被使用，5个核心将被浪费）。如果是20，那么5是更好的选择（因为这样你会得到4个执行者，并且没有核心被浪费）。

对于 spark.executor.memory ，我们推荐计算 yarn.nodemanager.resource.memory-mb *（spark.executor.cores / yarn.nodemanager.resource.cpu-vcores）， 然后拆分spark.executor.memory和。根据我们的实验，我们建议设置 为总内存的15-20％左右。 spark.yarn.executor.memoryOverhead``spark.yarn.executor.memoryOverhead

在决定每个执仔启行程序接姿嫌收多少内存之后，您需要决定将多少执行程序分配给查询。在GA版本中，将支持Spark动态执行程序分配。但是，对于这个测试版，只能使用静态资源分配。根据每个节点的物理内存的配置 spark.executor.memory 和 spark.yarn.executor.memoryOverhead ，你需要选择实例和组的数量 spark.executor.instances 。

现在是一个真实世界的例子 假设每个节点念册如具有12个虚拟内核的10个节点具有64GB的内存，例如， yarn.nodemanager.resource.cpu-vcores=12 。一个节点将被用作主节点，因此集群将有9个从节点。我们将配置 spark.executor.cores 为6.鉴于64GB的内存 yarn.nodemanager.resource.memory-mb 将为50GB。我们将确定每个执行程序的内存量如下：50GB *（6/12）= 25GB。我们将分配20％ spark.yarn.executor.memoryOverhead ，或5120和80％ spark.executor.memory ，或20GB。

在这个9节点集群上，每个主机都有两个执行者。因此，我们可以配置 spark.executor.instances 2到18之间的某个值。值为18将利用整个群集。

有关这些设置的详细信息，请参阅 HIVE-9153 。

有关其他属性，请参阅 配置页面的Spark部分 。

Spark应用 | Hive On Spark性能调优

我们迹岩公司yarn node节点的可用资源配置为：单台node节点可用资源数：核数33cores、内存110G。Hive on Spark任务的基础配置，主要配置对象包括：Executor和Driver内存，Executor配额，任务并行度。

配置参数为spark.executor.memory和spark.executor.cores。如果要最大化使用core，建议将core设置为4、5、6，且满足core的个数尽量可以整除yarn资源核数。yarn资源可用33核，建议spark.executor.cores设置为4，最多剩下一个core，如果设置为5，6都会有3个core剩余。 spark.executor.cores=4，由于总共有33个核，那么最大可以申请的executor数是8。总内存处以8，也即是 110/8，可以得到每个executor约13.75GB内存。

建议 spark.executor.memoryOverhead（spark的executor堆外内存）站总内大档存的 15%-20%。 那么最终 spark.executor.memoryOverhead=2.75 G 和spark.executor.memory=11 G

注意：默认情况下 spark.executor.memoryOverhead = max(executorMemory * 0.10, 384M)，正常情况下不需要手动设置spark堆外内存，如果spark任务出现如下报错，可以手动提高堆外内存大小。

注意：默认情况下 spark.executor.memoryOverhead = max(executorMemory * 0.10, 384M)，正常情况下不需要手动设置spark堆外内存，如果spark任务出现如下报错，可以手动提高堆外内存大小。

Container killed by YARN for exceeding memory limits. 16.9 GB of 16 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.

对于drvier的内存配置，主要有两个参数：

Driver的内存通常来说不设置，或者设置1G左右应该就够了。需要注意的是，如果需要使用collect算子将RDD的数据全部拉取到Driver端进行处理，那么必须确保Driver的内存足够大，否则会出现OOM内存溢出的问题。

配置参数为spark.executor.instances。该参数用于设置Spark作业总共要用多少个Executor进程来执行。

executor的数目是由每个节点运行的executor数目和集群的节点数共同决定。我们离线集群27个节点，那么离线spark任务使用的最大executor数就是 216(27*8). 最大数目可能比这个小点，因为driver也会消耗核数和内存。

该参数可以结合spark.executor.cores设置，默认单个spark任务最大不超过60cores，spark.executor.cores设置为4，则spark.executor.instances不超过15。

设置spark任务的并行度参数为spark.default.parallelism。spark任务每个stage的task个数=max(spark.default.parallelism, HDFS的block数量)。如滚州乱果不设置该参数，Spark自己根据底层HDFS的block数量来设置task的数量，默认是一个HDFS block对应一个task。spark默认spark.default.parallelism配置较少，如果task个数比较少的话，前面spark资源配置没有意义。官网建议：该参数设置为 num-executors * executor-cores的2~3倍较为合适。

当一个运行时间比较长的spark任务，如果分配给他多个Executor，可是却没有task分配给它，而此时有其他的yarn任务资源紧张，这就造成了很大的资源浪费和资源不合理的调度。动态资源调度就是为了解决这种场景，根据当前应用任务的负载情况，实时的增减Executor个数，从而实现动态分配资源，使整个Spark系统更加健康。

开启spark动态资源分配后，application会在task因没有足够资源被挂起的时候去动态申请资源。当任务挂起或等待spark.dynamicAllocation.schedulerBacklogTimeout(默认1s)的时间后，会开始动态资源分配；之后每隔spark.dynamicAllocation.sustainedSchedulerBacklogTimeout(默认1s)时间申请一次，直到申请到足够的资源。每次申请的资源量是指数增长的，即1,2,4,8等。

当application的executor空闲时间超过spark.dynamicAllocation.executorIdleTimeout（默认60s）后，就会被回收。

使用场景：同一个SQL语句需要同时更新多个分区，类似于如下SQL语句：

关于hiveonspark和hiveonspark和sparkonhive的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。