Yelp 利用数据流架构解决 Apache Cassandra 集群数据损坏问题

Yelp 通过其数据流架构成功解决了 Apache Cassandra 集群数据损坏的问题。面对数据损坏，团队探索了多种解决方案，最终决定将数据迁移至新集群以移除损坏的记录。

背景与问题

Yelp 使用 Apache Cassandra 作为其平台多个部分的数据存储。公司通常根据数据、流量和业务需求运行多个较小的 Cassandra 集群。最初，这些集群直接托管在 EC2 上，但最近大部分已迁移到 Kubernetes 上。团队发现，其中一个运行在 EC2 上的 Cassandra 集群受到数据损坏的影响，且常规数据维护工具无法解决此问题，导致集群健康状况进一步恶化。

解决方案

由于数据损坏范围广泛，删除 SSTables 和运行修复操作会导致数据丢失，因此团队决定不恢复到最后一个无损坏的备份状态。团队从制造业中的分拣系统获得灵感，设计了一个数据管道，使用其 PaaStorm 流处理器和 Cassandra Source 连接器，该连接器依赖于 Cassandra 3.8 版本及以上的变更数据捕获（CDC）功能。

数据管道架构

团队在 Kubernetes 上创建了一个新的 Cassandra 集群，并利用硬件和软件升级的优势。数据管道使用 Stream SQL 处理器定义数据清理标准，将数据分为有效和畸形流。通过 Cassandra Sink 连接器，管道将清理后的数据流导入新集群，并利用畸形数据流进一步分析数据损坏的严重性。

数据迁移验证

团队采用统计抽样技术验证整个数据迁移过程，通过比较新旧集群中的数据来检查小部分数据。在切换流量到新集群之前，团队设置了一个读取请求同时发送到两个集群并比较返回数据的机制。分析结果显示，旧集群中有 0.009% 的数据损坏。最终，流量顺利切换到新集群，损坏的集群被拆除。

总结

Yelp 通过创新的数据流架构和严谨的验证流程，成功解决了 Cassandra 集群的数据损坏问题，确保了数据完整性和系统稳定性。