s4数据处理框架.docx

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搜索、欺诈检测、约会等各种各样的实际应用中 但是通用的分布式流计算软件却没有类似的发展趋势虽然已经有各种各样的工程和商业引擎（⑹，［力，⑻」9］ ,［10］），但是它们的使用仍然局限于高度专业化的应用。

Amini et. alQ］给出了各种 系统的评论实时搜索、高频交易、社交网络等新应用的出现将传统数据处理系统所能做的推向了极限［11］ 对能够在高数据流量下操作，处理巨量数据的高可扩展流计算解决方案有了一个清晰的需求例如， 为了个性化搜索广告，我们需要实时处理来自几百万唯一用户每秒成千上万次的查询，典型的包括分 析用户最近活动如查询、点击等我们发现用户的会话特征可以提高广告相关性预测模型的精确度 这个性能改善用来提高显示给每个特定用户的广告的相关性［12］S4致力于一个通用的分布式流计算 平台的需求值得注意的是，某些现实世界的系统实现了这样一种流处理策略：将输入数据分隔成固定大小的 片段，再由MapReduce平台处理这种方式的缺点在于其延迟与数据片段的长度加上分隔片段、初 始化处理任务的附加开销成正比小的分段会降低延迟，增加附加开销，并且使分段间的依赖管理更 加复杂（例如一个分段可能会需要前一个分段的信息）反之，大的分段会增加延迟最优化的分段 大小取决于具体应用与其尝试将方形的木钉嵌入圆形的孔，我们决定探索一种简单的可以操作实时 数据流的编程模型我们的设计目标是：提供一种简单的编程接口来处理数据流设计一个可以在普通硬件之上可扩展的高可用集群。

通过在每个处理节点使用本地内存，避免磁盘I/O瓶颈达到最小化延迟使用一个去中心的，对等架构；所有节点提供相同的功能和职责没有担负特殊责任的中心节点这大大简化了部署和维护使用可插拔的架构，使设计尽可能的即通用又可定制化友好的设计理念，易于编程，具有灵活的弹性为了简化S4初始的设计，我们作了如下假设：不完全的failover是可以接受的在一个服务器故障时，处理自动的转移到稳定的服务器存储 在本地内存中的处理状态在交接中会丢失新的处理）状态会根据输入数据流重新生成下游系统 必须能够优雅降级不会有节点从正在运行的集群中增加或移除我们发觉这些要求对于我们大部分的应用都可以接受将来我们计划为无法接受这些限制的应用 找出解决方案允许在常用硬件之上进行分布式操作，和避免集群内使用共享内存这两个目标引导我们为S4采 用Actor模式［i］这种模式有一个简单的原语集并且在工业级规模下的各种框架使用中被证明是有效 的［13］在S4中，通过处理单元（Processing Elements （PEs））进行计算，消息在处理单元间以数据 事件的形式传送每个PE的状态对其他PE不可访问PE之间唯一的交互模式就是发出事件和消费 事件。

框架提供了路由事件到恰当的PE和创建新PE实例的能力这方面的设计提供了封装和地址 透明的特性S4的设计和IBM的流处理核心（SPC）中间件有很多相同的特性两个系统都是为了大数据量设计 的都具有使用用户定义的操作在持续数据流上采集信息的能力两者主要的区别在架构的设计上： SPA的设计源于一种订阅模式，而S4的设计是源于MapReduce和Actor模式的结合我们相信因为 其对等的结构，S4的设计达到了非常高程度的简单性集群中的所有节点都是等同的，没有中心控制 就像我们将要描述的，这得益于ZooKeeper*］, —个简单优雅的集群管理服务，可以给数据中心的 多个系统共用一、 S4最简单的介绍S4 （简单可扩展流系统的首字母简称：Simple Scalable St reaming Sys tem）是 一个受Map-Reduce模式启发的分布式的，可扩展的，分区容错的，可插拔的流 处理引擎，开发者可以很容易的在其上开发面向无界不间断流数据处理的应用 且S4能够运行在构筑于普通硬件之上的大规模集群中二、 要解决的问题s4用于解决"cost-per-click “（点击数付费）广告，通过实时计算预测用 户对广告的可能的点击行为。

三、s4适用的场景s4适用于业务允许部分容错性的实时性分布式计算 （s4没有严格的fail over机制，运行节点突然crash时，会导致当前节点中的数据丢失后续 的请求会fail over到其他的节点上，但crash时的状态已经丢失）如上图所示：在S4中所有事件流由client触发，经由Adapter到达S4集群进行分步式计算 处理，关键的数据事件被分类路由到处理单元（Processing Elements， PEs）, 处理单元消费这些事件，做如下事情之一或全部：a. 发出一个或多个可能被其他PE处理的事件b. 发布结果这种架构类似提供了封装和地址透明语义的Actor模式，因此允许应用在大规模 并发的同时暴露简单的编程接口给应用开发者一、 S4优点• S4是基于事件的分布式流计算平台，能够对高频度事件作出快速反应• S4提供了灵活的事件路由、合并等功能，并提供了标准接口易于开发自己的应用• S4的架构中，client-adapter采用tpc/ip协议保证数据的可靠性adapter-s4server 采用udp协议（忧喜参半），优点是减少通讯等待，提高性能• S4的架构中，adapter-s4server采用udp协议（忧喜参半），优点是减少通讯等待, 提咼性能。

• S4内部采用linkqueue作为事件流的中专，内部异步通讯提高了处理性能• S4内部提供checkpoint和Recovery机制待深入验证其中的实现）• S4能与zookeeper进行集成，增强集群的管理能力二、 s4缺点• S4文档不准确，官方提供的实例文档不准确需要修改才能完成实例的部署运行• s4现有的参数应用不简洁，需要在sh中设置系统变量，将来的应用中要进行优化为 系统配置文件方式• s4现有的部署分adapte集群和s4 （核心计算）集群，他们之间通讯方式为udp存 在数据丢失风险• s4没有严格的failover机制，运行节点突然crash时，会导致当前节点中的数据丢 失后续的请求会failover到其他的节点上，但crash时的状态已经丢失• s4目前persist支持方式过于简单，需要考虑网络持久化，类似于nfs，分布式文件 系统等，配合failover机制。