《Storm Applied》书评与作者访谈

最新推荐文章于 2024-10-06 09:56:58 发布

原创最新推荐文章于 2024-10-06 09:56:58 发布 · 64 阅读

CC 4.0 BY-SA版权

文章标签：

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所有格式。