hive 动态分区-动态分区数量太多也会导致效率下降只设置非严格模式也能执行动态分区

hive 动态分区-动态分区数量太多也会导致效率下降&只设置非严格模式也能执行动态分区

结论

1. 在非严格模式下不开启动态分区的功能的参数（配置如下），同样也能进行动态分区数据写入，目测原因是不严格检查SQL中是否指定分区或者多分区。
2. 动态分区数量太多也会导致效率下降，合理设置分区数，可以提高任务执行效率。

（1）开启动态分区功能（默认true，开启）
hive.exec.dynamic.partition=false
（2）设置为非严格模式（动态分区的模式，默认strict，表示必须指定至少一个分区为静态分区，nonstrict模式表示允许所有的分区字段都可以使用动态分区。）
hive.exec.dynamic.partition.mode=nonstrict

1. 相关参数配置以及解释

（1）开启动态分区功能（默认true，开启）
hive.exec.dynamic.partition=true
（2）设置为非严格模式（动态分区的模式，默认strict，表示必须指定至少一个分区为静态分区，nonstrict模式表示允许所有的分区字段都可以使用动态分区。）
hive.exec.dynamic.partition.mode=nonstrict
（3）在所有执行MR的节点上，最大一共可以创建多少个动态分区。默认1000
hive.exec.max.dynamic.partitions=1000
（4）在每个执行MR的节点上，最大可以创建多少个动态分区。该参数需要根据实际的数据来设定。比如：源数据中包含了一年的数据，即day字段有365个值，那么该参数就需要设置成大于365，如果使用默认值100，则会报错。
hive.exec.max.dynamic.partitions.pernode=100
（5）整个MR Job中，最大可以创建多少个HDFS文件。默认100000
hive.exec.max.created.files=100000
（6）当有空分区生成时，是否抛出异常。一般不需要设置。默认false
hive.error.on.empty.partition=false

2. 生产案例经验

背景

目前所使用的集群规模3000c+20TB+3PB，计算引擎spark，代码spark sql，shell提交

数据量规模是TB级别，一般表数据量都在百亿上下

实际数据包含近7年的查询数据，数据量在去重之前有数百亿，现在需要进行性能优化，对一张DWS原每天全量计算的表，优化为增量计算，那么初次就需要考虑全量动态分区+日调度增量动态分区。

难点：

1. 数据量规模大
2. 历史数据周期长
3. 多个数据来源

方案：

1.按天进行动态分区：所有的历史数据和每天的增量直接进入日分区，初次直接进行全量计算，全部数据进入各个日分区

2.历史按年或者按月进行分区存储，每日增量进入日分区

3.历史数据直接合并为一个分区，增量进行日分区

方案分析：

方案1:经过测试200excutors*2c+4Tb耗时巨久，不管shuffle.partitions设置多少都没用。进入日志观察发现计算时间很短，但是落盘写数据时间巨长，经过分析是七年数据大概产生2500左右分区数量 * shuffle.partitions 分区数 * 每个分区产生几千个文件，导致落盘写入时间耗时太长。最终放弃方案1

方案2：未经过测试，直接选择方案3。出方案2的原因是，如果直接下游指标需要按月或者按年统计那么比较合适，如果直接下游指标计算不涉及时间年月维度，可以选方案3。

方案3：最终采用方案，将初次执行时当前日期-1的所有历史数据写入一个指定分区（建议指定的分区数据值和设计的分区数据类型保持一致，比如：时间，年月日，方便后续的比较和筛选）。增量计算每天数据写入新的分区，在增量计算时，选择筛选最近两个周期的数据（天），防止数据上报不及时的一些情况，具体可以根据具体业务调整这个筛选的周期。当前日期-1的这天的数据在全量执行后，再启动一次增量。

经过测试全量在1个小时内完成执行，增量在半个小时内完成执行。