《Storm Applied》书评与作者访谈_Book Review_Sergio De Simone



 写点什么

Storm 是一个分布式、容错的实时计算系统，最初由 BackType 开发，后来 Twitter 收购 BackType 后将其开源。《Storm Applied》是Manning 出版有限公司出版的一本新书，旨在向开发人员提供一本无论是在开发或者生产环境中使用Storm 的实用指南。InfoQ 访问了本书的两位作者Sean T. Allen 和Matthew Jankowski。

《Storm Applied》描述了Storm 如何用于数种不同的用例。前四个章节介绍了Storm 的核心概念：spouts、bolts、topology、processing guarantees 等等。接着本书详细描述了什么是集群，包括其组件、其容错的作用以及如何在集群中部署一个给定的拓扑（topology）。第六和第八章节的内容对在生产环境中相当有价值以及有关处理Storm 拓扑调优、度量指标收集、资源冲突和调试技术的内容。最后，第九章节涵盖了Trident 引擎，一个建立在Storm 之上更高级别的抽象，目的是为了使建立和使用Storm 拓扑更加容易。

书中的大部分章节都呈现了这样的具体用例：提供必要的语境，使在讨论Storm 的特性时使其更加的具体和容易理解。此外, 书中也提供了在Java 环境下的一个参考实现。作者利用这些用例逐步引入流处理系统中的新概念和典型顾虑, 比如如何处理不可靠的数据源，如何通过并行化、可靠性、消息回顾等手段识别和解决瓶颈问题。

总体而言，由于作者采用的是循序渐进的叙述方式，同时也提供了许多图表帮助说明Storm 的基本概念，所以本书的内容很容易理解。甚至在不需要Storm 或者流处理相关知识的前提下，本书仍然成功的诠释了一些复杂话题，比如规模（scale）、调优、调试。本书很注重主题的严谨性，所以本书的内容仍然简洁精炼。

InfoQ 访问了本书的两位作者 Sean T. Allen 和 Matthew Jankowski。

InfoQ: 促使您写这本书的主要动机是什么？

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

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

InfoQ: 哪些人群应该阅读你们的书本，他们能够从中学习到什么？

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

InfoQ: 目前，Storm 对高度可扩展、批处理或实时流处理系统的实现过程产生了哪些影响？

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

InfoQ: 是什么让 Storm 成为实时流处理正确的选择？

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

InfoQ: 出于一些考虑，比如篇幅、复杂性、内容过于深奥，书中您忽略了哪些主题？

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

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

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

InfoQ: 自从 2011 年开源后，Storm 是如何演变的？

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

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

InfoQ: 你认为 Storm 应该在哪些方面改进或提供额外的特性?

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

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

InfoQ: 你在书中用整整一章讲述了 Triden。你能简要的评论一下，在哪种典型的场景下，开发者将会用到 Trident？另一方面，在什么情况下只用 Storm，并在其上构建自己的抽象是一个明智的决定呢？

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

InfoQ: 最后，您是如何看待 Twitter 采用 Heron后，将会对 Storm 的未来产生什么样的影响?

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

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

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

可以使用优惠代码‘storm40iq’购买《Storm Applied》，将享受 4 折优惠——适用 manning.com所有格式 _。_