数据收集和存储的速度正在惊人地发展,对Google而言,数以万计的服务器中存储的PB级数据,以及每天在服务器中处理的数以亿计的图片文件,都对其未来的系统架构提出了新的挑战。重新设计系统架构以此优化搜索引擎的增量处理能力已是Google当务之急。
在此背景下,Percolator诞生了——谷歌日前公开表示,将内容索引系统从Mapreduce上迁移至Percolator上。目前该系统已经在2010年交付于Google的搜索索引内容,并按照系统需求有步骤地进行增加。按照Google官方给出的解释是,在Google的应用场景中,其作用在于将搜索的网页引入索引,在爬取的文件的同时,Google的主系统能够同时进行数据处理,系统可平均可以减少50%-100%的延迟时间。
必然的,Percolator的工作原理以及Mapreduce未来的技术方向成为了众多技术人员所关心的问题。
Percolator的设计新思路
日前,Daniel Peng和Frank Dabek发布了一篇关于Google新的内容索引系统——Percolator的论文,在其论文中,着重谈到了Percolator的工作原理。
他们表示,作为一个基于BigTable的系统,Percolator在功能上其非常类似传统数据库的触发器(Trigger),但是在伸缩性方面有其独到的设计。
Daniel Peng和Frank Dabek解释说,索引检索是一个批量处理任务,过去,当更新网页索引后数据仓库中的现有文件同时需要进行更新,这个工作可由MapReduce进行完成,问题是,MapReduce和其它批量处理系统创造了大数据批量,因此无法处理单个小规模的数据更新。Percolator系统便是为了解决这一问题,它能对一个大数据集增量处理更新。
“Percolator的设计原理其中之一在于提供一个能够随机访问的文件库,并单独进行处理,以替代MapReduce的全局式处理方式”,Daniel Peng在论文中写道,“快照隔离——这是Percolator的设计核心,其目的在于提供cross-row、cross-table、ACID兼容性等数据交换。”
此外,Percolator还提供了一个类似系统观测员“observers”的功能,意思是一旦用户对指定的列进行更改,系统将进行自动调用,“目的在于协助开发人员保持服务器计算状态的跟踪”。
所有observers都会连接到Percolator的工作进程上,Percolator需要调用相应的observers作为工作进程中的一个函数,observers会在扫描Bigtable后改变列。observers执行相应进程——发送读/写RPC服务数据库操作到Bigtable tablet服务器上,然后再发送读写RPC服务数据库操作到GFS模块服务器上。
Percolator并非完美
但是Daniel Peng同时指出,Percolator是专为增量处理而建立的,而非取代Google现有主要的数据处理方案。毕竟Mapreduce在将分布式计算方面尤其是处理序列文件方面处理得更好。
“Percolator并非执行操作管理的核心,原因在于其缺乏全局的lock detector”,Daniel Peng表示,Percolator并没有像传统的OLTP数据库管理的低延迟运行要求。
实际上,Percolator是建立于BigTable上的分布式存储系统的顶层架构,在每个集群系统中,其由三个采用二进制计算的服务器所构成:一个是工作服务器,一个BigTable tablet服务器,一个Google文件系统服务器。
Percolator的线性架构是在大量的服务器之上。在性能方面,Percolator介于MapReduce和传统的DBMSs之间。和传统的DBMSs相比,由于其分布式的数据体系结构决定了它必须使用更多的硬件资源进行处理。而和MapReduce相比,Percolator由于有observers的存在,能够将数据延迟变得更短。
在该论文中,Daniel Peng指出,Percolator更适合于计算需要保持一致性的环境,其对数据量、CPU等有更庞大的需求,而在构建Percolator的过程中,需要改造大量服务器上数据仓库的多线程运算方式。
与此同时,Percolator架构的增加同时意味着服务器数量的大量增加,这同时增加了潜在的运行冲突,但由于其可以扩展到数千台服务器以增强其运行能力,它能够让用户更准确的判断系统状态,将错误规避在形成数据栈之前。