13.108.Spark 优化、Spark优化与hive的区别、SparkSQL启动参数调优、四川任务优化实践:执行效率提升50%以上

这篇具有很好参考价值的文章主要介绍了13.108.Spark 优化、Spark优化与hive的区别、SparkSQL启动参数调优、四川任务优化实践:执行效率提升50%以上。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

13.108.Spark 优化
1.1.25.Spark优化与hive的区别
1.1.26.SparkSQL启动参数调优
1.1.27.四川任务优化实践:执行效率提升50%以上

13.108.Spark 优化:

1.1.25.Spark优化与hive的区别

先理解spark与mapreduce的本质区别,算子之间(map和reduce之间多了依赖关系判断,即宽依赖和窄依赖。)
优化的思路和hive基本一致,比较大的区别就是mapreduce算子之间都需要落磁盘,而spark只有宽依赖才需要落磁盘,窄依赖不落磁盘。
13.108.Spark 优化、Spark优化与hive的区别、SparkSQL启动参数调优、四川任务优化实践:执行效率提升50%以上,# Spark(大数据分析引擎),大数据,Spark
13.108.Spark 优化、Spark优化与hive的区别、SparkSQL启动参数调优、四川任务优化实践:执行效率提升50%以上,# Spark(大数据分析引擎),大数据,Spark

1.1.26.SparkSQL启动参数调优

13.108.Spark 优化、Spark优化与hive的区别、SparkSQL启动参数调优、四川任务优化实践:执行效率提升50%以上,# Spark(大数据分析引擎),大数据,Spark

1)先对比结果:executors优化
Hive执行了30分钟(1800秒)的sql,没有优化过的SparkSQL执行需要,
最少化的Executor执行需要640秒(提高了Executor的并行度,牺牲了HDFS的吞吐量:5个core最合适),
最大化的Executor 281.634秒(最大限度的利用HDFS的吞吐量,牺牲Executor的并行度),
优化取中间值,253.189秒。

方案1:最少化 Fat executors

---------------------------------	Fat executors	--------------------------------------------------------------------------------
./spark-sql --master yarn \	# Fat executors (每个节点一个Executor)【优势:最佳吞吐量】
--num-executors 3 \			# 集群中的节点的数目 = 3
--executor-memory 30G \	# 每个节点的内存/每个节点的executor数目 = 30GB/1 = 30GB
--executor-cores 16 \		# 每个executor独占节点中所有的cores = 节点中的core的数目 = 16
--driver-memory 1G			# AM大约需要1024MB的内存和一个Executor
耗时:Time taken: 640 seconds

方案2:最大化Tiny executors

---------------------------------	Tiny executors	--------------------------------------------------------------------------------
./spark-sql --master yarn \	# Tiny executors [每个Executor一个Core]【优势:并行性】
--num-executors 48 \		# 集群中的core的总数 = 每个节点的core数目 * 集群中的节点数 = 16*3
--executor-memory 1.6G \	# 每个节点的内存/每个节点的executor数目 = 30GB/16 = 1.875GB
--executor-cores 1 \			# 每个executor一个core
--driver-memory 1G			# AM大约需要1024MB的内存和一个Executor
耗时:Time taken: 281.634 seconds
executor并发度只有45,task的并发度,1个executor 50左右,总数 18382

方案3:折中方案

---------------------------------	Balance between Fat (vs) Tiny	--------------------------------------------------------------------------------
./spark-sql --master yarn \	# Balance between Fat (vs) Tiny
--num-executors 8 \			# (16-1)*3/5 = 9 留一个executor给ApplicationManager => --num-executors = 9-1 = 8
						# 每个节点的executor的数目 = 9 / 3 = 3
--executor-memory 10G \	# 每个executor的内存 = 30GB / 3 = 10GB【默认分配的是8G,需要修改配置文件支持到10G。】
						# 计算堆开销 = 7% * 10GB = 0.7GB。因此,实际的 --executor-memory = 10 - 0.7 = 9.3GB
--executor-cores 5 \			# 给每个executor分配5个core,保证良好的HDFS吞吐。
						# 每个节点留一个core给Hadoop/Yarn守护进程 => 每个节点可用的core的数目= 16 - 1
--driver-memory 1G			
耗时:Time taken: 253 seconds

Task并行度优化
1.调整 Executors 下 每个stage的默认task数量,即设置Task 的并发度:

