1、Storm简介
Storm
是Twitter开源的分布式实时大数据处理框架，最早开源于github，从0.9.1版本之后，归于Apache社区，被业界称为实时版Hadoop。随着越来越多的场景对Hadoop的MapReduce高延迟无法容忍，比如网站统计、推荐系统、预警系统、金融系统(高频交易、股票)等等，大数据实时处理解决方案（流计算）的应用日趋广泛，目前已是分布式技术领域最新爆发点，而Storm更是流计算技术中的佼佼者和主流。
2、Storm与hadoop对比
大部分读者应该都是在了解了hadoop的基础后，才研究storm。因此个人觉得通过比对的方式，读者可能更容易理解Storm与Hadoop的区别以及Storm的应用场景。
2.1 应用场景对比
Storm： 分布式实时计算，强调实时性，常用于实时性要求较高的地方
Hadoop:分布式批处理计算，强调批处理，常用于对已经在的大量数据挖掘、分析
具体来说，Hadoop擅长于分析统计大批量的数据，在hadoop权威指南中，指出：
MapReduce的设计目标是服务于那些只需要数分钟或者数小时既可以完成的作业
。例如有这样的案例，美国国家气候中心使用hadoop分析统计1901年到2001年的气象数据，统计出气温最高的年份。实际上这里已经体现出了hadoop处理数据的一个特点：对于已经存在的大量数据进行统计分析。这种特性注定了hadoop是高延迟的，即使我们在几秒中内可以算出结果，但是还是不够实时。假设我们要将统计分析的结果直接显示给数以千万计的普通用户，普通用户是无法忍受几秒中后才得到返回结果的。但是这并不是说hadoop没用，对于公司的运营人来说，这个时间是可以忍受的。例如本人所在公司目前每天大概收集1亿条的用户行为数据，每天晚上都会由定时hadoop任务来分析统计这些数据，运营人员基本上都是第二天来看结果。当然，案例并不止这一个。目前本人所在公司的云计算管理中心调度接近2000个hadoop任务。
而storm同样是一个大数据处理框架，与hadoop不同的是，
storm不是批量处理已经存在的大量数据，而是实时计算每一条数据
。例如，一个促销活动，假设首页上有100种商品，同时有几亿用户访问。运营者就需要实时统计每种商品的点击率，如果在一段时间内，某种商品的访问量太低，就应该使用其他商品替换这个商品。因为在促销中，首页上的商品位置资源是比较稀缺的，如果一个商品长时间没多少人访问，应该让更有价值的商品来放在这个位置上。而因为用户量太大，商品太多，可能几分钟内就能产生几亿甚至几十亿的点击数据。如果让hadoop来处理的话，批量处理这些数据的时间较长，可能几分钟甚至更长时间才能算出结果。这明显是不合适的。如果我们使用是storm的话，就可以实时的统计出最新点击率，从而不会让一个没人访问的产品在一个重要的位置上占据过长时间。
总结：
hadoop和storm擅长处理的方面不同。经常在网上看到一些对于大数据处理框架到底是使用hadoop还是storm的讨论，个人认为这要根据实际情况而定，如果需要分析统计大量的数据，且对实时性要求不高就使用hadoop；如果实时要求高，且数据量大的话，还是要使用storm。本人有一个理解，有点片面，但在某种程度上也反应了一些问题：hadoop更像是为公司运营管理人员服务的大数据框架，因为这类用户为了查看统计数据通常是可以忍受高延迟的；storm更像是为普通用户服务的大数据框架，因为我们通常会使用storm计算出的实时数据，及时的展现给用户不同的信息，从而影响用户的行为。之所以说片面，是因为storm并不完全只对普通用户服务，对于一些比较重要的数据，可能公司运营者也想看到实时数据，例如双11大屏幕上显示的实时成交额，可能与普通用户无关，但是运营者非常关心，可能也会使用storm来做实时统计。