Percolator：大数据集增量更新系统

随着需要收集和处理的数据规模以惊人的速率增长，曾经只有Google级别的系统才会遇到的可伸缩性需求变得更普遍，并常常需要专门的解决方案。Daniel Peng和Frank Dabek最近发表了一篇论文，介绍Google索引系统Percolator的技术细节。Percolator目前运行在数千台服务器上，存储了数十PB的数据，并且每天要处理数十亿次的更新。

在抓取网页的同时进行索引更新，意味着在新文档不断加入时，需要对已有的总文档库进行持续地更新。这是通过小规模、独立的变换实现海量数据转换任务的一个典型范例。现有的技术基础平台恰恰不能胜任这样的任务：传统DBMS无法满足存储量和吞吐率的需求，而MapReduce和其它批处理系统无法逐个处理小规模更新，因为它们必须依赖于创建大量的批处理任务才能获得高效率。

Daniel和Frank解释说，尽管索引的过程是一项批处理任务，可以通过一系列的MapReduce操作来表现。但每次重新爬完一些页面后要更新索引的时候，由于新增文档和已有文档之间存在链接引用的关系，只对增量部分运行MapReduce操作是远远不够的，实际上必须基于整个文档库进行MacReduce操作。事实上在Percolator出现之前，索引就是以上述的方式更新的。这样带来的主要问题就是由于要对整个文档库重新处理而产生的延迟。

解决此问题的关键是优化增量数据的处理方式。Percolator的一个关键设计理念是：提供对库中文档的随机访问，以实现对单个文档的处理，从而避免了像MapReduce那样对文档全集进行处理。Percolator通过“快照隔离”实现了遵从ACID的跨行及跨表事务，从而满足多线程在多台服务器上对文档库进行转换操作的需求。Percolator还提供了“观察者（observer）”机制，在用户指定的列发生更新之后，这些观察者会被系统触发，以帮助开发者追踪计算过程所处的状态。

论文作者补充到：

Percolator是专门针对处理增量更新而设计，但不是用于取代大多现有的数据处理解决方案。那些不能被拆分为单个微小更新的计算任务（比如对一个文件排序）仍然最好由MapReduce承担。

Percolator更适合于在高一致性及在数据量和CPU等方面有很高需求的计算任务。对于Google来说，它的主要用途是将网页实时地添加到Web索引中。运用Percolator，Google可以在抓取网页文档的同时来对文档进行处理，从而将平均延迟降低为原来的百分之一，平均文档寿命（document age）降低50%。

Percolator建立于分布式存储系统BigTable之上。集群里的每台服务器上运行着三个可执行文件：worker，BigTable tablet服务器和Google File System chunkserver服务器

所有观察者都被关联到Percolator worker上，后者会对BigTable进行扫描，一旦发现更新过的列就会在worker进程中以函数调用的方式触发（"notification"）相应的观察者。观察者通过向BigTable tablet服务器发送读、写RPC请求来运行事务，继而触发后者向GFS chunkserver服务器发送读、写RPC请求。

Percolator没有提供用于事务管理的中心服务器，也没有全局锁侦测器。因为Percolator不需要像运行OLTP任务的传统DBMS一样，对低延迟有很高要求，所以它采取了一种延迟的方式来清理锁，也因此在事务提交时造成了数十秒的延迟。

这种方法增加了事务冲突时的延迟，但保证了系统可以扩展到几千台服务器的规模……尽管增量数据处理在没有强事务的情况下也能进行，但事务使得开发者更容易地去分析系统的状态，并避免将错误引入到长时间运行的文档库中。

Percolator的架构可以在普通廉价服务器集群上线性扩展多个数量级。在性能方面，Percolator处于MapReduce和DBMS之间。和DBMS相比，在处理同样数量的数据情况下，Percolator由于其分布式架构，资源消耗远大于DBMS，同时它还引入了约30倍的额外性能开支。和MapReduce相比，Percolator可以以低很多的延迟来处理数据，同时需要额外的资源来支持随机查找。Percolator自2010年4月开始为Google web搜索提供索引，它利用合理的额外资源消耗，获得了更低的延迟。

不知道读者们是否看见或者预见了对处理海量数据集的快速增长的需求了没有？前不久Phil Wehlan问了同样的问题，希望大家给他提供反馈。

查看英文原文：Percolator: a System for Incrementally Processing Updates to a Large Data Set