dbt快照模型首次运行正常，二次执行百万行表时无限挂起

问题背景 #

处理一张超100万行的表时遇到dbt快照执行异常：首次运行可正常生成目标快照表，但第二次执行（需对比数据生成更新记录）始终无法完成。表的复合主键为document、change、proposal（对应SQL中documento、alteracao、proposta），通过这三列用dbt_utils.generate_surrogate_key生成id_documento作为快照的unique_key，并指定了大量check_cols用于校验数据变化。已尝试创建独立唯一键列、替换SELECT *为枚举所有列名，但问题仍未解决。

快照代码片段：

{% snapshot snapshot_quiver_documentos %}

{{
    config(
      target_schema='data_lake_snapshot',
      unique_key='id_documento',
      strategy='check',
      check_cols=['grupo_hierarquico', 'cliente', 'documento', 'alteracao', 'calculo', 'proposta', 'proposta_cia', 'apolice', 'endosso', 'seguradora', 'produto', 'tipo_documento', 'tipo_endosso', 'nome_tipo_negocio', 'situacao', 'premio_liqdesc', 'adicional', 'premio', 'perc_comissao', 'perc_cocorret', 'data_proposta', 'data_inclusao', 'data_emissao', 'inicio_vigencia', 'termino_vigencia', 'data_entrada', 'data_cancel', 'tipo_emis', 'usuario', 'usuario2', 'premio_liqprop', 'premio_total' ],
      file_format='delta'
    )
}}

SELECT tabela_documentos.*,
       {{ dbt_utils.generate_surrogate_key(['documento', 'alteracao', 'proposta']) }} AS id_documento
FROM {{ source('source_silver', 'fato_documentos_producao')}} tabela_documentos

{% endsnapshot %}

排查与解决方案 #

1. 精简check_cols，降低对比成本 #

当前指定的check_cols包含30+列，百万级表场景下，check策略需要全量对比新旧表的所有指定列，计算量指数级上升，直接导致执行超时或卡住。

• 优化操作：
  • 仅保留业务上真正会发生变更的核心列（如situacao、premio_liqdesc、data_cancel等），移除不会变化的字段（比如documento、proposta这类主键相关列，它们是unique_key的组成部分，本身不会触发更新）。
  • 若数据源存在更新时间戳字段，直接改用timestamp策略，大幅降低对比成本：

    {{
        config(
          target_schema='data_lake_snapshot',
          unique_key='id_documento',
          strategy='timestamp',
          updated_at='data_ultima_atualizacao', -- 替换为数据源实际的更新时间戳字段
          file_format='delta'
        )
    }}
    

2. 验证unique_key的唯一性 #

即使基于复合主键生成id_documento，仍需确认该字段在源表中完全唯一，否则会导致快照逻辑匹配混乱：

• 执行验证查询：

  SELECT {{ dbt_utils.generate_surrogate_key(['documento', 'alteracao', 'proposta']) }} AS id_documento,
         COUNT(*)
  FROM {{ source('source_silver', 'fato_documentos_producao')}}
  GROUP BY id_documento
  HAVING COUNT(*) > 1
  

  若存在重复值，需先修复源数据的主键唯一性，或调整unique_key的生成规则。

3. Delta格式快照性能优化 #

使用Delta Lake存储时，通过以下配置提升大表快照效率：

• 添加partition_by，按高频过滤字段（如seguradora、data_proposta）分区，减少每次对比的数据量：

  {{
      config(
        target_schema='data_lake_snapshot',
        unique_key='id_documento',
        strategy='check',
        check_cols=['situacao', 'premio_liqdesc', 'data_cancel'],
        file_format='delta',
        partition_by=['seguradora']
      )
  }}
  

• 通过post-hook开启Delta优化，清理冗余数据：

  {{
      config(
        -- 其他配置...
        post_hook=[
          'OPTIMIZE {{ this }}',
          'VACUUM {{ this }} RETAIN 7 DAYS'
        ]
      )
  }}
  

4. 调整dbt运行资源配置 #

百万级表的快照执行需要足够的资源支撑：

• 确认dbt运行集群（如Databricks、Snowflake）的节点规格，临时提升资源后重试。
• 在dbt_project.yml中调高该快照的线程数：

  models:
    your_project_name:
      snapshots:
        snapshot_quiver_documentos:
          +threads: 8
  

5. 简化SQL逻辑，避免冗余数据 #

替换SELECT *为明确枚举需要的字段，减少不必要的数据加载：

SELECT 
  grupo_hierarquico, cliente, documento, alteracao, calculo, proposta,
  proposta_cia, apolice, endosso, seguradora, produto, tipo_documento,
  tipo_endosso, nome_tipo_negocio, situacao, premio_liqdesc, adicional,
  premio, perc_comissao, perc_cocorret, data_proposta, data_inclusao,
  data_emissao, inicio_vigencia, termino_vigencia, data_entrada, data_cancel,
  tipo_emis, usuario, usuario2, premio_liqprop, premio_total,
  {{ dbt_utils.generate_surrogate_key(['documento', 'alteracao', 'proposta']) }} AS id_documento
FROM {{ source('source_silver', 'fato_documentos_producao')}}

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