近日，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