近日,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 )关注我们。
评论