【技術(shù)難點(diǎn)】hive on spark 調(diào)優(yōu)
hive on spark 性能遠(yuǎn)比hive on mr 要好，而且提供了一樣的功能。用戶的sql無需修改就可以直接運(yùn)行于hive on spark。udf函數(shù)也是全部支持。
本文主要是想講hive on spark 在運(yùn)行于yarn模式的情況下如何調(diào)優(yōu)。
下文舉例講解的yarn節(jié)點(diǎn)機(jī)器配置，假設(shè)有32核，120GB內(nèi)存。
yarn.nodemanager.resource.cpu-vcoresyarn.nodemanager.resource.memory-mb
這兩個(gè)參數(shù)決定這集群資源管理器能夠有多少資源用于運(yùn)行yarn上的任務(wù)。這兩個(gè)參數(shù)的值是由機(jī)器的配置及同時(shí)在機(jī)器上運(yùn)行的其它進(jìn)程共同決定。本文假設(shè)僅有hdfs的datanode和yarn的nodemanager運(yùn)行于該節(jié)點(diǎn)。
1. 配置cores
基本配置是datanode和nodemanager各一個(gè)核，操作系統(tǒng)兩個(gè)核，然后剩下28核配置作為yarn資源。也即是
yarn.nodemanager.resource.cpu-vcores=282. 配置內(nèi)存
對(duì)于內(nèi)存，預(yù)留20GB給操作系統(tǒng)，datanode，nodemanager，剩余100GB作為yarn資源。也即是
yarn.nodemanager.resource.memory-mb=100*1024。給yarn分配資源以后，那就要想著spark如何使用這些資源了，主要配置對(duì)象：
execurtor 和driver內(nèi)存，executro配額，并行度。
1. executor內(nèi)存
設(shè)置executor內(nèi)存需要考慮如下因素:
executor內(nèi)存越多，越能為更多的查詢提供map join的優(yōu)化。由于垃圾回收的壓力會(huì)導(dǎo)致開銷增加。
某些情況下hdfs的 客戶端不能很好的處理并發(fā)寫入，所以過多的核心可能會(huì)導(dǎo)致競爭。
spark.driver.memoryOverhead 每個(gè)driver能從yarn申請(qǐng)的堆外內(nèi)存的大小。 spark.driver.memory 當(dāng)運(yùn)行hive on spark的時(shí)候，每個(gè)spark driver能申請(qǐng)的最大jvm 堆內(nèi)存。該參數(shù)結(jié)合 spark.driver.memoryOverhead共同決定著driver的內(nèi)存大小。
driver內(nèi)存申請(qǐng)12GB，假設(shè) X > 50GB driver內(nèi)存申請(qǐng) 4GB，假設(shè) 12GB < X <50GB driver內(nèi)存申請(qǐng)1GB,假設(shè) 1GB < X < 12 GB driver內(nèi)存申請(qǐng)256MB，假設(shè) X < 1GB
Hive on spark 共享了很多hive性能相關(guān)的配置。可以像調(diào)優(yōu)hive on mapreduce一樣調(diào)優(yōu)hive on spark。然而，hive.auto.convert.join.noconditionaltask.size是基于統(tǒng)計(jì)信息將基礎(chǔ)join轉(zhuǎn)化為map join的閾值，可能會(huì)對(duì)性能產(chǎn)生重大影響。盡管該配置可以用hive on mr和hive on spark，但是兩者的解釋不同。
totalSize- 數(shù)據(jù)在磁盤上的近似大小。 rawDataSize- 數(shù)據(jù)在內(nèi)存中的近似大小。
hive.optimize.reducededuplication.min.reducer=4hive.optimize.reducededuplication=truehive.merge.mapfiles=truehive.merge.mapredfiles=falsehive.merge.smallfiles.avgsize=16000000hive.merge.size.per.task=256000000hive.merge.sparkfiles=truehive.auto.convert.join=truehive.auto.convert.join.noconditionaltask=truehive.auto.convert.join.noconditionaltask.size=20M(might need to increase for Spark, 200M)hive.optimize.bucketmapjoin.sortedmerge=falsehive.map.aggr.hash.percentmemory=0.5hive.map.aggr=truehive.optimize.sort.dynamic.partition=falsehive.stats.autogather=truehive.stats.fetch.column.stats=truehive.compute.query.using.stats=truehive.limit.pushdown.memory.usage=0.4 (MR and Spark)hive.optimize.index.filter=truehive.exec.reducers.bytes.per.reducer=67108864hive.smbjoin.cache.rows=10000hive.fetch.task.conversion=morehive.fetch.task.conversion.threshold=1073741824hive.optimize.ppd=true
在開始新會(huì)話后提交第一個(gè)查詢時(shí)，在查看查詢開始之前可能會(huì)遇到稍長的延遲。還會(huì)注意到，如果再次運(yùn)行相同的查詢，它的完成速度比第一個(gè)快得多。
Spark執(zhí)行程序需要額外的時(shí)間來啟動(dòng)和初始化yarn上的Spark，這會(huì)導(dǎo)致較長的延遲。此外，Spark不會(huì)等待所有executor在啟動(dòng)作業(yè)之前全部啟動(dòng)完成，因此在將作業(yè)提交到群集后，某些executor可能仍在啟動(dòng)。但是，對(duì)于在Spark上運(yùn)行的作業(yè)，作業(yè)提交時(shí)可用executor的數(shù)量部分決定了reducer的數(shù)量。當(dāng)就緒executor的數(shù)量未達(dá)到最大值時(shí)，作業(yè)可能沒有最大并行度。這可能會(huì)進(jìn)一步影響第一個(gè)查詢的性能。
在用戶較長期會(huì)話中，這個(gè)額外時(shí)間不會(huì)導(dǎo)致任何問題，因?yàn)樗辉诘谝淮尾樵儓?zhí)行時(shí)發(fā)生。然而，諸如Oozie發(fā)起的Hive工作之類的短期繪畫可能無法實(shí)現(xiàn)最佳性能。
為減少啟動(dòng)時(shí)間，可以在作業(yè)開始前啟用容器預(yù)熱。只有在請(qǐng)求的executor準(zhǔn)備就緒時(shí)，作業(yè)才會(huì)開始運(yùn)行。這樣，在reduce那一側(cè)不會(huì)減少短會(huì)話的并行性。
要啟用預(yù)熱功能，請(qǐng)?jiān)诎l(fā)出查詢之前將hive.prewarm.enabled設(shè)置為true。還可以通過設(shè)置hive.prewarm.numcontainers來設(shè)置容器數(shù)量。默認(rèn)值為10。
預(yù)熱的executor的實(shí)際數(shù)量受spark.executor.instances（靜態(tài)分配）或spark.dynamicAllocation.maxExecutors（動(dòng)態(tài)分配）的值限制。hive.prewarm.numcontainers的值不應(yīng)超過分配給用戶會(huì)話的值。
注意：預(yù)熱需要幾秒鐘，對(duì)于短會(huì)話來說是一個(gè)很好的做法，特別是如果查詢涉及reduce階段。但是，如果hive.prewarm.numcontainers的值高于群集中可用的值，則該過程最多可能需要30秒。請(qǐng)謹(jǐn)慎使用預(yù)熱。
--end--
掃描下方二維碼 添加好友，備注【交流】 可私聊交流，也可進(jìn)資源豐富學(xué)習(xí)群
更文不易，點(diǎn)個(gè)“在看”支持一下??