原文：Evolution of the Netflix Data Pipeline

译者：杰微刊兼职翻译王强

Netflix在2015年12月上线了新一代数据管道"Keystone"。这篇文章将介绍Netflix的数据管道几年来的发展演变，也是关于新一代Keystone数据管道的一系列文章的第一篇。

Netflix是一家数据驱动型的公司，通过数据分析探究出的信息做出了很多商业和产品决策。数据管道的职责是从云端层面收集、存储、处理和迁移数据。Netflix几乎所有的应用都使用了数据管道。

来看看Netflix数据管道的一些指标：

1、每天处理约5000亿事件，1.3PB数据

2、峰值状态下每秒处理800万事件、24GB数据

有数百种事件流程通过数据管道执行，例如：

1、视频查阅操作

2、UI 操作

3、错误记录

4、性能事件

5、故障申报和反馈事件

需要注意的是运营指标的监测不通过上面这条数据管道。Netflix有另一套监测系统Atlas来处理运营数据，Atlas也像Netflix的许多其他技术一样是开源系统。

过去数年来，Netflix的数据管道在不断增长的需求和技术进步推动下经历了多次重大转变。

V 1.0版本 "Chukwa"

早期的数据管道唯一的职责就是将事件集中上传至Hadoop/Hive数据库系统进行批量处理。如你所见，那时的架构是相当简单的：Chukwa收集事件，以Hadoop的S3序列格式存储下来。接下来大数据平台进一步处理这些S3文件，以Parquet格式传送给Hive。整个端到端处理延迟最多可达10分钟。对于每天或者每小时批量处理一次数据的频率来说这个延迟并不算低效。

V 1.5版本，Chukwa与实时处理分支

随着Kafka（开源消息系统）、Elasticsearch（开源搜索服务）过去几年的进步，Netflix对数据实时分析的需求不断增强。所谓"实时"，这里指的是处理延迟小于一分钟。

除了将事件上传至S3/EMR,Chukwa还能将流量输送到Kafka（这是实时分支的入口）。1.5版本的Chukwa中，大约30％的事件被分发到了实时管道。实时分支的核心是路由，其负责将Kafka传来的数据递送到不同的数据池：Elasticsearch或者第二套Kafka系统。

过去两年里Netflix的Elasticsearch的需求暴涨。现在有大约150个节点处理约3500个实例，管理1.3PB的数据。绝大部分的数据都是通过数据管道注入的。

Chukwa将流量输送到Kafka时，既可以传送原始数据流也能对数据做预过滤。有时Netflix需要将Chukwa写入Kafka的数据流做进一步过滤，所以路由这时要从一个Kafka的主题（topic）读取数据输出到另一个Kafka主题中。

数据提交到Kafka后，用户就可以使用Mantis、Spark或者定制应用来进行实时数据处理了。Netflix文化的DNA是"自由与责任"。根据实际任务选择合适的工具是用户的事情。

Netflix的团队擅长海量数据的迁移工作，因而他们将路由做成了可管理的服务。在运营路由服务的过程中团队也获得了很多经验教训：

1、Kafka的上层用户有时会在一段时间的稳定运行后失去分区的权限，不再使用一些分区。结果团队就得来解决问题。

2、系统代码更新时，有时上层用户会在rebalance的过程中卡在bad state。

3、团队将几百项路由任务分组到几十个节点处理，然而管理这些节点、分发任务的开销负担越来越大。团队需要一个更好的平台来管理这些路由任务。

V2.0 Keystone数据管道（Kafka前端）

除了路由服务的这些问题外，Netflix还有一些其他方面的需求促成了数据管道的更新换代：

1、简化架构

2、Kafka支持副本模式，提升了可靠性，但Chukwa不支持这一功能。

3、 Kafka有一个充满活力、前途光明的技术社区。

新版本由三大主要部分组成：

1、数据入口 － 应用有两种方式载入数据。

①使用Java库直接写入Kafka。

②传送到HTTP代理，后者将数据写入Kafka。

2、 数据缓存 － Kafka负责以复制模式处理永久消息队列。

这一部分也能为下游数据池提供缓冲，减少断流。

3、数据路由 － 路由服务负责将数据从前端Kafka迁移到各个数据池：S3、Elasticsearch、第二套Kafka。

Netflix已经在实战状态下运行Keystone数据管道几个月时间了。Netflix仍在不断改进Keystone，专注于QoS、扩展性、可用性、可操作性和自助服务等指标。