Storm优势:
1、简单的变成模型。类似于MapReduce降低了并行处理的复杂性,Storm降低了进行实时处理的复杂性
2、服务化,一个服务框架支持热部署,即时上线或者下下App
3、可以使用各种编程语言。你可以在Storm智商使用各种编程语言。默认Clojure、java、Ruby和Python。要增加
对其他语言的支持,只需要实现一个简单的Stomr通信协议即可
4、容错性。Storm会管理工作进程和节点的故障
5、水平扩展。计算是在多个新城、进程和服务器之间并行进行的
Storm基本概念:
1、可靠的消息处理。Storm保证每个消息至少能得到一次完整的处理。任务失败时候,他会负责从消息源重试消息
2、快速。系统的设计保证能得到快速的处理,使用ZeroMQ作为其底层消息队列
3、本地模式.Stomr是一个“本地模式”,可以在处理过程中完全模拟Storm集群。这让你可以快速进行开发和单元测试
Storm存在的问题
1、目前的开源版本中只有单节点Nimbus,挂掉只能自动重启,可以考虑实现一个nimbus的布局
2、Clojure是一个在JVM平台运行的动态函数编程语言,优势在于流程计算,Storm的核心内容是由Clojure编写,
虽然性能上提升不少但是同时也提升了维护成本。
Storm的架构
Storm集群由一个主节点和多个工作节点组成。主节点运行了一个名为"Nimbus"的守护县城,用于分配代码、布置任务
及故障检测。每一个工作节点都运行了一个名为Supervisor的守护线程,用于监听工作,开始并终止工作进程,Nimbus和Supervisor都能快速失败
而且是无状态的,这样一来他们就变得十分健壮,两者的协调工作是由zookeeper来完成的,Zookeeper用于管理集群中的不同组件
ZeroMQ是内部消息系统,JZMQ是ZeroMQ的javaBinding。有个名为storm-deploy的子项目,可以在aws上一键部署Storm集群
对比:
Hadoop Storm
系统角色 JobTracker Nimbus
TaskTracker Subervisor
Child Worker
应用名称 Job Topology
组件接口 Mapper/reducer Spout/Bolt
Storm基本概念:
1、Nimbus:负责资源分配和任务调度
2、Supervisor:负责接收nimbus分配的任务,启动和停止属于自己管理的worker京城
3、Worker:运行具体处理组件,逻辑的进程
4、Task:worker中每一个spout/bolt的线程成为一个task。在Storm0.8之后,task不在与物理线程对应,同一个spout、bolt
的task可能会共享一个物理线程,改线程成为executor
5、Topology:storm中运行的一个实时应用程序,应为各个组件间的消息流动形成逻辑上的一个拓扑结构
6、Spout:在一个topoogy中生产源数据流的组件。通常情况下spout会从外部数据源中读取数据,然后转换为topology
内部的源数据。Spout是一个主动的角色,其接口中有个nextTuple()函数,storm框架会不停的调用此函数,用户只要在其中生成源数据即可
7、Bolt:在一个topology中接受数据然后执行处理的组件,Bolt可以执行过滤、函数操作、合并、写数据库等任何操作。
Bolt是一个被动的角色,其接口中有个executor(Tupleinput)函数,在接受到消息后会调用此函数,用户可以在其中执行自己想要的操作
8、Tuple:一次消息传递的基本单元。本来应该是key-value的map,但是由于各个组件间传递的tuple的字段名称已经实现定义好,所以
tuple只能按照填入各个value就行了,所以就是一个value
9、Stream:源源不断的传递的tuple就组成了stream。
Storm使用场景:
1、流聚合:流聚合把两个或者多个数据流聚合成一个数据流--基于一些共同的tuple字段
2、批处理:有时候为了性能或者一些别的原因,你可以想把一组tuple一起处理,而不是一个个单独处理
3、BasicBolt
1)读一个tuple
2)根据这个输入tuple发射一个或者多个tuple
3)在execute的方法的最后ack那个输入tuple遵循这个模式的bolt一般是函数或者过滤器,这个模式太常见,storm为这个模式单独封装了一个接口:ibasicBoil
4、内存缓存+Fields grouping组合
在bolt的内存里面缓存一个东西非常常见,缓存在和fields grouping结合起来之后就更有用了,比如,你有一个bolt把段链接变成一个长链接,可以把短连接到长链接
的对应关系利用LRU算法缓存在内存里面以避免重复计算
5、计算top N 比如有一个bolt发射这个的tuple:“value”,“count”并且你想一个bolt基于这些信息top N的tuple。最简单的方法是一个bolt可以做一个全局的grouping的动作并且
在内存里面保持这个top N的值。
这个方式对于大数据量的流显示显然没有扩展性,因为所有的数据会被发到同一台机器上,一个更好的方法是在多台机器上并行计算这个流每一个部分的top N,然后在有一个bolt
合并这些机器上面所计算出来的top N以算出最后的top N,代码大概是这样的
1、简单的变成模型。类似于MapReduce降低了并行处理的复杂性,Storm降低了进行实时处理的复杂性
2、服务化,一个服务框架支持热部署,即时上线或者下下App
3、可以使用各种编程语言。你可以在Storm智商使用各种编程语言。默认Clojure、java、Ruby和Python。要增加
对其他语言的支持,只需要实现一个简单的Stomr通信协议即可
4、容错性。Storm会管理工作进程和节点的故障
5、水平扩展。计算是在多个新城、进程和服务器之间并行进行的
Storm基本概念:
1、可靠的消息处理。Storm保证每个消息至少能得到一次完整的处理。任务失败时候,他会负责从消息源重试消息
2、快速。系统的设计保证能得到快速的处理,使用ZeroMQ作为其底层消息队列
3、本地模式.Stomr是一个“本地模式”,可以在处理过程中完全模拟Storm集群。这让你可以快速进行开发和单元测试
Storm存在的问题
1、目前的开源版本中只有单节点Nimbus,挂掉只能自动重启,可以考虑实现一个nimbus的布局
2、Clojure是一个在JVM平台运行的动态函数编程语言,优势在于流程计算,Storm的核心内容是由Clojure编写,
虽然性能上提升不少但是同时也提升了维护成本。
Storm的架构
Storm集群由一个主节点和多个工作节点组成。主节点运行了一个名为"Nimbus"的守护县城,用于分配代码、布置任务
及故障检测。每一个工作节点都运行了一个名为Supervisor的守护线程,用于监听工作,开始并终止工作进程,Nimbus和Supervisor都能快速失败
而且是无状态的,这样一来他们就变得十分健壮,两者的协调工作是由zookeeper来完成的,Zookeeper用于管理集群中的不同组件
ZeroMQ是内部消息系统,JZMQ是ZeroMQ的javaBinding。有个名为storm-deploy的子项目,可以在aws上一键部署Storm集群
对比:
Hadoop Storm
系统角色 JobTracker Nimbus
TaskTracker Subervisor
Child Worker
应用名称 Job Topology
组件接口 Mapper/reducer Spout/Bolt
Storm基本概念:
1、Nimbus:负责资源分配和任务调度
2、Supervisor:负责接收nimbus分配的任务,启动和停止属于自己管理的worker京城
3、Worker:运行具体处理组件,逻辑的进程
4、Task:worker中每一个spout/bolt的线程成为一个task。在Storm0.8之后,task不在与物理线程对应,同一个spout、bolt
的task可能会共享一个物理线程,改线程成为executor
5、Topology:storm中运行的一个实时应用程序,应为各个组件间的消息流动形成逻辑上的一个拓扑结构
6、Spout:在一个topoogy中生产源数据流的组件。通常情况下spout会从外部数据源中读取数据,然后转换为topology
内部的源数据。Spout是一个主动的角色,其接口中有个nextTuple()函数,storm框架会不停的调用此函数,用户只要在其中生成源数据即可
7、Bolt:在一个topology中接受数据然后执行处理的组件,Bolt可以执行过滤、函数操作、合并、写数据库等任何操作。
Bolt是一个被动的角色,其接口中有个executor(Tupleinput)函数,在接受到消息后会调用此函数,用户可以在其中执行自己想要的操作
8、Tuple:一次消息传递的基本单元。本来应该是key-value的map,但是由于各个组件间传递的tuple的字段名称已经实现定义好,所以
tuple只能按照填入各个value就行了,所以就是一个value
9、Stream:源源不断的传递的tuple就组成了stream。
Storm使用场景:
1、流聚合:流聚合把两个或者多个数据流聚合成一个数据流--基于一些共同的tuple字段
2、批处理:有时候为了性能或者一些别的原因,你可以想把一组tuple一起处理,而不是一个个单独处理
3、BasicBolt
1)读一个tuple
2)根据这个输入tuple发射一个或者多个tuple
3)在execute的方法的最后ack那个输入tuple遵循这个模式的bolt一般是函数或者过滤器,这个模式太常见,storm为这个模式单独封装了一个接口:ibasicBoil
4、内存缓存+Fields grouping组合
在bolt的内存里面缓存一个东西非常常见,缓存在和fields grouping结合起来之后就更有用了,比如,你有一个bolt把段链接变成一个长链接,可以把短连接到长链接
的对应关系利用LRU算法缓存在内存里面以避免重复计算
5、计算top N 比如有一个bolt发射这个的tuple:“value”,“count”并且你想一个bolt基于这些信息top N的tuple。最简单的方法是一个bolt可以做一个全局的grouping的动作并且
在内存里面保持这个top N的值。
这个方式对于大数据量的流显示显然没有扩展性,因为所有的数据会被发到同一台机器上,一个更好的方法是在多台机器上并行计算这个流每一个部分的top N,然后在有一个bolt
合并这些机器上面所计算出来的top N以算出最后的top N,代码大概是这样的