dbt

unique_key 누락과 --full-refresh

merge 증분 모델에서 unique_key를 설정하지 않으면 dbt는 증분 SELECT의 모든 행을 이미 존재하는 행인지 여부와 상관없이 그대로 INSERT한다. 그 결과 실행할 때마다 중복이 누적되며, 이는 dbt를 쓰면서 가장 흔하게 발생하는 프로덕션 버그 중 하나다. unique_key는 항상 같은 컬럼에 대한 unique 테스트와 함께 짝지어 중복을 조기에 잡아내는 것이 좋은 습관이다.

--full-refresh는 증분 테이블을 드롭하고 처음부터 다시 만든다. 모델의 스키마를 바꾸거나(컬럼 추가/제거), 증분 로직을 바꾸거나, 누적된 지연 도착 레코드로 인한 데이터 품질 문제가 의심될 때 사용한다. 리스크는 비용이다 — 5억 행짜리 팩트 테이블에서 전체 재구축은 몇 시간이 걸리고 웨어하우스 비용을 급증시킬 수 있다. 프로덕션에서는 트래픽이 적은 시간대나 주말에 전체 재구축을 스케줄링하는 것이 좋다.

insert_overwrite vs merge, on_schema_change

insert_overwrite는 행 단위로 병합하는 대신 전체 파티션을 교체한다. BigQuery에서는 바이트 스캔량 기준으로 과금하기 때문에 이 차이가 극적으로 저렴해진다 — MERGE는 대상 테이블 전체를 스캔하지만 insert_overwrite는 영향받은 파티션만 건드린다. 매일 파티션 단위로 처리하는 모델을 BigQuery에서 운영한다면 insert_overwrite를 기본값으로 삼아야 하며, 대형 테이블에서는 이 전환 하나로 웨어하우스 비용을 60~80% 절감할 수 있다.

on_schema_change는 소스에 새 컬럼이 추가됐을 때 증분 모델의 기존 테이블에는 그 컬럼이 없는 상황을 어떻게 처리할지 제어한다. ignore(기본값)는 새 컬럼을 증분 INSERT/MERGE 문에서 제외해 반영하지 않고, fail은 에러를 발생시키며, append_new_columns는 새 컬럼을 추가하고 기존 행은 NULL로 채우며, sync_all_columns는 새 컬럼 추가와 제거된 컬럼 삭제를 모두 수행한다. 대부분 팀은 append_new_columns를 쓰는데, ignore는 스키마 드리프트를 조용히 숨기는 데이터 버그로 이어지기 때문이다.

— 정정: 원문은 ignore가 새 컬럼을 '조용히 드롭한다(silently drops)'고 표현하는데, 이는 오해의 소지가 있다. 정확히는 새 컬럼이 삭제되는 것이 아니라, 증분 실행의 INSERT/MERGE 문 컬럼 목록에서 그냥 제외되어 반영되지 않는 것이다(원천 테이블 자체는 그대로 있다). --full-refresh를 실행하면 그 시점의 소스 스키마 전체를 다시 읽으므로 새 컬럼도 정상적으로 포함된다. '드롭'이 아니라 '증분 갱신에서 누락'이라고 이해하는 것이 더 정확하다.