storm,13.storm理论-Storm介绍以...
937
2023-08-07
Storm是个实时的、分布式以及具备高容错的计算系统
Storm进程常驻内存
Storm数据不经过磁盘,在内存中处理
Storm架构架构Nimbus(老板)
负责资源调度和任务分配,接收jar包
Supervisor(监工)
负责接受nimbus分配的任务,启动和停止属于自己管理的worker进程
Worker(工人)
运行具体处理组件逻辑的进程
Task
worker中每一个spout/bolt的线程称为一个task. 在storm0.8之后,task不再与物理线程对应,同一个spout/bolt的task可能会共享一个物理线程,该线程称为executor
zookpeer(CEO)
Nimbus做任务的规划设计,相当于公司老板
zk负责维护集群健康,具体调度Supervisor相关作业
计算模型DAG (Topology)
– 有向无环图
对于Storm实时计算逻辑的封装
即,由一系列通过数据流相互关联的Spout、Bolt所组成的拓扑结构
生命周期:此拓扑只要启动就会一直在集群中运行,直到手动将其kill,否则不会终止(区别于MapReduce当中的Job,MR当中的Job在计算执行完成就会终止)
Tuple
– 元组
Stream中最小数据组成单元
Stream
– 数据流
从Spout中源源不断传递数据给Bolt、以及上一个Bolt传递数据给下一个Bolt,所形成的这些数据通道即叫做Stream
Stream声明时需给其指定一个Id(默认为Default)
实际开发场景中,多使用单一数据流,此时不需要单独指定StreamId
Spout
– 数据源
1. 拓扑中数据流的来源。一般会从指定外部的数据源读取元组(Tuple)发送到拓扑(Topology)中
2. 一个Spout可以发送多个数据流(Stream)
可先通过OutputFieldsDeclarer中的declare方法声明定义的不同数据流,发送数据时通过SpoutOutputCollector中的emit方法指定数据流Id(streamId)参数将数据发送出去
3. Spout中最核心的方法是nextTuple,该方法会被Storm线程不断调用、主动从数据源拉取数据,再通过emit方法将数据生成元组(Tuple)发送给之后的Bolt计算
Bolt
– 数据流处理组件
1. 拓扑中数据处理均有Bolt完成。对于简单的任务或者数据流转换,单个Bolt可以简单实现;更加复杂场景往往需要多个Bolt分多个步骤完成
2. 一个Bolt可以发送多个数据流(Stream)
可先通过OutputFieldsDeclarer中的declare方法声明定义的不同数据流,发送数据时通过SpoutOutputCollector中的emit方法指定数据流Id(streamId)参数将数据发送出去
3. Bolt中最核心的方法是execute方法,该方法负责接收到一个元组(Tuple)数据、真正实现核心的业务逻辑
Stream Grouping
– 数据流分组(即数据分发策略)
数据传输ZMQ(twitter早期产品)
ZeroMQ 开源的消息传递框架,并不是一个MessageQueue
Netty
Netty是基于NIO的网络框架,更加高效。(之所以Storm 0.9版本之后使用Netty,是因为ZMQ的license和Storm的license不兼容。)
优势高可靠性
异常处理
消息可靠性保障机制(ACK)
可维护性
StormUI 图形化监控接口
应用场景流式处理流式处理(异步 与 同步)
客户端提交数据进行结算,并不会等待数据计算结果
逐条处理例:ETL(数据清洗)extracted transform load
统计分析例:计算PV、UV、访问热点 以及 某些数据的聚合、加和、平均等
客户端提交数据之后,计算完成结果存储到Redis、HBase、MySQL或者其他MQ当中,
客户端并不关心最终结果是多少。
实时请求实时请求应答服务(同步)
客户端提交数据请求之后,立刻取得计算结果并返回给客户端
Drpc
实时请求处理
例:图片特征提取
计算框架对比Strom vs mapreduceStorm:进程、线程常驻内存运行,数据不进入磁盘,数据通过网络传递。
MapReduce:为TB、PB级别数据设计的批处理计算框架。
Strom vs Spark StreamingStorm:纯流式处理
专门为流式处理设计
数据传输模式更为简单,很多地方也更为高效
并不是不能做批处理,它也可以来做微批处理,来提高吞吐
Spark Streaming:微批处理
将RDD做的很小来用小的批处理来接近流式处理
基于内存和DAG可以把处理任务做的很快
发表评论
暂时没有评论,来抢沙发吧~