百度陈尚义：大数据时代的搜索与应用 2012年7月22日下午，由北京大学信息化与信息管理研究中心、北京大学CIO班教务办公室主办，CIO时代网承办，北达软协办的首届中国大数据应用论坛在北京大学北配殿成功举办。来自各企事业单位领导、行业权威专家、信息化负责人等出席了本次论坛，就如何挖掘大数据价值、大数据时代的应用等问题进行了分享和交流。 百度技术委员会理事长陈尚义先生在论坛上做了关于《大数据时代的搜索与应用》的主题演讲，以下为演讲实录：百度技术委员会理事长陈尚义先生 尊敬的各位领导、各位嘉宾大家好！刚才听到宁老前辈所做的报告，还有王主任的演讲，都非常高瞻远瞩，对于大数据特性以及大数据所面临的挑战已经了如指掌，使得我的这个报告里头很多东西讲起来可能有点重复。再一个中国移动的孙所长所介绍的情况，又压缩了我的报告空间，所以感到压力很大。但尽管如此，互联网发展很快，百度情况发展也很快，所以今天我跟大家讲一下我们面临大数据方面所采取的办法以及未来所要做的事情。在这里跟大家做一个报告。 百度是做搜索的，很多公司都是说我们公司是业务驱动，但我们是需求驱动的。过去十年里互联网发展非常快，几个数字可以证明。

首先比如说网民数量，还有就是大数据。今天我们的主题是大数据。数据量的增长是非常惊人的速度，以至于后面我们在不断优化情况下，我们的服务器数量每年增长是以往库存所有数量总和还要多，而且这个趋势会进一步蔓延。为什么会这样？因为我们的设备现在变的非常的容易，像大数据、多媒体数据向互联网上传，过去是文字的东西多，现在带宽也宽了，设备也先进了，所以后台压力很大。每年会投资很多购买相关的设备，优化存储性能。当然还有很多的数据可以表示互联网发展速度快，这里就不一一介绍了。 为什么百度具有大数据？因为百度作为搜索公司，百度要处理的是全互联网的数据。你想找的信息是全互联网，而其他互联网公司不一样，仅仅是自己产生的内容。百度要把全球所有中文网页集中在一起，这些中文网页总共有多少呢？有3000亿个网页，占用存储空间是10到50TB。除了网页之外，百度现在非常大的日志以及清洗过的日志变成数据仓库，还有10个TB，还有广告和百度用户产生的内容，目前是百个TB的量级。我加入百度时间并不长，那时讨论的是10个TB甚至是更小一点的规模，而现在经过了这么长时间，是100个TB，我们架构师在对1000个TB做准备，相信很快就可以到来。

搜索数据的特点，刚才也讲到了一些，比如大数据不仅仅是大，而且也因为它的复杂性结构，还有易变、多变性。搜索数据除了这些之外还有很多特性，比如结构化和非结构化大量并存，这使得对存储架构造成了非常强烈的冲击；比如记录大小差异巨大，比如小的可能是几个字节，甚至是零字节，大到一个视频，可能是好几个T；再一个就是一致性强弱不一样，大家知道百度是做搜索推广，搜索推广数据存储了用户各种广告信息、用户信息，它在运行过程当中实际上直接变化的就是钱的多少，对这样的数据我们有非常强一致的要求。而网页数据对其一致性要求就不是那么强烈；还有一个特点就是数据冷热不均，就是变化快。这个对于百度影响尤其明显。比如说前段时间的黄岩岛事件，黄岩岛这几个字在平时我们大家不知道，或者说不关心这个事，它是处于冷的状态。当菲律宾向中国提出挑衅的时候，黄岩岛就成为了敏感词、热词。那么搜索引擎就要在你打出黄后面拼出岩岛。还有一个特点就是突发访问，跟数据冷热不均有一些关联之处。还有一个特点是线上线下需求不同。我们线上会提供一些应用，比如百度文库、百度知道。再比如说我们对于网页抓取、处理等等这是线下的很多事情。[page] 这是搜索引擎公司数据一些特点。

