운영DB → 웨어하우스 배치 파이프라인

Situation

운영 DB에서 웨어하우스로 데이터를 옮겨야 했는데, 직접 연결하는 방식은 운영 DB에 부하가 걸리고 실패하면 처음부터 다시 읽어야 했습니다. 클라우드 간 전송 비용도 있었습니다.

Task

운영 DB 부하를 낮추면서, 중간에 실패해도 원천을 다시 읽지 않고 재처리할 수 있는 적재 경로를 만들어야 했습니다. 적재 이후의 변환도 관리 가능한 형태로 옮겨야 했습니다.

Action

중간에 오브젝트 스토리지를 한 단계 뒀습니다. 원천에서 한 번 읽어 파일로 떨어뜨려 두면, 이후 단계가 실패해도 원천을 다시 건드리지 않고 그 파일부터 재처리할 수 있습니다.

읽기는 리드 레플리카에서 새벽에만, 기본키 범위로 잘라 가져갑니다. OFFSET 방식은 뒤로 갈수록 느려져서 쓰지 않았습니다.

적재는 파티션 단위 덮어쓰기로 통일했습니다. 같은 날짜를 몇 번 돌려도 결과가 같아야 재처리가 안전합니다. 코드성 테이블은 전체 적재, 트랜잭션 테이블은 증분으로 나누고, 늦게 도착하는 데이터를 위해 며칠치 버퍼를 뒀습니다.

변환은 dbt로 옮겼습니다. 그전에는 SQL이 코드에 하드코딩돼 재사용도 테스트도 문서도 없었습니다.

Result

• 파티셔닝·클러스터링 적용 후 쿼리 스캔량 70~80% 감소
• 중간 단계 실패 시 원천 재조회 없이 저장된 파일부터 재처리
• 정합성 검증 3지점 — 원천 행 수, 적재 직후 원천 대비 오차 ±0.01% 이내, 변환 후 dbt 테스트
• 운영 DB 접근을 리드 레플리카·새벽 시간대로 한정
• dbt 전환으로 테이블 간 계보가 드러나고 스키마 테스트가 파이프라인에 편입