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