分布式实时计算框架Storm

问题导读：
1.Storm与hadoop有什么优势？
2.Storm有哪些术语？
3.Storm的编程模型是什么？
4.Storm在淘宝被用来做什么





前言

全量数据处理使用的大多是鼎鼎大名的hadoop或者hive，作为一个批处理系统，hadoop以其吞吐量大、自动容错等优点，在海量数据处理上得到了广泛的使用。但是，hadoop不擅长实时计算，因为它天然就是为批处理而生的，这也是业界一致的共识。否则最近这两年也不会有s4,storm,puma这些实时计算系统如雨后春笋般冒出来啦。先抛开s4,storm,puma这些系统不谈，我们首先来看一下，如果让我们自己设计一个实时计算系统，我们要解决哪些问题:

A:低延迟。都说了是实时计算系统了，延迟是一定要低的。
B:高性能。性能不高就是浪费机器，浪费机器是要受批评的哦。
C:分布式。系统都是为应用场景而生的，如果你的应用场景、你的数据和计算单机就能搞定，那么不用考虑这些复杂的问题了。我们所说的是单机搞不定的情况。
D:可扩展。伴随着业务的发展，我们的数据量、计算量可能会越来越大，所以希望这个系统是可扩展的。
E:容错。这是分布式系统中通用问题。一个节点挂了不能影响我的应用。

Storm概述

   针对以上的需求，有了s4、storm、puma等等用于实时计算的框架出现，其中Storm是Twitter开源的一个分布式的、容错的实时计算系统，按照storm作者的说法，storm对于实时计算的意义类似于hadoop对于批处理的意义。类似于MapReduce降低了并行批处理复杂性，Storm降低了进行实时处理的复杂性。可以使用各种编程语言。你可以在Storm之上使用各种编程语言。默认支持Clojure、Java、Ruby和Python。Storm为分布式实时计算提供了一组通用原语，可被用于“流处理”之中，实时处理消息并更新数据库。这是管理队列及工作者集群的另一种方式。 Storm也可被用于“连续计算”（continuous computation），对数据流做连续查询，在计算时就将结果以流的形式输出给用户。它还可被用于“分布式RPC”，以并行的方式运行昂贵的运算。 Storm的主工程师Nathan Marz表示：Storm可以方便地在一个计算机集群中编写与扩展复杂的实时计算，Storm之于实时处理，就好比 Hadoop之于批处理。Storm保证每个消息都会得到处理，而且它很快——在一个小集群中，每秒可以处理数以百万计的消息。更棒的是你可以使用任意编程语言来做开发。

storm的适用场景

1：流数据处理。Storm可以用来处理源源不断流进来的消息，处理之后将结果写入到某个存储中去。

2：分布式rpc。由于storm的处理组件是分布式的，而且处理延迟极低，所以可以作为一个通用的分布式rpc框架来使用。当然，其实我们的搜索引擎    本身也是一个分布式rpc系统。

Storm的主要特点

A；简单的编程模型：类于MapReduce降低了并行批处理复杂性，Storm降低了进行实时处理的复杂性。

B:容错性：Storm会管理工作进程和节点的故障。

C:水平扩展：计算是在多个线程、进程和服务器之间并行进行的。
D:可靠的消息处理：Storm保证每个消息至少能得到一次完整处理。任务失败时，它会负责从消息源重试消息。
E:快速：系统的设计保证了消息能得到快速的处理，使用MQ作为其底层消息队列。
F:本地模式：Storm有一个“本地模式”，可以在处理过程中完全模拟Storm集群。

Storm的术语

Storm的术语包括Stream、Spout、Bolt、Task、Worker、Stream Grouping和Topology。
Stream是被处理的数据。
Sprout是数据源。
Bolt处理数据。
Task是运行于Spout或Bolt中的线程。
Worker是运行这些线程的进程。
Stream Grouping规定了Bolt接收什么东西作为输入数据。数据可以随机分配（术语为Shuffle），或者根据字段值分配（术语为Fields），或者广播（术 语为All），或者总是发给一个Task（术语为Global），也可以不关心该数据（术语为None），或者由自定义逻辑来决定（术语为 Direct）。
Topology是由Stream Grouping连接起来的Spout和Bolt节点网络。
在Storm Concepts页面里对这些术语有更详细的描述。

Storm的编程模型

