10

멱등 적재 파이프라인 실행

데이터 적재와 검증

학습 목표
  • L2 문지기를 적재 전에 세운다
  • 멱등 MERGE 로 적재하고 두 번 돌려 검증한다
  • LoadBatch 로 신선도를 기록한다

파이프라인 실행

코스 3의 5정거장을 그대로 만듭니다.

raw/ → reports/ → clean/ + rejected/ → staged/ → Neo4j → LoadBatch

헌법 2조: 원본 불변 · 거부는 버리지 않는다.

1. L2 문지기 (적재 전)

def validate_l2(df):
    """통과분과 거부분(사유 포함)을 분리 반환"""

매핑 시트의 검증 열을 전부 옮깁니다. 존재성 검사도 여기 들어갑니다(L1 아님).

⚠️ 거부율이 30%를 넘으면 검증이 아니라 매핑이 틀렸을 가능성을 먼저 의심하세요.

2. 결정적 이벤트 ID

이벤트는 자연키가 없어 재적재마다 중복됩니다. 원천+신고번호의 해시로 ID를 발급합니다.

3. 멱등 MERGE

⚠️ MERGE 는 반드시 키만으로, 나머지는 SET 으로. 관계도 MERGE 로(CREATE 면 중복됩니다).

UNWIND 배치(1,000행)로 묶고 트랜잭션은 배치 단위로 겁니다.

4. LoadBatch 기록

(:LoadBatch {source, loadedAt, rowCount, rejectedCount})

적재분 이벤트와 [:LOADED_IN] 으로 연결합니다. 마지막 모듈에서 답변의 신선도 배지가 됩니다.

실습

  1. 파이프라인을 다섯 단계 함수로 분리해 구현합니다.
  2. 같은 파일을 두 번 돌리고 노드·관계 수를 비교합니다. 숫자가 같아야 멱등성 확보입니다.
  3. 다르면 어느 MERGE 가 키를 안 쓰는지 찾습니다.
  4. 실패 레코드를 사유와 함께 rejected/ 에 보관하고 사유별 건수를 집계합니다.

산출물: 적재 스크립트 + 멱등성 검증 결과 + 거부 리포트

에디터 로딩 중...
용어