Storm是Twitter开源的分布式实时大数据处理框架,被业界称为实时版Hadoop。随着越来越多的场景对Hadoop的MapReduce高延迟无法容忍,比如网站统计、推荐系统、预警系统、金融系统等, 大数据实时处理解决方案的应用日趋广泛,目前已是分布式技术领域最新爆发点,而Storm更是流计算技术中的佼佼者和主流。
Q:Storm原理及核心概念
A:分布式的实时计算系统,能够可信任的处理大量的流式数据,就好比Hadoop对于批量数据进行的处理一样;通常来说,Hadoop能够进行大批量数据的离线处理,但是在实时计算上的表现实在是不尽如人意;而Storm就可以担当这部分的作用。
说一下Storm一些核心概念:
Q:Storm有哪些特点?
A:编程简单:开发人员只需要关注应用逻辑,而且跟Hadoop类似,Storm提供的编程原语也很简单
高性能,低延迟:可以应用于广告搜索引擎这种要求对广告主的操作进行实时响应的场景。
分布式:可以轻松应对数据量大,单机搞不定的场景
可扩展:随着业务发展,数据量和计算量越来越大,系统可水平扩展
容错:单个节点挂了不影响应用
消息不丢失:保证消息处理
Q:Storm的基本架构
A:从网上找到的一张图,参照于Hadoop的架构,来理解其核心组件:
Nimbus:如上图,就好比Hadoop中的JobTracker,是集群中的主节点,负责分发用户代码,把需要处理的任务指派给具体的Supervisor,再由其上的Worker进行实际的处理。
Supervisor:集群中的从节点,负责管理机器上运行的Worker进程,这里,需要注意,worker是一个进程,其内部还可以启动多个线程来进行任务的处理;通常,我们再指定的时候,会在此处通过指定端口号,来指定机器上到底启动多少个worker。
Zookeeper:基本只要牵涉到集群,都需要用到zookeeper,这也符合其作为动物园管理员的职责,通过zookeeper,nimbus会感知到Supervisor的下线和上线,会合理分配资源,完成Topology的处理
Topology:这就好比我们平时提交的一个Application,只是换了一个名称而已。
Q:Storm的应用有哪些?
A:跟Hadoop不一样,Storm是没有包括任何存储概念的计算系统。这就让Storm可以用在多种不同的场景下:非传统场景下数据动态到达或者数据存储在数据库这样的存储系统里(或数据是被实时操控其他设备的控制器(如交易系统)所消费)
例如Nathan Marz提供的例子,产生Twitter的趋势信息。Twitter从海量推文中抽取趋势信息,并在本地区域和国家层级进行维护。这意味者一旦一个案例开始出现,Twitter的话题趋势算法就能实时的鉴别出这个话题。这个实时的算法就是通过在Storm上连续分析Twitter数据来实现的。
Q:Spark与Storm的区别有哪些?
A:其实,这里更应该说是Spark-Streaming与storm的区别,因为spark目前也在朝着打造一个生态圈的目标而努力,拥有spark-sql,能够实现类似Hive的数据仓库管理;而Saprk-Streaming,则是用来进行实时处理,类似于Storm的功能;二者实现的功能相似,但实际上还是有些区别的。
实时性来说,Storm的实时性更强,基本上就是来一条数据,就处理一条数据;在编写Spark代码的时候,会发现,其本身就是收集一段时间的数据来进行统一处理,虽然可以尽可能缩小这个时间,但如果数据瞬间涌入过多的话,其性能相比于Storm还是有些不足的。
健壮性来说,Storm的实现中使用了zookeeper来实现,而且还有Ack机制,对于数据是否处理成功能够感知到而Spark则是采取了业界常用的WAL,即预写日志和CheckPoint机制,相比之下,健壮性要差一些
并行度的适时调整:对于一个公司来说,业务肯定会存在高峰期和低谷期,所以storm能够动态调整实时计算程序的并行度,能够最大限度利用集群资源,这点也很棒;而Spark是实现不了的。
但是,Spark最好的一点在于,其吞吐量比较大,而且Spark-Streaming位于Spark生态圈中,如果想要加入许多的附加功能,可以用Spark自己的组件就能够实现无缝对接,这一点是Storm无法相比的,因为Storm就是专门用于做实时处理的,其他功能的实现,肯定性能要差一些。
Q:Storm的配置需要注意什么问题?
A: yaml跟我们一般用的属性配置文件有所不同, 它的要求更严格一些,因此在往conf/storm.yaml中添加配置的时候必须注意,比如必须注意开始位置和冒号后面的空格, 否则配置不会生效。
Q:如何检查配置是否生效?
A:可以使用命令:
storm localconfvalue
配置关键字,但是这个命令只能在nimbus上生效 。
Q:如何关闭nimbus相关进程?
A:可以使用以下命令:
kill `ps aux | egrep '(daemon\.nimbus)|(storm\.ui\.core)' |fgrep -v egrep | awk '{print $2}'`
Q:安装jzmq 时遇到cannot access org.zeromq.ZMQ 的make 错误,具体的错误信息如下:
error: cannot access org.zeromq.ZMQ class file fororg.zeromq.ZMQ not found
javadoc: error - Class org.zeromq.ZMQ not found.
A:解决方法:手动编译,然后重新make 即可通过:
cd src
javac -d . org/zeromq/*.java
cd ..
Q:如何理解spout/bolt的生命周期?
A:一般来说spout/bolt的生命周期如下:
1 、在提交了一个topology之后(在nimbus所在的机器),创建spout/bolt实例(spout/bolt在storm中统称为component)并进行序列化;
2、将序列化的component发送给所有的任务所在的机器;
3、在每一个任务上反序列化component;
4、在开始执行任务之前, 先执行component的初始化方法(bolt是prepare, spout是open);
因此component的初始化操作应该在prepare/open方法中进行,而不是在实例化component的时候进行。
Q:如何将Storm与Spring框架集成?
A:在进行Storm与Spring集成时,需要对Storm的spout和bolt的生命周期按照上个问题那样理解清楚。这样的话就会知道,component的初始化操作应该在prepare/open方法中进行,而不是在实例化component的时候进行.按照这种说法进行改造,结构该问题消失了。但接下来可能会有新的问题:
Caused by: org.xml.sax.SAXParseException: Content is not allowedin prolog.
这个异常是由于*.xml文件编码的问题。原因是在从其他项目里或者编辑工具编辑时,在文件编码中加入了BOM头的原因,于是用notePad++打开xml文件选择去掉BOM头信息,重新进行保存即可。
Q:在使用了storm一段时间后,需要重新部署storm的集群,主要是想将storm部署在其它机器上。做了以下错误操作:
1) 没有kill 正在运行的topology,kill nimbus和supervisor的storm进程
2) 删除了配置中"storm.local.dir"的文件夹内的内容
3) 启动storm nimbus
系统报错,如何解决?
A:因为没有先killtopology,所以在启动nimbus时,zookeeper中依然保留了上次运行着的topology的信息,解决办法如下:
用zookeeper的zkCli.sh清理一下,直接重装了zookeeper。但是据说在storm0.6.1中已经解决了该bug。
Q:在配置文件storm.yaml中,有:
# to nimbus nimbus.childopts: "-Xmx1024m" # to supervisor supervisor.childopts: "-Xmx1024m" # to worker worker.childopts: "-Xmx768m"
那么,如何配置JVM参数呢?
A:如果worker在运行时,需要用指定的JVM参数,那么可以像这样配置:
worker.childopts: "-Dworker=worker -Xmx768m -Xdebug –Xnoagent-Djava.compiler=NONE-Xrunjdwp:transport=dt_socket,address=8111,suspend=y,server=y"
Q“java.lang.NoClassDefFoundError: clojure.core.protocols$”故障如何解决?
A:故障的原因是因为JDK版本不匹配,安装虚拟机时系统会自带一个jdk.1.5.0。解决办法是检查JDK版本,卸载系统自带的JDK,使用自己安装的JDK版本。
#rpm –qa | grep java # rpm –e –nodeps java-*
配置环境变量
vi /etc/profile
重新执行一遍即可。