浅谈Storm流式处理框架

　　的高吞吐，海量数据处理的能力使得人们可以方便地处理海量数据。但是，的缺点也和它的优点同样鲜明——延迟大，响应缓慢，运维复杂。

　　有需求也就有创造，在Hadoop基本奠定了大数据霸主地位的时候，很多的开源项目都是以弥补Hadoop的实时性为目标而被创造出来。而在这个节骨眼上Storm横空出世了。

　　带着流式计算的标签华丽丽滴出场了，看看它的一些卖点：

　　分布式系统：可横向拓展,现在的项目不带个分布式特性都不好意思开源。

　　运维简单：Storm的部署的确简单。虽然没有Mongodb的解压即用那么简单，但是它也就是多安装两个依赖库而已。

　　高度容错：模块都是无状态的，随时宕机重启。

　　无数据丢失：Storm创新性提出的ack消息追踪框架和复杂的事务性处理,能够满足很多级别的数据处理需求。不过，越高的数据处理需求，性能下降越严重。

　　多语言：实际上，Storm的多语言更像是临时添加上去似的。因为，你的提交部分还是要使用Java实现。

　　一.Storm简介

　　是一个免费开源、分布式、高容错的实时计算系统。令持续不断的流计算变得容易，弥补了Hadoop批处理所不能满足的实时要求。经常用于在实时分析、在线机器学习、持续计算、分布式远程调用和ETL等领域。的部署管理非常简单，而且，在同类的流式计算工具，的性能也是非常出众的。

　　主要分为两种组件Nimbus和Supervisor。这两种组件都是快速失败的，没有状态。任务状态和心跳信息等都保存在Zookeeper上的，提交的代码沈阳app开发

　　负责在集群里面发送代码，分配工作给机器，并且监控状态。全局只有一个。

　　会监听分配给它那台机器的工作，根据需要汇海/关闭工作进程Worker。每一个要运行Storm的机器上都要部署一个，并且，按照机器的配置设定上面分配的槽位数。

　　是Storm重点依赖的外部资源。Nimbus和Supervisor甚至实际运行的Worker都是把心跳保存在上的。Nimbus也是根据Zookeerper上的心跳和任务运行状况，进行调度和任务分配的。

　　提交运行的程序称为Topology。

　　处理的最小的消息单位是一个Tuple，也就是一个任意对象的数组。

　　由Spout和Bolt构成。Spout是发出Tuple的结点。Bolt可以随意订阅某个Spout或者Bolt发出的Tuple。Spout和Bolt都统称为component。

　　虽然，有些地方做得还是不太好，例如，底层使用的ZeroMQ不能控制内存使用(下个release版本，引入了新的消息机制使用netty代替ZeroMQ），多语言支持更多是噱头，Nimbus还不支持HA。但是，就像当年的Hadoop那样，很多公司选择它是因为它是唯一的选择。而这些先期使用者，反过来促进了Storm的发展。

　　二.Storm发展

　　已经发展到0.8.2版本了，看一下两年多来，它取得的成就：

　　有50个大大小小的公司在使用Storm，相信更多的不留名的公司也在使用。这些公司中不乏淘宝，百度，Twitter，Groupon，雅虎等重量级公司。

　　从开源时候的0.5.0版本，到现在的0.8.0+，和即将到来的0.9.0+。先后添加了以下重大的新特性：

　　使用kryo作为Tuple序列化的框架（0.6.0）

　　添加了Transactional topologies（事务性拓扑）的支持（0.7.0）

　　添加了Trident的支持（0.8.0）

　　引入netty作为底层消息机制（0.9.0）

　　和Trident都是针对实际应用中遇到的重复计数问题和应用性问题的解决方案。可以看出，实际的商用给予了Storm很多良好的反馈。

　　在GitHub上超过4000个项目负责人。Storm集成了许多库，支持包括Kestrel、Kafka、JMS、Cassandra、Memcached以及更多系统。随着支持的库越来越多，Storm更容易与现有的系统协作。Storm的拥有一个活跃的社区和一群热心的贡献者。过去两年，Storm的发展是成功的。

 1/2    1 2 下一页 尾页