Question

我们正在评估为部署而追求Storm，但我有点担心。我们目前运行Hadoop MapReduce，并希望将我们的一些处理从MapReduce转换为Storm进程。请注意，这是一些，但不是全部。我们仍然会有一些MapReduce功能。

我找到了Mesos，它可能（可能）允许我们在同一硬件上维护Storm和Hadoop部署，但还有其他一些问题：

我设想理想的情况是能够随意“借用”Storm和Hadoop之间的插槽。恩。两者都会根据需要使用相同的资源。不幸的是，这是一个固定的部署，并不像EC2那样“基于云”。
我想避免在Storm环境中遇到瓶颈。一个理想的情况是根据需求“旋转”（或反向）螺栓的更多实例。这可能/现实吗？
“重新启动”拓扑似乎是一项相当昂贵的操作，而且我不确定它是否真的是一种选择。理想情况下，我希望它尽可能无缝。

我们是否正确处理此问题？从本质上讲，Storm拓扑将“提供”MapReduce批处理作业。我们的一些处理可以以流方式处理，并且作为Storm拓扑会更好，而其中一些需要批量处理。

任何一般性反馈，即使它没有解决我的具体问题，也会受到欢迎。在这一点上，这更像是一个探索阶段，我可能会以错误的方式接近这一点。

Answer 1

一些想法，以及我迄今为止进行类似实验的经验（在Sprint期间通过Sprint工作）：

根据我的经验（我可能是错的），随着需求的增加，你并没有真正地增加螺栓，而是调整拓扑中每个螺栓的并行配置。拓扑不是通过添加更多螺栓来缩放的，而是通过增加并行性来缩放，因为任何螺栓都是瓶颈。以示例字数问题：

builder.setBolt(4, new MyBolt(), 12)
    .shuffleGrouping(1)
    .shuffleGrouping(2)
    .fieldsGrouping(3, new Fields("id1", "id2"));

最后一个参数（“12”）是该螺栓的平行度。如果它是拓扑中的瓶颈而您需要扩展以满足需求，那么您可以增加这一点。 12的并行性意味着它将导致12个线程在风暴群集中并行执行螺栓。

builder.setBolt（new MyBolt（），3） .setNumTasks（64） .shuffleGrouping（ “someSpout”）;

此处，MyBolt()的执行程序（线程）数为3，您可以动态更改线程数而不会影响拓扑。 storm rebalance用于此：

$ storm rebalance someTopology -n 6 -e mySpout=4 -e myBolt=6

这会将“someTopology”拓扑的工作者数量更改为6，将mySpout的执行者/线程数量更改为4，将myBolt的执行者/线程数量更改为6。

听起来您的风暴拓扑将处理流数据。需要批处理的数据将在持久保存到您正在使用的任何数据存储（HDFS）后启动。在这种情况下，您可以使用螺栓包装来为数据存储区执行持久性以获取所需的任何数据。
另一方面，如果您希望在已有的任何数据存储区（并保持有状态）之上进行某种增量处理，请使用Trident（https://github.com/nathanmarz/storm/wiki/Trident-tutorial）。三叉戟实际上可能会解决你遇到的很多问题。