Pinterestは、KafkaベースのCDCインジェストプラットフォームのために、堅牢な自動スキーマ進化フレームワークを開発しました。スキーマの変更は、重要なクロスシステム契約であり、チェックされていない進化はパイプラインの故障やデータの不一致につながる可能性があります。彼らの解決策は、スキーマの進化を安全、繰り返し、スケーラブルにすることに焦点を当てており、多段階の収束プロセスとして扱います。アーキテクチャには、CDCソース、Kafka、Flinkによる変換、Icebergテーブルへのupsert用のSparkが含まれます。コアコンポーネントの1つは、安定した数値識別子を持つスキーマ定義ファイルを真実の源として使用する信頼性の高いオンボーディングモデルです。更新は、バージョニングと監査を伴うPRベースのロールアウトを介して、Kafka、Flink、Spark、Iceberg全体に自動的に伝播します。システムは、後方互換性を維持し、複雑さを最小限に抑えるために、主に加法的なスキーマ変更をサポートしています。型の変更は、数値精度の拡大などの意味の保証を伴うものに厳密に制限されています。スキーマの進化は、パイプラインの可用性を維持するために、3段階の収束モデルで管理されます。フェーズ1ではIcebergスキーマを更新し、フェーズ2では更新されたFlinkとSparkコードをデプロイし、フェーズ3ではデータの収束を確保します。この段階的なアプローチにより、スキーマの伝播とデータの正確性が切り離され、定義されたSLA内で一時的な乖離が許容されます。Pinterestは、スキーマの進化のためにSLAベースのモデルを採用しており、予測可能性と運用の安全性を優先しています。デプロイ戦略は、特にFlinkの場合、データの損失を防ぐために慎重に管理されます。デフォルト値やプライマリーキーの変更などのサポートされていない、またはあいまいなケースには、特定の手動での復旧パスがあります。CREATE TABLEのあいまいな差分は、テキストの変更から意図を推測するのではなく、データベースの実際のDDL履歴と比較して解決されます。同時に発生するスキーマの変更は、競合状態を防ぐために順番に処理され、シリアル化された収束が保証されます。列の変換は、必要な変換をスキーマに注釈付けし、それらをインジェストパイプラインに注入することで管理されます。エラーの処理と復旧メカニズム、特にSparkの故障の場合、処理が最後の成功したウォーターマークから再開されることを保証します。