Storm创始人Nathan Marz：反馈即一切

**摘要： **Nathan Marz是分布式容错实时计算系统Storm的创始人。在2011年7月Twitter收购社交媒体数据分析公司BackType前，他是BackType首席工程师。2013年3月，他选择离开Twitter，创立了属于自己的公司。

关于个人经历

《程序员》：你何时开始学习编程，编写的第一个有趣的程序是什么？

Nathan：我十岁那年开始在自己的TI-82图形计算器上写程序。原因是我想在它上面开发游戏，也是因为那时我在数学课上感到太无聊了。我在计算器上写出的头一个有趣的程序是款射箭游戏——玩家向移动的目标发射箭头，命中的目标越多，或任务完成得越快，都能得到更多分数。几年后，当我毕业时，就在TI-89上写程序了。它的性能要强大多了，我还记得TI-82只允许用户使用26个变量（从字母“a”到字母“z”），而TI-89随便你想拥有多少变量都可以，想一想真是太了不起了。

《程序员》：作为程序员，你如何不断提高自己的技能？ Nathan：通过大量实践和不断尝试新事物，我的程序写得越来越好。成为优秀程序员的最佳途径之一，就是学习新的编程语言。所谓“学习”，并非单纯了解这门语言的语法，而是掌握它的习惯用法，并用学到的语言写出切实的应用。对我而言，学习Clojure，让我在使用所有其他语言编程时也都大获提高。

《程序员》：请谈谈你加入BackType前的经历。 Nathan：我从美国斯坦福大学获得了计算机科学学士和硕士学位，主攻软件理论。也因此完成了许多有关算法和验证方面的研究。不过在斯坦福，我做过最得意的事，可能要数我没怎么根据专业方向挑选课程，而是依据教授来选。当我发现某教授是位好老师，就会尽量完成所有由他主讲的课程。 举例来说，Tim Roughgarden教授是我遇见过的最好的老师之一，跟随他，我研习了一系列有关“算法博弈论”方面的科目——这一领域是经济学与计算机科学的交叉点。我选择这一系列课程，并非为了掌握课堂本身所讲述的知识，而是为了提高自己解决问题的能力。Roughgarden教授对于将极其艰深的问题分解，使之易于理解，有一套难以置信的连贯而规律的方法。学到这些本领，令我在解决所有领域的难题时都获益匪浅，对于将不同概念关联起来受益良多。

《程序员》：你曾说，离开Twitter是一个艰难的决定，能否谈谈你为何最终还是决定创立自己的公司？ Nathan：在Twitter，我所处的环境无可挑剔，拥有一整队人马全职投身由我创立的项目。然而一想起创建自己的公司这个念头，我就被它推动着不能自已。于是我意识到，若不在此时创立这家公司，将抱憾终生。

《程序员》：BackType和Twitter的这段经历让你学到了什么？ Nathan：反馈即一切。绝大多数时刻，你做出的是错误决定，只有反馈能令人意识到问题所在，并帮你少犯错。这一原则是普适的。在产品开发中，需要尽快将其呈现出来，之后才能收集反馈，看看究竟何处可行，哪里又行不通。不过许多时候，你甚至不需要创建真实的产品——一个有关“新特性”的问卷页面链接，就足以为你收集反馈，进而验证自己的想法。 管理团队，在所有流程中收集反馈也极为重要。在BackType，我们曾每月召开例会讨论流程，评价它们是否有效或者过于严苛。由此我们引入了“站会”，但随即取消，因为觉得这种形式对我们帮助不大。我们也曾将每月一次的例会改为隔周进行，进而又改为每周一次，后来又改回隔周。

《程序员》：你在博客中提到，你一直乐于和做有趣工作的人建立联系，并愿意为他们出谋划策。你参与了哪些项目，又提出了哪些建议？ Nathan：Insight Data Science（http://insightdatascience.com）项目伊始，它的创始人就与我取得了联系，我认为这是个绝佳的项目。它提供为期6周的训练营课程，帮助数学、科学、物理专业的博士生掌握编程技能，让他们能以“数据科学家”的身份开启自己的职业生涯。 一方面，大批聪明人不能从事自己理想的工作，而另一方面，科技产业的迅速发展，对数据科学家的迫切渴求，令这一职业形成了巨大缺口，而Insight Data Science项目为两者搭建起了桥梁。我为他们提供了一些自己的经验，而他们的执行力也令人印象深刻。

《程序员》：你贡献了多个开源项目，什么原因让你信仰开源？ Nathan：开源能令许多人以不同方式受益。初创公司的资源高度受限，倘若别人的工作能为自己所用，真乃天赐之物。对于整个社会，降低初创公司的开销当然也有裨益。既然你已从开源之中受惠良多，自然也感觉有义务回馈。最重要的是，当你以开源软件作为产品经营公司，将能享受到使用者的回馈——发现问题、提高软件质量，而且还是免费的。 在个人层面，开源让我有机会能与全世界开发者接触，而不受限于我所就职的公司。这一点对我的职业生涯帮助巨大，让我有机缘广交能人，又能通过在会议上演讲周游世界。

