dbt

지연 도착 데이터와 버퍼 윈도우

단순한 MAX(timestamp) 룩백 대신, 버퍼 윈도우를 빼는 방식을 쓴다: {% if is_incremental() %} WHERE event_timestamp > (SELECT DATEADD(hour, -3, MAX(event_timestamp)) FROM {{ this }}) {% endif %}. 이 3시간 겹침(overlap)은 늦게 도착했을 수 있는 최근 행들을 다시 처리한다. 이 겹침이 중복을 만들지 않도록 merge 전략과 unique_key를 함께 써야 한다. 버퍼 크기는 원천 시스템의 지연 특성에 따라 다르다 — 스트리밍이라면 3시간, 배치 벤더 피드라면 1~2일 정도로 잡는다.

참고: 모듈 dbt-blog-draft-05에서 다뤘듯, dbt-core 1.9부터는 이런 수동 버퍼 윈도우 패턴 대신 microbatch 전략(event_time/batch_size/lookback 설정)으로 이 문제를 표준화해서 처리할 수 있다. 신규 프로젝트라면 수동 DATEADD 버퍼보다 microbatch를 우선 검토하는 것이 좋다.

스냅샷(SCD Type 2)과 {{ this }}

스냅샷은 행 수준 변경을 시간에 따라 추적해 서서히 변화하는 차원(SCD Type 2)을 포착한다. 각 버전의 행이 언제부터 언제까지 유효했는지 기록하기 위해 dbt_valid_from과 dbt_valid_to 컬럼을 추가한다. 증분 모델은 데이터의 최신 상태만 신경 쓰지만, 스냅샷은 전체 이력을 보존한다. '이 고객의 요금제가 3월 1일에는 무엇이었는가?' 같은 질문에 답해야 하는 차원 테이블에는 스냅샷을 쓴다.

{{ this }}는 현재 모델의 이미 구체화된 테이블을 데이터베이스 완전 한정 이름으로 반환한다. 룩백 쿼리를 위해 기존 테이블을 참조할 목적으로 {% if is_incremental() %} 블록 안에서 거의 독점적으로 쓰인다. 증분 모델 밖에서는 거의 필요하지 않다. 흔한 오류는 view materialization에서 {{ this }}를 쓰는 것인데, 이 경우 실패하거나 오래된 오브젝트를 참조하게 된다.

참고: 원문은 스냅샷을 항상 {% snapshot %}...{% endsnapshot %} Jinja 블록으로 감싼 .sql 파일로만 정의하는 것을 전제로 설명한다. dbt-core 1.9(2024년 말)부터는 스냅샷 설정을 YAML 파일에서도 정의할 수 있게 됐다 — 기존 .sql 기반 방식도 계속 지원되지만, 신규 프로젝트에서는 다른 리소스와 마찬가지로 YAML로 설정을 선언하는 방식이 권장되는 방향이다.