【当集群数量比较大时】
很多人常犯的一个错误就是不去设置这个参数,那么此时就会导致Spark自己根据底层HDFS的block数量来设置task的数量,
!【默认是一个HDFS block对应一个task(如果不设置那么可以通过第三种方案来优化!)】。
通常来说,Spark默认设置的数量是偏少的(比如就几十个task),
如果task数量偏少的话,就会导致你前面设置好的Executor的参数都前功尽弃。
试想一下,无论你的Executor进程有多少个,内存和CPU有多大,但是task只有1个或者10个,
那么90%的Executor进程可能根本就没有task执行,也就是白白浪费了资源!
因此Spark官网建议的设置原则是,设置该参数为num-executors * executor-cores的2~3倍较为合适,
比如Executor的总CPU core数量为300个,那么设置1000个task是可以的,此时可以充分地利用Spark集群的资源。

30 G 16 core

/home/admin/bigdata/spark-2.2.0-bin-hadoop2.6/bin/spark-sql \
--master yarn \
--num-executors 16 \
--executor-memory 1G \
--executor-cores 10 \
--driver-memory 1G \
--conf spark.default.parallelism=450 \
--conf spark.storage.memoryFraction=0.5 \
--conf spark.shuffle.memoryFraction=0.3	

1.1.27.四川任务优化实践:执行效率提升50%以上

一、四川的信息
账号:xxxxxx 密码: xxxxxxxx

一、事实表优化
1、**优化结果: 20 分钟左右,优化完成后 5 分钟左右。**数据量:5.8亿

2、原SQL:(spark不一定快)

drop table if exists dc_f_organization;
create table if not exists dc_f_organization (
	orgid int,
	orgcode string,
	yearmonth string ,
	zzdate string,
	orgname string,
	orglevel int,
	id int,
	orgtagging int, 
	createdate timestamp
);

insert into dc_f_organization
select 
	a.orgid, .orgcode, a.yearmonth, a.zzdate, n.orgname, n.orglevel, n.id, n.orgtagging, n.createdate
from 
	( select o.id orgid, o.orgcode, d.yearmonth, d.zzdate from dc_d_organization o, dc_d_wddate ) a
	left join dc_d_organization n on to_date(n.createdate)=a.zzdate and n.orgcode = a.orgcode;
	

3、优化方案:
– ############################## HIVE 执行:增加 block 的数量,提高Spark的并发度(当前任务文件比较小,设置了26;一般参考数量:300左右;) #################################
– (1) 单独执行笛卡尔积,
– 先拆分文件:(改用hive,拆分文件,增加并行度)
– 【耗时:101.586 seconds;结果文件数量 26】
– 检查文件块数量:hadoop fs -ls /user/hive/warehouse/test.db/dc_d_org_date 26 个block

set mapreduce.map.memory.mb=1024;
set mapred.max.split.size=524288;
set mapred.min.split.size.per.node=524288;
set mapred.min.split.size.per.rack=524288;
drop table if exists dc_d_org_date;
create table dc_d_org_date as select o.id orgid,o.orgcode,d.yearmonth,d.zzdate from dc_d_organization o CROSS JOIN dc_d_wddate d;
-- ##############################	SPARK 执行;参数:spark-sql --master yarn --num-executors 100 --executor-memory 5G --executor-cores 3 --driver-memory 3G	#################################
-- (2)【Spark:Time taken: 115.78 seconds;】
set spark.shuffle.consolidateFiles=true;
drop table if exists dc_f_organization;
create table if not exists dc_f_organization
(orgid int,orgcode string,YEARMONTH string ,ZZDATE string,ORGNAME string,orglevel int,id int,ORGTAGGING int, createdate timestamp);

insert into dc_f_organization
select a.orgid,a.orgcode,a.YEARMONTH,a.ZZDATE,n.ORGNAME,n.orglevel,n.id,n.ORGTAGGING,n.createdate
from dc_d_org_date a
left join DC_D_ORGANIZATION n on to_date(n.CREATEDATE)=a.ZZDATE and n.orgcode = a.orgcode;

– ############################## 持续优化方向:将上述两者合并到一起在 spark 中执行 ##############################
问题:可能是因为文件太小,spark 分区命令没有生效。set spark.sql.shuffle.partitions=300;
注意:SPARK中笛卡尔积需要改成 CROSS JOIN,否则语法报错。

二、优化CUBE表文章来源地址https://www.toymoban.com/news/detail-686810.html

  1、优化结果:原来1小时左右,优化后26分钟。
		总结:shuffle时间:16分钟,数据量	35.2亿
		任务含有宽依赖(group)被分成2个stage
			
		✔采用方案 1:改用spark执行。提高并行度。
			执行参数:spark-sql --master yarn --num-executors 100 --executor-memory 5G --executor-cores 3 --driver-memory 3G
			stage 1 执行时间:11(partitions=300)
			stage 2 执行时间:15(partitions=200)
			设置分区数量,默认是200set spark.sql.shuffle.partitions=300;(理论上可以提高 stage 2 30%的速度,实际运行的时候可能会丢失executor,运行不稳定,不建议设置。)
			(原因可能是设置了虚拟核心数量。)
			
		方案 2:将case when的操作独立出一张表,去除部分重复扫描计算,减少cube阶段的计算量。
			抽取的时间增加了2分钟,节省的 shuffle 时间也是2分钟。没有意义。
			预处理时间:2-3分钟
			stage 1 执行时间:11
			stage 2 执行时间:13(节省的时间也是2-3分钟)
			
		方案 3:提高 shuffle 使用内存的占比 设置为60%
			执行参数:spark-sql --master yarn --num-executors 100 --executor-memory 5G --executor-cores 3 --driver-memory 3G --conf spark.storage.memoryFraction=0.3 --conf spark.shuffle.memoryFraction=0.5
			执行结果:效果不明显,多次执行时间也不太一致。
			
		方案 4:减少CUBE的维度数量, orgid 和 orgcode是一对一关系,可以去掉1个维度,计算完成之后再join
			执行结果:join 消耗的时间更久。
				
	2、采用的方案1:SPARK执行
		-- 执行参数 spark-sql --master yarn --num-executors 100 --executor-memory 5G --executor-cores 3 --driver-memory 3G
		-- set spark.sql.shuffle.partitions=300;
		drop table  if  exists dc_c_organization;
		create table if not exists dc_c_organization(
			YEARMONTH string,ZZDATE string,orgid int ,orgcode string,total int,
			provinceNum int,cityNum int,districtNum int, newDistrictNum int,townNum int,streetNum int,otherNum int,communityNum int,villageNum int,gridNum int);
			
		-- 如果用 hive 执行可以开启 combiner,map端先预聚合,减少reduce端的数据量和计算量,减少磁盘的IO和网络传输时间。
		-- set hive.map.aggr = true;
		-- set hive.groupby.mapaggr.checkinterval = 10000;
		
		-- ##############################	SPARK	#################################
		-- set spark.sql.shuffle.partitions=300;
		insert into dc_c_organization
		select  
		n.YEARMONTH,
		n.ZZDATE,
		n.orgid,
		n.orgcode,
		count(n.id) total,
		nvl(SUM(case when pt.displayname='省' then 1  else 0 end),0) AS provinceNum,
		nvl(SUM(case when pt.displayname='市' then 1  else 0 end),0) as cityNum,
		nvl(SUM(case when pt.displayname='县(区)' then 1  else 0 end),0) AS districtNum,
		(nvl(SUM(case when pt.displayname='县(区)'  then 1  else 0 end),0) -nvl(SUM(case when pt.displayname='县(区)' AND n.ORGTAGGING= 31 then 1  else 0 end),0)) as newDistrictNum,
		nvl(SUM(case when  ((n.ORGNAME LIKE '%乡%' OR n.ORGNAME LIKE '%镇%' OR n.ORGNAME LIKE '%乡镇%')) AND pt.displayname='乡镇(街道)' then 1  else 0 end),0) townNum,
		nvl(SUM(case when (n.ORGNAME LIKE '%街道%') AND pt.displayname='乡镇(街道)' then 1  else 0 end),0) streetNum,
		(nvl(SUM(case when pt.displayname='乡镇(街道)'then 1  else 0 end),0)-nvl(SUM(case when ((n.ORGNAME LIKE '%乡%' OR n.ORGNAME LIKE '%镇%' OR n.ORGNAME LIKE '%乡镇%') ) AND pt.displayname='乡镇(街道)' then 1  else 0 end),0)-nvl(SUM(case when (n.ORGNAME LIKE '%街道%' )  AND pt.displayname='乡镇(街道)' then 1  else 0 end),0)) otherNum,
		(nvl(SUM(case when pt.displayname='村(社区)' then 1  else 0 end),0)-nvl(SUM(case when ((n.ORGNAME LIKE '%村' OR n.ORGNAME LIKE '%村民委员会' OR n.ORGNAME LIKE '%农村工作中心站' OR n.ORGNAME LIKE '%村委会')) AND pt.displayname='村(社区)' then 1  else 0 end),0)) communityNum,
		nvl(SUM(case when ((n.ORGNAME LIKE '%村' OR n.ORGNAME LIKE '%村民委员会' OR n.ORGNAME LIKE '%农村工作中心站' OR n.ORGNAME LIKE '%村委会')) AND pt.displayname='村(社区)' then 1  else 0 end),0) villageNum,
		nvl(SUM(case when pt.displayname='片组片格'then 1  else 0 end),0) gridNum
		from dc_f_organization n
		left join dc_d_property pt on n.orglevel = pt.id
		GROUP BY n.YEARMONTH,n.ZZDATE,n.orgid,n.orgcode
		WITH CUBE;
			
	3、优化方案2:从业务逻辑上进行优化。(发现SQL逻辑中存在重复的计算)
		-- ############################	预处理:去除重复计算和减少CUBE的计算量	############################
			drop table if exists temp_dc_c_organization;
			create table temp_dc_c_organization
			as select
			n.yearmonth,
			n.zzdate,
			n.orgid,
			n.orgcode,
			n.id as id,
			case when pt.displayname='省' then 1  else 0 end as provincenum,
			case when pt.displayname='市' then 1  else 0 end as citynum,
			case when pt.displayname='县(区)' then 1  else 0 end as districtnum,
			case when pt.displayname='县(区)' and n.orgtagging= 31 then 1  else 0 end as old_districtnum,
