Pinterest推出了新一代数据库数据导入框架，旨在解决其传统批处理系统的局限性，并提升数据的实时可用性。之前的基础设施依赖于多个独立维护的数据处理流程以及针对整个表格进行的批处理操作，这导致了较高的延迟、复杂的运营流程以及资源利用效率低下。对于那些需要快速、可靠地访问数据的场景来说——比如数据分析、机器学习以及产品功能的开发——这种旧架构显然已经无法满足需求。
传统系统存在几个主要问题：数据延迟常常超过24小时，从而影响了数据分析及机器学习工作的正常进行；许多表格的每日数据变化幅度其实不足5%，但批处理流程仍然会重新处理那些没有发生变化的数据记录，从而导致计算资源和存储资源的浪费；系统也不支持对数据进行行级别的删除操作，而各个数据处理流程之间的运营逻辑差异也导致了数据质量的不稳定以及维护成本的增加。
正如Pinterest的一位工程师所指出的那样：“一个基于Change Data Capture技术（包括Debezium和TiCDC）、Kafka、Flink、Spark以及Iceberg等工具构建的统一数据库数据导入框架，能够在几分钟内就检测到数据库中的变化，并且只处理那些真正发生变化的数据记录，这样一来就能大幅降低基础设施的维护成本。”
这个框架具有通用性，能够支持MySQL、TiDB以及KVStore等多种数据库类型；它的配置方式也非常简单，便于快速部署；同时，该框架还集成了监控功能，并确保数据传输的可靠性。
以下是这一新一代数据库数据导入架构的示意图（来源：Pinterest官方博客文章）：
该架构将用于捕获数据变化的表格与基础表格区分开来。用于捕获数据变化的表格被设计成只能进行追加操作的日志记录系统，它们能够以低于5分钟的延迟时间记录下每一次数据变化；而基础表格则会保存完整的历史数据副本，这些数据会每隔15分钟到1小时通过Spark的“Merge Into”操作进行更新。Iceberg框架提供的“Merge Into”操作支持两种更新策略：一种是“Copy on Write”方式，另一种是“Merge on Read”方式。“Copy on Write”会在更新数据时重新写入整个数据文件，从而导致存储和计算资源的消耗增加；而“Merge on Read”则会将变化数据写入单独的文件中，并在读取数据时再将这些变化应用到原始数据上，这种方式能够有效减少数据写入时的开销。在对比了这两种策略之后，Pinterest最终选择了“Merge on Read”方式，因为对于大多数应用场景来说，“Copy on Write”方式所带来的存储成本增加远远超过了它带来的好处。所选择的这种更新机制能够在保持基础设施维护成本处于可控制范围内的同时，实现数据的渐进式更新。
Spark作业首先会从CDC表中删除重复的数据，然后再将更新或删除操作应用到基础表中。历史数据最初是通过自举流程加载进系统的，而后续的维护任务则负责处理数据的压缩以及过期快照的清理工作。
优化措施包括：利用Iceberg的分区机制，根据主键的哈希值对基础表进行分区划分，这样Spark就可以并行执行插入操作，从而减少每次操作所需扫描的数据量。该框架还通过指导Spark按分区进行数据写入，有效解决了因任务中存在大量小文件而导致的开销问题。
实际测试结果显示：这种方案将数据访问延迟从超过24小时缩短到了15分钟以内；同时只处理那些每天会发生变化的5%的数据记录，从而避免了不必要的全表操作，进而降低了基础设施维护成本。该系统能够处理规模高达拍字节级别的数据，并支持增量式的更新与删除操作。
Pinterest基于CDC的数据导入框架能够实现实时获取数据库中的变更信息。其中，AWS S3上的Iceberg表负责处理流式数据传输任务，而Flink-Spark则用于处理批量数据处理工作。未来的改进方向将集中在自动化模式演进方面，以确保上游发生的变更能够安全地传递到下游系统，从而进一步提升大规模数据处理流程的可靠性与可维护性。