[置顶] 谷歌大牛 Jeff Dean 是如何成为互联网战神的

谷歌大牛 Jeff Dean 是如何成为互联网战神的

原文链接： Will
Oremus   翻译： 伯乐在线- Lex
Lian

译文链接： http://blog.jobbole.com/47726/

“光在真空中的速度曾经是大约每小时35英里，然后Jeff Dean花了一个周末优化了基础物理学。”——出自“关于Jeff Dean的事实”

其实，“关于Jeff Dean的事实”这个G+帖中描述的并非是真实的。不过有人大费周折为他建立了一个类似于“关于Chuck Norris 的事实”这样的网站，这倒是件不同寻常的事。这是因为Jeff Dean是一位软件工程师，而软件工程师们通常是不会像武术界的战神Chuck
Norris那样的。一方面，他们不是独行侠，软件开发从本质上来讲是一个协作过程。另一方面，他们也从来不会像这个视频里面的Chuck Norris那样用冲锋枪来打牛仔。

译注：Chuck Norris（查克·诺里斯）是空手道世界冠军、美国电影演员。他有另一个更为人所共知的译名“罗礼士”，出自功夫名片《猛龙过江》。 他发展电影事业初期，在李小龙执导的武打电影《猛龙过江》中饰演一名空手道高手Colt，与李小龙在罗马斗兽场决斗，公认是经典的武打场面。（摘自维基百科）

Jeff Dean

然而，在2007年的愚人节，一些慕名而来的年轻谷歌工程师觉得应该给Jeff Dean制作一个网站，来赞扬他在编程方面的成就（译者：以下都只是玩笑，并不是真的）。例如：

• 编译器不会向Jeff Dean给出警告的，Jeff Dean会给编译器警告的。
• Jeff Dean是直接写二进制代码的，然后他写了源代码，作为给其他开发人员看的文档。
• 当Jeff Dean考虑人体工程学的问题的时候，这是为了保护他的键盘。
• 有一天当Jeff Dean在优化一个功能时，他被迫发明了异步调用的API。这样的话这个功能可以在它被调用之前就可以返回结果了。

关于Jeff Dean的一个真正的事实是：你必须是一个计算机高手，才能了解人们说的很多关于Jeff Dean的笑话。（对此有兴趣的读者，Business Insider 网站提供了一些关于他的比较流行的笑话的解释。）如果你没有计算机科学的背景知识，那么你就很难理解那些玩笑中谈到的那些他的虚假成就，更不用说理解他在工作中真正的成就了。Dean亲手打造的系统，例如，MapReduce、BigTable、Spanner等，对于众多Google用户来说并不知道是来源于Goolge的。但是，这些程序都是Google和现代互联网存在的基石。他现在所工作的一些项目，很有可能会再次为信息技术带来革命。

当你在思考是谁创造了当今互联网的时候，你可能会想到很多公司的创始人和CEO，比如：蒂姆·伯纳斯 – 李（Tim Berners-Lee）、马克·安德森（Marc Andreessen）、拉里·佩奇（Larry Page）和谢尔盖·布林（Sergey Brin），也许是马克·扎克伯格（Mark Zuckerberg）。这是有道理的，这些人中的每一位都发明了一种产品或框架，塑造了我们今天使用互联网的方式。

同时，在这些已从繁重的日常工作中解脱出来的巨人阴影下，是一帮不知名的开发人员，在键盘上每日敲打出来给我们使用的产品和系统。同其他行业不同的是，在高科技行业，这些人通常是不可替换的。一个出色的会计可能会帮你节省5％的个人所得税。一个出色的棒球选手的上垒率也就比一般球员高出那么一点点（译者：棒球运动中一般会用上垒成功率，击球成功率等来衡量球员的水准）。但是一个出色的软件开发人员在一周中的工作可能需要一支近10人的团队花几个月才能完成。这种差异是指数级别的。这个并不是一个关于Jeff Dean的事实，而是硅谷的高科技行业的常识，也就是为什么最好的公司会花如此大的代价来吸引顶尖人才。

在Dean 1999年中加入Google的时候，他已经拥有了美国顶尖年轻计算机科学家的荣誉。在家用计算机刚开始普及的时候，Dean说他总是在寻找能够在一台给定的机器上不断追寻极限性能的方法。当他还是一个高中生的时候，他编写了一个软件来分析大量的流行病数据。据他说，他的软件比是当时专业软件快26倍。这个系统称之为Epi
Info，被美国疾病控制中心（Centers for Disease Control）采纳并翻译成13种语言。当他在读计算机科学博士的时候，他研究的是编译器，用来将程序源代码翻译成计算机能够执行的语言。他说到，“我总是喜欢运行得快的代码”。

