Jeff Dean改写百度搜索，「种下」百度云

“Jeff Dean与百度那些不为人知的故事。”

作者丨覃倩雯

编辑丨刘伟

前言：

雷峰网此前曾讲述、、的系列文章，本文是Jeff Dean系列的最后一篇，继续讲述Jeff Dean如何启迪百度，以及他的技术思路如何在百度技术体系里延续生长。

2012年12月Jeff Dean亲自坐镇，代表Google与当时百度余凯在同一张对桌上激烈竞拍，争抢Hinton团队。

这是百度代表团和Jeff Dean少有的一次正面交锋，但双方的历史渊源技术纠葛远不止于此。

2008年左右，百度内部已经围绕Jeff Dean的三篇经典论文打过一场激烈的技术PK。当时，内部有两波技术人马，一波是Pyramid自研团队，另一波是Hadoop开源团队。

这场PK的结局很残酷，Hadoop开源团队竟以微弱优势获胜。百度高层一声叹息、壮士断腕，Pyramid团队迅速解散。

既然只是微弱优势，何至于此？

这是因为，Pyramid自研团队身上倾注了百度的骄傲和期望，投了很多人力和预算。

2007年时，Jeff Dean三篇论文横空出世，百度决定硬刚Google，照着Jeff Dean的思路，自己认真搞一套分布式系统出来，从底层的分布式系统到顶层的Map/Reduce API，全部自己造。

百度的投入非常大，从MSRA挖来了一位做分布式的知名学者带队，又从各个技术部门抽调了几十名T5、T6技术骨干成立专门的项目组。

当时全百度的技术开发人员大约200~300人，这个项目一下就从里面征调了几十个有经验的主力出来，可想而知其力度之大。

项目组从leader到一线开发都非常有激情，整个项目组狂加班。当时，普天大厦12层西侧几乎每天晚上都灯火通明。

做了一年后，Pyramid终于横空出世。而真正扎心的事，正是在这一点。

另一拨人马认为，既然Yahoo和开源社区已经把Google论文实现了一遍，就没必要重新造轮子。

于是，他们在很短的时间内，拿Hadoop的代码来包装了一下，用C重写了API，然后用C重写了一些性能模块，稳定性比Pyramid团队还要好一些。

Pyramid退出历史，但Jeff Dean的技术思路继续在百度生长。

它先进入搜索，随后又启发百度把分散在各个业务下的存储和计算重新抽成公共基础设施——这也成为百度后来走向云的一条重要伏线。

01

Jeff Dean，推动百度搜索“做大”、“做快”

2008年，Hadoop分布式计算系统在百度正式上线，但真正的考验也随之而来。

当时百度索引的数据量涨得很快，Spider抓回网页后，还要解析、去重、计算特征，再生成正排和倒排索引。

原来的伪分布式架构在规模较小时还能支撑，等机器越来越多，搜索团队开始被任务拆分、调度、故障恢复这些事情不断拖住。

这正是Jeff Dean的MapReduce擅长解决的问题。

过去，建库系统要自己处理机器之间的协作。MapReduce接手后，这些工作交给了计算框架。搜索工程师不必再反复考虑几千台机器如何配合，可以把更多精力放在网页和索引上。

此后三年多，百度的搜索工程团队把建库从伪分布式架构迁到MapReduce，又在MapReduce之上继续改造流式建库。

据早期参与的工程师回忆，建库效率最终提高了数十倍。而Hadoop也在这个过程中被百度越改越深。

最早时，Hadoop发布的开源版本距离真正支撑百度业务，有不小距离。

一方面，百度内部大量业务基于C/C++，而Hadoop主要围绕Java技术栈构建；另一方面，随着集群规模不断扩大，NameNode、DataNode、JobTracker等组件的性能和稳定性问题，也开始集中暴露。

当时社区更多面对千台以内的集群，而百度很快撞到了3000台规模，团队只能继续往Hadoop内核里改。

