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.6storm1.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确认机制