大数据系统——Storm @Twitter论文分享

1.背景介绍

这篇论文的题目很奇特，一度认为这是篇假论文。

Storm是针对流计算的，为早期的流处理系统，其它类似的比较知名的流处理系统还有：S4、MillWheel、Samza和Spark Streaming等。Storm最初由BackType的Nathan Marz建立起来，然后BackType于2011年被Twitter收购，进而被Twitter全方面提升：支持更多的节点和降低Storm对Zookeeper的依赖性。2012年Twitter开源了Storm。

Storm是一种实时、容错和分布式流数据处理系统。Storm被用于在Twitter上进行大规模，实时的各种关键计算。文章描述了Storm的体系结构及其分布式扩展和容错的方法。许多现代数据处理环境需要在实时的流数据上进行复杂的计算。在Twitter中尤其如此，每次与用户的交互都需要做出许多复杂的决策，通常是基于刚刚创建的数据。Storm是Twitter的实时分布式流数据处理引擎，用来支持实时流数据管理工作，而这些对于Twitter提供服务都是至关重要的。
Storm被设计为：

1. 延展性（Scalable）：操作团队需要轻松地从Storm集群添加或删除节点，而不会中断通过Storm拓扑的现有数据流。
2. 容错（Resilient）：容错对于Storm至关重要，因为它通常部署在大型集群上，而硬件组件可能会出现故障。Storm集群必须持续处理现有拓扑，同时将性能影响降至最低。
3. 可扩展（Extensible）：Storm拓扑可能会调用任意外部函数（例如，使用MySQL服务来刻画社交图），因此需要一个可扩展的框架。
4. 高效（Efficient）：由于Storm用于实时应用程序，所以它必须具有良好的性能。Storm使用了许多技术，包括将所有存储和计算数据保存在内存中。
5. 易于管理（Easy to Administer）：由于Storm位于Twitter上用户交互的核心，终端用户会立即注意到Storm相关的（失败或性能）问题。运营团队需要早期预警工具，并且必须能够在出现问题时快速指出问题的根源。因此，易于使用的管理工具不是锦上添花，而是需求的关键部分。

目前使用的流处理系统仍在不断发展（包括Storm），并将继续从流处理的丰富研究中吸取经验。例如，许多这些系统不支持声明性查询语言。流处理也是研究和高级开发的活跃且快速发展的领域。

2.数据模型和执行架构

Storm的基础数据处理框架包含：通过一定拓扑结构的元组流（Streams of tuples flowing through topologies）。一个拓扑结构是一个有向图：图的顶点表示计算，图的边表示图两端顶点数据的流向。顶点进一步分为两个不相交的组：喷口（spouts）和螺栓（bolts）。典型的spouts从队列中提取数据，例如Kafka或Kestrel队列。另一方面，bolts处理传入的元组并将它们传递给下游的下一组bolts。Storm拓扑可以具有循环。从数据库系统的角度来看，可以将拓扑视为运算符的有向图。

图中展示了一个简单的拓扑：用来表示计算Tweets流数据中word出现的次数，每五分钟产生一个计数结果。拓扑有一个Spout(TweetSpout)和两个bolts（ParseTweetBolt和WordCountBolt）。TweetSpout从Twitter的Firehose API中获取流数据，然后注入此拓扑中。ParseTweetBolt将数据分离，然后生成二元组（word，count）。然后WordCountBolt收到二元组，然后汇聚每一个词，然后每五分钟产生一个计数结果。

3.Storm概览

Storm在分布式集群上运行，在Twitter上经常为Mesos。客户端将拓扑提交给master节点，称为Nimbus。Nimbus负责分发和协调拓扑的执行。实际工作在worker节点上完成。每个worker节点运行一个或多个worker processes。在任何时间点，单个机器可能具有多个工作进程，但每个工作进程都映射到单个拓扑。同一台计算机上的多个工作进程可能正在执行相同拓扑的不同部分。

每个worker process都运行一个JVM，运行一个或多个executors。executors由一个或多个task组成。bolts或spouts的实际工作在task中完成。因此，task提供内部bolts/内部spouts并行性，并且executors提供拓扑内部并行性。worker processes充当主机上的容器以运行Storm拓扑。与每个spout或bolt相关联的是一组在集群中的计算机上的一组executors中运行的task。数据从生产者spout / bolt转移到消费者bolts（生产者和消费者都可能有多个任务）。这种shuffling就像并行数据库中的交换运算符。
每个worker节点都运行一个与Nimbus通信的Supervisor。集群状态在Zookeeper中维护，Nimbus负责调度worker节点上的拓扑并监视流经拓扑的元组的进度。