Storm集群由一个主节点和多个工作节点组成。
主节点运行了一个名为“Nimbus”的守护进程，用于分配代码、布置任务及故障检测。
每个工作节点都运行了一个名为“Supervisor”的守护进程，用于监听工作，开始并终止工作进程。
Nimbus和Supervisor都能快速失败，而且是无 状态的，这样一来它们就变得十分健壮，两者的协调工作是由Apache ZooKeeper来完成的。
具体情况如下：
Nimbus：负责资源分配和任务调度。类似Hadoop的JobTracker
Supervisor：负责接受nimbus分配的任务，启动和停止属于自己管理的worker进程。类似Hadoop的TaskTracker
Worker：运行具体处理组件逻辑的进程。类似Hadoop的Child
Task：worker中每一个spout/bolt的线程称为一个task.在storm0.8之后，task不再与物理线程对应，同一个spout/bolt的task可能会共享一个物理线程，该线程称为executor。
通信：Apache Zookeeper

Storm的事务拓扑

事务拓扑(transactional topology)是storm0.7引入的特性，在最近发布的0.8版本中已经被封装为Trident，提供了更加便利和直观的接口。因为篇幅所限，在此对事务拓扑做一个简单的介绍。
事务拓扑的目的是为了满足对消息处理有着极其严格要求的场景，例如实时计算某个用户的成交笔数，要求结果完全精确，不能多也不能少。Storm的事务拓扑是完全基于它底层的spout/bolt/acker原语实现的，通过一层巧妙的封装得出一个优雅的实现。个人觉得这也是storm最大的魅力之一。
事务拓扑简单来说就是将消息分为一个个的批(batch)，同一批内的消息以及批与批之间的消息可以并行处理，另一方面，用户可以设置某些bolt为committer，storm可以保证committer的finishBatch()操作是按严格不降序的顺序执行的。用户可以利用这个特性通过简单的编程技巧实现消息处理的精确。

Storm在淘宝

由于storm的内核是clojure编写的(不过大部分的拓展工作都是java编写的)，为我们理解它的实现带来了一定的困难，好在大部分情况下storm都比较稳定，当然我们也在尽力熟悉clojure的世界。我们在使用storm时通常都是选择java语言开发应用程序。
在淘宝，storm被广泛用来进行实时日志处理，出现在实时统计、实时风控、实时推荐等场景中。一般来说，我们从类kafka的metaQ或者基于hbase的timetunnel中读取实时日志消息，经过一系列处理，最终将处理结果写入到一个分布式存储中，提供给应用程序访问。我们每天的实时消息量从几百万到几十亿不等，数据总量达到TB级。对于我们来说，storm往往会配合分布式存储服务一起使用。在我们正在进行的个性化搜索实时分析项目中，就使用了timetunnel + hbase + storm + ups的架构，每天处理几十亿的用户日志信息，从用户行为发生到完成分析延迟在秒级。

Storm的未来

Storm0.7系列的版本已经在各大公司得到了广泛使用，最近发布的0.8版本中引入了State，使得其从一个纯计算框架演变成了一个包含存储和计算的实时计算新利器，还有刚才提到的Trident，提供更加友好的接口，同时可定制scheduler的特性也为其针对不同的应用场景做优化提供了更便利的手段，也有人已经在基于storm的实时ql(query language)上迈出了脚本。在服务化方面，storm一直在朝着融入mesos框架的方向努力。同时，storm也在实现细节上不断地优化，使用很多优秀的开源产品，包括kryo, Disruptor, curator等等。可以想象，当storm发展到1.0版本时，一定是一款无比杰出的产品，让我们拭目以待，当然，最好还是参与到其中去吧，同学们。

Strom入门

入门的最佳途径是阅读GitHub上的官方《Storm Tutorial》。 其中讨论了多种Storm概念和抽象，提供了范例代码以便你可以运行一个Storm Topology。开发过程中，可以用本地模式来运行Storm，这样就能在本地开发，在进程中测试Topology。一切就绪后，以远程模式运行 Storm，提交用于在集群中运行的Topology。如果英语不好，在百度文库中搜索关于Storm的中文文档也行。
要运行Storm集群，你需要Apache Zookeeper、?MQ、JZMQ、Java 6和Python 2.6.6

延伸阅读：

目前，互联网企业的海量数据采集工具，有Facebook开源的Scribe、LinkedIn开源的Kafka、Cloudera开源的Flume，淘宝开源的TimeTunnel、Hadoop的Chukwa等，均可以满足每秒数百MB的日志数据采集和传输需求。
实时流计算框架：Yahoo开源的S4、Twitter开源的Storm，还有Esper，Streambase，HStreaming等。

转自：http://www.maoxiangyi.cn/index.php/archives/337