流处理的前世今生（二）死在沙滩上的前浪Apache S4

摘要：Apache S4（简单可扩展流处理系统, Simple Scalable Streaming System）是一个通用的、分布式的、可扩展的、部分容错的平台，用于处理连续的无界数据流。没错这个S4比我们熟悉的AWS的S3还要多一个S，所以他也是死的很快。该系

Apache S4（简单可扩展流处理系统, Simple Scalable Streaming System）是一个通用的、分布式的、可扩展的、部分容错的平台，用于处理连续的无界数据流。没错这个S4比我们熟悉的AWS的S3还要多一个S，所以他也是死的很快。该系统最初由 Yahoo! Labs 在 2008 年开发，2010 年捐赠给 Apache 软件基金会，并于 2014 年 6 月作为 Apache 项目退役。S4 开创了流处理中的 Actor 模型方法，并影响了后续流处理平台的设计。

先上代码

我们先看看S4的编程模型。

public class QueryCounterPE {private queryCount = 0;public void processEvent(Event event) {queryCount++;}public void output {String query = (String) this.getKeyValue.get(0);persister.set(query, queryCount);}}

API 设计：

主处理器 PE：processEvent 和 output配置 Spring Framework在 PE 实例中维护状态变量灵活的输出触发（时间间隔或事件计数）

S4的概念相对比较简单，使用Java编程来实现流数据处理。我们看看他的架构设计的细节。

S4 围绕几个关键原则构建：

Actor 模型实现：基于 Actors 模型，提供封装和位置透明性基于MapReduce 的分区：基于键(Key)属性将事件路由到处理元素，具有亲和性去中心化架构：所有节点共享相同功能，无中央协调器

Actors 模型是一种并发计算的数学模型，由 Carl Hewitt 在 1973 年提出，用于处理并发计算中的复杂性。它的核心概念Actor 是计算的基本单位，具有以下特征：

封装性（Encapsulation）每个 Actor 都有自己的私有状状态不能被其他 Actor 直接访问只能通过消息传递来通信消息传递（Message Passing）Actor 之间只能通过异步消息进行通信消息是不可变的发送消息是非阻塞的行为定义（Behavior）每个 Actor 在收到消息时可以执行三种操作：发送消息给其他 Actor创建新的 Actor改变自己的行为（为下一条消息做准备）

Actor模型有不少优势：

天然分布式：适合大规模集群容错性：单个 PE 失败不影响整体可扩展性：可以无限创建新 PE简化并发：避免锁和共享状态的复杂性

但是，它同时具有相当的挑战

调试困难异步消息传递使调试复杂化难以追踪消息流消息排序不保证消息到达顺序需要应用层处理学习曲线需要转变思维模式从共享状态到消息传递

这些挑战也成为S4项目早早收场的一个主要原因

基于上图的架构，我们来看看S4的主要组件

定义: 基本计算单元，通过功能、事件类型、键属性和键值进行唯一标识。

示例: 在单词计数应用中，为每个唯一单词实例化一个 WordCountPE，处理以该单词为键的所有事件。

2. 处理节点 (PNs)

定义: PE 的逻辑主机，负责事件处理和路由。

职责:

监听传入事件通过处理元素容器 (PEC) 执行操作通过通信层分发事件基于键属性的哈希函数路由事件通过 PE 原型管理 PE 实例化

3. 通信层

功能:

集群管理和自动故障转移将物理节点映射到逻辑节点硬件故障检测和重新映射多语言 API 绑定 (Java, C++)可插拔网络协议ZooKeeper 集成用于协调

4. 配置管理

基于 ZooKeeper 的集群协调物理节点到任务的动态分配用于故障转移的备用节点池基于 Spring Framework 的应用程序装配

S4的主要概念是事件处理数据流，事件定义为元组 (K, A)，其中 K 表示键属性，A 表示附加属性。

事件通过无键 PE 进入系统哈希函数基于键值将事件路由到适当的 PNPN 实例化或路由到现有 PE 进行处理PE 发出新事件用于下游处理结果发布到外部系统

这个也是典型的map-reduce的设计思路。

S4作为最早向Hadoop的批处理计算方式挑战的开源项目，有不少的优点，例如，它是最早成功实现 Actor 模型的分布式流处理系统之一；它曾经成功部署在 Yahoo 的搜索广告平台；等等。

但是，这个项目为什么没有活下来呢？原因是多方面的。

最根本的问题是 S4 无法建立和维持一个繁荣的开发者社区。项目提案承认"随着更多工具和文档的提供，采用率将显著增加"，并且开发者"基于志愿工作"，这些都揭示了该项目的核心弱点。一些失败的关键原因有：

文档危机：S4项目严重依赖不完整的基于 wiki 的文档，为新用户创造了无法克服的学习障碍。竞争时机：S4 面临同时期来自 Apache Storm 、Apache Spark 和 Kafka 生态系统兴起的同时竞争，每个都为不同用例提供更优越的价值主张。企业支持缺口：一个开源项目要成功，背后离不开稳定的资金和开发者团队的支持，与 Storm (Twitter)、Spark (UC Berkeley/Databricks) 或 Kafka (LinkedIn) 不同，S4 在 Yahoo 初始贡献后缺乏持续的企业投资。技术复杂性：Actor 模型编程范式对主流采用来说过于复杂，要求开发者学习全新概念，而替代方案提供了相对熟悉的编程模型。

这样的处境造成了S4的一个恶性循环：小社区 → 有限文档 → 高学习门槛 → 更少用户 → 更小社区 → 减少的开发资源 → 竞争劣势 → 项目退役。

S4 表明，在开源软件中，技术创新必须与卓越的社区建设、全面的文档、明确的商业价值主张以及对开发者体验的持续投资相结合。仅凭技术卓越无法克服这些关键领域的执行不力。

从S4项目的失败，我们能够学到很多：

1. 社区建设胜过技术卓越

S4 的技术创新令人印象深刻，但无法克服糟糕的社区建设：

Storm 的成功：大量投资于文档、示例和社区参与Spark 的成功：利用学术资源建立强大的初始社区S4 的失败：依赖技术优势而不投资于社区增长

2. 明确的价值主张胜过灵活性

S4 对灵活性的强调弱化了其价值主张：

成功项目：有明确、引人注目的价值主张（Storm：保证处理，Spark：统一批处理/流处理）S4 的问题：价值主张过于抽象和研究导向，不适合商业采用

3. 生态系统胜过平台

S4 专注于成为优秀平台但未能构建生态系统：

成功项目：投资于连接器、工具和补充项目S4 的限制：保持孤立，没有丰富的生态系统开发