1. Nimbus：Nimbus扮演的角色与Hadoop中的“JobTracker”类似，是用户和Storm系统之间的接触点。Nimbus是Apache Thrift服务，Storm拓扑定义是Thrift对象。要将作业提交到Storm集群（即Nimbus），用户将拓扑描述为Thrift对象并将该对象发送到Nimbus。通过此设计，可以使用任何编程语言来创建Storm拓扑。在Twitter上生成Storm拓扑的方法是使用Summingbird。Summingbird是一种通用流处理抽象，它提供了一个单独的逻辑规划器，可以映射到各种流处理和批处理系统。Summingbird的一个有趣的方面是它还可以生成在Hadoop上运行的MapReduce作业。Twitter的一个常见用例是使用Storm拓扑实时计算近似答案，这些答案随后会与MapReduce执行的准确结果进行协调。Supervisors通过定时的与Nimbus通信来证明自身在良好运行，同时说明自身还有多少运算资源。
2. Zookeeper：Nimbus和supervisor之间的所有协调都是使用Zookeeper完成的。此外，Nimbus和Supervisor守护进程是快速失败和无状态的，并且它们的所有状态都保存在Zookeeper或本地磁盘上。这种设计是Storm容错性的关键。如果Nimbus服务失败，那么worker仍然会继续前进；如果worker失败，则重新启动。
3. Supervisor：supervisor在每个Storm节点上运行。它接收来自Nimbus的任务，并根据任务产生worker。它还监测worker的状况，并在必要时重新生成。Supervisor的高级架构如图所示。如图所示，Supervisor产生三个线程。 主线程读取Storm配置，初始化Supervisor的全局映射，在文件系统中创建持久本地状态，并安排定期重复计时事件。
   
   有三种类型的事件：heartbeat、synchronize supervisor和synchronize process分别对应存放在图中的三个线程之中。
4. Worker和Executor：每个worker process在JVM中运行多个executor。这些executor是worker process中的线程。每个executor都可以运行多个task。task是spout或bolt的实例。task严格绑定到executor，因为该分配当前是静态的。
   
   图中为worker中的数据流向。

4.Storm在Twitter中的使用

Storm运行在数百台服务器上，数百个拓扑运行在集群上。每天有数T的数据在集群中运行，产生几十亿个输出元组。Twitter有很多团队在使用Storm来进行用户服务、搜索和内容发现。拓扑可以用来做过滤和word count这种简单的应用，也可以在流数据上运行简单的机器学习算法。
Storm可视化：在实践中使用Storm的一个关键部分是Storm可视化操作。使用内部开发的丰富可视化，连续显示来自Storm的日志，其中一些如图所示。

为了收集日志，每个拓扑都使用一个bolt度量标准进行扩充。在每个spout或bolt处收集的所有指标都会发送到此bolt。此bolt又将指标写入Scribe，Scribe将数据路由到持久键值存储。对于每个拓扑，使用此数据创建仪表板，以可视化此拓扑的行为方式。丰富的可视化对于帮助识别和解决导致警报被触发的问题至关重要。
度量标准可以大致分为系统度量标准和拓扑度量标准。系统指标显示平均CPU利用率，网络利用率，每分钟垃圾收集计数，每分钟垃圾收集所花费的时间以及堆的内存使用情况。报告每个bolt和每个spout的拓扑度量标准。
Spout指标包括每分钟发出的元组数，元组ack数，每分钟失败消息数以及处理拓扑中整个元组的延迟。bolt指标包括执行的元组数，每分钟的acks，平均元组处理延迟以及特定元组的平均延迟时间。

5.结论

未来的Storm应该实现自动通过统计进行拓扑优化，并且应该在运行时重新优化。此外，作者希望改进可视化工具，提高某些部分的可靠性（例如，将存储在Nimbus上的本地磁盘中的状态移动到更加容错的系统，如HDFS），提供Storm与Hadoop的更好集成，并使用Storm 监视，响应和调整自身以改进运行拓扑的配置。另一个有趣方向是支持Storm的声明性查询范例，这和上周的Spark有点类似，总体来说感觉大数据系统的工具太纷杂，未来估计会整合的简洁一些。
下一篇：Mesos:a platform for fine-grained resource sharing in the data center.