大数据-storm理论
Posted bug修复中
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了大数据-storm理论相关的知识,希望对你有一定的参考价值。
导读:
第一节:基础架构
1:编程模型
2:架构
3:数据传输
4:高可靠性
5:高维护性
6:数据处理方式
7:对比MR,SPARK
第二节:计算模型
1:spout
2:bolt
3:stream grouping
4:构建拓扑与提交
第三节:架构
第四节:部署
第五节:数据处理
1:同步计算
2:并发机制
第六节:flume+kafka+strom
1:kafka
2:strom兼容kafka
3:flume兼容kafka
第七节:容错机制
1:ACK
2:事务
第一节:基础架构
1、编程模型
DAG (Topology)
Spout(tuple)----->bolt(tuple)--->bolt(tuple)
Spout(数据推送源)
Bolt(数据处理源)
2、架构
Nimbus //主节点上的守护进程
资源管理
任务分配
Jar包任务的上传
Supervisor //从节点上的监督进程
接收nimbus分配的任务
启动、停止自己管理的worker进程(当前supervisor上worker数量由配置文件设定)
Worker //从节点上的工作进程
运行具体处理运算组件的进程(每个Worker对应执行一个Topology的子集)
worker任务类型,即spout任务、bolt任务两种
启动executor
(executor即worker JVM进程中的一个java线程,一般默认每个executor负责执行一个task任务)
3、数据传输
ZMQ(twitter早期产品)
Netty(现用的)
4、高可靠性
异常处理
消息可靠性保障机制(ACK):
不管在哪个bolt中出现问题,都会回到spout再次走流程,但是有问题,这个情况可以忽略。
5、可维护性
StormUI 图形化监控接口
6、数据处理方式
(1)、异步:无应答
client--->消息队列(kafka等)--->strom--->结果源(mysql,hbase,redis等)
(2)、同步:有应答,需要调用内置的drpc服务器才会是同步的
Client--->DRPC--->strom--->DRPC--->client
7、比较:
第二节:计算模型
Java写,所以不管是sport还是bolt都是类,业务的处理也就是对类中方法的实现
(1)Spout:继承BaseRichSpout或实现IRichSpout
open: //对象创建
This.conf = conf;
This.context= context;
This.collector= collector;
declare方法:声明定义,即定义要向后发送的是什么数据,declare英文注释:声明
可先通过DeclarerOutputFields中的declare方法声明定义的不同数据流,发送数据时通过SpoutOutputCollector中的emit方法指定数据流Id(streamId)参数将数据发送出去
例子:
DeclarerOutputFields
Declarer.declare(new Fields(“num”));
nextTuple方法:数据拉取,数据推送
Spout中最核心的方法是nextTuple,该方法会被Storm线程不断调用、主动从数据源拉取数据,再通过emit方法将数据生成元组(Tuple)发送给之后的Bolt计算
例子:
nextTuple
i++;
List tuple = new Values(i);
This.collector.emit(tuple);
(2)Bolt:继承BaseRichBolt或实现IRichBolt
prepare: //同上面的open一样创建
declare方法:声明定义,即定义要向后发送的是什么数据
可先通过OutputFieldsDeclarer中的declare方法声明定义的不同数据流,发送数据时通过SpoutOutputCollector中的emit方法指定数据流Id(streamId)参数将数据发送出去
execute方法:业务处理
Bolt中最核心的方法是execute方法,该方法负责接收到一个元组(Tuple)数据、真正实现核心的业务逻辑
例子:
Excute
Input.get...byField(“num”);
(3)Stream Grouping – 数据流分组(即数据分发策略)将tuple发送给哪个bolt task来处理
1. Shuffle Grouping 随机分发(常用)
随机分组,随机派发stream里面的tuple,保证每个bolt task接收到的tuple数目大致相同。
轮询,平均分配
例子:.shuffleGrouping(“sport1”);
2. Fields Grouping按字段分组(常用)
按字段分组,比如,按"user-id"这个字段来分组,那么具有同样"user-id"的 tuple 会被分到相同的Bolt里的一个task, 而不同的"user-id"则可能会被分配到不同的task。
例子:.fieldsGrouping(“sport1”,new Fields(“w”));
3. All Grouping所有的节点都获取到全量的(不用)
广播发送,对于每一个tuple,所有的bolts都会收到
4. Global Grouping(不用)
全局分组,把tuple分配给task id最低的task 。
5. None Grouping(同shuffle grouping,不用)
不分组,这个分组的意思是说stream不关心到底怎样分组。目前这种分组和Shuffle grouping是一样的效果。 有一点不同的是storm会把使用none grouping的这个bolt
放到这个bolt的订阅者同一个线程里面去执行(未来Storm如果可能的话会这样设计)。
6. Direct Grouping(指定哪个接收,首先声明Direct Stream指向流,emitDirect用这种的方式发送)
指向型分组, 这是一种比较特别的分组方法,用这种分组意味着消息(tuple)的发送者指定由消息接收者的哪个task处理这个消息。只有被声明为 Direct Stream
的消息流可以声明这种分组方法。而且这种消息tuple必须使用 emitDirect 方法来发射。消息处理者可以通过 TopologyContext 来获取处理它的消息的task
的id (OutputCollector.emit方法也会返回task的id)
7. Local or shuffle grouping(限制在一个工作进程中的随机分发,不用)
本地或随机分组。如果目标bolt有一个或者多个task与源bolt的task在同一个工作进程中,tuple将会被随机发送给这些同进程中的tasks。否则,和普通的Shuffle Grouping行为一致
8. customGrouping(不用)
自定义,相当于mapreduce那里自己去实现一个partition一样。
(4)构建拓扑及提交
Main
topologyBuilder tb = new topologyBuilder();
Tb.setSport(“sport1”,new Sport1());
Tb.setBolt(“bolt1”,new Bolt1(),2).shuffleGrouping(“sport1”); //这里的2是并行度,可以不设;shuffleGrouping是分发策略。
If(args.length > 0){ //集群形式运行
StormSubmitTopology.submitTopology(args[0],new conf(), tb.creatTopology());
}else{ //本地形式运行
localCluster lc = new localCluster();
Lc.submitTopology(“wc”, new conf(), tb.creatTopology());
}
第三节:架构设计
对比:
|
Hadoop |
Storm |
主节点 |
ResourceManager |
Nimbus |
从节点 |
NodeManager |
Supervisor |
应用程序 |
Job |
Topology |
工作进程 |
Child |
Worker |
计算模型 |
Map/Reduce(split,map,shuffle,reduce) |
Spout/Bolt |
任务提交流程:
第四节:环境部署
1、在storm目录中创建logs目录,出现问题时候存放日志
mkdir logs
2、解压
通讯端口是8080
3、修改配置文件 https://blog.csdn.net/l1028386804/article/details/51924272
storm.yaml
storm.zookeeper.servers:
- "node1"
- "node2"
- "node3"
storm.local.dir: "/tmp/storm"
nimbus.host: “node1"
supervisor.slots.ports: //supervisor上运行workers的端口列表.每个worker占用一个端口,且每个端口只运行一个worker.通过这项配 - 6700 置可以调整每台机器上运行的worker数.(调整slot数/每机)
- 6701
- 6702
- 6703
4、查看帮助信息
./storm help
5、启动Zookeeper
./bin/storm dev-zookeeper >> ./logs/zk.out 2>&1 &
6、在node1上启动Nimbus,UI
./bin/storm nimbus >> ./logs/nimbus.out 2>&1 &
./bin/storm ui >> ./logs/ui.out 2>&1 &
7、在node2、node3上启动Supervisor(按照配置每个Supervisor上启动4个slots)
./bin/storm supervisor >> ./logs/supervisor.out 2>&1 &
8、启动Logviewer(可以在浏览器上查看日志)
./bin/storm logviewer &
9、提交jar包到集群:
strom help jar(查看如何提交jar到storm集群)
第五节:数据处理方式
1、同步计算(DRPC):实现一个demo
集群:
修改配置文件conf/storm.yaml
drpc.servers:
- "node1”
启动:
启动 drpc
storm drpc >> ./logs/drpc.out 2>&1 &
代码:
1、自动方式:不建议使用,比较死板
LinearDRPCTopologyBuilder
2、手动方式:
2、并发机制:
Worker – 进程
一个Topology拓扑会包含一个或多个Worker(每个Worker进程只能从属于一个特定的Topology)
这些Worker进程会并行跑在集群中不同的服务器上,即一个Topology拓扑其实是由并行运行在Storm集群中多台服务器上的进程所组成
Executor – 线程
Executor是由Worker进程中生成的一个线程
每个Worker进程中会运行拓扑当中的一个或多个Executor线程
一个Executor线程中可以执行一个或多个Task任务(默认每个Executor只执行一个Task任务),但是这些Task任务都是对应着同一个组件(Spout、Bolt)。
Task
实际执行数据处理的最小单元
每个task即为一个Spout或者一个Bolt
注意:
Task数量在整个Topology生命周期中保持不变,Executor数量可以变化或手动调整
(默认情况下,Task数量和Executor是相同的,即每个Executor线程中默认运行一个Task任务)
代码中设置数量:
设置Worker进程数
Config.setNumWorkers(int workers)
设置Executor线程数
TopologyBuilder.setSpout(String id, IRichSpout spout, Number parallelism_hint)
TopologyBuilder.setBolt(String id, IRichBolt bolt, Number parallelism_hint)
设置Task数量
ComponentConfigurationDeclarer.setNumTasks(Number val)
例:
Config conf = new Config() ;
conf.setNumWorkers(2);
TopologyBuilder topologyBuilder = new TopologyBuilder();
topologyBuilder.setSpout("spout", new MySpout(), 1);
topologyBuilder.setBolt("green-bolt", new GreenBolt(), 2)
.setNumTasks(4)
.shuffleGrouping("blue-spout);
调整worker与excutor的数量:
Rebalance:命令行动态调整,可以多设置task,以后再发生扩充的时候,就可以直接调整worker与excutor数量来实现迁移
第六节:Flume+kafka+strom
(1)Kafka(Kafka的优势)
简介:
1、角色:
Producers ---topic----consumers
在一个分区中的生产与消费是有序的
2、搭建集群的节点:
Broker //编号
3、如何保证消费的有序性:
消费的偏移量
4、优势
高吞吐量:零拷贝,Netty的网络传输。
数据默认保存7天。
offset会更新到一个kafka自带的topic【__consumer_offsets】
安装:
解压:
Tar gz -C 目录
配置:
config/server.properties:
Broker.id
Log.dirs=真实数据存储路径
Zookeeper.connect=node01:2181,node02:2181
启动:
bin/kafka-server-start.sh config/server.properties //启动kafka,且指定要读取哪个配置文件
测试:
查看帮助手册:
bin/kafka-console-consumer.sh help
查看topic列表:
bin/kafka-topics.sh --zookeeper node06:2181,node07:2181,node08:2181 --list
查看“test”topic描述:
bin/kafka-topics.sh --zookeeper node06:2181,node07:2181,node08:2181 --describe --topic test
Topic创建
bin/kafka-topics.sh --zookeeper node06:2181,node07:2181,node08:2181 --create --replication-factor 2 --partitions 3 --topic test
(参数说明:
--replication-factor:副本个数,默认1个
--partitions:指定当前创建的topic分区数量,默认1个(向几个分区中分发数据,此时一个分区有序,整体无序)
--topic:指定新建topic的名称
)
Producer创建(往主题中生产数据)
bin/kafka-console-producer.sh --broker-list node06:9092,node07:9092,node08:9092 --topic test
Consumer创建(消费某主题的数据)
bin/kafka-console-consumer.sh --zookeeper node06:2181,node07:2181,node08:2181 --from-beginning --topic test
(参数说明:
--from-beginning 从头消费
)
(2)strom兼容kafka
kafkaSpout 消费kafka数据
kafkaBolt 生产kafka数据
(3)Flume兼容kafka
1、flume安装
(1)解压
(2)配置flume-env.sh
配置Java的环境变量位置
(3)在conf/下 创建配置文件fk.conf
#取别名
a1.sources = r1 a1.sinks = k1 a1.channels = c1 # Describe/configure the source a1.sources.r1.type = avro //客户端连接source源的协议 a1.sources.r1.bind = node06 //flume所在节点(如果是集群呢???????????????) a1.sources.r1.port = 41414 //与flume连接的端口 # Describe the sink 对输出源的规定 a1.sinks.k1.type = org.apache.flume.sink.kafka.KafkaSink //往哪里推送 a1.sinks.k1.topic = testflume //主题 a1.sinks.k1.brokerList = node06:9092,node07:9092,node08:9092 a1.sinks.k1.requiredAcks = 1 //数据完整保障机制,1:主节点告诉消息已传递即可,0:只管推送,-1:所有的都反馈 a1.sinks.k1.batchSize = 20 a1.sinks.k1.channel = c1 # Use a channel which buffers events in memory 内存区设定 a1.channels.c1.type = memory a1.channels.c1.capacity = 1000000 a1.channels.c1.transactionCapacity = 10000 # Bind the source and sink to the channel a1.sources.r1.channels = c1 a1.sinks.k1.channel = c1
(4)启动flume
bin/flume-ng agent -n a1 -c conf -f conf/fk.conf -Dflume.root.logger=DEBUG,console
//agent是代理
//Dflume.root.logger=DEBUG,console 日志输出格式,控制台打印debug日志
第七节:容错机制
1、容错机制(消息的完整性:速度降低了,完整度提高):
(1) 怎么判断消息是否完整传递:
传递数据的同时,带有16位二进制的ID,数据传递到下一个点时候,将新的ID进行xor运算,如果是全0,则说明数据正常传递。
如果有问题,则通知spout重新发送。
(2) Ack
保证数据至少一次发送,但是不保证会重复。
2、事务:
要解决的问题:
事务解决让数据有且仅有一次被处理。
Transcation:
tuple传递时候带着transcationID,且这个ID是线性增长,数据的处理也是强有序性的。
将tuple存入库时,那么可根据ID判断,如果有这个ID的数据了,那么就是代表数据被处理过了,就不做处理了。
弊端:每次的tuple频繁的与数据库交互。所以衍生出:
Design2:
现在是多个tuple组成batch,这个批里面带着一个transcationID,以批处理形式,进行数据传递与数据库交互。
弊端:一个batch在运行时候,其他的是在阻塞状态,不仅影响速度,还有资源浪费。
Design3:
在前面的bolt阶段,所有的batch是自由竞争阶段,但是在要入库时候还是要保持强有序性。
以上是关于大数据-storm理论的主要内容,如果未能解决你的问题,请参考以下文章
关于举办“大数据分析和挖掘技术实战-Mahout/MLlib/Storm/Docker” 培训
流式大数据处理的三种框架:Storm,Spark和Samza