深度图计算系统进展和展望.docx
- 文档编号:2966298
- 上传时间:2022-11-16
- 格式:DOCX
- 页数:7
- 大小:24.16KB
深度图计算系统进展和展望.docx
《深度图计算系统进展和展望.docx》由会员分享,可在线阅读,更多相关《深度图计算系统进展和展望.docx(7页珍藏版)》请在冰豆网上搜索。
深度图计算系统进展和展望
深度图计算系统进展和展望
挖掘大规模图数据能增强现有商业业务,甚至产生新的商业模式。
然而,这些图数据的规模让图数据挖掘本身成为难题,这些突出的挑战都指向了发展具有高可扩展能力的大规模图计算处理的有效工具。
本文先展开叙述图计算技术的几个核心层面,进而介绍华为诺亚方舟实验室的VENUS图计算系统,最后对图计算发展的趋势作简要展望。
背景大量不同个体之间彼此交互产生的数据以图的形式表现,在通信、互联网、电子商务、社交网络和物联网等领域中积累了大量的图数据。
其规模巨大并且不断增长。
简言之,图由节点(即个体)与边(即个体之间的联系)构成;而图数据是不同领域的数据中有这种图结构的相关部分。
由Web网页和页面间的超链接构成的图或者社会网络中的不同用户和用户之间的关系链(见图1)都构成了大规模图数据。
据CNNIC统计,仅在中国的Web页面所形成的图规模在2010年就达到600亿节点,并以78.6%的年增长率不断增大。
Facebook的社交网络在2011年已超过8亿节点;而腾讯QQ社交网络目前在10亿个节点的规模。
在电信工业中,广州市仅一个月内由电话呼叫方和被呼叫方组成的图就操过4.5千万个节点、1.5亿条边。
而著名的ClueWeb数据包含全量的Web站点和网页,2012年公布的数据集已经达到1亿个节点、425亿条边,仅是存储边的列表的磁盘文件就超过400GB。
图1社会网络中的不同用户和用户之间的关系链构成了大规模图数据
非常有价值的是:
挖掘这些大规模图数据能增强现有商业业务,甚至产生新的商业模式。
然而,这些图数据的规模让图数据挖掘本身成为难题。
比如ClueWeb图的全量SimRank计算需要几千年。
这些突出的挑战都指向了发展具有高可扩展能力的大规模图计算处理的有效工具。
虽然业界经过多年的实践发展出MapReduce和Spark等主流大数据平台,但图挖掘任务有其本身的独特性:
由于数据之间依赖性强,使分布式处理模式需要频繁地在各个机器之间进行数据交换;且图挖掘算法流程本身由多次迭代处理构成。
因此,主流大数据平台公认被不适合处理图挖掘任务[1],而基于图计算的大数据分析平台成为了图挖掘和相关机器学习算法的新方法。
代表之一是Google提出的Pregel系统[2],Google称20%的数据处理是使用Pregel实现的,图计算是成功的数据挖掘处理框架。
然而,Google一直没有将Pregel的具体实现开源,外界争相对Pregel进行模仿实现。
2012年,卡内基梅隆大学教授CarlosGuestrin提出了分布式GraphLab框架[3],引起业界的广泛关注。
据Guestrin介绍,GraphLab在推荐系统中有很多应用,其他主要应用领域还包括互联网欺诈侦测和入侵探测等。
GraphLab项目剥离出一个独立运作的商业公司GraphLabInc,由CarlosGuestrin负责。
2013年5月,该公司从MadronaVentureGroup和NEA募集了675万美元资金并于2015年1月再得到1,850万美元的B轮融资。
在2016年8月,这家图计算公司被苹果以2亿美元左右的价格收购。
例证了图计算在大数据趋势下的重要性和在人工智能产业发展中的必要性。
本文以下先展开叙述图计算技术的几个核心层面,进而介绍华为诺亚方舟实验室的VENUS图计算系统,最后对图计算发展的趋势作简要展望。
图计算核心技术随着大规模图数据分析的需要,近几年涌现出了很多图计算系统,其中值得注意的标志性工作有:
Pregel[2]、GraphLab[3]和GraphChi[4]等。
类似于现有Hadoop/Spark大数据框架通过MapReduce这样的简单接口函数去实现各种分布式集群处理任务,图计算的基本思想是使用“thinklikeavertex”去抽象表达图挖掘及相关机器学习算法,使得各种数据挖掘任务可以变为编写顶点程序(vertexprogram)并通过现有的图计算系统执行得以完成。
顶点程序计算更新图中顶点和邻接边的计算状态。
而这些计算状态进一步被其他顶点程序执行时调用。
图计算系统按BSP并行机制(Pregel)或异步并行机制(GraphLab)在计算集群上调度所有的顶点程序,并加入一定的容错机制,比如快照恢复。
这样,图计算任务自动具有容错的并行处理,从而极大地提升数据挖掘算法的可扩展性。
具体些说,图计算系统预定义好的一个虚函数update(),通过对其重载以实现表达用户逻辑的顶点程序。
于是,图计算系统将该函数对每一个顶点进行调用。
update()方法可以访问使用的是当前顶点及其边的信息,以及入边的顶点及其边的信息;同时可以修改一个顶点以及与它相连的边上的权值。
在图计算完成一个算法的多次迭代中,每次迭代就是系统完成一遍在图的每一个顶点上执行更新函数。
由于Pregel采用同步执行模式等原因,速度较慢,目前GraphLab和GraphChi已经分别成为了分布式图计算系统和基于磁盘单机图计算系统的业界标杆。
GraphLab是基于内存的分布式图计算系统,一个图被分割成多个子图,每个子图保存在一台计算机的内存中。
图的分割采用选取顶点切开图的方式。
分开之后,选出来切图的顶点进一步并入所有和这些顶点有邻接关系的不同子图中。
这样,每个切图的点就同时有多份保存在多个主机上。
所以在每次图计算迭代中,每台主机都执行该主机上的子图内的顶点上的更新函数,每次更新过的顶点的计算结果值都需要同步到其他主机该顶点的备份上去。
图数据包括图的顶点和边,以及顶点和边上的值。
所以,虽然GraphLab不需要用网络传输图的结构信息,但在计算过程中,GraphLab仍然需要大量的网络开销传输同步顶点的值。
从卡内基梅隆大学的GraphLab项目分派出一个发展很快的分支:
GraphChi。
它将数据挖掘算法自动转化为基于外存算法和核外处理(out-of-coreprocessing),图不需要被分割成子图就能处理执行vertex-centric计算模型。
这样,即使一台PC也能处理大数据分析的任务。
在基于磁盘的单机图计算系统GraphChi中,一个图被分割成多个数据片,每个数据片保证可以被放在内存中。
每个数据片包含一个完整的子图,包括一个连续的顶点区间和这些顶点的入边与出边。
基于磁盘的单机图计算系统的图计算也是由多次迭代组成,每次迭代,系统在每个顶点上执行一次用户定义的更新函数。
在每次迭代中,系统依次处理每个数据分片,并在每个数据分片内并行执行更新函数,并行仅是多个线程间的单机并行。
GraphChi解决的一个主要难点是如何使用高效的I/O代价完成数据挖掘算法。
由于基于图计算模型的数据挖掘算法的数据是作为图上的信息全部存储到磁盘上,一个迭代通常需要扫描整个图模型的数据存储。
一次扫描一共需要读取|E|个数据单元,因为数据是根据图的边来存储,这就是说,一个迭代可能会最多引起|E|个读和写的操作,即2×|E|次磁盘I/O。
为了解决这个问题,GraphChi的核心思想是经过仔细设计边在磁盘上的排列分组以配合图计算模型,使得任何基于这个图计算模型的数据挖掘算法完成一个迭代只需在P2次磁盘读取操作和P2次磁盘写入操作。
这种机制被命名为滑动窗口机制(ParallelSlidingWindow,PSW),是将图的顶点按顶点ID的区间(interval)分成P份。
区间不是均匀的,但数据分片(shard)的大小统一,所以区间大小由其对应的数据分片(shard)大小决定。
数据分片就是区间内每一顶点与其相连的所有入边构成的所有子图的集合。
这就是说,数据分片包含了图中所有指向区间内顶点的边,这些边的数目在不同数据分片中基本相同。
而数据分片的这些边进一步按源顶点的ID升序排列。
数据分片的大小选取以主存能容纳最大的数据分片所确定。
当计算机主存无法容纳全部图数据进行内存计算的时候,GraphChi这种图数据的磁盘存储设计使得图计算能具有I/O高效的性质。
在一个图计算算法的处理过程中,GraphChi一次读入一个数据分片到主存,从而相应区间内的所有顶点的入边就都可用了。
而这些顶点的出边必然存于剩下的P-1个数据分片中。
并且由于各个数据分片的边都按源顶点的ID升序排列,这些顶点的出边必然在每一个数据分片内的一个连续区域中。
所以,一个顶点区间内的所有同时具有入边和出边的子图都可以由一次数据分片全扫描和P-1次数据分片部分扫描完成。
对内存中得到的这些子图,GraphChi把基于不同子图的计算任务并发到多个线程中处理。
当所有的计算完成后,所有边上的数据更新都可由当前的数据分片全部写回和剩下的P-1个部分数据分片的写回操作完成。
这种方式,GraphChi按照顶点ID的升序依次处理P个数据分片就能完成一次所有的图中的顶点程序的计算,这通常是机器学习算法的一个迭代。
所以,任何一个迭代一定能在P2次磁盘读取操作和P2次磁盘写入操作完成。
以上过程的顶点程序的计算是严格按照顶点ID由小到大来执行的,因为首先整个顶点区间按照顶点ID升序枚举。
而在一个顶点区间内,虽然不同子图的计算任务并发到多个线程中处理,但GraphChi会提前检查是否存在这样的顶点它们的入边同时也是该区间内某顶点的出边,这些边会形成冲突。
GraphChi让具有冲突出边的点先执行,从而整个处理都能保证具有确定性(deterministic)的可序列化(serializable)操作。
进而保证了程序并行处理的正确性。
分布式计算系统(如GraphX[5]、Giraph[6],Pregel、和GraphLab)可以处理10亿顶点——规模的图数据,然而这些方案也同时需要大规模计算机集群,存在对相当部分用户来说过高的代价。
与此同时,基于磁盘的单机图计算系统(如GraphChi、X-Stream[11])提供廉价且有竞争力的处理能力。
例如在一个有15亿条边的Twitter社交网络上运行PageRank算法,Spark需要50台计算机(100个CPU)和8.1分钟,而GraphChi只需要1台MacMini和13分钟[4]。
华为诺亚自主研发的图计算系统VENUS只需要1台普通PC和5分钟。
诺亚图计算系统VENUS从2013年起,华为诺亚方舟实验室启动了大规模图数据挖掘的研究项目,负责研发图计算系统、图挖掘算法和商用。
学术上,该项目已产出了若干研究成果[7,8,9,10],取得了一定的技术突破;商业上,在华为的业务中获得了重要应用。
其中,所开发的图计算系统VENUS成为业界最快的单机图计算平台之一,能高效支撑各种大规模图数据挖掘应用。
目前,VENUS系统在华为手机应用市场中分析10亿量级的用户日志数据,支撑了重要的广告推送目标客户选择和手机应用推荐业务。
图2VENUS架构
当前图计算面临几大主要挑战是单机系统具有很高的磁盘IO并且无法有效利用较大的内存;而分布式系统需要处理很难得图分割问题,并且计算过程会产生很高的网络开销以至于成为系统整体的扩展性能瓶颈,GraphLab甚至会出现在增加节点时处理时间反而变长的情形。
为了应对这些挑战,VENUS图计算系统从最初设计开始考虑了一种新的扩展模式:
纵向扩展+横向扩展。
特别考虑在先不往外扩展(scaleout)数据的情况下,先充分发挥单个计算节点往上(scaleup)图计算系统的能力,再去大规模计算集群上往外扩展(scaleout)多节点上的同质的计算。
以处理计算量大,复杂度高的图算法。
基于磁盘的流水化计算模型VENUS提出的以顶点为中心流水化图计算模型将基于磁盘的图IO显著降低,极大改善了系统IO瓶颈突出的情况。
相对常见的大数据平台如Hadoop和Spark,VENUS的设计理念是往外扩展(scaleout)数据,在大规模集群上并发读取大数据,去应对大量数据所需要的大量IO。
VENUS有独特的基于外存算法的技术途径,称为基于分级存储的顶点为中心流水化图计算模型,已经在单机上突破图计算系统的可扩展能力,解决了如何有效利用磁盘带宽,减少图计算中访问海量图数据IO的问题。
在基于磁盘的单机图计算系统Gr
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 深度 图计算系统进展和展望 计算 系统 进展 展望
![提示](https://static.bdocx.com/images/bang_tan.gif)