Pinterest 最近弄了个新的数据抓取系统，把数据库的延迟从24小时硬是压缩到了15分钟。做这个系统的人叫Leela Kumili，这篇文章是平川翻译的。 他们这个新一代的框架，就是想打破老的那种批处理的条条框框，让数据能用得更快更稳。以前的老办法用了一大堆独立的管道，又要搞全表批量处理，搞得延迟大、运维麻烦、资源也浪费。像数据分析、机器学习还有产品功能这种关键业务，急需快点拿到可靠的数据。 老系统的毛病不少：数据老是拖个一两天才能看到；很多表每天也就变个5%的数据，全表重跑一遍太浪费；还有个大问题是处理不了行级删除，各个管道各自为政导致数据乱七八糟，维护成本也高得吓人。 有个Pinterest的工程师说得挺直白：用了Change Data Capture（Debezium或者TiCDC）、Kafka、Flink、Spark和Iceberg这套东西，只处理那些真的变了的记录，几分钟就能把新数据搞出来，成本一下子就省下来了。 这套系统是个通用的框架，配置就能用，支持MySQL、TiDB还有KVStore。它整合了监控功能，保证消息至少能送一次。 具体怎么弄的？架构里把CDC表和基表给分开了。CDC表是个只写不删的日志本，记录每次改动的速度一般不超过五分钟。基表负责存完整的历史快照，每过15分钟到1小时用Spark的Merge Into操作去更新。 Iceberg有两种合并策略：一种是写时复制（COW），也就是每次改数据都要重写整个文件；另一种是读时合并（MOR），就是把变更写到单独的文件里，读的时候再把它们合并起来。 Pinterest最后选了读时合并。因为他们发现大多数情况下，写时复制那点收益根本不值那份存储成本。这样既省资源又不耽误更新。 Spark干活的时候先给CDC表去个重，然后把变更加进基表里或者删掉。刚开始的历史数据是靠导数据的管道装进来的，后面就靠维护作业去管压缩和快照过期的事。 系统还有不少优化招数：用Iceberg分桶按主键哈希把基表分好区，这样Spark干活的时候就能并行插入数据了；还教Spark怎么按区分布写文件，防止生一大堆小文件。 实测下来效果显著：数据能用的时间从24小时压到了15分钟；再也不用傻乎乎地全表扫描了；只盯着那5%天天变的数据处理；成本也省下来不少。 这套系统撑得起PB级的数据量，管着成百上千个管道，还能增量更新和删数据。Iceberg的表存放在AWS S3上，Flink和Spark一块儿干活处理流和批处理任务。 以后改进的地方就是自动化模式演变了：怎么安全地把上游的改动传给下游？还有怎么让大规模的管道更可靠、更好维护？