spark分发策略
storm中存在着多种分发策略,以便我们根据自身的需求进行选择。storm的Grouping分发策略是控制着它的数据上游的分发策略。
接下来我们对每一种分发策略进行介绍:
Storm Grouping – 数据流分组(即数据分发策略)
-
ShuffleGrouping (轮询分发)
随机分组,随机派发stream里面的tuple,保证每个bolt task接收到的tuple数目大致相同。
轮询,平均分配
举个例子:领导有三个手下,分别是A,B,C。当任务过来的时候,会按照ABCABCABC…这样的顺序将任务分发下去,我们也将shuffleGrouping称为轮询分发 -
FieldsGrouping(按字段分发)
按字段分发,比如,按"user-id"这个字段来分组,那么具有同样"user-id"的 tuple 会被分到相同的Bolt里的一个task, 而不同的"user-id"则可能会被分配到不同的task。
这个和我们的mapreduce一样,相同的键值由同一个bolt去解决。
举个例子:领导有三个手下,分别是A,B,C。当任务过来的时候,会把A擅长做的事情交给A,B擅长做的事情交给B,C擅长做的事情交给C, -
AllGrouping
广播发送,对于每一个tuple,所有的bolts都会收到
这个很简单,就是将数据给每个bolit都全量发送,一般不用 -
GlobalGrouping
全局分组,把tuple分配给task id最低的task 。这个可以实现高可用的功能。相当于,我们一开始把任务都交给taskid最低那个bolt去做,这个bolt如果哪天蹦了,就让第二个bolt工作。 -
None Grouping
不分组,这个分组的意思是说stream不关心到底怎样分组。目前这种分组和Shuffle grouping是一样的效果。 有一点不同的是storm会把使用none grouping的这个bolt放到这个bolt的订阅者同一个线程里面去执行(未来Storm如果可能的话会这样设计)。 -
Direct Grouping
指向型分组, 这是一种比较特别的分组方法,用这种分组意味着消息(tuple)的发送者指定由消息接收者的哪个task处理这个消息。只有被声明为 Direct Stream 的消息流可以声明这种分组方法。而且这种消息tuple必须使用 emitDirect 方法来发射。消息处理者可以通过 TopologyContext 来获取处理它的消息的task的id (OutputCollector.emit方法也会返回task的id) -
Local or shuffle grouping
本地或随机分组。如果目标bolt有一个或者多个task与源bolt的task在同一个工作进程中,tuple将会被随机发送给这些同进程中的tasks。否则,和普通的Shuffle Grouping行为一致。
我们如果数据量很大,需要配置多线程来进行处理。可是如果线程多的话,需要多个jvm一起运行。这个local shuffle意思就是说为了避免jvm之间数据交换造成的开销,我们尽可能让同一个jvm的tuple分发给同一个jvm的bolt -
customGrouping
自定义,相当于mapreduce那里自己去实现一个partition一样。