Storm 简介
发布时间:
>>>>Storm简介
场景
伴随着信息科技日新月异的发展,信息呈现出爆发式的膨胀,人们获取信息的途径也更加多样、更加便捷,同时对于信息的时效性要求也越来越高。举个搜索场景中的例子,当一个卖家发布了一条宝贝信息时,他希望的当然是这个宝贝马上就可以被卖家搜索出来、点击、购买啦,相反,如果这个宝贝要等到第二天或者更久才可以被搜出来,估计这个大哥就要骂娘了。再举一个推荐的例子,如果用户昨天在淘宝上买了一双袜子,今天想买一副泳镜去游泳,但是却发现系统在不遗余力地给他推荐袜子、鞋子,>>>>根本对他今天寻找泳镜的行为视而不见,估计这哥们心里就会想推荐你妹呀。其实稍微了解点背景知识的码农们都知道,这是因为后台系统做的是每天一次的全量处理,而且大多是在夜深人静之时做的,那么你今天白天做的事情当然要明天才能反映出来啦。
实现一个实时计算系统
全量数据处理使用的大多是鼎鼎大名的hadoop或者hive,作为一个批处理系统,hadoop以其吞吐量大、自动容错等优点,在海量数据处理上得到了广泛的使用。但是,hadoop不擅长实时计算,因为它天然就是为批处理而生的,>>>>这也是业界一致的共识。否则最近这两年也不会有s4,storm,puma这些实时计算系统如雨后春笋般冒出来啦。先抛开s4,storm,puma这些系统不谈,我们首先来看一下,如果让我们自己设计一个实时计算系统,我们要解决哪些问题。
1.低延迟。都说了是实时计算系统了,延迟是一定要低的。2.高性能。性能不高就是浪费机器,浪费机器是要受批评的哦。
3.分布式。系统都是为应用场景而生的,如果你的应用场景、你的数据和计算单机就能
搞定,那么不用考虑这些复杂的问题了。我们所说的是单机搞不定的情况。4.可扩展。伴随着业务的发展,我们的数据量、计算量可能会越来越大,所以希望这个
系统是可扩展的。>>>>
5.容错。这是分布式系统中通用问题。一个节点挂了不能影响我的应用。
好,如果仅仅需要解决这5个问题,可能会有无数种方案,而且各有千秋,随便举一种方案,使用消息队列+分布在各个机器上的工作进程就ok啦。我们再继续往下看。1.容易在上面开发应用程序。亲,你设计的系统需要应用程序开发人员考虑各个处理组
件的分布、消息的传递吗?如果是,那有点麻烦啊,开发人员可能会用不好,也不会想去用。
2.消息不丢失。用户发布的一个宝贝消息不能在实时处理的时候给丢了,对吧?更严格
一点,如果是一个精确数据统计的应用,那么它处理的消息要不多不少才行。这个要求有点高哦。
3.消息严格有序。有些消息之间是有强相关性的,比如同一个宝贝的更新和删除操作消
息,如果处理时搞乱顺序完全是不一样的效果了。
不知道大家对这些问题是否都有了自己的答案,下面让我们带着这些问题,一起来看一看storm的解决方案吧。
>>>>Storm是什么
如果只用一句话来描述storm的话,可能会是这样:分布式实时计算系统。按照storm作者的说法,storm对于实时计算的意义类似于hadoop对于批处理的意义。我们都知道,根据googlemapreduce来实现的hadoop为我们提供了map,reduce原语,使我们的批处理程序变得非常地简单和优美。同样,storm也为实时计算提供了一些简单优美的原语。我们会在第三节中详细介绍。>>>>
我们来看一下storm的适用场景。
1.流数据处理。Storm>>>>可以用来处理源源不断流进来的消息,处理之后将结果写入到某
个存储中去。
2.分布式rpc。由于storm的处理组件是分布式的,而且处理延迟极低,所以可以作为一
个通用的分布式rpc框架来使用。当然,其实我们的搜索引擎本身也是一个分布式rpc系统。
说了半天,好像都是很玄乎的东西,下面我们开始具体讲解storm的基本概念和它内部的一些实现原理吧。
Storm的基本概念
首先我们通过一个storm和hadoop的对比来了解storm中的基本概念。>>>>>
系统角色
>>>>>HadoopJobTrackerTaskTrackerChild
应用名称组件接口
Job
Mapper/Reducer
StormNimbusSupervisorWorkerTopologySpout/Bolt
表3-1