Automated Schema Evolution in Pinterest’s Next-Generation DB Ingestion Framework
Author: Pinterest Engineering | Source: Medium (Pinterest Engineering) | Published: 2026-06-25
한 줄 요약
스키마를 ingestion·transformation·storage·backfill을 아우르는 cross-system contract로 보고, additive 변경에 한해 Kafka·Flink·Spark·Iceberg 전반에 자동 전파하는 SLA 기반 3-phase 수렴 모델.
핵심 주장/내용
- CDC 파이프라인에서 스키마는 메타데이터가 아니라 cross-system contract. 부주의한 변경이 Flink 잡 중단, Spark upsert 차단, online-offline 불일치를 유발
- schema evolution은 atomic 연산이 아님 → control plane + data plane을 가로지르는 multi-stage 수렴 과정으로 처리해 가용성 유지하며 점진적으로 정확성 복원
- additive 변경만 자동화(의도적 trade-off): 컬럼 추가 + 좁은 type widening(numeric precision). STRING→INT·narrowing·lossy는 coordinated migration/backfill로 별도 처리
- 탐지: push-based(DDL CDC 메시지 → Iceberg 메타데이터 비교) + pull-based(일일 비교 잡, safety net)
- 3-phase 수렴: ① Schema Divergence(Iceberg 먼저 업데이트, 컬럼은 nullable default null로 기존 잡 계속) ② Code Convergence(Spark 먼저 — backfill, 그 다음 Flink) ③ Data Convergence(base 테이블이 최신 schema로 수렴)
- PR 기반 롤아웃(auditability·versioning), Flink는 staging 검증 후 프로덕션(Kafka retention 만료 + 잡 실패 = 데이터 유실 위험)
- 향후 zero-gap: dynamic Iceberg sink가 CDC 레이어에서 직접 스키마 업데이트, 미지원 타입은 DLQ
주요 수치 / 사실
- 스택: Kafka, Flink, Spark, Iceberg(Part 1의 CDC ingestion 플랫폼 위)
- 컬럼은 stable numeric identifier로 추적(reorder/rename에도 unambiguous)
- ambiguous CREATE TABLE diff: Skeema로 ALTER 도출(build time) + binlog DDL 감사(deployment time)으로 해결
- 동시 변경은 직렬화(한 워크플로만 실행)
관련 위키
Source: 원문 보기