云计算环境下的大规模图数据处理技术

分享一下我老师大神的人工智能教程！零基础，通俗易懂！http://blog.csdn.net/jiangjunshow

也欢迎大家转载本篇文章。分享知识，造福人民，实现我们中华民族伟大复兴！

                       

1. 引 言

图是计算机科学中最常用的一类抽象数据结构， 在结构和语义方面比线性表和树更为复杂， 更具有一般性表示能力。 现实世界中的许多应用场景都需要用图结构表示， 与图相关的处理和应用几乎无所不在。 传统应用如最优运输路线的确定、疾病爆发路径的预测、科技文献的引用关系等; 新兴应用如社交网络分析、语义Web 分析、生物信息网络分析等。

虽然图的应用和处理技术已经发展了很长时间， 理论也日趋完善， 但是随着信息化时代的到来，各种信息以爆炸模式增长， 导致图的规模日益增大，如何对大规模图进行高效处理， 成为一个新的挑战。

1.1 大规模图数据处理问题

以互联网和社交网络为例， 近十几年来， 随着互联网的普及和Web2.0 技术的推动， 网页数量增长迅猛， 据CNNIC统计， 2010年中国网页规模达到600亿， 年增长率78.6% ， 而基于互联网的社交网络也后来居上， 如全球最大的社交网络Facebook， 已有约7 亿用户， 国内如QQ 空间、人人网等， 发展也异常迅猛。

真实世界中实体规模的扩张， 导致对应的图数据规模迅速增长， 动辄有数十亿个顶点和上万亿条边。 本文所指的大规模强调的就是单个图的大规模性， 通常包含10 亿个以上顶点。 面对这样大规模的图， 对海量数据处理技术提出了巨大挑战。 以搜索引擎中常用的PageRank 计算为例， 一个网页的PageRank 得分根据网页之间相互的超链接关系计算而得到。 将网页用图顶点表示， 网页之间的链接关系用有向边表示， 按邻接表形式存储100 亿个图顶点和600 亿条边， 假设每个顶点及出度边的存储空间占100 字节， 那么整个图的存储空间将超过1TB。如此大规模的图， 对其存储、更新、查找等处理的时间开销和空间开销远远超出了传统集中式图数据管理的承受能力。 针对大规模图数据的高效管理， 如存储、索引、更新、查找等， 已经成为急需解决的问题。

1.2 采用云计算环境处理大规模图的优势

云计算是网格计算、分布式计算、并行计算、效用计算、网络存储、虚拟化等先进计算机技术和网络技术发展融合的产物， 具有普遍适用性。 云计算技术的发展， 一直与大规模数据处理密切相关。 因此， 依靠云计算环境对大规模图数据进行高效处理， 是一个非常有发展潜力的方向， 其主要优势表现在:

(1)海量的图数据存储和维护能力。 大规模图的数据量可达几百GB 甚至PB 级别， 难以在传统文件系统或数据库中存储， 而云计算环境提供分布式存储模式， 可以汇聚成百上千普通计算机的存储能力和计算能力， 提供高容量的存储服务， 完全能够存放和处理大规模的图数据。 云计算环境下的并发控制、一致性维护、数据备份和可靠性等控制策略， 可以为大规模图数据的维护提供保障。

(2)强大的分布式并行处理能力。 利用云计算分布平行处理的特点， 可以将一个大图分割成若干子图， 把针对一个大图的处理分割为若干针对子图的处理任务。 云计算分布式并行运算能力， 能够显著提高对大规模图的处理能力。

(3)良好的可伸缩性和灵活性。 从技术角度和经济角度讲， 云计算环境具有良好的可伸缩性和灵活性， 非常适合处理数据量弹性变化的大规模图问题。 云计算环境通常由廉价的普通计算机构成。 随着图数据规模的不断增大， 可以向云中动态添加节点来扩展存储容量和计算资源， 而无需传统并行机模式的巨大投资。

1.3 关键技术挑战

虽然云计算环境对于大规模图数据的管理有诸多优势， 但是由于云计算只是一个通用的处理框架，而且其本身也正处于发展阶段， 如何在云计算环境下进行大规模图数据处理， 仍有很多关键技术难题需要解决。 图计算及其分布式并行处理通常涉及复杂的处理过程， 需要大量的迭代和数据通信， 针对联机事务处理等应用的传统技术很难直接应用到图数据处理中。 云计算环境下的大规模图处理主要面临两大挑战:

（1）图计算的强耦合性。 在一个图中， 数据之间都是相互关联的， 图的计算也是相互关联的。 图计算的并行算法中对内存的访问表现出很低的局部性。 对于几乎每一个顶点之间都是连通的图来讲，难以分割成若干完全独立的子图以进行独立的并行处理。 并且，“水桶效应”问题加剧， 即先完成的任务需要等待后完成的任务， 处理速度最慢的任务， 将成为整个系统的效率制约瓶颈。 为了提高执行效率， 需要采取多种优化技术。 首先， 在预处理阶段， 进行合适的图分割时， 尽可能地降低子图之间的耦合性; 其次， 在执行阶段， 应选取合适的图计算模型， 避免迭代过程中反复启动任务和读写磁盘， 降低任务调度开销和IO开销; 应充分利用迭代过程中的收敛特性进行查询优化， 同时进行有效的同步控制和消息通信优化， 减少通信开销， 以达到降低水桶效应的目的。

