Storm是Twitter开源的分布式实时大数据处理框架，被业界称为实时版Hadoop。随着越来越多的场景对Hadoop的MapReduce高延迟无法容忍，比如网站统计、推荐系统、预警系统、金融系统等， 大数据实时处理解决方案的应用日趋广泛，目前已是分布式技术领域最新爆发点，而Storm更是流计算技术中的佼佼者和主流。
1
Q：Storm原理及核心概念
A：分布式的实时计算系统，能够可信任的处理大量的流式数据，就好比Hadoop对于批量数据进行的处理一样；通常来说，Hadoop能够进行大批量数据的离线处理，但是在实时计算上的表现实在是不尽如人意；而Storm就可以担当这部分的作用。
说一下Storm一些核心概念：
2
Q：Storm有哪些特点？
A：编程简单：开发人员只需要关注应用逻辑，而且跟Hadoop类似，Storm提供的编程原语也很简单
高性能，低延迟：可以应用于广告搜索引擎这种要求对广告主的操作进行实时响应的场景。
分布式：可以轻松应对数据量大，单机搞不定的场景
可扩展：随着业务发展，数据量和计算量越来越大，系统可水平扩展
容错：单个节点挂了不影响应用
消息不丢失：保证消息处理
3
Q：Storm的基本架构
A：从网上找到的一张图，参照于Hadoop的架构，来理解其核心组件：
Nimbus：如上图，就好比Hadoop中的JobTracker，是集群中的主节点，负责分发用户代码，把需要处理的任务指派给具体的Supervisor，再由其上的Worker进行实际的处理。
Supervisor：集群中的从节点，负责管理机器上运行的Worker进程，这里，需要注意，worker是一个进程，其内部还可以启动多个线程来进行任务的处理；通常，我们再指定的时候，会在此处通过指定端口号，来指定机器上到底启动多少个worker。
Zookeeper：基本只要牵涉到集群，都需要用到zookeeper，这也符合其作为动物园管理员的职责，通过zookeeper，nimbus会感知到Supervisor的下线和上线，会合理分配资源，完成Topology的处理
Topology：这就好比我们平时提交的一个Application，只是换了一个名称而已。
4
Q：Storm的应用有哪些？
A：跟Hadoop不一样，Storm是没有包括任何存储概念的计算系统。这就让Storm可以用在多种不同的场景下：非传统场景下数据动态到达或者数据存储在数据库这样的存储系统里（或数据是被实时操控其他设备的控制器(如交易系统)所消费）
例如Nathan Marz提供的例子，产生Twitter的趋势信息。Twitter从海量推文中抽取趋势信息，并在本地区域和国家层级进行维护。这意味者一旦一个案例开始出现，Twitter的话题趋势算法就能实时的鉴别出这个话题。这个实时的算法就是通过在Storm上连续分析Twitter数据来实现的。
5
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就是专门用于做实时处理的，其他功能的实现，肯定性能要差一些。
