Airflow DAG单日运行触发HIVE_TOO_MANY_OPEN_PARTITIONS错误求助

核心问题拆解 #

1. HIVE_TOO_MANY_OPEN_PARTITIONS错误本质是Athena写入时打开的分区/桶写入器超过100个上限，通常源于临时表生成了异常多的分区。
2. 你看到的未知S3路径是dbt Athena适配器自动生成的临时表存储路径，属于dbt执行增量更新时的临时资源，并非你配置的目标路径，异常情况下可能残留未清理的文件。

排查步骤 #

1. 验证增量模型的过滤逻辑 #

检查你的dbt模型SQL，确保增量模式下严格过滤了单日event_date：

select col1, col2, event_date
from raw_source
{% if is_incremental() %}
-- 必须确保这里只取单日数据，避免临时表生成多分区
where event_date = '{{ var("run_date") }}'
{% endif %}

如果过滤条件宽松（比如event_date >= '{{ var("run_date") }}'），会导致临时表写入多日数据，生成多个分区，触发写入器上限。

2. 检查Airflow任务的并发与重试配置 #

• 确认同DAG任务没有并发执行的实例（比如Airflow的max_active_runs设置是否大于1）
• 检查任务的重试次数，过多重试会导致多个dbt进程同时操作同一个临时路径，生成大量临时分区文件。

3. 检查分区列的数据格式 #

确认event_date列的数据类型和格式统一：

• 如果是date类型，确保没有字符串格式的脏数据混入
• 如果是字符串类型，确保所有值格式一致（比如统一为yyyy-MM-dd），避免因格式差异被识别为不同分区。

4. 查看dbt运行日志 #

在Airflow的任务日志中，找到dbt执行的SQL语句，重点看：

• 临时表的创建语句，确认临时表的分区配置是否和目标表一致
• 插入临时表的语句，检查是否有多余的event_date值被写入。

解决方案 #

1. 清理残留临时资源 #

手动删除错误信息中的S3临时路径：

aws s3 rm s3://dbt/temp/tables/c2311026-c464-4a2b-a59a-f3aef7fa9fd8 --recursive

清理后再重试任务，避免旧的临时分区文件干扰。

2. 强制临时表的分区配置 #

在dbt模型配置中，显式指定临时表的分区规则，确保临时表仅生成单日分区：

{{ config(
    materialized='incremental',
    incremental_strategy='insert_overwrite',
    partitioned_by=['event_date'],
    external_location='your_target_s3_path',
    # 显式配置临时表的分区和存储路径，便于管控
    temp_table_config={
        'partitioned_by': ['event_date'],
        'external_location': 's3://your-custom-bucket/dbt/temp/model_name/'
    }
) }}

3. 限制Airflow任务并发 #

修改DAG配置，确保同模型任务不会并发执行：

default_args = {
    # ...其他配置
    'max_active_runs': 1,
    'retries': 1
}

4. 严格增量过滤逻辑 #

确保增量模式下只读取单日数据，避免临时表写入多分区数据，比如结合Airflow的execution_date变量传递准确的日期：

{% set run_date = macros.dbt_utils.date_trunc('day', var('execution_date')) %}

select * from raw_source
{% if is_incremental() %}
where event_date = '{{ run_date }}'
{% endif %}

内容的提问来源于stack exchange，提问作者pratiksha kulkarni