转自:http://qing.weibo.com/2294942122/88ca09aa33002dsh.html
EMC中国研究院 向东
提起Big Data,人们往往会提起大数据的4个V: Volume,Velocity , Variety 以及Value。这四个V从各个侧面说明了大数据并不是新瓶装旧酒: 面对数据产生来源,产生方式,处理方式等等一系列质变,原来适用的数据挖掘/BI工具已经不再满足实际需要,人们迫切需要新的计算模式,基础架构以及开箱即用的工具集来使自己的业务运行的更好。这也是当前大数据如此火热的原因。
流处理(Stream Processing) 或者复杂事件处理(CEP,complex event processing) 也不是一个新概念,对此相关的研究和相应的产品已经有很多了,其中最有名的应该算开源CEP引擎Esper(http://esper.codehaus.org/)。 相对于原有的产品,现在的流处理新贵,比如来自Yahoo!的S4和来自Twitter的Storm,到底有哪些独到的长处,让人们趋之若鹜?
本文试图在Storm的基础上对此解读。
)这门极具潜力的函数式编程语言开发的,这也使得Storm格外引人注目。
@EMC中国研究院 版权所有
Grouping,Shuffle Grouping可以保证event在Boltinstance间随机分布,每个instance都收到相同数量的event。
Berkeley的SparkStreaming项目现在正在尝试挑战这一结论,感兴趣的同志请自行查看)。另一方面,人们对传统的CEP解决方案心存疑虑,认为其非分布式的架构可扩展性不够,无法scale out来满足海量的数据处理要求。这时候,Yahoo!的S4以及Twitter的Storm恰到好处的挠到了人们的痒处。
简单来说就是当一个集群的处理能力不够用的时候,只要往里面再追加一些新的节点,计算有能力迁移到这些新的节点来满足需要。可能的情况下,选择Scale out 而非Scale up,这个观念已经深入人心。一般来说,实现Scale out的关键是Shared nothing architecture,即计算所需要的各种状态都是自满足的,不存在对特定节点强依赖,这样,计算就可以很容易的在节点间迁移,整个系统计算能力不够用的时候,加入新的节点就可以了。Storm的计算模型本身是Scale out友好的,Topology
对应的Spout和Bolt 并不需要和特定节点绑定,可以很容易的分布在多个节点上。此外,Storm还提供了一个非常强大的命令(rebalance),可以动态调整特定Topology中各组成元素(Spout/Bolt)的数量以及其和实际计算节点的对应关系。
,Storm可以保证每个tuple“被且仅被处理一次”。@EMC中国研究院 版权所有
而Storm则给出了一个很好的实例。从另一个角度来说,Storm也能大大的推动Clojure的普及。
store的事实解决方案,Storm在设计时所做的这个折中相当不错。文档(http://xumingming.sinaapp.com/466/twitter-storm-code-analysis-zookeeper-dirs/)讨论了Storm到底保存了那些状态信息到Zookeeper中,可以详细参考。
task很类似,实际的数据处理发生在这里。 不同的是,map/reduce task 终究会结束,但worker则会一直执行下去。同样,Storm引入了WorkerSlot的概念,也就是说,slave节点上的worker的数量是有限的。
文档 (https://github.com/nathanmarz/storm/wiki/Understanding-the-parallelism-of-a-Storm-topology)详细解释了Topology是如何映射到Worker。简言之,这个过程涉及到了3个相关实体:
1. Worker。 一个完整的Topology是由分布在多个节点上的Worker进程来执行的,每个Worker都执行(且仅执行)Topology的一个子集。
2. Executor。在每个Worker内部,会有多个Executor,每个executor对应一个线程。
3. Task。执行具体数据处理的相关实体,也就是用户实现的Spout/Blot实例。Storm中,一个executor可能会对应一个或者多个task。这就是说,系统中executor的数量是小于等于task的数量的。
上述代码定义的Topology共有2个worker,BlueSpout/Green Bolt/Yellow Bolt各自的executor以及task的数量分别是 2/2/6以及2/4/6 (注:1. 如果没有显式的定义task的数量,Storm会默认其数量和component对应的executor数量相同 2. 实际在Storm中执行的Topology和用户定义的有稍许差别,系统会自动增加acker Bolt来保证消息能被处理)。此Topology被Storm执行时,可能的映射如下:
图五: Topology 映射
对于特定的Topology来说,其Task的数量在其整个生命周期是固定的,但是Worker/Executor的数量可以通过命令行和Web UI工具使用rebalance命令来调整。
总结
上文仅仅讨论了Storm系统层面简介优雅的设计保证其做到高可扩展性,高可用的。实际上,Storm的文档代码是一个宝库,值得研究的研究的地方很多,比如,确保消息会被完整处理的实现机制以及Transactional Topology的实现机制;再在比如ZMQ这个高性能的网络通信库是如何被集成的。任何对分布式计算以及大数据感兴趣的同志都应该深入的研究Storm,展望将来,Storm必将被更加广泛的接受的采纳。