不过Dean并不是安于现状的人，他也不想把一辈子都花在编译器上，所以他后来离开了学术界。三年不到，他加入了当时只有20个人的Google。（根据Steven Levy的《In
the Plex》一书，　作为搜索初创企业的Google，当时觉得Dean是一个来之不易的人才。）他为早期的Google News 和AdSense 做出重大贡献，其中AdSense这一广告产品改写了互联网公司的游戏规则。在此之后，他转而关注了公司核心的问题之一：扩展性。

Google公司基础算法的最初想法来自于Page和Brin, 他们两在当时都算是顶级的开发人员。在90年代末，他们创造了PageRank算法，一种在用户给定搜索查询的时候返回最相关搜素结果的算法。对于搜索结果相关性的专注让Google一举超越了Yahoo,
AltaVista以及当时处于领先地位的其他各个搜索引擎。不过随着Google变得越来越成功的同时，它也碰到了一项巨大的技术挑战。Dean回忆道，“我们不能足够快地部署更多的机器来响应需求”。

所以Dean和他的同事们，包括另一位出色的程序员Sanjay Ghemawat一起找到了解决方案。这个问题就像他在高中时对待Epi Info 一样，看起来象是一个硬件问题。Ghemawat帮助带领了一个团队开发了谷歌文件系统（Google File System, GFS），使得超大型的文件能够分布地被存储在众多廉价的服务器上。然后Dean和Ghemawat一起开发了一个称之为MapReduce的编程工具，来帮助开发人员有效地使用这些机器并行处理庞大的数据集。正像编译器帮助程序员在编写程序的时候不用考虑CPU是如何处理该程序一样，MapReduce使得Google的开发人员在调整搜索算法或者增加新功能的同时不必担忧如何将这些运算并行化，也不必担心如何处理硬件的故障。

Dean和Ghemawat的方法如此之强大，当他们在2004年的一个会议上发表了一篇研究论文之后，这个方法马上就变成了业界的标准。直到今天，MapReduce成为了众多其他项目的重要基石，其中之一就是著名的开源框架Hadoop。而正是Hadoop，
造就了业界中新的流行语“大数据”。从在线旅行到能源勘探等不同的领域中都会用到大数据的方法。而正当Google
开始在一些核心的应用中从MapReduce进一步扩展到其他新的编程模型时，Dean说他还是看到许多夏季实习生到Google后开始新项目的时候，都会大量地开始使用MapReduce。

MapReduce正是Google的创始人之一Page所说的10倍效应的一个好例子。10倍效应说的是比原来的好10倍，而不是比原来做得好10%。MapReduce并没有使得某一种特定类型的运算更快一点，而是帮助了Google的每一位开发人员可以做到他们以前做不到的事情。

Dean的其他几个项目也有类似的指数效应。在谷歌文件系统的基础上，他和Ghemawat创建了一个分布式数据库系统，名为BigTable。　BigTable可以处理1PB的数据（1 PB=1千万GB。）（
译者：开源社区也有类似的项目， 基于Hadoop 之上的 Hive）之后他们又进一步开发了被称之为世界上最大的单一数据库的Spanner系统。连线杂志（The
Wired）的Case Metz说，通过使用创新的时间同步方式，Spanner的物理存储虽然跨越了全球不同的数据中心，但操作起来就像是在一个地方。换句话来说，它能够使得全球的数据中心中不同的信息保持一致，即使一个特定的更新请求可能会需要不同的时间达到不同的数据中心。Metz又说道，在Spanner被报道之前，从来没有人觉得这种系统是能够搭建出来的。

现在看起来，这些关于Jeff Dean真正的事实看起来有点像是假的一样。Dean自己也会对这种情况笑起来，说这个有点尴尬，但同时也一种被恭维的感觉。但他又说，要记住的是，他的这些工作上真正的成就，总是通过和不同的人共同合作得来的。

几乎每天早上，他都会到位于加利福尼亚州，Mountain View的Google总部上班，而且总是坐下来和同一伙人一起喝咖啡。他估算到，这些年来我们大概一起消灭了20,000杯卡布奇诺吧。这些人并不总是在一起工作。事实上，有些人已经搬到了Google园区另一边不同的办公室里。不过当他们聚在一起讨论他们正在做的事情的时候，一些人的问题总是能激励其他人的新想法。这些咖啡闲聊使得Dean把他在优化、并行计算、软件架构等方面的经验运用到众多不同类型的项目中去。这些使得他产生了足够的雄心和自信心。作为他长期合作伙伴的Ghemawat说，“他总是对于我们能做到什么程度充满了热情和乐观，没有什么能够阻碍他”。