《程序员》：哪个人对你的影响最大？ Nathan：从哲学角度讲，对我影响最大的人非Carl Sagan莫属。我几乎阅读过他的所有著作，并被其深深鼓舞。我觉得他是有史以来最杰出的传播者，而留给我印象最深的是，他与读者能保持极强的同理心。例如，他撰写了许多有关“科学vs.宗教”的话题——但身为科学家，他并未对宗教或其他事物流露出敌对心态。他理解为何有人信仰宗教，也理解他们能从宗教中获取哪些抚慰。因此，当他传播科学的价值并对信教者持怀疑论时，他会先以“宗教等同于价值”作为出发点。换位思考能达到这种程度真是罕见，这也是我不断想在自己身上获得提高的地方。他教给我同理心是良好沟通的基础。

《程序员》：你曾到John McCarthy家中，和他有过一段对话，他同你讲了什么，对你有哪些影响？ Nathan：这件事发生在我读大学二年级时，我与John McCarthy有过两个小时的交谈。最令我感到意外的，是当我问起Lisp的历史时他的讲述。他告诉我，当时他需要一门更好的语言用于AI研究，为了这个目的才发明了Lisp。而他自己，看起来真的并不怎么关心语言本身——AI才是他的钟情所在。这件事对我的震撼就如同牛顿之所以发明微积分，是为了方便他研究物理问题那样。巨人们随手撇下的鹅卵石都是庞然大物。

《程序员》：什么原因促成你开始写作《Big Data：Principles and Best Practices of Scalable Realtime Data Systems》这本书？你希望在其中解决哪些问题？写书是个漫长的过程，在这段时间，你又有哪些感悟？ Nathan：对于架构大数据系统，我已提出了多项理论和最佳实践，这些内容都是旁人从未讲述过的。人们大多专注于某些具体用例，而我提出的是一套严格、完整的方法论。 许多我曾阐述过的话题，例如系统应能从容恢复人为失误引发的故障（在我看来，这一原则绝无妥协余地），但在工业界中，却被大多数人所忽视。我相信，在搭建这类系统时，倘若能多些严格验证，少些任性随意，整个工业界都会因此而受益。而写作《Big Data》这本书正是为了推动这种转变。 我理解写书需要花费大量精力，但未曾想真实付出远远超出我的预期。写作这本书尤其富有挑战，因为它试图涵盖一个宏大的主题。在某个时间点，我已完成了半本书的写作，却意识到素材的组织方式并不妥当，于是我弃置了所有旧稿，转而另起炉灶。这样做完全是值得的，这从读者的反馈中可以得到证实。他们能更好地理解我使用的素材和希望表达的思想。 我的编辑们在写作过程中功不可没，他们也助我成为了更好的作家。我发现，学校教授的那套写作方法，完全有悖于高效沟通。那时老师告诉我们要把“论点”放在文章的开头，之后再向下逐层展开一般性观点和对应支撑，最后才是具体细节。 然而事实证明，这种方式迫使读者颇费一番功夫来整合作者的陈述。他们不可能在一开篇就把握论点——因为这会儿还没读到相应的支撑点呢。所以跟随作者逐层向下之后，读者还要拐“上”来串联一切。要通过这种方式理解事物，真叫人费解。更有效的沟通方式是讲故事——由读者感同身受的话题出发，一步步串联，直至你希望读者理解的终极概括性观点。从具体到概括，总是胜过从概括到具体。

《程序员》：你在博客上也呼吁其他程序员开始写作，提高写作技能，对此你有哪些秘诀？ Nathan：提高写作技能的唯一办法是多写。当其他人阅读我的文章，为我提供反馈时，例如在博客中留言，我总会思考他们为何如此评论。倘若他们误解了我的本意，可能意味着我没能恰当地交流——抑或表达不够清晰，抑或我未能准确预测读者的反对（这些反对意见是否成立无关紧要）。通过理解信息为何没能准确传递，下次我就会做得更好。 同时我也大量阅读，并尝试向伟大的作家学习。我已提到Carl Sagan是我最欣赏的作家之一，阅读他的作品，我获益良多，而且每次阅读都是如此。 关于编程感悟

**《程序员》：设计软件系统时，你会采用哪些步骤？ ** Nathan：我认为，设计软件系统完全就是学习如何在行进中开发。我应用一种被我称之为“面向痛苦编程”（Suffering-Oriented Programming）的原则，使学习最大化，浪费最小化。关于这种方式的详细介绍我已写在博客上（http://nathanmarz.com/blog/suffering-oriented-programming.html）。其核心思想是，避免做出“通用”和“可扩展”的设计，除非你已透彻理解了问题域（Problem Domain）。 相反，你应该直截了当地尽快打造出可用原型，继而通过迭代和改进学习问题域，当你对问题域的盘根错节有了清晰的理解后，再回过头来重新设计系统，使之具备通用和可扩展等特性。到最后一步才开始收紧代码，优化性能。归纳为三个步骤，就是“先使之可能，再使之漂亮，后使之快速。”