（2）云计算节点的低可靠性。 大规模图处理， 需要相对较长的时间来完成计算任务， 如Pag eRank计算需要约30 次迭代处理， 消耗大量的时间和资源。而云计算节点通常是由普通的计算机组成， 在这种长时间的处理过程中， 个别节点出现故障是难免的。 这时， 不能简单地重新计算， 而应该从断点或者某个合适的位置接续执行。否则，将造成很大的浪费，甚至一些大型的图计算根本就不能完成。另一方面，由于图计算并行子任务之间的强耦合性， 一个子任务的失败可能导致其它子任务的失败， 这又增加了恢复处理的复杂性。 因此， 需要考虑有效的容错管理机制， 减少大规模图处理过程中的故障恢复开销，尽量避免重复计算， 提高大规模图处理的运算效率和稳定性。

为了解决云计算环境下的大规模图处理问题，可从图数据管理和图处理机制两方面加以考虑。 在图数据管理上， 需要解决图数据的分割、图数据的存储、图数据索引的建立、图查询处理等问题; 在图处理机制上， 需要解决处理过程中图计算模型选取、同步控制、消息通信、容错管理和可伸缩性等问题。 本文将针对上述内容， 结合云计算的优势和存在的挑战， 综述云计算环境下的大规模图处理现有技术的进展、解决方案以及今后的发展趋势和研究方向。

---

2. 图数据模型与存储管理

图数据的逻辑表达形式和物理存储结构是实现图处理的基础。 本节首先介绍图数据模型， 然后， 介绍图的存储管理以及为了提高查找效率而为图数据建立的索引结构。

2.1 图数据模型

作为数学的一个重要分支， 图论以图作为研究对象， 在简单图的基础上衍生出超图理论、极图理论、拓扑图论等， 使图可以从多方面表达现实世界。当前大规模图数据管理， 采用的数据模型有多种， 按照图中节点的复杂程度分为简单节点图模型和复杂节点图模型; 按照一条边可以连接的顶点数目分为简单图模型和超图模型。 不论是简单图模型、超图模型、简单节点模型还是复杂节点模型， 它们的顶点和边都可以带有属性。 下面介绍简单图模型和超图模型。

（1）简单图模型。 这里所说的简单图， 并不是图论中的简单图， 是相对于超图而言的。 简单图中，一条边只能连接两个顶点允许存在环路。 简单图的存储和处理都比较容易， 对于一般的应用， 简单图的表达能力完全可以胜任， 如Pag eRank 计算、最短路径查询等。 Pregel、Hama 等系统均采用简单图模型来组织存储和处理大规模图数据。

（2）超图模型。 一条边可以连接任意数目的图顶点。此模型中图的边称为超边。基于这种特点， 超图比上述简单图的适用性更强， 保留的信息更多。 例如， 以图顶点代表文章， 每条边代表两个顶点( 文章)享有同一个作者。 现有3 篇文章V1(作者A、B)、V2(作者A、C)、V3(作者A、D)收敛。 由于实际应用中的图一般具有较小的直径， 因此，HCC 算法通常可以较少的迭代次数结束。

目前比较通用的图查询处理系统， 主要包括基于BSP 模型的Pregel 和基于Hadoop的GBASE。Pregel 对于最短路径计算、PageRank 计算、聚类等操作都可以支持。 但是， Pregel 仅支持稀疏图， 且全部数据驻留内存， 需要进一步的改进以支持更复杂的应用。 在PEGASUS 算法库基础上开发的GBASE 是一个功能比较强大的图数据管理系统，所支持的查询处理也比较全， 将所有的大图查询分为两类: 全局查询( global query) 和定向查询( targ etedquery) 。 前者需要遍历整个图结构， 如PEGASUS 算法库中包含的RWR、连通域查询等应用。 后者仅需要访问图的一部分， 例如GBA SE 目前支持neighborhoods、induced subgraphs、egonets、K-core和cross-edges 等多种不同的定向查询。 GBASE 以邻接矩阵存储图数据， 将所有的查询处理转化为矩阵迭代操作， 底层计算由Hadoop 完成。 当然对于大规模图， 邻接矩阵过大的存储开销和分割存放的复杂性， 对于某些以图顶点为核心的应用， 如PageRank计算而言， 是有些得不偿失的。

从大规模图应用的角度看， 目前各种图处理系统， 尚不能很好地支持子图挖掘、图模式匹配等功能。 在图的模式匹配查询方面， 针对RDF 开发的SPARQL， 可以完成Triple Pat tern、Optional Pattern等查询， 具有很高的参考价值， Hypergraph-DB 正计划采用该语言实现对超图的模式查询。

