Yelp 开源数据管道项目最新组件——数据管道客户端库

2016 年底，Yelp开源了他们基于Python 和Apache Kafka 的数据管道客户端库。该库提供了一个发布和消费数据管道主题的接口。之前的讨论涉及Yelp 的数据管道组件以及分布式服务数据集成所面临的挑战，也就是 N+1 问题和梅特卡夫定律。

客户端库只是最新发布的一个 Yelp 数据管道组件。对于创建 Yelp 数据管道的动机和原因，据 Yelp 报道，切换到新的数据管道每年为他们节省了 1000 万美元。Yelp 工程副总裁 Jason Fennel 表示：

我们的动力产生于我们考察自己的数据仓库时。我们将所有的数据都集中在一起，供业务和战略人员以数据为驱动制定销售战略或产品战略。过去，那个过程极其费力。对于 MySQL 中的每一张表，我们的工程师都必须把它取出来存入那个数据仓库。那需要几天甚至是几周的工作……我们开始考察我们的数据仓库。把我们所有的数据都存进去需要 10 到 15 年的时间，但我们希望可以快点。即使把我们在这个管道上投入的时间和精力考虑在内，我认为，我们通过构建这个系统节省了 1000 万的工程成本。一旦我们接入了 Salesforce，那个数值就更大了。

服务通过客户端库从管道消费数据，在 Yelp，我们将这些数据输入类似 Salesforce 、 RedShift 和 Marketo 这样的目标。据报道，该库处理 Kafka 主题名称、加密和客户划分。通过一个消息代理来集中化服务通信并执行不可变的版本方案，这有助于保护下游消费者，也是更广泛的数据管道方案背后一个主要的动机。

例如，服务背后的物理变化或者从上游 MySQL 数据库加载数据的业务逻辑可以通过 Yelp 的 MySql streamer 以流的方式传输到 Kafka。 Schematizer 和数据管道客户端注册主题的模式、数据类型和格式，将消息封装到相关元数据中，并为下游消费实现版本控制。元数据封装器可以确保各种负载类型的消息和 kafka 主题的一致性，但是，负载内容本身可以用于变更数据捕获，并针对下游更新使用了 Kafka流和日志压缩。

新管道大大缩短了上游更新和数据库更新之间的端到端时间。Fennell 指出：

我们设法将一个需要用长达三周的时间获取数据的过程压缩到了几秒……我们开始加入其他类型的东西。不只是 Salesforce，还有 Redshift，我们的许多业务战略人员都在使用它。随着我们连接其他类似 MySQL 的东西，日志也进入了我们的数据管道，Kafka 构成了这一核心路由层，这意味着，我们每额外增加一个数据源受到的影响就会倍增。

查看英文原文： Yelp Open-Sources Latest in Data Pipeline Project, Data Pipeline Client Library