他最近的工作可以很好地说明Google接下来会做什么。去年，他和斯坦福大学机器学习领域的专家、Coursera创始人之一的Andrew Ng一起，帮助了Ng的研究生Quoc Le进行了一项前所未有的无监督机器学习的试验。这个属于Google公司秘密的Google
X 臭鼬项目下（译者：指秘密的创新项目）的试验，将16,000个处理器用于对YouTube视频进行无人干摄的学习，来得出如何识别一只猫的方法。这个看起来是用了很多计算机来得出一个非常基本的结果，但是这个试验能够帮助我们为下一代的人工智能技术打下基础。未来的人工智能技术将在许多的潜在应用中发挥作用，这些包括使用了个人助手技术的Google
Now，以及对Google 眼镜项目（Project Glass）会有很大帮助的图像搜索功能等。

Jeff Dean可能正的会发明一些不可思议的东西，就像“关于Jeff Dean的事实”中提到的只有0和1的特殊键盘（译者：这种键盘是不存在的，这个网页上的文章在开玩笑说Jeff
Dean是直接用二进制的机器代码写程序的。）Jeff Dean承认他并不是机器学习的专家，不过他乐于使用它在搭建可扩展、高可用系统方面的经验来帮助这一方面的研究。

和“关于Jeff Dean的事实”说的相反的是，Dean说在很多情况下解决问题的最佳方法并不是简单地一坐下来就开始写程序。他的方法总是在开始的时候需要进行一些简单的计算，来找到对于特定过程的质量和速度之间的最佳平衡点。他说，从机器翻译到搜索质量的许多领域，你总是试图权衡你能够对每一个查询所做的计算量。也许你不能找到最理想的解决方案，但是我们总是可以通过某种近似的方式，通过1%的计算，得到98%的好处。

Dean经常做这类计算，以至于他给出了一个“每个计算机工程师都应该知道的数字列表”（或者这个http://everythingisdata.wordpress.com/2009/10/17/numbers-everyone-should-know/）。其中包括诸如在光速情况下，从加利福尼亚到阿姆斯特丹发送一个网络包要花多少毫秒，（150毫秒）。将这些数字牢记在心，
在20分钟内，你就能从白板上区分在3个设计中哪一个会是最好的。他又说到，如果你不能快速地进行计算？把所有这些数字近似地转换为2的次方吧，这样做乘法的时候会比较容易。

如果Dean真的拥有超人的力量的话，那么这种能力并不能在瞬间就把事情做到完美。这是一种能够根据事情的不同级别进行权衡、优化，及处理问题的能力。换个角度来说，它是一种能发现机会，并把事情在很短的时间内做到尽可能好，而不是一开始就尽全力追求完美的能力。在硅谷，这可比拿着冲锋枪向牛仔们扫射酷多了。

--------------------------------------------------------------------------------

Jeff Dean的Stanford演讲

Google 公司的 Jeff Dean 在Stanford大学做了一个非常 精彩的演讲。我觉得我们每一个人都应该去看一看这个视频，当然，没有字幕，需要不错的听力，当然，我不可能全部翻译出来，因为我也不是完全能听懂，下面是一些相关的Notes，供你参夸，并欢迎牛人指证。

• 比较了从1999年到2010年十年来的搜索量的变化。搜索量增加了 1000 倍，而搜索速度快了5 倍。1999年，一个网页的更新最多需要一个月到两个月，而今天，只需要几秒钟，足足加快了5w倍。
• 一开始，这些大量的查询产生了大约30GB的I/O量。2004年，他们考虑过全部重写infrastructure。
• 讨论了一些关于变量长度字节对齐的东西。
• 今天的MapReduce 有400万个作业，处理将近1000PB的数据，130PB的中间数据，还有45PB的输出数据。（1PB =1024TB）关于 MapReduce （Google云计算的精髓） 的一些统计，见下图：
• 

• 现在Jeff正在做一个叫Spanner的项目，这是一个跨多个数据中心的项目。在后来的Q&A中，Jeff解释了现在的数据基本上都在各个数据中心中，数据在不同数据中心间的交换几乎不可能。所以，他们需要提供一些手动的方式或是一些工作或任务来达到数据共享。这其中还需要有一些策略配置，共同的namespace，事务处理，数据一致性等等工作。

