前段时间考虑监控统计面临的两个问题，一是Key太多的问题。客户端输出日志的埋点程序可以通过LRUMap缓解，但是服务端就比较麻烦。对于某些以MapReduce模式实现的日志分析框架，当一个应用的key太多的时候，每个分析节点的内存中维护的Map都会变的非常巨大，并且当一个应用的日志量太大的时候，会造成每个分析节点都在分析同一个应用的日志，而阻塞其他的应用。另一个问题是流控阀值的调节。当新加入一个流控的时候，没人知道阀值应该设成多少比较合适，只能根据监控数据逐步调整。调整一次的周期比较漫长；即使阀值可以动态调整，每次调整仍然需要许多人肉操作和观察，等待。。。而最近看了下S4的论文，发现S4可以完美的解决这两个问题。首先S4根据keyedattribute的取值来分发/路由事件到不同的节点、不同的处理单元，这样可以非常方便的做应用以及更小粒度的隔离，完全可以做到局部问题不影响全局，解决了key太多的问题。其次，在S4架构之上实现的在线参数调优系统，可以通过重建线上流量，应用不同参数，比较统计结果，自动找出最优参数再反设回线上系统，这种实现可以说是参数调优最理想的做法了。

于是翻译了S4的整篇论文和大家分享。

原文地址：http://labs.yahoo.com/files/KDCloud2010S4.pdf

开源地址：http://s4.io/

下面是前两节的翻译：（英文好的同学请略过）

概要

S4是一个通用的，分布式的，可扩展的，分区容错的，可插拔的平台。开发者可以很容易的在其上开发面向×××不间断流数据处理的应用。编键的数据事件被分类路由到处理单元（ProcessingElements，PEs），处理单元消费这些事件，做如下事情之一或全部：（1）发出一个或多个可能被其他PE处理的事件。（2）发布结果。这种架构类似提供了封装和地址透明语义的Actor模式，因此允许应用在大规模并发的同时暴露简单的编程接口给应用开发者。在这篇论文里，我们将勾画S4的架构细节，描述各种各样的应用，包括实际中的部署。我们的设计主要由大规模应用在生产环境中的数据采集和机器学习所驱动。我们展示了S4设计令人惊奇的灵活性，使其运行在构筑于普通硬件之上的大规模集群中。

关键词：编程模型(programmingmodel);复杂事件处理(complexeventprocessing);并发编程(concurrentprogramming);数据处理(dataprocessing);分布式编程（distributedprogramming);map-reduce;中间件(middleware);并行编程(parallelprogramming);实时搜索(real-timesearch);软件设计(softwaredesign);流计算(streamcomputing)

一、介绍

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

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

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

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

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

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

  • 设计一个可以在普通硬件之上可扩展的高可用集群。

  • 通过在每个处理节点使用本地内存，避免磁盘I/O瓶颈达到最小化延迟

  • 使用一个去中心的，对等架构；所有节点提供相同的功能和职责。没有担负特殊责任的中心节点。这大大简化了部署和维护。

  • 使用可插拔的架构，使设计尽可能的即通用又可定制化。

  • 友好的设计理念，易于编程，具有灵活的弹性

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

  • 不完全的failover是可以接受的。在一个服务器故障时，处理自动的转移到稳定的服务器。存储在本地内存中的处理状态在交接中会丢失。（新的处理）状态会根据输入数据流重新生成。下游系统必须能够优雅降级。

  • 不会有节点从正在运行的集群中增加或移除。

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

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

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

—-

全文翻译放在这里：

内网：\10.13.40.158shareDistributedStreamComputingPlatform(S4)_cn.pdf

外网：百度文库：http://wenku.baidu.com/view/fb2d2c22482fb4daa58d4b7d.html