【重复1case when ((n.orgname like '%乡%' or n.orgname like '%镇%' or n.orgname like '%乡镇%')) and pt.displayname='乡镇(街道)' then 1  else 0 end townnum,
【重复2case when (n.orgname like '%街道%') and pt.displayname='乡镇(街道)' then 1  else 0 end streetnum,
			case when pt.displayname='乡镇(街道)'then 1  else 0 end as total_streetnum_01,
【重复1case when ((n.orgname like '%乡%' or n.orgname like '%镇%' or n.orgname like '%乡镇%')) and pt.displayname='乡镇(街道)' then 1  else 0 end as total_streetnum_02,
【重复2case when (n.orgname like '%街道%') and pt.displayname='乡镇(街道)' then 1  else 0 end as total_streetnum_03,
			case when pt.displayname='村(社区)' then 1  else 0 end as communitynum_01,
【重复3case when ((n.orgname like '%村' or n.orgname like '%村民委员会' or n.orgname like '%农村工作中心站' or n.orgname like '%村委会')) and pt.displayname='村(社区)' then 1  else 0 end as communitynum_02,
【重复3case when ((n.orgname like '%村' or n.orgname like '%村民委员会' or n.orgname like '%农村工作中心站' or n.orgname like '%村委会')) and pt.displayname='村(社区)' then 1  else 0 end villagenum,
			case when pt.displayname='片组片格'then 1  else 0 end gridnum
			from
			dc_f_organization n
			left join dc_d_property pt on n.orglevel = pt.id;
			
			
		-- ############################	CUBE:节省的时间相当于预处理的时间。############################
			create table dc_c_organization_02
			as select  
			yearmonth,
			zzdate,
			orgid,
			count(id) total,
			sum(provincenum) as provincenum,
			sum(citynum) as citynum,
			sum(districtnum) as districtnum,
			sum(districtnum)-sum(old_districtnum) as newdistrictnum,
			sum(townnum) townnum,
			sum(streetnum) streetnum,
			sum(total_streetnum_01)-sum(townnum)-sum(streetnum) othernum,
			sum(communitynum_01)-sum(villagenum) communitynum,
			sum(villagenum) villagenum,
			sum(gridnum) gridnum
			from temp_dc_c_organization as n
			group by yearmonth, zzdate, orgid with cube;
			

