【2019春招准备：106.storm（2）】

3.storm周边框架

• ZooKeeper（zookeeper.apache.org）

可以再cdh5上面下载（话说这个网站好强大）
安装zookeeper到hdp3
启动server端和cli端
可以在cli help ls（查看zookeeper的文件系统）

cli:
创建一个znode ：create /zk_test my_data(字符串绑定到这个node上面了)

• LogStash（收集日志数据的工具，类似Flume）

ELK框架(elastic.co ELK是三个开源软件的缩写，分别表示：Elasticsearch , Logstash, Kibana）
下载链接 https://www.elastic.co/cn/downloads/past-releases/logstash-2-4-1
实际工作都是些配置文件
有很多可以收集数据的流，如es elasticSearch file stdin等等，输出可以指定codec（json格式等）

• Kafka （0.9.0.0版本2015）

见kafka章节：https://blog.csdn.net/qq_33907408/article/details/85202666
源码：scala（2.11）

• Logstash整合Kafka

logstach向kafka producer API中写消息
注意版本（kafka client版本0.9—logstach版本(2.4-5.x)—plugin(4.x)版本）

4. Storm架构（重要）

• 架构

和hadoop中的namenode和datanode一样
在storm中nimbus表示主节点，supervisor表示从节点
不同的是：他们都是无状态的，所有的元数据都存放zookeeper上面某一个znode里面
nimbus主节点：负责任务（task）的指派和分发，资源的分配，是总经理
supervisor：上面可以启动或者停止多个worker进程（配置指定），是包工头；worker是具体干活的工人
一个topology对应几个worker也是可以设置的
worker进程上面 的task是指spout和bolts线程
executor：spout和bolt可能会共享一个线程

• 部署（单机版、集群版）

jdk 1.8
python centos7 自带2.6.6

storm1.2.2(161M) https://www.apache.org/dyn/closer.lua/storm/apache-storm-1.2.2/apache-storm-1.2.2.tar.gz
自带一个zookeeper：dev_zookeeper
drpc:分布式的远程调用

启动

后台启动dev-zookeeper：nohup sh storm dev-zookeeper &

nohup sh storm nimbus & ====>(jps:dev_zoo,config_value)
nohup sh storm ui & ====>(jps:dev_zoo,core,nimbus)(UI默认访问端口是8080）ziboris3:8080

nohup sh storm supervisor & ====>(jps:dev_zoo,core,nimbus,supervisor)
slot就是worker，默认启动了4个worker
nohup sh storm logviewer & ====>(jps:dev_zoo,core,nimbus,supervisor,logviewer)能在UI上面查看log，同时在STORM_HOME里面生成一个log文件夹，里面很多log文件

IDEA代码打包：view-tools window-maven projects-package
package三个类才14k（很小）不含运行环境和依赖

storm jar /home/hadoop/ZZBfiles/stormFile/storm-1.0.jar com.imooc.bigdata.ClusterlSumStormTopology
停止这topology可以在ui上面进入topology（类的名称点进去–kill–设置死亡倒计时）；同时也可以通过命令行kill掉（请不要直接kill -9杀掉worker进程）storm kill topology-name [-w wait-time-sec] (有个默认的时间差)
停止集群 直接kill -9

集群部署规划

5.并行度（executor的数量）

• worker数量设置
• executor数量设置
• task数量设置
• acker数量设置
  不需要对集群进行扩容，修改代码提高并行程度
  一个topology对应一个或者多个worker进程
  worker下面并非直接是task，是executors线程们，一个executor线程可以是一个或者多个task

【默认情况】
一个supervisor最多启动4个worker进程（submit函数的Config能调整）
一个topology对应一个worker进程
一个线程–一个executor–一个task（builder里面设置Executor数量）
默认acker是和worker的数量一样的，一个acker带一个task（config设置）

n那么问题来了！
简单的求和代码，见storm（1），应该只有两个task，就是两个executor，为什么显示会有三个呢？

答案：实际上还有一个acker导致的（单独的线程）

6.storm分组策略（Stream Grouping）

流在bolts应该怎么分区（partition）

• 6.1 Shuffle Grouping

分发tuple的时候，分到每个bolt里面的tuple数量是保证相等的。

• 6.2 Fields Grouping

tuple根据userId进行分组，相同的userId tuple分到同一个task中，不同去不同
根据奇偶的话 虽然设置了三个线程，但是真正干活的只有两个线程（并行度设置并不合理）
如果奇偶只设定一个线程，那么不会丢失数据，会都在这个bolt的端口上面输出

• 6.3 Partial Key Grouping

也是根据指定的字段开始分组，但是不同的是多了一个负载均衡的概念。将会在下游的bolt做负载均衡，如果有数据倾斜（数据分区不均匀）的时候可以得到更好的利用。

• 6.4 All grouping（WITH CARE！）

所有数据会被复制发送到所有的下一级bolt（是否有必要，什么场景需要？）

7. storm可靠性（容错性）

• 7.1 进程级别容错（worker,supervisor,nimbus）

• 如果worker死亡，supervisor会视图重启他，如果一直不行，nimbus出面讲这个worker在其他supervisor上面启动
• task节点死亡，在这个节点上面分配的任务超时之后就会被感知到，nimbus会将这些task重新分配

如果是Nimbus、Supervisor进程死亡：
fail-fast快速失败机制：都是无状态的，元数据信息都保持在ZooKeeper上面
zookeeper在监视着，能够自己重启，跟没事人一样，只是新提交的作业提交不上去了（和hadoop1.0不同，jobtracker挂掉了，所有的正在运行的job都丢失了）

SPOF（单点故障：single point of failure）
如果单点nimbus挂掉，所有的worker因为不在这个机器上面，也不需要往nimbus上面传输元数据，因此是没有关系的，能够正常跑完
只是worker如果在出故障，不能被重新分配到新的supervisor上面而已

• 7.2 ack/fail确认机制