Google的索引更新速度提升了100倍.docxVIP

经典论文翻译导读之《Large-scale Incremental Processing Using Distributed Transactions and Notifications》 英文原文：googleusercontent，编译：ImportNew - 储晓颖【译者导读】Percolator号称其取代MapReduce之后，Google的索引更新速 度提升了100倍。它究竟是如何实现 “100” 这个刺眼的数字？当今的并行计算世界真的有如此大的提升空间吗？当我们满心欢喜以为又有新的算法、新的并行计算架构可以学习时，她却又为何跟你聊起了分布 式事务？这篇文章将为您揭晓。摘要在搜索引擎系统中，文档被抓取后需要更新web索引，新的文档会持续到达，这就意味着包含大量已存在索引的存储库需要不断变化。现实中有很多这样的 数据处理任务，都是因为一些很小的、独立的变化导致一个大型仓库的转变。这种类型的任务的性能往往受制于已存在设施的容量。数据库能够很好的处理这种任 务，但是它不会用在如此大规模的数据上：Google的索引系统存储了十几个PB的数据，并且每天在几千台机器上处理数十亿次更新。MapReduce（后文简称MR）和其他批处理系统是为了大型批处理任务的效率而量身定制的，并不适合单独的处理小的更新。所以我们创建了Percolator，一个在大型数据集合上增量处理更新的系统，并且已经部署上线用于构建Google的web搜索索引。通过将基于批处 理的索引系统替换为Percolator，我们每天处理文档的数量相同，而搜索结果的年龄却减少了50%（比如本篇文章在今天中午12点发布，在 Google上能在下午一点被搜索到，那年龄就是1个小时）。1. 介绍在web索引系统中，系统开始会抓取互联网上的每一个页面，处理它们，同时在索引上维护一系列的不变量。比如，如果在多个URL下抓取到了相同的内 容，只需要将PageRank最高的URL添加到索引中。每个外部链接也会被反向处理，让其锚文本附加到链接指向的页面上（链接中的锚文本往往能比较准确 的评估其指向页面的内容）。链接反向处理还要考虑复制品（意指内容相同的多个页面）：在必要的情况下指向一个复制品的链接应该被指向最高PageRank 的页面（这样能增强最高PageRank的页面的评估）。上述任务能够被表达为一系列的MR操作：一个用于页面聚类分析，一个用于链接反向处理，等等。在MR任务中维护不变量很简单，因为它是组织型计算（计算是 按照一定逻辑和安排执行的，该并行的地方并行，该有序的地方有序），限制了计算的并行；所有文档都是按照步骤依次完成一个个阶段的处理。比如，当索引系统 正附加锚文本到当前最高PageRank的URL时，我们不需要担心它的PageRank会并发改变：之前的MR步骤已经完成了PageRank的计算， 确定了它的PageRank。现在考虑一下，在只重新抓取了一小部分文档时如何处理。对于MR来说，仅仅对新抓取的页面执行作业是不够的，比如新来页面和已存在的老页面之间可能 会有链接关系。MR必须在整个库之上再次运行，也就是说，既包括新页面也包括所有老页面。如果提供足够的计算资源，加上MR的可扩展性，这个途径确实是可 行的，而且事实上，在Percolator问世前，Google的索引制造一直都是按这种方式。然而，对整个库再处理的做法丢弃了之前的工作成果，延迟随 着整个库的增长而成比例增长，而不是这一次更新的量。【译者注】MR之所以不能有效重复利用上一次的工作成果，其中一个原因是索引制造的 计算不是“mergable computation”。mergable用数学公式表达就是：在mergable函数y=f(x)中，对于x中任意的子集x1和x2，此公式可以表示 为 y=l(m(x1),n(x2))。也就是说x中的数据无论怎么切分，都可以逐一基于上一次的结果进行计算。译者找到另一篇incoop的论文，它用MR的视角来诠释了传统的MR为何不适合增量计算：如图所示，假设First run中Reduce的结果为A，在第二次计算时(2)出现了，要为它执行增量计算，能不能直接将(2)的值与A进行计算得到新的结果？答案是不一定。假 如这个MR仅仅是对1到23各个数据进行求和，那就可以直接将A+(2)得到新的值（这就是mergable computation）。假如不是mergable（比如是将1、2、3、5的和与6到23的和相除），不仅1、2、3、5要重新计算，6到23都需要 重新计算（因为MR仅仅保存了最终Reduce结果，丢失了中间计算结果）。这就是为何Google要重复的执行全量的MR。对于此问题，译者曾发邮件给 作者Daniel Peng，他的回复是：There are partial resu