写点什么

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

  • 2010-10-24
  • 本文字数:1728 字

    阅读完需:约 6 分钟

随着需要收集和处理的数据规模以惊人的速率增长,曾经只有 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

2010-10-24 20:009744

评论

发布
暂无评论
发现更多内容

如何在API中实现搜索和过滤功能

数据追梦人

企业级软件定制:摒弃“银弹思维”,回归场景务实求解

TechLead Studio

软件研发

计算机网络协议介绍

京东科技开发者

诚邀加入天翼云用户体验官计划:您的洞察,重塑科技边界!

天翼云开发者社区

云计算

AI口语练习App的技术架构

北京木奇移动技术有限公司

AI技术 软件外包公司 AI口语练习

手把手教你用爬虫技术抓取1688商品详情与实现关键字搜索API——实战干货分享

代码忍者

1688API接口

京东中台化底层支撑框架技术分析及随想

京东科技开发者

音乐NFT项目的技术架构

北京木奇移动技术有限公司

区块链技术 软件外包公司 音乐NFT

shopeeAPI 系列:商品列表接口接入与应用

tbapi

Shopee shopee商品列表接口

通义灵码 - HTML智能编码辅助AI工具

阿里云云效

人工智能 云计算

添加DNS解析记录提示解析冲突是怎么回事?(国科云)

国科云

无需登录+离线调试,Apipost比Apifox更值得拥有

数据追梦人

shopee商品详情API接口(shopee API系列)

tbapi

Shopee shopee商品数据采集 shopee商品数据分析 shopee接口

第一期开讲!北京国家会计学院“数智财务高端人才”培养项目

用友智能财务

财经 会计

2025Q1大模型中标成绩出炉,百度智能云成为大模型“标王”

科技热闻

2025 中国人工智能教育大会召开,和鲸x智谱推出人工智能通识教育方案

ModelWhale

人工智能 高等教育 通识课 人工智能通识课

【解决方案】DistilQwen2.5-R1蒸馏小模型在PAI-ModelGallery的训练、评测、压缩及部署实践

阿里云大数据AI技术

人工智能 深度思考 大模型 模型蒸馏 DistilQwen2.5

安全运营 | 第十期「纵深防护·极智运营」度安讲技术沙龙成功举办

百度安全

2025年GitHub Star增长最快的15个开源低代码项目

NocoBase

GitHub 开源 低代码 零代码 无代码

电力生产和供应业需要堡垒机的情形简单聊聊

行云管家

网络安全 信息安全 数据安全 等保 堡垒机

智能制造常见系统,ERP、MES、WMS、SCM、PLM,一文吃透!

积木链小链

企业上云后,SRE认证为何成为企业“新宠”?

雅菲奥朗

SRE ITIL SRE培训 SRE认证

CloudWeGo 2025 黑客松报名指南

字节跳动开源

字节跳动 黑客马拉松 CloudWeGo hertz Eino

鸿蒙APP开发的技术架构

北京木奇移动技术有限公司

鸿蒙app 软件外包公司 APP外包公司

时序数据库 TDengine Cloud 私有连接实战指南:4步实现数据安全传输与成本优化

TDengine

数据库 tdengine 时序数据库

Web Components实践:如何搭建一个框架无关的AI组件库

京东科技开发者

2025年智能ITSM产品推荐

云智慧AIOps社区

ITSM ITSM软件 工单管理 工单系统

低代码平台终极拷问:NocoBase 像「乐高套装」,iVX 更像「3D 打印机」?

代码制造者

低代码开发 无代码平台

实习期间如何提升留用概率?

王中阳Go

Go 实习 厚度按

时序数据库 TDengine + Tableau,数据可视化一步到位!

TDengine

数据库 tdengine 时序数据库

谁在买王兴兴的机器人?「宇树科技」百笔订单梳理、分析!

机器人头条

科技 大模型 人形机器人 具身智能

Percolator:大数据集增量更新系统_Google_Jean-Jacques Dubray_InfoQ精选文章