加载中…
正文 字体大小:

Yahoo!流计算平台(S4--介绍篇)

(2012-12-30 10:36:05)
标签:

s4

stream

process

杂谈

分类: 科技文章

S4(简单可扩展流系统的首字母简称:Simple Scalable Streaming System)是一个受Map-Reduce模式启发的分布式流处理引擎。我们设计这个引擎是为了解决使用数据采集和机器学习算法的搜索应用环境中的现实问题。当前的商用搜索引擎,像Google、Bing和Yahoo!,典型的做法是在用户查询响应中提供结构化的Web结果的同时插入基于流量的点击付费模式的文本广告。为了在页面上的最佳位置展现最相关的广告,科学家开发了算法来动态估算在给定上下文中一个广告被点击的可能性。上下文可能包括用户偏好,地理位置,之前的查询,之前的点击等等。一个主搜索引擎可能每秒钟处理成千上万次查询,每个页面都可能会包含多个广告。为了处理用户反馈,我们开发了S4,一个低延迟,可扩展的流处理引擎。

为了便于在线实验算法,我们设想一种既适合研究又适合生产环境的架构。研究的主要需求是要具有将算法快速发布到特定领域的高度灵活性。这使得以最小的开销和支持在实际流量中测试在线算法成为可能。生产环境的主要需求是可扩展性(以最小的代价通过增加更多的机器来提高吞吐量的能力)和高可用性(在存在系统故障的情况下不需要人工介入仍然能持续提供服务的能力)。我们考虑过扩展开源的Hadoop平台来支持无界流计算但是我们很快认识到Hadoop平台是为批处理做了高度优化的。MapReduce系统典型的是通过调度批量任务操作静态数据。而在流计算中的典型范式是有一个在我们无法控制的数据比率之上的事件流流入系统中。处理系统必须赶得上事件流量,或者通过消减事件优雅的降级,这通常被称为负载分流(load  shedding)。流处理的这一模式决定了要和批处理使用非常不同的架构。试图建造一个既适合流计算又适合批处理的通用平台结果可能会是一个高度复杂的系统,并且最终可能都不是两者最理想的实现。一个作为Hadoop扩展构建的MapReduce在线架构的例子可以在[3]中找到。

MapReduce编程模型可以很容易的将多个通用批数据处理任务和操作在大规模集群上并行化,而不必担心像failover 管理之类的系统问题。MapReduce编程模型在Hadoop之类的开源软件浪潮推动下加速被采用,并且从实验室走向了Web搜索、欺诈检测、在线约会等各种各样的实际应用中。但是通用的分布式流计算软件却没有类似的发展趋势。虽然已经有各种各样的工程和商业引擎([6] ,[7] ,[8] ,[9] ,[10]),但是它们的使用仍然局限于高度专业化的应用。Amini et. al.[7]给出了各种系统的评论。

实时搜索、高频交易、社交网络等新应用的出现将传统数据处理系统所能做的推向了极限[11]。对能够在高数据流量下操作,处理巨量数据的高可扩展流计算解决方案有了一个清晰的需求。例如,为了个性化搜索广告,我们需要实时处理来自几百万唯一用户每秒成千上万次的查询,典型的包括分析用户最近活动如查询、点击等。我们发现用户的会话特征可以提高广告相关性预测模型的精确度。这个性能改善用来提高显示给每个特定用户的广告的相关性[12]。S4致力于一个通用的分布式流计算平台的需求。

值得注意的是,某些现实世界的系统实现了这样一种流处理策略:将输入数据分隔成固定大小的片段,再由MapReduce平台处理。这种方式的缺点在于其延迟与数据片段的长度加上分隔片段、初始化处理任务的附加开销成正比。小的分段会降低延迟,增加附加开销,并且使分段间的依赖管理更加复杂(例如一个分段可能会需要前一个分段的信息)。反之,大的分段会增加延迟。最优化的分段大小取决于具体应用。与其尝试将方形的木钉嵌入圆形的孔,我们决定探索一种简单的可以操作实时数据流的编程模型。我们的设计目标是:

提供一种简单的编程接口来处理数据流

 

  •  设计一个可以在普通硬件之上可扩展的高可用集群。
  • 通过在每个处理节点使用本地内存,避免磁盘I/O 瓶颈达到最小化延迟
  • 使用一个去中心的,对等架构;所有节点提供相同的功能和职责。没有担负

特殊责任的中心节点。这大大简化了部署和维护。

 

  • 使用可插拔的架构,使设计尽可能的即通用又可定制化。
  • 友好的设计理念,易于编程,具有灵活的弹性

为了简化S4初始的设计,我们作了如下假设:

  不完全的failover 是可以接受的。在一个服务器故障时,处理自动的转移到稳定的服务器。存储在本地内存中的处理状态在交接中会丢失。(新的处理)状态会根据输入数据流重新生成。下游系统必须能够优雅降级。 不会有节点从正在运行的集群中增加或移除。

我们发觉这些要求对于我们大部分的应用都可以接受。将来我们计划为无法接受这些限制的应用找出解决方案。

允许在常用硬件之上进行分布式操作,和避免集群内使用共享内存这两个目标引导我们为S4采用Actor模式[1]。这种模式有一个简单的原语集并且在工业级规模下的各种框架使用中被证明是有效的[13]。在S4 中,通过处理单元(Processing Elements (PEs))进行计算,消息在处理单元间以数据事件的形式传送。每个PE的状态对其他PE不可访问。PE之间唯一的交互模式就是发出事件和消费事件。框架提供了路由事件到恰当的PE和创建新PE实例的能力。这方面的设计提供了封装和地址透明的特性。

S4的设计和IBM 的流处理核心(SPC)中间件有很多相同的特性。两个系统都是为了大数据量设计的。都具有使用用户定义的操作在持续数据流上采集信息的能力。两者主要的区别在架构的设计上:SPA的设计源于一种订阅模式,而S4的设计是源于MapReduce和Actor模式的结合。我们相信因为其对等的结构,S4的设计达到了非常高程度的简单性。集群中的所有节点都是等同的,没有中心控制。就像我们将要描述的,这得益于ZooKeeper[14],一个简单优雅的集群管理服务,可以给数据中心的多个系统共用。

 

0

阅读 评论 收藏 转载 喜欢 打印举报
已投稿到:
  • 评论加载中,请稍候...
发评论

       

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 不良信息反馈 电话:4006900000 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有