Java ApacheStorm：使不可伸缩的资源可伸缩

我最近开始向大数据世界介绍自己，并尝试使用ApacheStorm。我曾经面对过以下问题，想了很多如何解决它，但我所有的方法似乎都很幼稚

技术 Apache Storm 0.9.3，Java 1.8.0_20

上下文 需要逐行读取一个大的xml文件（~400MB）（xml文件喷口）。然后，每个读取文件行由一系列螺栓发出和处理

它必须是有保证的消息处理（通过锚定发出…）

问题 由于文件相当大（包含大约200亿行），我使用扫描仪读取它，基于缓冲流，而不是将整个文件加载到内存中。到现在为止，一直都还不错。当处理过程中的某个地方出现错误时，这个问题就出现了：XML文件喷口本身已经死亡，或者存在一些内部问题…p>

Nimbus将重新启动喷口，但整个处理从一开始就开始

这种方法根本无法扩展

解决思路 解决第一个问题的最初想法是将当前状态保存到某个地方：分布式缓存、JMS队列、本地磁盘文件。当喷口打开时，它应该找到这样的存储，读取状态并从指定的文件行继续。在这里，我还考虑将状态存储在Storm的Zookeeper中，但我不知道是否有可能从喷口处寻址Zookeeper（有这样的能力吗）？你能建议一下这方面的最佳做法吗

对于问题2，我考虑将初始文件分解为一组子文件，并并行处理它们。这可以通过引入一个新的“断开”喷口来实现，在这里，每个文件都将由一个专用的螺栓进行处理。在这种情况下，保证处理会出现大问题，因为在出现错误的情况下，必须完全重新处理包含失败行的子文件（喷口的确认/失败方法）。。。你能建议解决这个问题的最佳方法吗

更新 好的，到目前为止我做了什么

先决条件

以下拓扑之所以有效，是因为它的所有部分（喷口和螺栓）都是幂等的

引入了一个单独的喷口，它可以读取文件行（一个接一个）并将它们发送到中间ActiveMQ队列（“文件行队列”），以便能够轻松地重放失败的文件行（请参阅下一步）

为“文件行队列”队列创建了一个单独的喷口，用于接收每个文件行并将其发送到后续队列。就我所使用的保证消息处理而言，如果任何螺栓出现故障，则会重新处理消息，如果螺栓链成功，则会确认相应的消息（客户端确认模式）

在第一个（文件读取）喷口失败的情况下，将引发RuntimeException，从而终止喷口。稍后，一个专门的主管会重新启动喷口，重新读取输入输出文件。这将导致重复的消息，但只要一切都是幂等的，这就不是问题。此外，这里值得考虑使用状态存储库来生成较少的副本

新发行的

为了使中间JMS更可靠，我添加了一个on exception侦听器，用于恢复使用者和生产者的连接和会话。问题是消费者：如果一个会话被恢复，并且在一个成功的处理过程中，我有一个JMS消息未被攻克，在成功的处理之后，我需要对它进行确认，但是只要会话是新的，我就接收到“找不到相关ID”的问题。p>

---

有人能建议如何处理吗？

首先回答您的问题：

是的，您可以将状态存储在Zookeeper之类的地方，并使用类似的库来处理它

分解文件可能会有所帮助，但仍然无法解决必须管理状态的问题

让我们在这里谈一谈设计。Storm是为流媒体而构建的，不是为批量而构建的。在我看来，对于批处理来说效果更好的Hadoop技术在这里会更好：MapReduce、Hive、Spark等等

---

如果您打算使用storm，那么它将有助于将数据流传输到更容易使用的地方。您可以将文件写入Kafka或队列，以帮助解决管理状态、确认/失败和重试的问题。

Hello Kit Menke。谢谢你的回答。我将使用一些中间件构建一个体系结构，以解耦难以维护的文件数据源，并在文件行处理出错时易于重放。是的，第一个想法是使用JMS，但这里的问题是可能会使JMS队列过载。我可以尝试使用xml文件喷口（作为生产者）和JMS中间件（作为消费者）之间的java阻塞队列来阻止它，但是有没有针对它的最佳实践（可能不仅仅是使用JMS…）？一种常见的模式是kafka->storm->hbase。是的，队列过载是一个问题，但无论如何，您都需要对此进行说明。写入队列的应用程序需要能够处理“队列已满”错误，并且您需要确保storm能够处理负载。