PinterestPinterest EngineeringProblem & solution
Automated Schema Evolution in Pinterest’s Next-Generation DB Ingestion Framework
Summary
Pinterest's CDC ingestion platform relies on a multi-stage pipeline built with Kafka, Flink, Spark, and Iceberg, where upstream schema updates risk disrupting data transformations and offline storage. To prevent pipeline failures and schema drift, Pinterest introduced an automated schema evolution framework based on a staged convergence model. Upstream changes are detected via push-based DDL messages and daily pull-based validation checks. The workflow automatically restricts automated updates to additive changes and numeric precision widening, updating Iceberg table definitions and regenerating Flink and Spark code through auditable pull requests. By decoupling schema divergence, code deployment, and data convergence, the system maintains continuous ingestion availability while working toward eventual schema consistency across all storage layers.
Context
Pinterest's CDC ingestion platform spans multiple stages across Kafka, Flink, Spark, and Iceberg. Upstream database schema changes acted as cross-system contracts across ingestion, transformation, storage, and backfills. Without unified automation, manual updates risked schema drift, broken Flink jobs, blocked Spark upserts, and inconsistencies between online and offline data representations.
Approach / What changed
Pinterest built an automated schema evolution framework using a staged convergence model. Changes are detected via push-based DDL CDC messages and daily pull-based schema comparisons. The framework restricts automated updates to additive changes and numeric precision widening, updating Iceberg metadata and regenerating Flink and Spark code via an auditable pull-request workflow.
Takeaways
Automated schema evolution is restricted to additive changes and numeric precision widening to preserve backward compatibility and avoid complex historical backfills.
The framework employs a multi-stage convergence model where Iceberg schemas update first, followed by sequential rollouts of generated Spark and Flink code to maintain pipeline availability.
Upstream schema changes are detected through low-latency push-based DDL CDC messages paired with daily pull-based comparison jobs acting as a safety net.
Source and freshness
- Source
- medium.com
- Published
- Added to Yomu
- Last updated
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.