大数据-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());

　　　　}

第三节：架构设计

　　　　对比：

　　　　任务提交流程：

第四节：环境部署

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是自由竞争阶段，但是在要入库时候还是要保持强有序性。