到了这里,关于13.108.Spark 优化、Spark优化与hive的区别、SparkSQL启动参数调优、四川任务优化实践:执行效率提升50%以上的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Spark 参数调优

    目录 Spark 调优 一、代码规范 1.1 避免创建重复 RDD 1.2 尽量复用同一个 RDD 1.3 多次使用的 RDD 要持久化 1.4 使用高性能算子 1.5 好习惯 二、参数调优 资源参数 1.1 --num-executors 100 1.2 --executor-memory 5g 1.3 --executor-cores 4 1.4 --driver-memory 内存参数 spark.storage.memoryFraction、spark.shuffle.memor

    2024年04月11日
    浏览(30)
  • spark SQL 任务参数调优1

    要了解spark参数调优,首先需要清楚一部分背景资料Spark SQL的执行原理,方便理解各种参数对任务的具体影响。 一条SQL语句生成执行引擎可识别的程序,解析(Parser)、优化(Optimizer)、执行(Execution) 三大过程。其中Spark SQL 解析和优化如下图 Parser模块:未解析的逻辑计划

    2024年02月07日
    浏览(39)
  • Spark on Yarn 最佳运行参数调优-计算方式_spark on yarn 调优 nodemanager

    先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7 深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前! 因此收集整理了一份《2024年最新软件测试全套学习资料》

    2024年04月26日
    浏览(44)
  • Spark参数配置和调优,Spark-SQL、Config

    一、Hive-SQL / Spark-SQL参数配置和调优 二、shell脚本spark-submit参数配置 三、sparkSession中配置参数

    2024年02月13日
    浏览(47)
  • Hive性能调优:Hive优化技术以及Hive集群规划

    作者:禅与计算机程序设计艺术 Apache Hive是一个开源的分布式数据仓库软件,可以用来进行数据提取、转换、加载(ETL)、查询等功能。作为Hadoop生态系统的一员,Hive具有强大的分析能力、灵活的数据定义、数据处理、数据分析和可扩展性,是一个理想的企业级数据仓库解决

    2024年02月06日
    浏览(45)
  • (12)Hive调优——count distinct去重优化

       离线数仓开发过程中经常会对数据去重后聚合统计,count distinct使得map端无法预聚合,容易引发reduce端长尾,以下是count distinct去重调优的几种方式。 原sql 如下: 优化思路:group by两阶段聚合   解决方案一通 过两阶段group by(分组聚合)  对count (distinct) 进行改造调优,需要

    2024年02月22日
    浏览(39)
  • 【Hive_06】企业调优2(数据倾斜优化、HQL优化等)

    数据倾斜问题,通常是指参与计算的数据分布不均,即某个key或者某些key的数据量远超其他key,导致在shuffle阶段,大量相同key的数据被发往同一个Reduce,进而导致该Reduce所需的时间远超其他Reduce,成为整个任务的瓶颈。 比如对于一张表的province_id字段,其中99%的值都为1,则

    2024年01月16日
    浏览(42)
  • 【jvm系列-13】jvm性能调优篇---参数设置以及日志分析

    JVM系列整体栏目 内容 链接地址 【一】初识虚拟机与java虚拟机 https://blog.csdn.net/zhenghuishengq/article/details/129544460 【二】jvm的类加载子系统以及jclasslib的基本使用 https://blog.csdn.net/zhenghuishengq/article/details/129610963 【三】运行时私有区域之虚拟机栈、程序计数器、本地方法栈 https

    2024年02月06日
    浏览(89)
  • hive企业级调优策略之Join优化

    原文链接:https://blog.csdn.net/m0_52606060/article/details/135080511 本教程的计算环境为Hive on MR。计算资源的调整主要包括Yarn和MR。 Join算法概述 Hive拥有多种join算法,包括Common Join,Map Join,Bucket Map Join,Sort Merge Buckt Map Join等,下面对每种join算法做简要说明: Common Join Common Join是Hiv

    2024年01月16日
    浏览(50)
  • 【大数据技术】Hive on spark 与Spark on hive 的区别与联系

    【大数据技术】Hive on spark 与Spark on hive 的区别与联系 Hive on Spark Hive 既作为存储元数据又负责sql的解析优化,遵守HQL语法,执行引擎变成了spark,底层由spark负责RDD操作 Spark on Hive Hive只作为存储元数据,Spark负责sql的解析优化,遵守spark sql 语法,底层由spark负责RDD操作

    2024年02月15日
    浏览(65)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包