【问题标题】:Storm parallel understandingStorm并行理解
【发布时间】:2015-11-27 02:24:07
【问题描述】:

我已经阅读了有关风暴并行的相关资料,但仍有一些不清楚的地方。假设我们以 Tweets 处理为例。一般来说,我们正在做的是检索推文流,计算每条推文的字数并将这些数字写入本地文件。

我的问题是如何理解 spout 和 bolts 的并行性的价值。在 builder.setSpout 和 builder.setBolt 的函数中,我们可以分配并行值。但是在推文的字数统计中,只设置一个 spout 是否正确?多个 spout 被视为第一个相同 spout 的副本,相同的推文通过该 spout 流入多个 spout。如果是这种情况,设置多个 spout 的价值是什么?

另一个不清楚的点是如何将作品分配给螺栓?以 Storm 的方式实现的并行机制是否会找到当前可用的螺栓来处理下一个发射喷口?我修改了基本的推文计数代码,因此最终的计数结果将写入特定目录,但是,所有结果实际上都合并在 nimbus 上的一个文件中。因此,在主管处理数据后,所有结果都将发送回 nimbus。如果这是真的,nimbus 和 supervisor 之间的通信机制是什么?

我真的很想弄清楚那些问题!!!感谢您的帮助!

【问题讨论】:

  • 我不明白你的最后一个问题:“我修改了基本的推文计数代码,因此最终的计数结果将写入特定目录,但是,所有结果实际上都合并在 nimbus 上的一个文件中. 因此,在supervisors上处理完数据后,所有结果都会被发送回nimbus。如果这是真的,nimbus和supervisors之间的通信机制是什么?"

标签: parallel-processing apache-storm


【解决方案1】:

为大于 1 的 spout 设置并行度,需要用户代码为不同的实例执行不同的操作。否则(正如您已经提到的),数据只会通过拓扑发送两次。例如,你可以有一个你想监听的端口列表(或者一个不同的 Kafka 主题列表)。因此,您需要确保不同的实例监听不同的端口或主题......这可以通过查看拓扑元数据(如自己的任务 ID 和 dop)在open(...) 方法中实现。由于每个实例都有一个唯一的 ID,您可以对端口/主题进行分区,以便每个实例从整个列表中选择不同的端口/主题。

关于并行性:这取决于将拓扑连接在一起时使用的连接模式。例如,使用shuffleGrouping 会导致您发出的元组循环分配到使用螺栓实例。对于这种情况,Storm 不会“查看”是否有任何螺栓实例可用于处理。如有必要,元组只是在接收器处传输和缓冲。

此外,Nimbus 和 Supervisor 仅交换元数据。它们之间没有数据流(即元组流)。

【讨论】:

  • 我想我明白设置spout并行度的第一点了。感谢您提到 shuffleGrouping 方法,我没有意识到在这种情况下,storm 不会寻找可用的螺栓进行处理。我将检查其他分组方法。关于我的第二个问题,我正在做的是在螺栓中它将处理结果写入特定目录,如 /home/storm/Results.txt。昨天我以为supervisor机器上的处理结果也会被发送回nimbus机器上的Results.txt文件。
  • 我不确定 nimbus 机器如何从主管机器中的螺栓获得最终处理结果。
  • Storm 没有提供您喜欢的负载平衡连接模式。为什么你认为 shuffleGrouping 对你不起作用?
  • Nibmus 不会从 bolts 接收任何数据。您需要自己在沉没螺栓中处理最终结果...
  • 是的。它将是执行 sink bolt 的主管本地的。
【解决方案2】:

在某些情况下,例如“Kafka 的消费者组”,您有队列行为 - 这意味着如果一个消费者从队列中读取,另一个消费者将从队列中读取不同的消息。 这会将队列中的读取负载分配给所有工作人员。 在这些情况下,您可以从队列中读取多个喷口

【讨论】:

  • 所以我们可以把它看成一个生动的场景,像实时推文这样的恒定来源扮演着水池的角色,而喷口扮演着管道的角色。这里的并行机制是我们希望在单位时间内抽出更多的水,因此需要多个喷嘴来处理它们。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2015-07-07
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多