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

结论

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

sql 复制代码

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

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

3sql 复制代码

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

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

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

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