Yelp 重构数据流架构：采用 Apache Beam 和 Apache Flink

Yelp 最近通过使用 Apache Beam 和 Apache Flink 重构了其数据流架构，取代了原有的分散数据管道，创建了一个统一且灵活的解决方案，用于将事务数据流式传输到分析系统，如 Amazon Redshift 和内部数据湖。

原有架构及其问题

Yelp 管理其平台上的主要数据实体之一——业务实体的属性，这些属性存储在两个不同的在线系统中：旧版系统使用 MySQL 数据库，而采用微服务架构的新系统使用 Cassandra 存储。

原有解决方案通过独立的数据管道将数据从在线数据库流式传输到离线（分析）数据库：

• 使用 MySQL Replication Handler 从旧版系统推送数据。
• 使用 Cassandra Source Connector 从新系统推送数据。
• 更新通过 Apache Kafka 发布，并通过 Redshift Connector 同步到相应的 Redshift 表。

原有架构存在以下问题：

1. 弱封装性：离线数据存储中的表与在线数据库中的表完全镜像，导致数据分析团队面临数据不一致和准确性问题。
2. 数据整合复杂：分析过程需要从多个表中收集数据并规范化。
3. 维护挑战：在线和离线数据存储的表结构相同，模式更改需要在两地同时应用。

新架构的设计与实现

为了解决上述问题，Yelp 团队决定抽象化在线系统的内部实现细节，为使用分析数据存储的客户端提供一致的体验。高级数据工程师 Hakampreet Singh Pandher 解释了团队的解决方案：

• 实现统一的流，以一致且用户友好的格式提供所有相关的业务属性数据。
• 使用 Apache Beam 和 Apache Flink 作为分布式处理后端，从 MySQL 和 Cassandra 表中提取数据，将其转换为一致格式，并发布到单一的统一流中。
• 使用 Joinery Flink 作业将业务属性数据与相应的元数据合并。
• 通过 Redshift Connector 和 Data Lake Connector，将业务属性数据同步到两个主要的离线数据存储中。

新架构的优势

重构后的流式架构带来了以下好处：

1. 统一数据访问：数据分析团队可以通过单一模式访问业务属性数据，便于数据发现和消费。
2. 降低维护成本：采用实体-属性-值（EAV）模型，帮助减少新业务属性引入系统的维护开销。

通过这次重构，Yelp 不仅简化了数据流处理的复杂性，还提升了数据分析的效率和准确性。