6.3 图查询处理的实现模式

虽然图查询处理的种类很多， 但在云计算的分布式环境下， 支持图查询处理的底层图遍历操作主要有两种驱动模式: 一种是以图顶点驱动的主动遍历模式; 另一种是以消息驱动的被动遍历模式。 这两种遍历模式仅是驱动不同， 但是遍历操作的对象仍为图顶点， 即处理操作的核心始终是图顶点。

在云计算环境下，以图顶点驱动的主动遍历计算模式， 需要每个任务在计算时， 主动遍历其所负责的全部图顶点，对于每一个图顶点，进行计算处理和消息收发。 这种处理模式适用性强， 可以支持所有的图应用场景，Hama 系统就采用这种遍历模式。 但是对于某些特定的应用， 可能造成资源浪费。以Pag eRank计算为例， 图顶点状态的更新依赖于消息的接收， 即只有邻居顶点所存储的PageRank 值发生变化时，其出度顶点的PageRank 值才可能变化。 如果某顶点没有接收的消息， 那么它的值就不会更新， 也不会对其邻居发送消息， 此时可以将该顶点视为达到稳定状态， 如果所有图顶点均达到稳定状态， 那么PageRank 的计算任务就完成了。 由于PageRank 计算是一个收敛算法， 随着迭代处理的进行， 越来越多的图顶点将达到稳定状态， 消息发送量越来越少。 如果以图顶点为驱动， 相当一部分图顶点的遍历和处理是没有实际意义的。 作为改进， 在以消息驱动的被动遍历模式中， 各任务仅需对有消息需要处理的图顶点， 进行遍历计算。 这样， 对于PageRank 这种具有收敛性的大规模图迭代处理应用， 可以有效减少不必要的顶点调用处理开销。

Pregel 系统采用的遍历模式介于两者之间， 通过“投票”机制， 图顶点可以将自己置于非活跃状态，除非该顶点接收到新的消息， 否则不会在后续的迭代处理中被计算。 但是各任务仍需要遍历图顶点来检查图顶点是否处于活跃状态。 Pregel 的优化之处在于， 对于非活跃状态的图顶点， 不需调用处理函数， 节省了处理函数调用的开销。

---

7. 结束语

综上所述， 在云计算环境下进行大规模图数据的处理， 涉及到图算法以及云计算领域的多个方面。目前的研究重点主要集中在以下5 个方面:

(1) 大规模图分割。 云计算环境下的大图分割，需要提高子图内部的连通性， 降低子图之间的连通性， 维持子图之间数据规模和图拓扑结构的均衡性，同时应该有较小的时间复杂度。 良好的图分割算法，是在云计算环境下降低图并行计算强耦合性的基础， 但是目前的图分割技术， 难以在连通性、均衡性和时间复杂度等方面同时达到较好的性能。

(2) 大规模图索引结构。 大规模图的数据管理，虽然依靠云计算环境的分布式并行处理机制， 可以提高效率， 但是索引的加入， 无疑将使管理效率有一个大幅度的提升。 目前关于分布式图数据的索引机制， 已经有成型的产品， 但是仍处在不断探索和研究过程中。 而针对图处理的索引， 只有部分图处理进行了云计算环境下的索引研究， 如最短路径计算等， 相当一部分图处理方法尚未考虑索引机制。

(3) 查询处理与磁盘存储。在云计算环境下的大规模图查询处理， 正处于开发阶段， 还有很大的性能提升空间， 而且像子图挖掘、图模式匹配查询等复杂应用， 尚没有得到很好的解决方案。 此外， 基于BSP 模型Pregel、Hama 和Giraph 等大规模图处理系统， 目前均基于内存， 限制了数据处理规模， 将硬盘存储融入BSP 模型并对磁盘IO 进行有针对性的优化， 是急需解决的问题。

(4) 消息通信优化。 在云计算环境下进行大规模图处理时， 制约系统效率的重要瓶颈就是消息通信， 特别是由于存在任务间的耦合性， 大量的网络通信使云计算的效率大打折扣。 Google、Yahoo、微软等开发机构对于网络通信的优化都进行了探索并取得了一定的效果， 但目前仍只是缓解而没有从根本上解决瓶颈问题。 对图处理应用， 结合图分割技术以及图数据结构的特点， 若能进一步降低网络通信开销， 甚至解决瓶颈问题， 会极大地提高大规模图处理效率。

(5) 容错管理。 虽然云计算系统本身拥有较为完备的容错管理机制， 但是针对需要多次迭代、运行时间过长的大规模图处理而言， 故障恢复的代价仍然十分昂贵。 而且， 冗余备份与系统处理效率之间的矛盾， 没有得到明确的解决。

---

【完】

           

给我老师的人工智能教程打call！http://blog.csdn.net/jiangjunshow