Hive 动态分区报错先别急着改 SQL：先看 strict 模式和 1000 上限

先说一个常见场景

每天凌晨要把一张订单明细宽表写入按日期和渠道分区的汇总表，SQL 看起来没什么问题：

INSERT OVERWRITE TABLE daily_order_summary PARTITION (dt, channel)
SELECT order_id, amount, dt, channel
FROM staging_order
WHERE dt = '2026-10-29';

结果作业在编译阶段就直接失败，报错是：

FAILED: SemanticException [Error 10096]: Dynamic partition strict mode requires at least one static partition column. To turn this off set hive.exec.dynamic.partition.mode=nonstrict

SQL 本身没有写错，分区列也放在了 SELECT 的最后。真正拦住它的是 Hive 动态分区的一个默认模式：没有给任何一个静态分区值，就不允许全动态写入。

一、strict 模式到底在防什么

Apache Hive 官方配置文档给出的默认值很清楚：hive.exec.dynamic.partition.mode 的默认值是 strict，在 strict 模式下必须至少指定一个静态分区；nonstrict 模式才允许所有分区列都动态生成。这个默认值的用意不是为难人，而是防一次误操作：INSERT OVERWRITE 配上全动态分区，一旦 WHERE 条件写漏，就可能把整张表的所有分区一次性覆盖掉，事后很难干净地恢复。

动手之前先查一下当前会话的实际取值，因为集群的 hive-site.xml 可能已经改过默认值，直接凭印象调参很容易调错地方：

SET hive.exec.dynamic.partition;
SET hive.exec.dynamic.partition.mode;

查完再决定改哪一项，这一步只要几秒，却能省掉很多来回试错。所以第一反应不应该是直接把模式改掉，而是先判断：这次写入本来就只针对某一天吗？如果答案是肯定的，用混合分区更稳妥——把日期写死为静态分区，只让渠道动态生成：

SET hive.exec.dynamic.partition = true;
SET hive.exec.dynamic.partition.mode = strict;

INSERT OVERWRITE TABLE daily_order_summary PARTITION (dt = '2026-10-29', channel)
SELECT order_id, amount, channel
FROM staging_order
WHERE dt = '2026-10-29';

注意两个容易写错的细节。第一，SELECT 里只放动态分区列，静态分区列 dt 不要再出现在 SELECT 里；第二，SELECT 的列顺序是先写非分区列，再按 PARTITION 子句的顺序写动态分区列，顺序一乱，渠道值就可能被写进错误的分区目录。

二、确实需要全动态时，再开 nonstrict

有些场景本来就是全动态的，比如一次回补多个日期，或者分区列本身就是从源数据里算出来的。这时再把模式改成 nonstrict，而不是在每条 SQL 里绕弯子：

SET hive.exec.dynamic.partition = true;
SET hive.exec.dynamic.partition.mode = nonstrict;

INSERT OVERWRITE TABLE daily_order_summary PARTITION (dt, channel)
SELECT order_id, amount, dt, channel
FROM staging_order
WHERE dt BETWEEN '2026-10-27' AND '2026-10-29';

nonstrict 打开后，保护就没了，所以要把原来由 strict 挡住的风险用别的手段补回来。最起码做到两点：WHERE 条件里必须有明确的分区范围，不要写无条件全表写入；执行前先用一条聚合查一下这次会生成多少个分区组合，数量和预期对不上就先停下来，而不是等作业跑完再去删分区。

SELECT dt, channel, COUNT(*) AS row_cnt
FROM staging_order
WHERE dt BETWEEN '2026-10-27' AND '2026-10-29'
GROUP BY dt, channel;

三、过了 strict，还有 1000 和单节点 100 两道上限

strict 改完，数据量一大还可能撞上第二道墙。官方文档给出的默认值是：hive.exec.max.dynamic.partitions 为 1000，即一条语句最多生成 1000 个动态分区；hive.exec.max.dynamic.partitions.pernode 为 100，即每个 mapper 或 reducer 节点最多生成 100 个。实际跑起来，往往是单节点 100 先被撞到，因为某个节点恰好分到了很多个分区值。

比如按日期加门店分区，一次写入覆盖几百家门店，总分区数没超 1000，但某个节点要写 100 多个分区，作业一样会失败。这时可以把两项上限一起调高，但不要只调其中一个：

SET hive.exec.dynamic.partition = true;
SET hive.exec.dynamic.partition.mode = nonstrict;
SET hive.exec.max.dynamic.partitions = 5000;
SET hive.exec.max.dynamic.partitions.pernode = 500;

调高之前先算一笔账：分区数乘以文件数就是这次写入要产生的文件数。分区一多，每个分区里的数据可能只有几 MB，小文件会直接传给下游查询和 NameNode。所以上限调高只是让作业能跑完，不是分区越多越好。如果分区组合本身已经上万，更该先回头看分区设计：是不是把基数很高的字段（比如门店编号、用户编号）直接当了分区列，这种字段更适合做成普通列加索引或分桶，而不是分区。

四、动手前按这个顺序排查

以后再遇到动态分区报错，按这个顺序查，基本不用反复试错：

1. 先看报错是不是 Error 10096，是就先确认能不能用静态分区兜底，不能再开 nonstrict；
2. 再看 SELECT 的列顺序，非分区列在前、动态分区列在后，且和 PARTITION 子句的顺序一致；
3. 再用聚合提前数一下分区组合数，超过 1000 先调设计，单节点容易超 100 再同步调高两项上限；
4. 最后确认 WHERE 条件有没有分区范围，nonstrict 下的全表 OVERWRITE 是最危险的一种写法。

小结

记住三个默认值就够了：动态分区模式默认是 strict，必须留一个静态分区；单条语句最多生成 1000 个动态分区；单个节点最多生成 100 个。能写静态分区就别急着开 nonstrict，非要全动态就先数分区数、再同步调上限。分区是用来裁剪数据的，不是用来给每个取值都建一个目录的，数量失控时先改设计，再改参数。