BT

您是否属于早期采用者或者创新人士?InfoQ正在努力为您设计更多新功能。了解更多

吴震:Netflix数据流水线的四个部分
录制于:

| 受访者 Steven Wu(吴震) 关注 0 他的粉丝 作者 InfoQ 关注 5 他的粉丝 发布于 2017年4月21日 | 硅谷人工智能、机器学习、互联网金融、未来移动技术架构 ,尽在QCon上海2017
10:31

个人简介 Steven Wu(吴震),Netflix 软件工程师。目前在 Real-time Data Infrastructure 组工作,负责的数据流水线是 Netflix 的数据大动脉——传输数据从生产者到消费平台(如 Hadoop/ElasticSearch/Kafka)。近期完成了数据流水线从 Chukwa 到 Keystone 的演化。之前在 Cloud Platform 组工作,构建 Netflix 的微服务架构的基石。

QCon是由InfoQ主办的全球顶级技术盛会,每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来,已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

2. 第一个问题是能否介绍一下Netflix微服务产生的数据类型是什么?为什么数据量会如此之大?

吴震:我们的数据类型有很多种,比如当你点击一个视频的时候,可以记录你点的是哪个视频、哪一季、哪一集,你的动作比如播放、停止、暂停,还有可能是security方面的,比如当用户连接之后,我们会记录你的ip,有时会有Denial of Service attack,我们也会做数据处理,检测distributed denial-of-service(DDoS) attack,还有很多比如错误日志会自动收集汇总到ElasticSearch里分析,各种各样的应用场景,我们大约有几百个话题目前。

   

3. 请介绍一下你们的数据流水线包括哪些部分。

吴震:主要包括4部分,在生产者端是数据导入,提供一个Java类库,还有一个http代理,http代理主要是为了支持非java语言的应用,像node.js或python,他们可以通过http post向我们发布消息。第二个是数据缓存,我们使用的kafka,缓存之后是路由器,路由器负责把数据从kafka拷贝到数据消费平台,比如hadoop或者ElasticSearch或其他的消费者kafka集群。最上面还有控制层,控制所有的数据导入、数据缓存和数据路由。

   

4. 您主导的数据流水线从Chukwa到Keystone的演化,这次重构的背景是什么?

吴震:首先Chukwa没有复制功能,如果丢失一个Chukwa节点,我们有可能丢失数据,而kafka提供了数据复制,这是一个重要原因。kafka早期的0.7版本并没有提供复制,那时候并不能用kafka代替。第二个是kafka有一个比较活跃的社区,所以我们用这个开源项目比较放心。第三方面是原来在Keystone之前,Chukwa到Keystone之间,我们其实还有Chukwa向实时分支拷贝数据,有了实时分支整个架构变的非常复杂,有Chukwa、kafka还有路由器,Keystone可以让我们简化架构,这可能也是最主要的原因,可以简化架构。

   

5. 数据流水线的话题的均衡分区分配是怎么做的?

吴震:如果话题的分区不能做到均匀分配,有的代理可能会收到过多的数据量,另外的代理收到比较少的数据量,所以我们比较追求均匀的分区分配,保证每个代理上的分区总数是一样的,如果我们的集群有N个代理,会为每个话题分配N×K个分区,K的大小根据话题的流量决定,一般尽量让每个分区控制在100kb到1mb之间,不会过大或者过小。

   

6. 演讲中提到Keystone的成本占在AWS上面的服务器费用的20%。

吴震:不是Keystone占20%,是整个数据处理和收集方面,包括Keystone数据流水线,包括hadoop、ElasticSearch和atlas。这四块加起来占20%。

   

7. Keystone是如何做成本优化的?

吴震:Keystone成本目前占4%,我们的服务器主要有两块,一个是kafka,还有一个是路由器,kafka作为一个stateful service,我们不能进行auto scale,因为这个非常复杂,现在也做不到。所以我们目前费用优化主要是集中在路由器方面,路由器是一个stateless service,我们目前是使用docker运行路由器,titus是我们的容器调度管理平台,整合了titus后我们可以对容器的使用进行准确的优化,根据流量动态调整容器的多少,所以我们的费用优化主要集中在路由器方面。

   

8. 您刚才提到的重构的一个背景是kafka更适合你们的需求,能不能谈一下为什么选用kafka? 

吴震:kafka有数据复制功能,其次它的社区也非常好,还有性能非常好,能够传送大量数据,我们的规模非常大所以对性能方面比较重视,它性能方面做的非常好,基于这些原因选择kafka。

   

9. 能谈一下在应用kafka的过程中遇到过哪些问题?

吴震:首先就是他有和zookeeper的dependency,zookeeper有的时候稳定性并不是特别好,所以有的时候kafka的问题是由于zookeeper的失败造成的。还有在kafka的应用过程中遇到最常见的问题就是outlier代理,有的时候代理会性能恶化,恶化以后对生产者和消费者的响应延迟就变的非常大,容易造成生产者丢弃消息。

   

10. 演讲中提到你们从devops转到了NoOps,能说一下NoOps是指什么?具体是怎么做的?

吴震:devops的工程管理模式是开发人员写代码自己测试自己的代码,自己运行自己写的应用服务,向NoOps转换是希望以后Keystone流水线能够自修复,也就是可以自动检测问题自动修复问题,这样就可以减少人工干预,或者完全不需要人工干预,这样工程师就可以从烦琐的运营事务中解脱出来,集中精力做更有意义的事,现在还没有到这个程度,是我们努力的方向。

   

11. 演讲中提到你们在应用keystone的过程中有一个上线的事故,如何预防这类事故发生?

吴震:不能预防,事故总会发生,不管做了多好的努力,但我们需要做到的是能够快速恢复,我们的努力不是说预防事情的发生,当然你可以比较小心减少事故的发生,但事故终归是发生,不管系统做的多好,但是我们需要有一个快速恢复的机制,这是我觉得更重要的方面,预防是一方面,但更重要的是即使你不知道是什么问题,也能够快速恢复系统,这是非常重要的保障。

   

12. 能介绍一下你们在快速恢复上面做的工作吗?

吴震:我们做的最重要的工作就是kafka集群的切换,如果一个kafka集群失败的时候,我们会利用云计算的伸缩性,一个kafka集群失败的时候我们会立即启动新的切换集群,把生产者和消费者的流量切换过来,这个时候故障集群就不使用了,可以停止数据丢失,当故障集群修复以后再把流量切换回来,就可以终止切换集群,这是我们做的最重要的一个创新,控制我们的故障影响时间不超过15分钟,15分钟就可以切换。

   

13. 感谢吴震老师,今天我们的采访就到这里。

吴震:谢谢,谢谢大家。

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT