메달리온 구조로 증분 수집 파이프라인을 만들어보자

메달리온 구조로 증분 수집 파이프라인을 만들어보자

매번 전체를 다시 수집·재임베딩했더니 데이터가 늘수록 처리 시간이 그대로 비례해 늘어났다. “바뀐 것만 표시해두자”는 manifest 아이디어로 옮겨가고 나서야 전체 재처리에서 벗어났다.

1. 서론 (Introduction)

• 문제/상황 (Problem): 검색용 데이터를 모을 때마다 전체를 다시 수집하고 다시 임베딩했다. 데이터 양이 늘어날수록 처리 시간도 그만큼 늘어났다.
• 목적 (Purpose): 원본은 그대로 보존하면서, 바뀐 레코드만 골라 처리하는 증분 수집 구조를 만든다.
• 대상 (Target Audience): 배치 수집·색인 파이프라인에서 전체 재처리 비용이 부담스러워진 개발자.

2. 방법 및 과정 (Methods & Process)

• 배경 조사 및 데이터 (Data Collection): 정량 벤치마크는 아직 없다. 대신 구조를 3단계로 나눠 역할을 분리했다.

  레이어	역할	저장 내용
  Bronze	원본 그대로 보존	원본 레코드 + manifest.json(source/as_of/last_change)
  Silver	증분 ingest	manifest의 last_change가 added/modified/deleted인 레코드만
  Gold	검색용 색인	Silver에서 처리된 결과만 반영한 최종 색인

• 접근 방법 (Approach Methods):
  • [방법 1]: Bronze는 원본을 절대 변형하지 않고, 대신 각 레코드의 source/as_of/last_change를 manifest.json에 별도로 기록한다.
  • [방법 2]: Silver의 ingest 단계는 직전 manifest와 이번 manifest를 비교(diff)해 added/modified/deleted로 표시된 레코드만 처리한다. unchanged는 건드리지 않는다.
• 분석 및 해결 프로세스 (Analysis Flow):
  • 도구/기술: 레코드 해시(hash)/수정시각(mtime) 비교 기반 manifest. git이 소스인 경우는 해시 비교 대신 git diff --name-status <prev>..HEAD로 같은 last_change(added/modified/deleted)를 얻는다.
  • 주요 단계: Bronze 원본 적재 $\rightarrow$ manifest 기록 $\rightarrow$ 다음 라운드 manifest와 diff $\rightarrow$ added/modified/deleted만 Silver ingest $\rightarrow$ Gold 색인 갱신.
  • 결과 도출 및 검증: 3라운드 데모(신규 1건·수정 1건·삭제 1건·무변경 1건)로 diff 로직을 확인했다. 4건 중 실제 처리 대상은 added·modified 2건뿐이었고, unchanged 1건과 deleted 1건은 재수집하지 않았다. 처음 설계할 때는 Gold를 “사용자 정의 사전”으로 정의했었는데, 표준 메달리온 구조에서 Gold는 서빙용 최종 마트를 뜻한다는 걸 뒤늦게 깨닫고 Gold를 원래 의미로 되돌린 뒤 사용자 사전은 쿼리 시점에 얹는 오버레이로 다시 정의했다.

3. 결과 (Results)

• 분석 결과 요약: 아직 데이터 규모별 처리 시간을 잰 수치는 없다. 대신 diff 결과로 “처리 대상이 전체에서 변경분으로 줄어든다”는 구조 자체는 확인했다 — 전체 4건 중 2건만 처리 대상으로 남았다.

4. 인사이트 및 액션 (Insights & Action)

• 인사이트 (Insight): 증분 처리의 전제조건은 “무엇이 바뀌었는지”를 먼저 아는 것이다. manifest는 그 질문에 답하는 가장 단순한 방법이었다. 처음부터 이렇게 설계하지 못했던 건, 데이터가 적을 때는 전체 재처리 비용이 눈에 띄지 않았기 때문이다. Gold 계층 이름을 표준 의미와 다르게 잡았다가 되돌린 것도 같은 맥락이다 — 처음 잡은 설계 용어의 의미가 표준과 어긋나면, 나중에 반드시 재정의 비용을 치른다.
• 실행 방안 (Action Plan): 다음은 실제 데이터 규모로 전체 재처리 대비 증분 처리의 시간 차이를 재서, 이 구조가 얼마나 절약이 되는지 수치로 남기는 것이다.
• 한 줄 결론 (Key Takeaway): 전체를 다시 보는 대신 “무엇이 바뀌었는지”부터 기록해두면 재처리 범위를 스스로 줄일 수 있다. 샘플 코드
• 다음 스텝 (Next Step): 레코드 수가 많아지면 manifest 자체를 통째로 비교하는 diff 비용도 늘어난다. manifest를 파티션 단위로 나눠 필요한 부분만 diff하는 방식이 남은 과제다.