《Storm Applied》书评与作者访谈

我们很早很早就是Storm的使用者了。在我们组织中，Storm从一个在少数不必要的流程中使用的 工具 发展成为我们基础结构中很大的一部分，并推动数个基本业务流程。在这个转换过程中，我们觉得通过在“生产”环境中运行Storm，我们学到了很多来之不易的知识。

虽然互联网在线上有许多关于Storm的使用文件，但是，我们并不觉得那些是实用的、经验驱动的建议。我们写这本书的主要动机是想分享我们的经验，希望让人们避免一些我们遇到的陷阱。

我们觉得这本书真的迎合广大受众：从刚刚接触学习Storm的初学者到那些希望从本书中针对某一特定问题寻求答案的Storm高级用户。我们写这本书最初希望的读者是那些更高级的用户，然而，当叙述章节时，我们发现很有必要建立对Storm核心概念的深刻理解。基于这个原因，我们认为那些对Storm几乎没有经验的人可以拿起本书，在前面的章节中找到价值。更高级的用户应该能够在后面的章节中找到价值。所以，任何对大数据技术，尤其是流处理系统感兴趣的人都会发现这本书的价值。

在大多数情况下，我们不认为这是一个特别负责任的问题。有很多工作在“大数据”空间进行着，任何一个特定的项目产生的影响都是很难知道的。除非一个项目完结，就像Heron和Hailstorm，名字检查Storm主要是凭空猜测。我们会轻松的宣称，我们认为根据开发人员的共识，Storm在突出流处理上发挥了很大的作用。

对于流处理而言，没有什么选择是正确的。正如与工程相关的事情，这是一个权衡的问题。我们认为Storm对于那些刚刚接触流处理的人而言是一个很好的选择。它提供了大量你想要的特性（容错性、可靠性、通过用户界面的可视化等）。当你使用Storm时，它也会促使你思考在一个流处理器中你需要什么和不需要什么（哪些地方Storm符合/不符合你的需要，哪些地方Storm增加了额外的复杂性，而你不需要这些，等等）。一旦你知道了这些，你就可以做出明智的决定：坚持使用Storm、使用另一个处理器或者自己编写一个。

由于篇幅和时间的限制，我们忽略了一些主题。能够想到的几个这样主题是：用不同的语言测试和使用Storm。

我们觉得可以把一整个章节专门用来描述测试，但是，有太多我们想覆盖的主题了。在本书的示例代码中，我们尽力提供一些测试Storm拓扑的案例。

能够使用不同的编程语言编写Storm这一特性，吸引着许多人。但是考虑所有情况之后，我们希望专注于Storm本身，而不是它所使用的语言，因此我们决定使用Java编程。我们实际使用Scala语言编写大多数我们自己的Storm拓扑，所以我们当然理解当我们决定在书中坚持使用一种编程语言时大家的失望情绪。

自从Storm诞生后，其核心概念几乎就没有改变过，这对于Storm来说是相当不错的。它允许我们继续以一致的方式构建拓扑。至于Storm的实际改变，浮现在我脑海中的一些改进是：更快的内部队列系统、改善了的度量指标收集能力、在Storm用户界面更好的可视化效果和整体稳定性的提升。

自从Storm2011年开源以来，我们认为有件事毫无疑问的改变了，那就是Storm获得了一般社区的支持。Storm拥有比以往更大的社区。这些以及技术、项目和以Storm方式使用而建立的框架的数量，是最让我们兴奋的。

我们认为Storm急需要改善的方面记载在Twitter最初的博客文章中和随后有关 Heron 的论文中。我们会得出和他们所做的一样的结论，并指明：在Storm内部解决它们将会是一件劳神费力的事情。在那篇论文中由Twitter确认的一系列问题都是跟规模有关的问题。大多数人不会遇到其中的一些问题。因为大多数人不会建立一个会被Storm的延迟问题所干扰的系统。如果他们这么做了，那么他们最好是重新着手另外一个系统。

我们认为，在Heron论文中确认的#1问题是可调试性问题，并且是每个使用Storm的开发者都会遇到的问题。当你在JVM上执行多个线程，这些线程是Storm拓扑的一部分时，他们都记录在同一个日志文件内，真的很难拼凑出它的处理过程。Twitter提出了这个问题的解决方案，在Heron论文中有详细论述（每个JVM一个线程）。我认为那仅仅解决了Storm可调试性问题的一部分。它同样很难通过拓扑从单个始发消息跟踪数据的转移，理解整个过程的每种转换。内置的端对端的跟踪工具会是一个很好的办法。虽然我们还不确定那会是什么样子，但是，这是我们乐意看到的结果。

如果你是对性能敏感的开发者，那么你应该马上在你的清单上划掉Trident。因为使用基础Strom基元将会获得更好的性能。如果你正在寻找“恰好一次”的处理方式，那么Trident可能会是你想要的。它不会豁免你理解“恰好一次”在一个分布式系统中代表的意义，但是它可以帮助你开始。Spark流占据了类似Trident的空间，相对于微批量及流处理，如果你对微批量及批量处理感兴趣，那么你应该选择Spark而不是Storm

假设在Heron开源的环境下，Storm将会因此失去一部分开发人群。设计Henron的初衷就是为了解决Storm的一些不足之处，同时它又是API兼容的，所以将会吸引那些考虑切换的开发人群。即便如此，Storm已经是一头复杂的野兽充斥着你的大脑，而Heron通过需要Mesos又增加了额外复杂的一层。我们可能是错的（因为只有有限的信息），但是在运行上，Heron似乎比Storm更上一层。它承诺简化调试，而这平衡了上面的不足，但是对此我持有怀疑。因为对大多数人来说，需要使用Mesos本身就是一大障碍

最近Yahoo对Storm的支持增加了一倍，因此我们很容易把Storm和Heron拿来比较，推测Storm的未来，所以我认为可以有把握的说，现在我们真的不知道他们各自的优缺点会是什么。

Storm的很多大量工作使其为“企业就绪”做好了准备，而这些并没有在Heron博客文章和论文中提及。我猜测，Storm将会有一个较大的领导优势。最后，就回到了哪个项目运作的更好，能够吸引更好的社区。开源项目的存亡通常立足于围绕它们周围而建立起来的社区，这些社区通常是人而不是与技术相关的东西。