老卫带你学--spark修炼之路（3.spark分发策略）

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一样。