DBT流水线中incremental模型放置的最佳实践是什么

核心结论先行 #

将数据源落地层改为增量加载策略，不需要强制将流水线其他层都设置为增量模式，各层的物化策略可以按需独立选择，不存在绑定要求。

增量模型放置位置的通用实践 #

• 首先澄清概念：DBT原生的source层仅为数据源的元数据定义，你提到的「source层改为增量加载」实际指的是对接原始数据源的第一层落地模型，从原来的视图改为增量物化表。
• 「增量模型尽量靠近数据源」的核心逻辑是越早完成增量数据裁剪，下游所有节点扫描的数据量都会同步减少，是整体性能收益最高的方案。所谓的存储冗余问题可以通过生命周期策略平衡，比如第一层落地的增量表仅设置7-30天的存储周期，不需要永久保留，完全可以覆盖绝大多数回溯需求，同时控制存储成本。
• 选择在staging层做增量的方案，适合原始数据源查询成本极低、或者全量数据规模很小的场景，此时全量扫描原始数据源的开销远低于多存储一层落地表的成本，性价比更高。

两种主流落地架构实操方案 #

你可以根据团队的成本、性能需求选择对应方案：

方案1：数据源落地层做增量，下游按需配置物化策略 #

该方案适合数据规模较大、性能要求高的场景

• 第一层原始数据落地模型配置为incremental模式，仅做最基础的字段名统一、数据类型校准，不做复杂加工逻辑，增量筛选用is_incremental()宏实现，示例代码：

{{ config(
    materialized = 'incremental',
    unique_key = 'id',
    partition_by = 'dt'
) }}

select 
    *
from {{ source('raw', '业务原始表') }}
{% if is_incremental() %}
-- 按分区或更新时间裁剪增量数据
where update_time >= (select max(update_time) from {{ this }})
{% endif %}

• staging层可保留为视图，也可按需设置为表/增量模型：如果staging层逻辑会被多个production层模型引用，可设置为增量进一步降低重复计算成本，否则直接用视图即可，上游增量表已经完成数据裁剪，视图不会触发全量扫描。
• production层按需选择：如果是大宽表、全量重刷成本高则设置为增量，数据量小的场景直接全量重刷即可，维护成本更低。

方案2：staging层做增量，保留source层为视图 #

该方案适合对存储成本极其敏感、原始数据全量扫描开销低的场景

• 直接在staging层的增量逻辑中对source视图做数据裁剪，避免全量扫描，示例代码：

{{ config(
    materialized = 'incremental',
    unique_key = 'id'
) }}

select 
    -- 此处实现staging层的清洗、字段统一逻辑
    cast(id as string) as id,
    user_name,
    update_time
from {{ source('raw', '业务原始表') }}
{% if is_incremental() %}
where update_time >= (select max(update_time) from {{ this }})
{% endif %}

• 下游production层同样按需选择物化策略即可，无强制增量要求。

通用注意事项 #

• 增量模型不需要全层覆盖：仅单表数据量超过100万、或全量重刷时长超过10分钟的场景适合用增量，小表全量重刷的成本远低于维护增量逻辑的成本。
• 所有增量模型必须配置唯一键和去重逻辑，避免数据重复写入。
• 建议每周/每月执行一次全量重刷修复增量逻辑可能带来的数据不一致，执行命令为dbt run --full-refresh --select 你的增量模型名。

内容的提问来源于stack exchange，提问作者pr.lwd