搜索也是在不断的发展过程当中，它对数据要求、对大数据处理也提出了非常严格的要求。比如说高可用、高可靠、高通量、高实效、高并发、低延迟、一致性、可扩展、全局有序。 尤其是高实效性，一方面大数据增长使得时效性比较难以达成，再一个是其要求越来越高。比如说互联网刚刚开始的时候，提交一个关键词，你在几秒钟之内得到结果，你不觉得它有问题。你觉得拿到结果就很不错了。如果说现在1秒钟之内没有得到百度搜索反馈，你心情就觉得很烦躁，觉得有问题。除了反馈速度之外，时效性对我们要求也是很多的。比如说推广，你把钱交给百度，需要很短时间内把广告展现出来。百度方面这个需求比你更加急迫，因为你交的预存的钱。还有热词学习也有时效性要求。如果说现在黄岩岛这个词才识别出来，肯定黄花菜就凉了。当然过早也不行，一定要恰恰好在时间窗口里面掌握好，要提醒用户。时效性要求很高，那也给我们造成了很大压力，比如说数据量越来越大，机器集群越来越多等等很多因素造成时效性要求很难以达成。 比如可扩展性，对互联网公司要求非常苛刻。现在有的机器集群规模达到10万台服务器的规模。在这个规模里头，坏掉的可能性是非常大的，事实上每年会坏掉很多服务器。

在这个过程里，坏了之后要去掉，不仅仅是去掉，它原来运行的数据进程还要转移到其他的服务器。在这种情况下，我们不可能要加上一个机器还要做很多工作，而是把它拿掉，把新机器替上，自动替换掉原来的工作。这是可扩展性方面。 在大数据的可扩展性，就使得我们必须水平扩展，而不需要做其他工作。之后我会详细介绍。 另外是全局有序，全局要做一些相应的工作。对于数据来讲，我们发现用户越来越多的要求是按照区间来查找，反映到我们内部来讲是要按照区间查找，实际上是要对所有网页进行全局排序。 快速增长，刚才我已经讲过了，扩展方式也比较简单，这也是业务对我们提出的一些要求。还有很多其他的要求，这里就不一一做详细介绍了。 刚才也说了，Hadoop已经成为事实标准。对，我们也是这么认为，认为它在大数据处理方面做出了很重要的贡献。但是它在百度公司成立很久以后的事情。实际上我们成立之初就面临着这样的问题，大规模的数据。 百度系统某种程度上有借鉴Hadoop的思想，但是百度系统是自主研发的存储体系。事实上开源系统无法满足百度的需求，首先因为性能受限，我们无法在它上面做大规模优化，特别是新硬件出现。在我们存储体系里头，我们大量的使用了新的SSD、新的flash。

还有无法针对百度自己特有的系统，无法针对自己业务特点做访问模式优化。 实际上百度这样的搜索引擎公司，每天面临着很痛苦的过程。为什么呢？因为数据量是在不断扩大的，而没有工业界的东西可以供百度使用，也没有现成的经验可以供百度借鉴。也许在Google这样的搜索引擎公司里头，会有相关的东西，但是它绝对不会给我们。国内的互联网公司在某些领域积累了很多经验，但是也是在动态当中突破一个又一个的技术瓶颈，迎来一个又一个的挑战。在这个过程当中甚至来不及，即使有这个心愿，可能他也来不及跟你交流。那么遇到问题时必须依靠自己去解决。 通过刚才的介绍，大家可能比较容易看出来，百度的数据除了满足大数据四个V所有特点之外，其实还有其他要求，例如一致性、数据冷热不均、突发访问等等要求。 面对这样一些大数据的挑战，百度在这方面做了很多努力。搜索引擎公司首先就是要把网页抓取回来，抓取的效率是一个非常重要的环节。为什么这样讲呢？面对3000亿网页数据，如果说写的速度不成问题，那么这个环节不成问题。但如果我们每天不更新库的话，网民会很快离开我们。所以我们要在一天之内完成所有工作，除了挖取还要写。这样的数据会存在磁盘上，随机写是一个很大的空白大数据时代 百度，速度很慢的。

所以说超大规模数据采集是我们必须要解决的第一个大问题。 第二个问题，搜索引擎发展到今天不仅仅是抓取数据，特别是百度2008年以后提出了一个概念是框计算理论，很多是第三方用户给我们推送过来的数据。过去我们抓取是说百度到外面抓，而这个数据是通过别人推给我们的。（PPT）当中也可以反映出我们如何跟第三方用户衔接。 整个对于网页处理过程（如PPT），抓取的数据我们放在Web Page storage，然后就是build（生成摘要和索引的过程）。这些数据是比较结构化的数据，因为是按照我们要求推的数据，就无所谓生成摘要和索引了。 我们的存储体系（PPT），百度根据自己的特点分成了几个系统，包括bailing系统，主要存储的是网页目前是50个TB、Bola Armor，主要是广告，数据量达到10个TB，还有日志，这个数据量是最大的，有100TB。还有关系型数据（通过分布式定制化用于处理百度内部部分比较少量的结构化数据）。这是我们正在使用的新的存储体系。底层就是持久化的，Flash、Disk。上面还有Table、Pipe、File、K/V，再往上有Data Access layer，P2P服务、CDN。

