DBT+BigQuery的insert_overwrite增量加载：update_timestamp与partition_date选哪个？

优先选择基于partition_date的增量策略，核心原因是大数据场景下成本控制是长期运行的核心约束——该策略能精准扫描目标月分区的上游数据，避免全表扫描带来的高额成本。而上游全量刷新属于低频事件，完全可以通过针对性优化覆盖这类场景的需求，无需为低频事件牺牲日常运行的效率。

针对弊端的优化方案 #

1. 手动触发的全量刷新开关 #

在dbt模型中加入变量控制逻辑，日常运行走增量逻辑，上游全量刷新时手动触发全量覆盖。示例代码如下：

{{ config(
    materialized='incremental',
    partition_by={
        "field": "partition_date",
        "data_type": "date",
        "granularity": "month"
    },
    incremental_strategy='insert_overwrite'
) }}

WITH upstream_data AS (
    SELECT * FROM {{ ref('upstream_model') }}
    {% if not var('full_refresh_trigger', false) %}
        -- 增量逻辑：只取当前模型已存在的月分区对应的上游数据
        WHERE DATE_TRUNC(partition_date, MONTH) IN (
            SELECT DISTINCT DATE_TRUNC(partition_date, MONTH) FROM {{ this }}
        )
    {% endif %}
)

SELECT * FROM upstream_data

日常运行直接执行dbt run --select your_model，上游全量刷新后执行dbt run --select your_model --vars '{full_refresh_trigger: true}'即可触发全量刷新。

2. 自动检测上游全量刷新事件 #

如果上游系统能记录全量刷新事件（比如维护一张upstream_refresh_log表，包含refresh_time、refresh_type字段），可以在模型中自动检测这类事件，触发对应刷新逻辑：

{{ config(...) }}

WITH latest_refresh AS (
    SELECT MAX(refresh_time) AS full_refresh_time
    FROM {{ ref('upstream_refresh_log') }}
    WHERE refresh_type = 'full'
),
should_full_refresh AS (
    SELECT 
        CASE 
            WHEN full_refresh_time > COALESCE((SELECT MAX(updated_at) FROM {{ this }}), TIMESTAMP('1970-01-01')) 
            THEN true 
            ELSE false 
        END AS trigger_full
    FROM latest_refresh
),
upstream_data AS (
    SELECT * FROM {{ ref('upstream_model') }}
    {% if not (select trigger_full from should_full_refresh) %}
        WHERE DATE_TRUNC(partition_date, MONTH) IN (
            SELECT DISTINCT DATE_TRUNC(partition_date, MONTH) FROM {{ this }}
        )
    {% endif %}
)

SELECT *, CURRENT_TIMESTAMP() AS updated_at FROM upstream_data

这样只要上游发生全量刷新，模型会自动触发全量覆盖，无需手动干预。

3. 定期兜底全量刷新 #

通过调度工具（如dbt Cloud、Airflow）设置两个任务：

• 日常任务：每天/每小时执行增量构建
• 兜底任务：每周/每月固定时间执行全量构建（dbt run --select your_model --full-refresh）
  作为低频全量刷新的兜底方案，避免因遗漏手动触发导致的数据不一致。

4. 基于update_timestamp策略的成本优化（备选） #

如果业务对自动检测变更的需求极高，不愿依赖手动或定期触发，可以优化基于update_timestamp的策略：

• 记录模型上次运行时上游的最大update_timestamp，存储在dbt变量或辅助表中
• 每次运行时，先对比当前上游的最大update_timestamp与记录值：
  • 如果差值在正常范围（比如小于24小时），则只扫描update_timestamp > 记录值的上游数据
  • 如果差值异常（比如远大于24小时，说明上游全量刷新），则触发全量刷新，同时更新记录值
    这种方式能在大部分时间控制扫描范围，仅在全量刷新时触发全表扫描，平衡成本与自动检测能力。

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