Storm

流计算

流数据

大数据包括静态数据和动态数据（流数据），大数据计算包括批量计算和实时计算。

 

流数据（或数据流）是指在时间分布和数量上无限的一系列动态数据集合体；数据记录是流数据的最小组成单元。

流数据特征：

-数据快速持续达到，潜在大小也许是无穷无尽的。

-数据来源众多，格式复杂。

-数据量大，但不十分关注存储，一旦流数据中的某个元素经过处理，要么被丢弃，要么被归档存储。

注重数据的整体价值，不过分关注个别数据。

-数据顺序颠倒，或不完整，系统无法控制将要处理的新到达的数据元素的顺序。

Hadoop就是典型的批处理模型，由HDFS和HBase存放大量的静态数据，由MapReduce负责对海量数据执行批量计算。

流数据必须采用实时计算。

流计算秉承一个基本理念，即数据的价值随着时间的流逝而降低。

数据采集系统的基本架构有三部分：

1、Agent：主动采集数据，并把数据推送到Collector部分。

2、Collector：接收多个Agent的数据，并实现有序、可靠、高性能的转发。

3、Store：存储Collector转发过来的数据。

对于流计算，一般在Store部分不进行数据的存储，而是将采集的数据直接发给流计算平台进行实时计算。

开源流计算框架Storm

基础组成

Twitter Storm 是一个免费、开源的分布式实时计算系统。

 

Storm对一些设计思想进行了抽象化，主要术语包括Streams、Spouts、Bolts、Topology和Stream Groupings。

Streams

流数据Streams是一个无限的Tuple序列（Tuple即元组，是元素的有序列表，每一个Tuple就是一个值列表，列表中每个值都有个名称，类型可以使基本类型/字符类型/字节数组/其他序列化类型）。这些Tuple序列会以分布式的凡是并行地创建和处理。

可以理解为List<List<Object>>

Spouts

Storm认为每个Stream都有一个源头，并把这个源头抽象为Spouts。Spouts会从外部读取流数据并持续发出Tuple。

Bolts

Storm将Streams的状态转换过程抽象为Bolts。Bolts可以处理Tuple，也可以将处理后的Tuple作为新的Streams发送给其他Bolts。对Tuple的处理逻辑都被封装在Bolts中，可执行过滤、聚合、查询等操作。

Topology

Storm将Spouts和Bolts组成的网络抽象成Topology，Topology是Storm中最高层次的抽象概念，可以被提交到Storm集群执行。一个Topology就是一个流转换图，途中节点是一个Spout或Bolt，图中的边则表示Bolt订阅了哪个Stream。当Spout或Bolt发送元组（Tuple）时，它会把元组（Tuple）发送到每个订阅了该Stream的Bolt上进行处理。

Storm中的Topology定义仅仅是一些Thrift结构体（Thrift是基于二进制的高性能通信中间件），Thrift支持各种编程语言进行定义，这样一来就可以使用各种编程语言来创建、提交Topology。

Stream Groupings

用于告知Topology如何在两个组件（如Spout和Bolt之间，或者不同的Bolt之间）之间进行Tuple传送。

 

框架设计 

在Hadoop上运行的是MapReduce作业，而在Storm上运行的是Topology。但两者任务大不相同，主要的不同点是一个MapReduce作业最终会完成计算并结束运行，而Topology将持续处理消息。

Storm集群采用“Master-Worker”的节点方式，其中Master节点运行名为“Nimbus”的后台程序（类似Hadoop的JobTracker），负责在集群范围内分发代码，为Worker分配任务和检测故障。而每个Worker节点运行名为“Supervisor”的后台程序，负责监听分配给它所在机器的工作，即根据Nimbus分配的任务来决定启动或通知Worker进程。

 

Nimbus后台进程和Supervisor后台进程都是快速失败和无状态的，Master和Worker不直接通信，而是借助Zookeeper，将状态信息存放在Zookeeper中或本地磁盘汇总，以便节点故障时快速恢复。

 

 

 

应用场景：例如微博中的实时热门话题、业务监控、广告推荐、用户实时分析等业务场景。

Storm与Spark Streaming对比