storm学习1

Apache Storm是一个开源的、分布式、流式计算系统。

非实时计算几乎都基于MapReduce计算框架，但MapReduce并不是万能的。对于搜索应用环境中的某些现实问题，MapReduce并不能很好地解决问题。

商用搜索引擎，像Google、Bing和Yahoo!等，通常在用户查询响应中提供结构化的Web结果，同时也插入基于流量的点击付费模式的文本广告。为了在页面上最佳位置展现最相关的广告，通过一些算法来动态估算给定上下文中一个广告被点击的可能性。上下文可能包括用户偏好、地理位置、历史查询、历史点击等信息。一个主搜索引擎可能每秒钟处理成千上万次查询，每个页面都可能会包含多个广告。为了及时处理用户反馈，需要一个低延迟、可扩展、高可靠的处理引擎。然而，对于这些实时性要求很高的应用，尽管MapReduce作了实时性改进，但仍很难稳定地满足应用需求。因为Hadoop为批处理作了高度优化，MapReduce系统典型地通过调度批量任务来操作静态数据；而流式计算的典型范式之一是不确定数据速率的事件流流入系统，系统处理能力必须与事件流量匹配，或者通过近似算法等方法优雅降级，通常称为负载分流（load-shedding）。当然，除了负载分流，流式计算的容错处理等机制也和批处理计算不尽相同。

最近Facebook在Sigmod 11上发表了利用HBase/Hadoop进行实时数据处理的论文，通过一些实时性改造，让批处理计算平台也具备实时计算的能力。这类基于MapReduce进行流式处理的方案有三个主要缺点。

将输入数据分隔成固定大小的片段，再由MapReduce平台处理，缺点在于处理延迟与数据片段的长度、初始化处理任务的开销成正比。小的分段会降低延迟，增加附加开销，并且分段之间的依赖管理更加复杂（例如一个分段可能会需要前一个分段的信息）；反之，大的分段会增加延迟。最优的分段大小取决于具体应用。
为了支持流式处理，MapReduce需要被改造成Pipeline的模式，而不是Reduce直接输出；考虑到效率，中间结果最好只保存在内存中等。这些改动使得原有的MapReduce框架的复杂度大大增加，不利于系统的维护和扩展。
用户被迫使用MapReduce的接口来定义流式作业，这使得用户程序的可伸缩性降低。
综上所述，流式处理的模式决定了要和批处理使用非常不同的架构，试图搭建一个既适合流式计算又适合批处理计算的通用平台，结果可能会是一个高度复杂的系统，并且最终系统可能对两种计算都不理想。

目前流式计算是业界研究的一个热点，最近Twitter、LinkedIn等公司相继开源了流式计算系统Storm、Kafka等，加上Yahoo!之前开源的S4，流式计算研究在互联网领域持续升温。不过流式计算并非最近几年才开始研究，传统行业像金融领域等很早就已经在使用流式计算系统，比较知名的有StreamBase、Borealis等。

Nimbus主节点，只负责整体分配工作，不具体干活儿。只负责一些管理性的工作
主要状态存储在分布式协调服务zookeeper上
内存中的东西都是可以丢失的
Nimbus重启之后就能处理系统中的事务了

Supervisior 从节点，直接甘丽干活儿的worker，小组经理。

启动并且监控进行计算的worker进程
也不负责数据计算和数据传输

worker

真正干活儿的TASK 进程

分布式RPC 服务

Storm 称用户的一个作业为topology

点 之间的 边  是  stream
数据流中的每一条记录为 tuple

Spout或者bolt中的executor的数量

本地模式的时候setNumberWorkers不生效，因为只会起一个进程执行作业。

指定计算是怎么分组的。