为了说明后面的一些情况，我必须把这个图里面的个别部分跟大家做一个介绍。（PPT），这是我们对外提供云存储服务的架构。中间最长的方块里头我们叫前端接入模块。下面有几个模块，比如数据提交模块，它下面有Data存储模块和Meta存储模块。我想说的消息队列和Data、Meta。Meta跟Data分开，以及其各自独立性使得可以水平扩展。消息队列是把存储模块和各种服务模块实行了节耦合，两边可以同时互不干涉或者互相没有耦合的改动和扩展，这集中体现了我们为拓展做准备的架构体系。 百度可以归纳为八个方面的努力。第一是网页更新模型。将随机问题转化为批量的顺序处理。我们把写的工作，一开始不直接对磁盘进行写，而是把它作为操作以及操作对象，给它存储起来。然后用Patch加上原来的base，使得其成为瞬时写的操作。我们在大量数据存储，尤其是放在disk这样的设备之上，有一个特点是顺序写非常容易。所以我们把困难的随机写改成了顺序写。这不是一个特别新的话题，这是一个比较传统的技术，但是百度把这个技术用到了极致。最终效率提高很多，所以使我们的更新3000亿网页的工作一天就可以完成。 第二就是全局优化。具体来讲针对访问模式做的优化，针对不同访问模式，有的是读有的是写。

还有是针对硬件特性做的变化，这里我要强调一下，不同硬件特性我们也有不同的硬件作为传统设备。我们是一天24小时做工作。不同的存储设备有不同的特点，我们会针对不同特点做优化。比如说根据服务对象、所承载业务进行配比。 第三就是依访问模式定制硬件，以及单机性能提高，还有与CDN的结合。这是全局方面通盘考虑。[page] 还有一个是SpecialFlash。它作为标准产品有一个东西叫FTL。对存储设备写入之前进行校验和安全检查。在百度所采用的所有的Flash设备把这个地方拆掉了，目的是为了加快它的写入速度和增加了存储硬件。因为FTL占了将近20%的空间。为安全性检查以及校验工作我们在上层已经解决掉了。这个地方可以最大限度利用存储设备。 多副本存储。一个文件它有多个副本。这是为了备份需要，当然也不仅仅是这样。比如说当服务器有一些坏掉的时候我要识别出来，给它踢出去，让新的设备替上来。多副本存储对这种情况起了很大的作用。这样的话原来数据还能找回来。部分程度上实现百度在数据牵引上的工作。数据牵引不是真的从一个服务器从第一个字节拷到另外一个里面去。 还有一个是我们自己发明的，Replication Protocol。

类似于互联网协议TCP。跨Group保持数据的一致性。当数据写到Primary时必须保证写到secondary。中途失败的话全部取消，要么是0要么是1。 刚才我讲了很多。下面要讲一下数据分治。刚才讲了解耦、独立性，互相是独立的才实现水平扩展（线性扩展）。它是什么意思呢？比如当服务器坏了，来个服务器往上一扔就可以直接工作。还比如说由10万扩大到15万，我加5万台就可以顶起原来的规模，这是线性扩展。扩展起来当然也没有那么简单。时间关系就不详细介绍了。 还有一个是拆片存储。当一个文件很大的时候，我们的文件最小的是几个字节，最大的是几个T的文件，对于大文件来说，所占用的服务器很可能成为整个网络的瓶颈。这个时候需要把它拆到不同的服务器里去，让瓶颈的问题得到解决或者是让服务器之间的负载获得比较均衡。如果一个数据、文件很大，比如说一个视频，它又很热如果集中放在一个服务器或者某几个服务器上的时候，那么这几个服务器会成为瓶颈。通过拆片存储可以解决这个问题。 还有一个是局部更新。当一个大文件局部发生改变，我们要写回磁盘时，在磁盘上写操作只是涉及到修改的那一小部分。 这里我再介绍一下三层模型。这是一个高度、概括抽象的。

当我们热数据放在Memory里（访问频次高），Flash是其次。热的数据放到Memory里，当它满的时候，根据某种策略然后给其放到Flash里去，依此类推。如果冷的数据还得往回走。三层模型展开以后就是这样的一个模型（PPT），这是百度大数据方面的一些实践。 下面介绍一下大数据的应用。首先我要介绍一下百度的开放平台，由于百度十几年来做了一件事情，就是在后台管理超大规模数据资源和超大规模计算机资源，就是服务器集

来源【首席数据官】，更多内容/合作请关注「辉声辉语」公众号，送10G营销资料！