• 最后一个段落应该是最精彩的，Jeff讲了很多很有意思的东西，绝对让你受用一生：
  • 一个大型的系统需要分解成N多的小services.（这和Amazon的很相似，一个页面的调用可能要经过几百个后台的services）
  • 代码的性能将会是想当的重要。Jeff给了一张叫“Numbers Everyone Should Know” 的slide，如下所示，我觉得太经典了，其中的东西，如果你看过我的那篇“给老婆普及计算机知识”，我想我不需要多解释了。（注：1
    ns = 十亿分之一秒）
  • 
  • 把相同的东西抽出来去建立一个系统，而不是把所有的事情交给所有的人。他说： “最后的那个功能可能会导致你怎么个系统超出了原有的复杂度”。
  • 不要无限制地设计可扩展性。5倍到50倍的扩展性设计足够了。如果你要达到100倍的，那应该是re-arch了。
  • Jeff很喜欢有中心主结点的架构体系，他并不喜欢分布式系统。当然，中心主结点主要是用来做控制的，而不是做数据或是计算服务的。
  • J在一些小机器上运行多个小服务，而不在一个大机器上运行一个mongo作业。越小的单元就越容易处理，修复，负载均衡和扩展。（化繁为简）
  • …… ……

这是一个非常不错的演讲，很让人开阔眼界。

最后，我想说说英文，很多程序员都很不喜欢英文，哎……怎么说呢？如果你今天对英文还很害怕的话，这只能怪我们的教育制度的失败。但如果你以此为借口的话，那只能怪你自己了。没有英文的能力，你的技术和认知仅限于中文圈中，而中文圈中基本上都是产商的文化。有人说，“功夫网”让我们的internet成为了局域网，而我想说，让我们成为局域网的不是那个墙，而是我们自己的世界观和英文能力。

（转载本站文章请注明作者和出处 酷壳 – CoolShell.cn ，请勿用于任何商业用途）

--------------------------------------------------------------------------------

趣文：谷歌大牛Jeff Dean的那些“惊人真相”

原文链接： businessinsider   翻译： 伯乐在线- JingerJoe

译文链接：http://blog.jobbole.com/51607/

在谷歌加州山景城总部，除了拉里·佩奇（Larry Page）和谢尔盖·布林（Sergey Brin），真正的牛人工程师要数杰夫·迪恩（Jeff Dean）了。

谷歌员工都认为谷歌搜索惊人的速度都归功于Jeff Dean，因此他也成了谷歌的名人。

大家对他的崇拜到底有多深？

你有听过关于武术战神查克·诺里斯的一些笑话吗？就像“查克从不洗盘子，盘子会因为恐惧他，自动清洗的”或者“查克被商业航班拒载，因为他的拳头会将飞机击落”等等诸如此类的笑话。

江湖中有一大堆关于Jeff Dean的传奇故事，都是由崇拜他的（前）谷歌员工写的。如果你了解软件工程师，懂得程序员幽默的话，那你会觉得那些故事非常有趣。

有时遇到不理解的，我们也会请求 BI首席架构师Pax Dickinson为我们解释那些笑话。

“编译器从不会给Jeff Dean警告的，Jeff Dean会给编译器警告的。”

解释：当你的代码有误时，编译器会给出警告，但是Jeff比编译器还牛叉。

“Jeff Dean 提交代码前会编译和运行他的代码，只是为了检验编译器和链接器有没有问题。”

解释：Jeff 的代码从不出错，他编译代码只是为了确保编译器和链接器没有bug。

“Jeff Dean 每次只给一条腿穿裤子，但是如果他有很多腿，你会发现他穿裤子的时间复杂度为O(log n)”

解释：Jeff Dean 穿裤子的算法复杂度是对数级的而不是线性级的，这样的话，如果他有很多条腿的话，就会大大节约穿裤子的时间。

“当 Richard Stallman 听说Jeff Dean的自传专属Kindle平台，他就去买了Kindle。”

解释：Richard Stallman是著名的极力反对非自由软件的人，并且从来不购买和使用Kindle。但是Jeff Dean就是这样神奇，Richard会因为想要阅读Jeff的自传而去违背自己的原则。”

“Jeff Dean 是直接写二进制机器代码的，他写源代码，是为了给其他开发人员作参考。”

解释：所有的代码在执行前都要先编译成二进制机器码，Jeff是直接写二进制机器码的，他写源代码主要是方便其他程序员理解。

