神刀安全网

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 )关注我们。

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » Netflix详述Keystone Data Pipeline的演进过程

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
分享按钮