基于dbt与Athena创建Iceberg分区表的配置问题咨询

1. 确认分区配置是否正确 #

可以通过三种方式验证：

• Athena元数据查询：执行 DESCRIBE FORMATTED <你的表名>，在输出的Partition Information区块中，会明确列出分区列的名称（dt、country）和对应数据类型，能直接确认分区列是否配置生效。
• 信息模式查询：运行 SELECT partition_key, partition_value FROM information_schema.partitions WHERE table_name = '<你的表名>'，结果会展示所有已存在的分区键和对应值组合，检查是否包含dt、country的分区逻辑。
• S3路径验证：Iceberg表的分区数据会以dt=YYYY-MM-DD/country=XX的Hive风格路径存储在S3中，直接前往表对应的S3存储桶查看路径结构，若符合该格式则分区配置正确。

2. 在Glue/Lake Formation中配置主键 #

dbt的unique_key仅用于增量合并的逻辑判断，不会自动同步为Iceberg表的主键约束到Glue。需要通过properties参数显式配置Iceberg表级主键：
修改你的config配置如下：

{{ config(
    materialized='incremental',
    table_type = 'iceberg',
    unique_key = ['dt', 'country'],
    partition_by = ['dt', 'country'],
    s3_data_naming = 'schema_table',
    on_schema_change='append_new_columns',
    incremental_strategy='merge',
    properties={
        'primary_key': 'dt, country'
    }
) }}

运行dbt run后：

• 在Glue控制台的表详情Table properties中，能看到primary_key属性已添加；
• 可通过Athena查询 SELECT * FROM information_schema.table_constraints WHERE table_name = '<你的表名>' 验证主键约束是否生效；
• Lake Formation会同步Glue的表元数据，主键信息会在表的约束中展示。

3. 增量加载近2天数据+自动删除1个月以上旧分区 #

仅加载近2天新分区 #

在模型的SQL逻辑中添加增量过滤条件，确保每次增量运行只拉取近2天的数据：

SELECT 
    -- 你的字段列表
    dt,
    country,
    ...
FROM 
    <源表>
{% if is_incremental() %}
    -- 增量运行时仅加载近2天的数据
    WHERE dt >= current_date - interval '2' day
{% endif %}

自动删除超过1个月的旧分区 #

通过dbt的post-hook在模型运行后自动执行分区删除操作，修改config配置：

{{ config(
    ... 保留原有配置 ...
    post_hook=[
        "ALTER TABLE {{ this }} DROP PARTITION(dt < current_date - interval '30' day)"
    ]
) }}

注意：该操作要求Athena引擎版本支持Iceberg的ALTER TABLE DROP PARTITION语法，若需要更灵活的执行时机（比如固定每天凌晨执行），也可以单独编写dbt操作或通过AWS Lambda定期触发删除命令。

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