Netflix 详述 Keystone Data Pipeline 的演进过程

近日，Netflix 公司介绍了他们使用其最新版 Keystone Data Pipeline 的方式，Keystone Data Pipeline 是一款针对业务与产品分析的 PB 级可伸缩的实时事件流处理系统。

目前几乎所有的 Netflix 程序主要使用三个版本的 pipeline，这三个版本的 pipeline 可以概括如下：

• 从 Chukwa 到 S3，基于 Elastic Mapreduce（EMR）后续处理的数据获取。
• 流水线（Kafka fronted）分支的相同的 pipeline。它支持 S3 到 EMR 流程, 也支持像 Druid 和 Elasticsearch 这样的通过一个新的路由服务的实时流处理工具。
• RESTful Kafka 实现控制平面管理流入新版本的路由服务，然后由 consumer Kafka，Elasticsearch，或其他 consumer 如 Mantis 或者 Spark 获取相应服务。

版本 1 的端至端数据传输用了 10 分钟。batch pipeline 使用 S3 作为持久性存储，使用 EMR 进行数据处理。并且 Chukwa 是不可复制的，这使得它对 downstream sinks 很敏感。

后来在 1.5 版本时，Chukwa 的 SocketTeeWriter 允许分支到 Kafka 的 pipeline，它突出了早期版本 pipeline 可扩展性和不影响现有功能的派生能力。

1.5 版本引入了 Kafka fronted branch，即流向 consumer，或者流向路由服务，该服务对余外的 Kafka streams 或 Elasticsearch. 进行过滤和转让活动。Netflix 的一个实时数据基础机构工程师 ----Steven Wu 指出：

我们要针对不同的 sink（S3，ES，secondary Kafka）隔离单独的路由工作。 否则，一个 sink 运行中断会影响其他 sink 的相同的路由的工作。 我们有很多 ES 和 secondary Kafka 集群。

Steven Wu 补充说，downstream sink 可能会影响 upstream publish 服务，我们在提供对其的隔离和缓冲时，会导致“每个事件类型 / 流建立一个主题”。

新分支在 Elasticsearch 中暴露了其事件实时流量的 30％，而其他 Kafka stream 用于转化，或在 Spark 中用于一般数据处理的需要。这样就能在 Python、Scala 和 R 中进行实时交互式数据分析。

这种路由服务是由多个 Docker 容器组成，Docker 容器跨 EC2 实例运行 Samza 的 job。独立的 EC2 feet 管理 S3、Elasticsearch 和 Kafka route，并且生成的容器级别性能监控数据。latencies, lags 和 sinks 生成的统计汇总也用于分析流水线的各个部分性能。

特别的，在围绕 Kafka fronte 和路由服务这一块，许多成果来自于实时分支执行。 Steven Wu 指出：

Kafka 高层次的 consumer 可能会失去分区的所有权，并且运行一段时间稳定后会停止耗费一些分区。 这就要求我们反弹处理。

当我们推出新的代码，有时高层次的 consumer 在重新平衡的过程中会停留在一个糟糕的状态。

根据 Netflix 在 2.0 版本中的总结，要从 1.5 版本吸取经验，从而创建具有“三个主要组成部分” 的 pipeline。 第一个部分是通过获取直接写到 Kafka 一个 Java 库，并且获取例如 Python 语言 post JSON 到 HTTP 代理组件进访问。

第二个部分是缓冲部件包括作为持久消息队列的 Kafka，以及新的用于管理第三部分控制平面服务，该服务是一个路由服务。其中在摘要中提到的促成因素是“管理这些 job 和集群的运营开销 [是] 增加负担”

Netflix 能够在这个领域（Topic）发挥更大的作用，就像 Kafka 在海量云服务上做到的一样，实施使用 Samza 路由服务，并且实现如何为路由服务管理和部署 Docker 容器。

查看英文原文： Netflix Details Evolution of Keystone Data Pipeline

感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。