百度随后进入了一轮持续数年的改造。当时百度团队选择了相对稳定的版本建立内部开发分支，再根据百度的业务环境持续修改。

到2010年前后，百度已经不再直接使用社区版本，而是从Hadoop 0.19附近建立了自己的内部代码分支。

此后，团队围绕百度的实际集群规模重新设计了多项核心能力：NameNode需要承担更大的元数据压力，DataNode的读写路径需要提升吞吐，JobTracker和任务调度系统也要适应不断增加的作业数量。

与此同时，百度还针对内部大量C++业务补充了相应的接口和扩展能力，包括Shuffle在内的一些关键模块也被重新设计。

到2010年前后，百度已经不再直接使用社区版本，而是从Hadoop 0.19附近建立了自己的内部代码分支。

但百度很快又碰到了另一个问题。

数据规模不断扩大之后，百度已经能够处理更多网页，但搜索结果的更新速度仍然受到限制。

MapReduce更适合大规模批处理：网页经过一段时间的积累后，统一完成计算，再进入后续索引流程。这种方式能够提高整体处理能力，却难以满足搜索业务对时效性的要求。

也是这时，百度开始启动另一套分布式存储系统的研发，其被命名为Tera，参照的也正是Jeff Dean参与设计的另一套Google系统：Bigtable。

Bigtable，改变了搜索系统处理网页数据的基本方式。它把海量数据组织成可以按行键快速访问的分布式表，并通过底层存储和集群管理机制，支持数据持续写入、更新和读取。

百度沿着这套思路研发Tera后，链接和网页不再只是等待批处理的静态文件，而变成了可以被持续更新的在线数据。

这直接改变了Spider的工作方式。

此前，Spider抓回网页后，很多处理环节依赖MapReduce：先积累一批数据，再统一计算，计算完成后才能进入下一步。

到了以Tera为核心的Spider 3.0，链接库和网页库可以持续读写。新链接抓回来后，可以直接写入分布式存储；网页内容发生变化，也可以更新原有记录。后续的解析、去重、特征计算和索引筛选，不再完全依赖下一轮全量批处理，而是可以围绕新增和变化的数据持续推进。

百度后来披露，这套架构将原来基于MapReduce的批量计算逐渐转成实时计算，每天可以处理万亿量级链接操作。索引筛选也从过去的天级处理，被压缩到分钟甚至秒级。

02

三篇论文，把百度从“贴吧”推向“云”

Jeff Dean的影响不只体现在Hadoop和Tera上。

云计算萌芽阶段时，Jeff Dean也影响了百度对另一件事情的理解——一家拥有越来越多产品、越来越多机器的互联网公司，底层的存储和计算究竟应该怎样组织。

外界提起百度云，更熟悉的故事往往是另一套版本：李彦宏曾把云计算形容为“新瓶装旧酒”，百度因此被视为一家错过云计算、后来又匆忙追赶的公司。

但如果把“云”往底层技术追，百度和它的渊源其实要早得多。这个故事甚至可以从2005年讲起。

2005年的8月有两件大事，一是百度成功登陆美国纳斯达克，成为中国互联网征战海外的标志性事件；二是湖南卫视《超级女声》总决赛落下帷幕，李宇春夺冠，比赛期间万人空巷，那一届超女至今仍是中国电视史上的流量巅峰。

这两件事之间有个不得不提的联系，那一年超女的流量压垮过国内绝大多数社区和论坛，百度贴吧是当时唯一能扛住的网络讨论区，因此迅速成为了粉丝们的主要根据地。

这完全超出了百度的预料，他们内测的所有数据，无一比得过李宇春；为了减轻系统负担，管理员删掉了张靓颖吧一栋有三十余万跟帖的高楼，惹得众人不快，他们惊觉为此上门前来交涉的粉丝带头人竟然还有高校教授……

超女这股东风，是贴吧崛起史上浓墨重彩的一笔，让老百度人印象深刻。同时，这也从侧面反映了一个事实：百度比现在任何一家云巨头，都更早地接受了高并发的考验。