《程序员》：你在编程时，通常会遵循哪些原则？ Nathan：我非常笃信不变性（Immutability）与引用透明函数（Referentially Transparent Function）是大幅简化软件系统的途径。可变性在代码中编织了依赖网络（一个对象的改变，导致另一个的改变，进而又改变其他对象），令你不知所措。代码的作用是理解程序的运行状况，任何能使其简单化的方法都有益处。不变性就是这类简化方法之一，它能便于你理解和掌控代码。此外，引用透明函数只依赖于其参数（与其他状态无关），也有利于理解代码。 另一个我所倚赖的重要原则是“我的代码有缺陷”。显而易见，我们尚不清楚如何编写完美代码——所有我使用或编写过的代码都存在Bug。因此，我在假设自己的代码有缺陷的前提下，设计并使系统尽可能运转起来（至少大多数情况如此）。其中的技术细节我在2013年的技术会议中分享过。

《程序员》：同刚开始编程时相比，这些年你在编程方面最大的变化是什么？ Nathan：自从抛弃了图形计算器，我得说最大的变化在于可以在全键盘上写程序了，而不是用那些小按键。

《程序员》：你面试过许多程序员，那些最优秀的人有什么共同之处？ Nathan：最好的程序员都痴迷于提高自身的核心技能，他们喜欢探索新的编程语言和想法。好程序员的另一个重要特征是，他们都有“把事情做成”的心态。与完美的设计相比，让系统真正可以运行要重要得多。还有一点，他们都知道除非先让系统运转起来，然后从中学习，否则别想得到完美的设计。

大数据系统与Storm

《程序员》：关于大数据系统，是否存在误解和迷思？ Nathan：我所见到最普遍和严重的一种误解是，人们往往对关系型数据库与相关理论（如CRUD）顶礼膜拜。将RDBMS视为终极的数据库技术，并且似乎每个人都尝试在大数据的版图上重新实现RDBMS。然而这样做忽视了RDBMS的痼疾：它们都基于可变性，容易遭Bug或人为失误侵袭而崩溃；此外，这类技术迫使你要么标准化Schema并忍受性能缺陷，要么采用非规范化的Schema并准备迎接维护的梦魇（还有其他问题）。 而当你真正从首要原则审视数据系统时，就像我在书里面的做法，其实存在多种架构数据系统的方式，能克服所有的这些复杂性。

《程序员》：开发Storm是为了解决BackType的哪些问题？ Nathan：开发Storm是为了解决两个问题。其一是确保我们的数据库中总是包含最新的实时社交媒体分析统计状态。其二是“到达问题”——计算机如何才能快速获取发布在Twitter上的链接，它需要计算所有用户的关注者发布的全部链接。这是一项高度的计算密集型任务，难以预先处理。Storm是这一系列看似互不关联的用例的简单抽象。

《程序员》：在极少的人力支援，有限的时间和预算，以及创业公司紧张的气氛下，你完成了Storm这样一套复杂的系统，信心从何而来？ Nathan：Storm正是遵循“面向痛苦编程”方法的结果。能在这种背景下完成Storm并非意外，我们在BackType采用手工将Workers与队列结合的方式处理实时计算工作已有相当长的时间，因此，我们对实时处理的需求有着坚实的理解。Storm的核心只不过是一套抽象集合，以及一套聪明的算法在幕后保障数据处理。那时，一想到我在BackType将面对实时处理这个长期而艰巨的任务，设计Storm来解决这个问题便再自然不过了。此外，我还有丰富的Hadoop经验，晓畅它的设计缺陷，我将这些经验都用在了Storm的设计上，令它更坚韧。 正是因为有着这样的背景，我对能否成功实现Storm从来没有过疑问，那些可能存在的陷阱，我早就了然于胸了。

《程序员》：你为何选择用Clojure实现Storm？哪些特性是你最青睐的？假如Clojure不存在，会有哪些不同？ Nathan：Clojure是我迄今用过最好的语言。它允许我轻松地使用不可变性及函数式编程等技术，令我的效率大幅提高。基于Lisp的动态特性，使我总能将Clojure塑造成符合最佳抽象的状态。假如没有Clojure，Storm倒不会有什么不同，但实现过程将痛苦得多。

《程序员》：因为Clojure的缘故，你也改用Emacs作为编辑器，它带给你哪些不一样的感受？ Nathan：我之所以使用Emacs，是因为它是最理想的Clojure编程环境（它们都有Lisp的渊源）。我惊讶于一款工具在提供如此强大功能的同时，还能如此灵活地随心定制。 除此之外，因其最初开发年代久远，资源占用难以置信的小。不像那些现代IDE，往往吞噬掉大量资源。 我的配置相当简单，在Emacs中我使用REPL做探索式开发和交互测试。我的电脑里还有不计其数的设计笔记和构思，都以纯文本格式保存。我的待办事项列表，就是一个文本文件。

本文为《程序员》原创文章，未经允许不得转载，如需转载请联系market#csdn.net(#换成@)