pile·
DB / 데이터·pinterest-engPinterest Engineering·

Pinterest 차세대 DB 수집 프레임워크의 자동화된 스키마 진화

Pinterest의 CDC 기반 DB 수집 파이프라인은 MySQL에서 Kafka, Flink, Spark, Iceberg를 거치는 다층 구조다. 스키마 변경이 생기면 모든 계층을 동시에 업데이트해야 해 드리프트, 배포 실패, 데이터 불일치가 반복됐다. Pinterest 엔지니어링 팀은 이를 해결하기 위해 가산적 변경만 자동화하는 스키마 진화 프레임워크를 구축하고, PR 기반 롤아웃과 SLA 기반 일관성 모델을 도입했다.

핵심 포인트
  • nullable 컬럼 추가와 제한적 숫자 타입 확장(additive 변경)만 자동화해 하위 호환성을 유지하고 히스토리 데이터 재처리를 피한다.
  • 스키마 분기 → 코드 수렴(Flink 먼저, Spark 순차) → 데이터 수렴(백필)의 3단계 모델로 최종 일관성을 달성한다.
  • push 기반(저지연) + pull 기반(안전망) 이중 탐지로 스키마 변경을 놓치지 않는다.
  • Flink 배포 전 스테이징 검증을 의무화해 데이터 손실을 사전에 차단한다.
  • default 값 컬럼, 민감 데이터, PK 변경 등 자동화 범위 밖의 엣지 케이스는 명시적 수동 인터벤션 절차로 처리한다.
상세 정리
  • 배경: Pinterest DB 수집 플랫폼은 CDC 기반으로 MySQL → Kafka → Flink → Iceberg 경로로 실시간 수집한다. 스키마 변경 시 모든 계층의 코드·설정을 동기화해야 해 운영 부담이 컸다.
  • 가산적 변경만 지원: nullable 컬럼 추가, 제한적 숫자 타입 확장(예: INT → BIGINT)만 자동화한다. 컬럼 삭제나 타입 축소는 히스토리 재처리 없이 하위 호환성 유지를 위해 의도적으로 제외했다.
  • PR 기반 롤아웃: 모든 스키마 변경은 PR로 제출되고, 버전 관리·감사 추적(audit trail)이 자동으로 기록된다.
  • 3단계 수렴 모델 1단계(스키마 분기): Iceberg 스키마는 즉시 업데이트되고 기존 Flink·Spark 잡은 계속 실행된다.
  • 3단계 수렴 모델 2단계(코드 수렴): Flink 잡 먼저 배포하고, Spark 잡을 순차 롤아웃한다.
  • 3단계 수렴 모델 3단계(데이터 수렴): 백필 완료 후 온라인·오프라인 스키마가 일치 상태에 도달한다.
  • 이중 탐지: push 기반(변경 이벤트 즉시 트리거, 저지연)과 pull 기반(주기적 폴링, 안전망)을 병행 운용해 한쪽 실패 시 나머지가 보완한다.
  • SLA 기반 일관성: 완전 동기 방식이 아닌 설정된 SLA 기간 안에 모든 계층이 일치하면 성공으로 간주하는 eventual consistency 모델이다.
  • 스테이징 검증: 새 Flink 코드는 프로덕션 배포 전 스테이징 환경에서 반드시 검증해 데이터 손실이나 싱크 오류를 사전에 발견한다.
  • 모니터링: 파이프라인 상태, 스키마 일치 여부, 데이터 품질 신호 세 가지를 종합 추적한다.
  • 엣지 케이스(default 값 컬럼): 기본값 있는 컬럼 추가 시 기존 행에 수동 백필이 필요해 자동화 범위 밖이며 별도 부트스트랩 절차를 따른다.
  • 엣지 케이스(민감 데이터): 개인정보 등 민감 컬럼은 보안이 강화된 별도 파이프라인으로 라우팅하는 마이그레이션 절차를 따른다.
  • 엣지 케이스(PK 변경): 기본 키 변경은 자동화 불가, 수동 인터벤션 옵션이 제공된다. 모호한 스키마 diff는 Skeema 분석과 감사 추적으로 해소한다.
  • 향후 방향: 코드 배포 없이 스키마 업데이트를 즉시 적용하는 동적 Iceberg sink("제로 갭 스키마 진화")를 탐색 중이며 미지원 변경 타입은 dead-letter 큐로 라우팅한다.
왜 읽나Kafka·Flink·Spark·Iceberg 스택에서 CDC 기반 데이터 수집 파이프라인을 운영하며 스키마 변경 관리에 어려움을 겪는 데이터 엔지니어에게 실전에서 검증된 자동화 프레임워크 설계의 레퍼런스.
pinterest-eng
Pinterest Engineering 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)
·takedown 요청

이 글과 비슷한

  1. DB / 데이터·여기어때 (GC컴퍼니)여기어때 (GC컴퍼니)·

    분석가가 직접 만든 마케팅 자동화 시스템 — 오디언스 빌더 제작기

    여기어때 데이터 분석팀(UB팀)이 개발 경험 없이 AI 에이전트 바이브 코딩으로 마케팅 자동화 시스템 '오디언스 빌더'를 구축한 과정이다. SQL 없이 UI에서 타겟 조건을 설정하면 BigQuery에서 수천만 행 대상자를 추출해 Kafka·S3를 통해 마케팅 도구로 전달하는 파이프라인을 직접 만들어, 캠페인 준비 시간을 2~3일에서 10분으로 단축했다.

    요약 이어보기
    #data-pipeline#kafka#postgres+2
  2. DB / 데이터·vercel-blogVercel Blog·

    모든 Vercel 빌드를 지탱하는 데이터베이스 마이그레이션 이야기

    Vercel이 빌드 웜 풀(warm pool) 상태 데이터를 Redis에서 DynamoDB로 마이그레이션한 과정을 다룬다. 빌드 풀의 청구 매핑 데이터가 Redis 장애 시 복구 불가능하다는 구조적 위험이 이주를 결정한 핵심 이유였고, 24/7 프로덕션 트래픽 속에서 다운타임 없이 5단계 점진적 전환을 완료했다.

    요약 이어보기
    #database-migration#zero-downtime#redis+2
  3. DB / 데이터·channel-talk채널톡·

    DynamoDB 핫 파티션을 해결하는 3가지 방법 (3): 조회를 인덱스 테이블로 옮기기

    채널톡이 DynamoDB 핫 파티션을 해결하려 GSI를 별도 인덱스 테이블로 떼어낸 연재의 마지막 편으로, 조회 경로를 GSI에서 인덱스 테이블로 옮긴 과정을 다룬다. 2편에서 쓰기 파이프라인이 완성돼 WriteThrottleEvents가 월 110만 회에서 0회가 됐지만, 조회 코드가 여전히 GSI를 읽고 있어 GSI를 지울 수 없었다. GSI가 읽기에서 대신해주던 키 해석·정확 일치·삭제 필터·페이지 채우기를 사내 공통 라이브러리의 조회 규칙으로 흡수해, 호출부는 GSI든 인덱스 테이블이든 같은 코드를 쓰게 만들었다.

    요약 이어보기
    #migration#dynamodb#hot-partition+5