“Jeff来面试谷歌时，被问到等式P=NP成立的条件，他回答，P=0 或者N=1时成立。然后在面试官哈哈大笑的时候，他看了一眼谷歌公有证书，就直接在白板上写出了相应的私钥。”

解释：“P与NP一直是计算机科学领域的一个悬而未决的问题，但是 Jeff Dean把它想成了一个代数问题，他直接用大脑根据谷歌的公有证书算出了相应的私有秘钥，这在超级计算机看来，都是不可能的事。

“X86-64 规范有几项非法指令，标志着‘私人使用’，它们其实是为Jeff Dean专用。”

解释：私有的非法CPU指令是不能被任何人使用的，但是Jeff Dean 就可以用。

“Jeff Dean 进行人体工程学评估，是为了保护他的键盘。”

解释：通常评估人体工程学是纠正坐姿，保护你的健康的，但是Jeff 却是为了保护他的键盘。

“所有的指针都是指向Jeff Dean的。”

解释：指针是C编程的核心，但是Jeff  Dean 是编程世界的中心。

“在2000年末的时候，Jeff Dean 写代码的速度突然增长了40倍，原因是他把自己的键盘升级到了USB 2.0。”

解释：是键盘和计算机之间接口的速度影响了Jeff Dean 的编码速度。

--------------------------------------------------------------------------------

出处: http://www.parallellabs.com/2010/12/02/jeff-dean-on-google-system-architecture/

Jeff Dean关于Google系统架构的讲座

2013-11-06 补充：谷歌大神Jeff Dean院士由于业务突出，近日被提拔为Google Senior Fellow。上个月在湾区的一次ACM活动上，Jeff做了关于《大规模深度学习及征服延迟时间易变性》
的报告。强烈推荐！视频：SFBayACM 2013.10.16 Jeffrey Dean

上个月Jeff Dean在Standford的Computer Systems Colloquium (EE380)这门讨论课上详细讲了讲Google的系统架构发展过程，因为这是份很新的资料，所以特意把它的Slide下下来与大家分享一下。这门课是Standford的讲座课程，每一节课都由不同的顶级工程师/科学家/投资人前来讲授IT行业的最新动向，非常非常有料，绝对值得深挖。这门课的每节课都是带视频的，Jeff
Dean的这个讲座的录像在这里。想要下载该视频的同学可以去这里（要会功夫，你懂的）。

这个讲座的主要内容包括：

• Evolution of various systems at Google

– computing hardware

– core search systems

– infrastructure software

• Techniques for building large-scale systems

– decomposition into services

– design patterns for performance & reliability

个人的一点小感想：Jeff Dean在Google的这几年能面临这么多有意思的挑战，编程模型，可靠性，伸缩性，运行时环境等等等等，真是羡煞旁人。随着Google业务的扩展，整个系统的设计也面临各种各样新的挑战。只有有了扎实的基本功，在面对没有现成解决方案的新问题时才能游刃有余，做工程是如此，做研究更是如此。

可能有些同学会因为这是个英语的讲座而头疼。我觉得大家可以坚持看，哪个单词看不懂的就查字典，刚开始可能痛苦点，但是只要坚持下去，积少成多，你就会发现自己的英语慢慢就上来了，至少看这些英文slides是没问题了。

Building
Software Systems at Google and Lessons Learned另外还有几个关于Jeff Dean的Google架构的博文：

Jeff Dean 在WSDM 2009上面的演讲 Keynote 和视频终于出来了

来自Jeff Dean的分布式系统设计模式（更新版）

Jeff Dean的Stanford演讲

我还发现了Jeff另外一个在09年做的类似主题的讲座，内容稍有重复，但是可以算是一个补充，例如这个里面包括了BigTable等内容。

Enjoy！

Dean keynote-ladis2009-jeff-dean



##########################################################################################################################################################

Latency numbers every programmer should know

L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns  =   3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns  =  20 µs
SSD random read ........................ 150,000 ns  = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns  = 250 µs
Round trip within same datacenter ...... 500,000 ns  = 0.5 ms
Read 1 MB sequentially from SSD* ..... 1,000,000 ns  =   1 ms
Disk seek ........................... 10,000,000 ns  =  10 ms
Read 1 MB sequentially from disk .... 20,000,000 ns  =  20 ms
Send packet CA->Netherlands->CA .... 150,000,000 ns  = 150 ms

Assuming ~1GB/sec SSD

Visual chart provided by ayshen

Data by Jeff Dean

Originally by Peter Norvig