不光是贴吧火热，百度上市后的两三年时间里，新产品层出不穷。

百度人逐渐意识到一个问题：不能每个新产品的所有构成都从头做起吧，能不能摸索出一些通用的、可复用的基础模块或服务，减少工程师们的重复劳动？

于是一个叫ibase的小部门成立了，侯震宇（现百度集团副总裁）担任负责人，它的职能是最大程度上统一百度非搜索业务的技术底座，建立一些基础的通用库。

多位亲历者告诉雷峰网，从打造通用技术底座的角度，百度云的历史应该可以追溯到2006年。

2006年，百度世界大会发布了百度的博客产品——百度hi。百度hi开始向用户提供图片的存储和展示功能，其中，图片存储功能被做成了一个可以通用的存储模块。

这里就是百度云的发端，也是中国互联网最早的面向C端的云存储系统的雏形。

“百度网盘现在这样的大存储，也是从当年我们云上的那个所谓的通用存储模块开始的。”百度早期员工回忆道：“把一些基础功能模块化让我们的研发事半功倍”。

2008年，iBase进一步升级为基础架构部。

这支团队服务的主要还是搜索之外的产品，目标也很明确：把各个业务下面重复出现的存储、公共库和基础服务抽出来，变成公司可以反复使用的底座。

这时候的百度，实际上同时存在两套基础设施。搜索有自己多年积累下来的存储、计算和在线系统。另一边，空间、贴吧、知道等产品又沿着iBase，逐渐形成一套非搜索业务的通用底座。

很快，2010年百度开始动手整合，在原有的基础架构部上，建立一个更大的公司级的基础架构部，目标从针对非搜索产品，变成把所有的百度技术底座打通。

搜索多年形成的存储和计算能力，非搜索业务积累的通用服务，以及下面的机器和系统资源，开始被重新放进一套公司级基础架构里。

这是百度基础设施和工程体系第一次真正走向公司级统一。

当时搜索架构的林仕鼎、廖若雪和原基础架构部的王劲、侯震宇以及黎科峰等人，组成了最早一波百度云的创始团队。

2010年也是百度在PC互联网时代的顶峰和股价的一个高峰，资金充裕的百度工程师开始大规模采买各种服务器。据悉当时的服务器规模只有小几万台，百度大手一挥，很快立项了两个十万台量级的机房项目。

当管理的资源上了一个新的台阶，后而达到恐怖的量级的时候，百度开始考虑搭建一种可以横向拉通的底层基础设施。

这种架构的实施的外在之一，就是BAE（Baidu App Engine）。

在谷歌也有对应的概念GAE（Google App Engine），“这可能和现在的PaaS，从技术上是不太一样的，但是理念上是一致的，就是基于云的技术底座上面的一层。”

有资深业者认为，谷歌的GAE和百度的BAE，本质上可以看做是第一代有PaaS概念的云产品，目标都是为了让用户在一个比IaaS层更高、用户使用方便程度也更高的层次上使用云和一些底层能力，但这些概念并没有转化为今天的主流PaaS或者说云原生架构，属于“太超前的尝试”。

2011年移动互联网风起。当时百度没有将云纯粹作为基础设施来做，而是将其作为移动生态的组成部分，BAE、PCS个人云存储、LBS云、移动测试等能力陆续被推到前台。

百度过去多年只服务于内部业务的技术，开始以平台和服务的方式向开发者开放。

回头再看，这条路线和后来流传的“百度错过云计算”并不完全一样。百度很早就碰到了云计算最底层的那些问题。

从2005年贴吧经历的高并发，到2006年的百度空间倒逼百度开始做通用存储。

在Jeff Dean的影响下，百度又开始把这些零散的技术积累放进一套更大的基础设施框架里，再通过BAE把它从内部基础设施推到了平台层。

Jeff Dean留给百度的，不只是用了什么系统，也包括后来怎么造系统。