文章目录
- 第1章集群环境概述
-
- [1.1 集群配置概述](#1.1 集群配置概述)
- [1.2 集群规划概述](#1.2 集群规划概述)
- [第2章 Yarn配置](#第2章 Yarn配置)
-
- [2.1 Yarn配置说明](#2.1 Yarn配置说明)
- [2.2 Yarn配置实操](#2.2 Yarn配置实操)
- [第3章 Spark配置](#第3章 Spark配置)
-
- [3.1 Executor配置说明](#3.1 Executor配置说明)
-
- [3.1.1 Executor CPU核数配置](#3.1.1 Executor CPU核数配置)
- [3.1.2 Executor内存配置](#3.1.2 Executor内存配置)
- [3.1.3 Executor个数配置](#3.1.3 Executor个数配置)
- [3.2 Driver配置说明](#3.2 Driver配置说明)
- [3.3 Spark配置实操](#3.3 Spark配置实操)
- [第4章 Hive SQL执行计划](#第4章 Hive SQL执行计划)
- 第5章分组聚合优化
-
- [5.1 优化前执行计划](#5.1 优化前执行计划)
- [5.2 优化思路](#5.2 优化思路)
- [5.3 优化后执行计划](#5.3 优化后执行计划)
- [第6章 Join优化](#第6章 Join优化)
-
- [6.1 Hive Join算法概述](#6.1 Hive Join算法概述)
- [6.2 Map Join优化](#6.2 Map Join优化)
-
- [6.2.1 优化前执行计划](#6.2.1 优化前执行计划)
- [6.2.2 优化思路](#6.2.2 优化思路)
- [6.2.3 优化后执行计划](#6.2.3 优化后执行计划)
- [6.3 Sort Merge Bucket Map Join](#6.3 Sort Merge Bucket Map Join)
-
- [6.3.1 优化说明](#6.3.1 优化说明)
- [6.3.2 优化案例](#6.3.2 优化案例)
- 第7章数据倾斜优化
-
- [7.1 数据倾斜说明](#7.1 数据倾斜说明)
- [7.2 分组聚合导致的数据倾斜](#7.2 分组聚合导致的数据倾斜)
-
- [7.2.1 优化前执行计划](#7.2.1 优化前执行计划)
- [7.2.2 优化思路](#7.2.2 优化思路)
- [7.3 join导致的数据倾斜](#7.3 join导致的数据倾斜)
-
- [7.3.1 优化前的执行计划](#7.3.1 优化前的执行计划)
- [7.3.2 优化思路](#7.3.2 优化思路)
- 第8章任务并行度优化
-
- [8.1 优化说明](#8.1 优化说明)
- [8.2 Map阶段并行度](#8.2 Map阶段并行度)
- [8.3 Reduce阶段并行度](#8.3 Reduce阶段并行度)
- 第9章小文件合并优化
-
- [9.1 优化说明](#9.1 优化说明)
-
- [9.2 Map端输入文件合并](#9.2 Map端输入文件合并)
- [9.3 Reduce输出文件合并](#9.3 Reduce输出文件合并)
- 第10章其他优化
- 参考
第1章集群环境概述
1.1 集群配置概述
本课程所用集群由5台节点构成，其中2台为master节点，用于部署HDFS的NameNode，Yarn的ResourceManager等角色，另外3台为worker节点，用于部署HDFS的DataNode、Yarn的NodeManager等角色。
Master节点配置为16核CPU、64G内存。
Workder节点配置为32核CPU、128G内存。
1.2 集群规划概述
具体集群规划如下图所示：
| hadoop100 | hadoop101 | hadoop102 | hadoop103 | hadoop104 |
|---|---|---|---|---|
| master | master | worker | worker | worker |
| NameNode | NameNode | DataNode | DataNode | DataNode |
| ResourceManager | ResourceManager | NodeManager | NodeManager | NodeManager |
| JournalNode | JournalNode | JournalNode | ||
| Zookeeper | Zookeeper | Zookeeper | ||
| Kafka | Kafka | Kafka | ||
| Hiveserver2 | Metastore | hive-client | hive-client | hive-client |
| Spark | Spark | Spark | Spark | |
| DS-master | DS-master | DS-worker | DS-worker | DS-worder |
| Maxwell | ||||
| mysql | ||||
| flume | flume |
第2章 Yarn配置
2.1 Yarn配置说明
需要调整的Yarn参数均与CPU、内存等资源有关，核心配置参数如下。
（1）yarn.nodemanager.resource.memory-mb
该参数的含义是，一个NodeManager节点分配给Container使用的内存。该参数的配置，取决于NodeManager所在节点的总内存容量和该节点运行的其他服务的数量。
考虑上述因素，此处可将该参数设置为64G，如下：
yarn.nodemanager.resource.memory-mb
65536
（2）yarn.nodemanager.resource.cpu-vcores
该参数的含义是，一个NodeManager节点分配给Container使用的CPU核数。该参数的配置，同样取决于NodeManager所在节点的总CPU核数和该节点运行的其他服务。
考虑上述因素，此处可将该参数设置为16。
yarn.nodemanager.resource.cpu-vcores
16
（3）yarn.scheduler.maximum-allocation-mb
该参数的含义是，单个Container能够使用的最大内存。由于Spark的yarn模式下，Driver和Executor都运行在Container中，故该参数不能小于Driver和Executor的内存配置，推荐配置如下：
yarn.scheduler.maximum-allocation-mb
16384
（4）yarn.scheduler.minimum-allocation-mb
该参数的含义是，单个Container能够使用的最小内存，推荐配置如下：
yarn.scheduler.minimum-allocation-mb
512
2.2 Yarn配置实操
（1）修改$HADOOP_HOME/etc/hadoop/yarn-site.xml文件
（2）修改如下参数
yarn.nodemanager.resource.memory-mb
65536
yarn.nodemanager.resource.cpu-vcores
16
yarn.scheduler.maximum-allocation-mb
16384
yarn.scheduler.minimum-allocation-mb
512
（3）分发该配置文件
（4）重启Yarn。
第3章 Spark配置
3.1 Executor配置说明
3.1.1 Executor CPU核数配置
单个Executor的CPU核数，由spark.executor.cores参数决定，建议配置为4-6，具体配置为多少，视具体情况而定，原则是尽量充分利用资源。
此处单个节点共有16个核可供Executor使用，则spark.executor.core配置为4最合适。原因是，若配置为5，则单个节点只能启动3个Executor，会剩余1个核未使用；若配置为6，则只能启动2个Executor，会剩余4个核未使用。
3.1.2 Executor内存配置
Spark在Yarn模式下的Executor内存模型如下图所示：
Executor相关的参数有：spark.executor.memory和spark.executor.memoryOverhead。spark.executor.memory用于指定Executor进程的堆内存大小，这部分内存用于任务的计算和存储；spark.executor.memoryOverhead用于指定Executor进程的堆外内存，这部分内存用于JVM的额外开销，操作系统开销等。两者的和才算一个Executor进程所需的总内存大小。默认情况下spark.executor.memoryOverhead的值等于spark.executor.memory*0.1。
以上两个参数的推荐配置思路是，先按照单个NodeManager的核数和单个Executor的核数，计算出每个NodeManager最多能运行多少个Executor。在将NodeManager的总内存平均分配给每个Executor，最后再将单个Executor的内存按照大约10:1的比例分配到spark.executor.memory和spark.executor.memoryOverhead。
根据上述思路，可得到如下关系：
(spark.executor.memory+spark.executor.memoryOverhead)= yarn.nodemanager.resource.memory-mb * (spark.executor.cores/yarn.nodemanager.resource.cpu-vcores)
经计算，此处应做如下配置：
spark.executor.memory 14G
spark.executor.memoryOverhead 2G
3.1.3 Executor个数配置
此处的Executor个数是指分配给一个Spark应用的Executor个数，Executor个数对于Spark应用的执行速度有很大的影响，所以Executor个数的确定十分重要。
一个Spark应用的Executor个数的指定方式有两种，静态分配和动态分配。
1**）静态分配**
可通过spark.executor.instances指定一个Spark应用启动的Executor个数。这种方式需要自行估计每个Spark应用所需的资源，并为每个应用单独配置Executor个数。
2**）动态分配**
动态分配可根据一个Spark应用的工作负载，动态的调整其所占用的资源（Executor个数）。这意味着一个Spark应用程序可以在运行的过程中，需要时，申请更多的资源（启动更多的Executor），不用时，便将其释放。
在生产集群中，推荐使用动态分配。动态分配相关参数如下：
#启动动态分配
spark.dynamicAllocation.enabled true
#启用Spark shuffle服务
spark.shuffle.service.enabled true
#Executor个数初始值
spark.dynamicAllocation.initialExecutors 1
#Executor个数最小值
spark.dynamicAllocation.minExecutors 1
#Executor个数最大值
spark.dynamicAllocation.maxExecutors 12
#Executor空闲时长，若某Executor空闲时间超过此值，则会被关闭
spark.dynamicAllocation.executorIdleTimeout 60s
#积压任务等待时长，若有Task等待时间超过此值，则申请启动新的Executor
spark.dynamicAllocation.schedulerBacklogTimeout 1s
#spark shuffle老版本协议
spark.shuffle.useOldFetchProtocol true
说明：Spark shuffle服务的作用是管理Executor中的各Task的输出文件，主要是shuffle过程map端的输出文件。由于启用资源动态分配后，Spark会在一个应用未结束前，将已经完成任务，处于空闲状态的Executor关闭。Executor关闭后，其输出的文件，也就无法供其他Executor使用了。需要启用Spark shuffle服务，来管理各Executor输出的文件，这样就能关闭空闲的Executor，而不影响后续的计算任务了。
3.2 Driver配置说明
Driver主要配置内存即可，相关的参数有spark.driver.memory和spark.driver.memoryOverhead。
spark.driver.memory用于指定Driver进程的堆内存大小，spark.driver.memoryOverhead用于指定Driver进程的堆外内存大小。默认情况下，两者的关系如下：spark.driver.memoryOverhead=spark.driver.memory*0.1。两者的和才算一个Driver进程所需的总内存大小。
一般情况下，按照如下经验进行调整即可：假定yarn.nodemanager.resource.memory-mb设置为X，
若X>50G，则Driver可设置为12G，
若12G<X<50G，则Driver可设置为4G。
若1G<X<12G，则Driver可设置为1G。
此处yarn.nodemanager.resource.memory-mb为64G，则Driver的总内存可分配12G，所以上述两个参数可配置为。
spark.driver.memory 10G
spark.yarn.driver.memoryOverhead 2G
3.3 Spark配置实操
1 **）修改spark-defaults.conf文件**
（1）修改$HIVE_HOME/conf/spark-defaults.conf
spark.master yarn
spark.eventLog.enabled true
spark.eventLog.dir hdfs://myNameService1/spark-history
spark.executor.cores 4
spark.executor.memory 14g
spark.executor.memoryOverhead 2g
spark.driver.memory 10g
spark.driver.memoryOverhead 2g
spark.dynamicAllocation.enabled true
spark.shuffle.service.enabled true
spark.dynamicAllocation.executorIdleTimeout 60s
spark.dynamicAllocation.initialExecutors 1
spark.dynamicAllocation.minExecutors 1
spark.dynamicAllocation.maxExecutors 12
spark.dynamicAllocation.schedulerBacklogTimeout 1s
spark.shuffle.useOldFetchProtocol true
2 **）配置Spark shuffle服务**
Spark Shuffle服务的配置因Cluster Manager（standalone、Mesos、Yarn）的不同而不同。此处以Yarn作为Cluster Manager。
（1）拷贝$SPARK_HOME/yarn/spark-3.0.0-yarn-shuffle.jar到
$HADOOP_HOME/share/hadoop/yarn/lib
（2）分发$HADOOP_HOME/share/hadoop/yarn/lib/yarn/spark-3.0.0-yarn-shuffle.jar
（3）修改$HADOOP_HOME/etc/hadoop/yarn-site.xml文件
yarn.nodemanager.aux-services
mapreduce_shuffle,spark_shuffle
yarn.nodemanager.aux-services.spark_shuffle.class
org.apache.spark.network.yarn.YarnShuffleService
（4）分发$HADOOP_HOME/etc/hadoop/yarn-site.xml文件
（5）重启Yarn
第4章 Hive SQL执行计划
Hive SQL的执行计划，可由Explain查看。
Explain呈现的执行计划，由一系列Stage组成，这个Stage具有依赖关系，每个Stage对应一个MapReduce Job或者Spark Job，或者一个文件系统操作等。
每个Stage由一系列的Operator组成，一个Operator代表一个逻辑操作，例如TableScan Operator，Select Operator，Join Operator等。
Stage与Operator的对应关系如下图：
Explain****相关资料
1.https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Explain
2.https://cwiki.apache.org/confluence/download/attachments/44302539/hos_explain.pdf?version=1&modificationDate=1425575903211&api=v2
第5章分组聚合优化
示例SQL语句如下
hive>
select
coupon_id,
count(*)
from dwd_trade_order_detail_inc
where dt='2020-06-16'
group by coupon_id;
5.1 优化前执行计划
5.2 优化思路
优化思路为map-side聚合。所谓map-side聚合，就是在map端维护一个hash table，利用其完成分区内的、部分的聚合，然后将部分聚合的结果，发送至reduce端，完成最终的聚合。map-side聚合能有效减少shuffle的数据量，提高分组聚合运算的效率。
map-side 聚合相关的参数如下：
--启用map-side聚合
set hive.map.aggr=true;
--hash map占用map端内存的最大比例
set hive.map.aggr.hash.percentmemory=0.5;
--用于检测源表是否适合map-side聚合的条数。
set hive.groupby.mapaggr.checkinterval=100000;
--map-side聚合所用的HashTable，占用map任务堆内存的最大比例，若超出该值，则会对HashTable进行一次flush。
set hive.map.aggr.hash.force.flush.memory.threshold=0.9;
5.3 优化后执行计划
第6章 Join优化
6.1 Hive Join算法概述
Hive拥有多种join算法，包括common join，map join，sort Merge Bucket Map Join等。下面对每种join算法做简要说明：
1 **）**common join
Map端负责读取参与join的表的数据，并按照关联字段进行分区，将其发送到Reduce端，Reduce端完成最终的关联操作。
2 **）**map join
若参与join的表中，有n-1张表足够小，Map端就会缓存小表全部数据，然后扫描另外一张大表，在Map端完成关联操作。
3 **）**Sort Merge Bucket Map Join
若参与join的表均为分桶表，且关联字段为分桶字段，且分桶字段是有序的，且大表的分桶数量是小表分桶数量的整数倍。此时，就可以以分桶为单位，为每个Map分配任务了，Map端就无需再缓存小表的全表数据了，而只需缓存其所需的分桶。
6.2 Map Join优化
示例SQL语句如下
hive>
select
*
from
(
select
*
from dwd_trade_order_detail_inc
where dt='2020-06-16'
)fact
left join
(
select
*
from dim_sku_full
where dt='2020-06-16'
)dim
on fact.sku_id=dim.id;
6.2.1 优化前执行计划
6.2.2 优化思路
上述参与join的两表一大一小，可考虑map join优化。
Map Join相关参数如下：
--启用map join自动转换
set hive.auto.convert.join=true;
--common join转map join小表阈值
set hive.auto.convert.join.noconditionaltask.size
6.2.3 优化后执行计划
6.3 Sort Merge Bucket Map Join
6.3.1 优化说明
Sort Merge Bucket Map Join相关参数：
--启动Sort Merge Bucket Map Join优化
set hive.optimize.bucketmapjoin.sortedmerge=true;
--使用自动转换SMB Join
set hive.auto.convert.sortmerge.join=true;
6.3.2 优化案例
1 **）示例SQL语句**
hive (default)>
select
*
from(
select
*
from dim_user_zip
where dt='9999-12-31'
)duz
join(
select
*
from dwd_trade_order_detail_inc
where dt='2020-06-16'
)dtodi
on duz.id=dtodi.user_id;
2**）优化前**
上述SQL语句共有两张表一次join操作，故优化前的执行计划应包含一个Common Join任务，通过一个MapReduce Job实现。
3**）优化思路**
经分析，参与join的两张表，数据量如下
| 表名 | 大小 |
|---|---|
| dwd_trade_order_detail_inc | 162900000000（约160g） |
| dim_user_zip | 12320000000 （约12g） |
两张表都相对较大，可以考虑采用SMBSMB Map Join对分桶大小是没有要求的。下面演示如何使用SMB Map Join。
首先需要依据源表创建两个的有序的分桶表，dwd_trade_order_detail_inc建议分36个bucket，dim_user_zip建议分6个bucket,注意**分桶个数的倍数关系以及分桶字段和排序字段**。
--****订单明细表
hive (default)>
drop table if exists dwd_trade_order_detail_inc_bucketed;
create table dwd_trade_order_detail_inc_bucketed(
id string,
order_id string,
user_id string,
sku_id string,
province_id string,
activity_id string,
activity_rule_id string,
coupon_id string,
date_id string,
create_time string,
source_id string,
source_type_code string,
source_type_name string,
sku_num bigint,
split_original_amount decimal(16,2),
split_activity_amount decimal(16,2),
split_coupon_amount decimal(16,2),
split_total_amount decimal(16,2)
)
clustered by (user_id) sorted by(user_id) into 36 buckets
row format delimited fields terminated by '\t';
--****用户表
hive (default)>
drop table if exists dim_user_zip_bucketed;
create table dim_user_zip_bucketed(
id string,
login_name string,
nick_name string,
name string,
phone_num string,
email string,
user_level string,
birthday string,
gender string,
create_time string,
operate_time string,
start_date string,
end_date string,
dt string
)
clustered by (id) sorted by(id) into 6 buckets
row format delimited fields terminated by '\t';
然后向两个分桶表导入数据。
--****订单明细分桶表
hive (default)>
insert overwrite table dwd_trade_order_detail_inc_bucketed
select
id ,
order_id ,
user_id ,
sku_id ,
province_id ,
activity_id ,
activity_rule_id ,
coupon_id ,
date_id ,
create_time ,
source_id ,
source_type_code ,
source_type_name ,
sku_num ,
split_original_amount ,
split_activity_amount ,
split_coupon_amount,
split_total_amount
from dwd_trade_order_detail_inc
where dt='2020-06-16';
--****用户分桶表
hive (default)>
insert overwrite table dim_user_zip_bucketed
select
id,
login_name,
nick_name,
name,
phone_num,
email,
user_level,
birthday,
gender,
create_time,
operate_time,
start_date,
end_date,
dt
from dim_user_zip
where dt='9999-12-31';
然后设置以下参数：
--启动Sort Merge Bucket Map Join优化
set hive.optimize.bucketmapjoin.sortedmerge=true;
--使用自动转换SMB Join
set hive.auto.convert.sortmerge.join=true;
最后在重写SQL语句，如下：
hive (default)>
select
*
from dwd_trade_order_detail_inc_bucketed od
join dim_user_zip_bucketed duser
on od.user_id = duser.id;
优化后的执行计如图所示：
第7章数据倾斜优化
7.1 数据倾斜说明
数据倾斜问题，通常是指参与计算的数据分布不均，即某个key或者某些key的数据量远超其他key，导致在shuffle阶段，大量相同key的数据被发往一个Reduce，进而导致该Reduce所需的时间远超其他Reduce，成为整个任务的瓶颈。
Hive中的数据倾斜常出现在分组聚合和join操作的场景中，下面分别介绍在上述两种场景下的优化思路。
7.2 分组聚合导致的数据倾斜
示例SQL语句如下
hive>
select
province_id,
count(*)
from dwd_trade_order_detail_inc
where dt='2020-06-16'
group by province_id;
7.2.1 优化前执行计划
7.2.2 优化思路
由分组聚合导致的数据倾斜问题主要有以下两种优化思路：
1 **）启用map-side聚合**
相关参数如下：
--启用map-side聚合
set hive.map.aggr=true;
--hash map占用map端内存的最大比例
set hive.map.aggr.hash.percentmemory=0.5;
启用map-side聚合后的执行计划如下图所示
2 **）启用skew groupby优化**
其原理是启动两个MR任务，第一个MR按照随机数分区，将数据分散发送到Reduce，完成部分聚合，第二个MR按照分组字段分区，完成最终聚合。
相关参数如下：
--启用分组聚合数据倾斜优化
set hive.groupby.skewindata=true;
启用skew groupby优化后的执行计划如下图所示
7.3 join导致的数据倾斜
示例SQL语句如下。
hive>
select
*
from
(
select
*
from dwd_trade_order_detail_inc
where dt='2020-06-16'
)fact
join
(
select
*
from dim_province_full
where dt='2020-06-16'
)dim
on fact.province_id=dim.id;
7.3.1 优化前的执行计划
7.3.2 优化思路
由join导致的数据倾斜问题主要有以下两种优化思路：
1**）使用****map join**
相关参数如下：
--启用map join自动转换
set hive.auto.convert.join=true;
--common join转map join小表阈值
set hive.auto.convert.join.noconditionaltask.size
使用map join优化后执行计划如下图。
2 **）启用skew join优化**
其原理如下图
相关参数如下：
--启用skew join优化
set hive.optimize.skewjoin=true;
--触发skew join的阈值，若某个key的行数超过该参数值，则触发
set hive.skewjoin.key=100000;
需要注意的是，skew join只支持Inner Join。
启动skew join优化后的执行计划如下图所示：
第8章任务并行度优化
8.1 优化说明
对于一个分布式的计算任务而言，设置一个合适的并行度十分重要。在Hive中，无论其计算引擎是什么，所有的计算任务都可分为Map阶段和Reduce阶段。所以并行度的调整，也可从上述两个方面进行调整。
8.2 Map阶段并行度
Map端的并行度，也就是Map的个数。是由输入文件的切片数决定的。一般情况下，Map端的并行度无需手动调整。Map端的并行度相关参数如下：
--可将多个小文件切片，合并为一个切片，进而由一个map任务处理
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
--一个切片的最大值
set mapreduce.input.fileinputformat.split.maxsize=256000000;
8.3 Reduce阶段并行度
Reduce端的并行度，相对来说，更需要关注。默认情况下，Hive会根据Reduce端输入数据的大小，估算一个Reduce并行度。但是在某些情况下，其估计值不一定是最合适的，故需要人为调整其并行度。
Reduce并行度相关参数如下：
--指定Reduce端并行度，默认值为-1，表示用户未指定
set mapreduce.job.reduces;
--Reduce端并行度最大值
set hive.exec.reducers.max;
--单个Reduce Task计算的数据量，用于估算Reduce并行度
set hive.exec.reducers.bytes.per.reducer;
Reduce端并行度的确定逻辑为，若指定参数mapreduce.job.reduces的值为一个非负整数，则Reduce并行度为指定值。否则，Hive会自行估算Reduce并行度，估算逻辑如下：
假设Reduce端输入的数据量大小为totalInputBytes
参数hive.exec.reducers.bytes.per.reducer的值为bytesPerReducer
参数hive.exec.reducers.max的值为maxReducers
则Reduce端的并行度为：
其中，Reduce端输入的数据量大小，是从Reduce上游的Operator的Statistics（统计信息）中获取的。为保证Hive能获得准确的统计信息，需配置如下参数：
--执行DML语句时，收集表级别的统计信息
set hive.stats.autogather=true;
--执行DML语句时，收集字段级别的统计信息
set hive.stats.column.autogather=true;
--计算Reduce并行度时，从上游Operator统计信息获得输入数据量
set hive.spark.use.op.stats=true;
--计算Reduce并行度时，使用列级别的统计信息估算输入数据量
set hive.stats.fetch.column.stats=true;
第9章小文件合并优化
9.1 优化说明
小文件合并优化，分为两个方面，分别是Map端输入的小文件合并，和Reduce端输出的小文件合并。
9.2 Map端输入文件合并
合并Map端输入的小文件，是指将多个小文件划分到一个切片中，进而由一个Map Task去处理。目的是防止为单个小文件启动一个Map Task，浪费计算资源。
相关参数为：
--可将多个小文件切片，合并为一个切片，进而由一个map任务处理
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
9.3 Reduce输出文件合并
合并Reduce端输出的小文件，是指将多个小文件合并成大文件。目的是减少HDFS小文件数量。
相关参数为：
--开启合并Hive on Spark任务输出的小文件
set hive.merge.sparkfiles=true;
第10章其他优化
参考资料：
1.https://docs.cloudera.com/documentation/enterprise/6/6.3/topics/admin_hos_tuning.html#hos_tuning
2.https://cwiki.apache.org/confluence/display/Hive/Hive+on+Spark%3A+Getting+Started