【ARL】Parallel Processing of Graphs

Graph

本次学术前沿讲座由邵斌老师主讲,标题已经揭示了主题:Graph。1.5h的talk,听完自觉意犹未尽。本来以为是一节自己没接触过的图形学的talk,没想到讲的很多内容都跟自己学过的很多东西能Match。这里记录了一些笔记与各位分享,希望各位园友一起跟着邵斌老师来感受一下Graph的魅力。
Lecture是以三个领域的对比娓娓道来的:Graph、Image与Graphics。直观上讲,Image象征图像处理,Graphics则是计算机图形学。
那么,Graph是什么呢?它其实一点也不神秘。对大多数程序员来说,它可能要比前两者更亲切,因为大部分人都曾在数据结构书中见过它。比如著名的七桥问题,抽象为图的结构,就是这样的:

【ARL】Parallel Processing of Graphs

这里的Graph,我们用图谱来称呼它可能更为合适。和图像图形相比,它显得更抽象一些,所以概括能力也更强:我们可以说一个社交网络是一张图谱,一个人物关系也是一张图谱,图谱在我们生活之中无处不在。引用一句充满哲学意味的话来形容就是:“万物之间皆有联系”。万物组成了一张大大的图谱,每个人都是其中的一个结点。粗浅地了解一下图谱的基本概念以后,就开始进入本次talk的主题。

Challenges

我们在处理大规模的图谱时,会遇到各种各样的挑战,包括但不仅限于以下:

  • 图的多样性
    由于实体和关系的复杂性,图的多样性也是必然事件。笔者以为,图的多样性作为挑战之一,主要是因为它给建设统一的图谱处理系统带来了巨大的困难。不同的图谱依赖的数据特点不一,对于不同的图谱需要的处理方法即使相似,但也还是有不小差异。
  • 计算的多样性
    在图谱处理的背后是大量的计算,所以计算对图谱的处理有很重要的影响。丰富的操作类型决定了多种多样的计算模式,比如:有Online的查询处理,也有Offline的数据分析,不同的操作对应着不同的计算方式,这些都是在构建图谱时所需要面对的challenge。
  • 图的规模
    如果一个任务的计算规模很大,那么我们可以把它分成若干个子任务,在不同的机器上分别跑每个子任务。当每个子任务顺利完成后,我们把子任务的结果汇总合并,就可以得到原任务的结果了。这是传统的做法,也就是MapReduce的大致思路。然而在面对图时,这样的办法就不是很奏效了。最大的困难之处在于:图很难切割。MapReduce是分而治之,但图的处理在第一步上就栽了个跟头。

Design Principles

下面我们来介绍一下在设计一个系统时用到的一些通用的设计准则。

No one size fits all

第一条,也是非常重要的一条设计准则:There is no one-size-fits-all system. What is one size fits all?
没有任何一个系统是可以放之四海而皆准的。当然,现有的系统当然是能够处理图的,从这一方面讲,图这个东西就像链表,数组等,只是一种数据结构,没有什么特别的地方。但是,能够处理只是最基本的功能,我们这里所说的“皆准”指的是:对于不同的数据结构有大致相同的处理性能。
但我们目前分层的体系结构中,在处理图和处理其他数据结构的速度上会有巨大的差异。这种差异主要来源于图区别于其他的一些特性,这些特性恰恰与分层体系结构的设计理念产生了冲突。

Random Access

有计算机基础的同学应该都知道局部性原理。它强调了CPU访存时的一大特性:所访问的存储单元总趋向于在一小块连续区域【更完整准确的解释戳这里】。这样就意味着,当我们访问了一块数据后,接下来一段时间内的活跃数据将是这块数据周围的数据。既然我们可以预测活跃数据,那我们就希望把这些活跃数据预取到访问速度最快的存储器中,以此来减少平均访问数据的时间,这样做代价又小,效果又好。于是,Cache出现了。

但是想象一下,如果我们要对一个图遍历操作,就会在大量的结点之间跳来跳去。图的结构决定了在遍历时是真正的随机存储访问,局部性很弱。在这种局部性概念极度弱化的场景下,一个结点相邻的存储数据刚取到Cache里,跳跃一个相邻结点可能会命中Cache,但再跳跃一个结点,就很难继续命中Cache了。这是制约图处理速度的很重要的一部分原因。
当然,笔者认为,存在大量先验知识的情况下,我们做一些对图结构友好的Cache优化也是可以的。比如统计概率上关联更深的结点,把它们在内存布局上调整靠近,以满足Cache预取的本意(访问最频繁的数据放在最快的存储器中)。

Hard to Divide

之前也提到了,传统的MapReduce无法在图的处理上很好work的主要原因就是图很难Divide。所以也就没有什么高效的分治算法,不好做Partition。

Data Driven

在图谱中,最重要的部分就是支撑图谱的数据。不同的数据组织对图谱的效率影响很大,不仅仅只有算法才会影响图处理的效率。

Tradeoff

我们要做的是一个可work的系统,而不是一个只能供观赏的art。所以在设计一个系统时不能总追求理想化的完美,总要考虑一些 Tradeoff。在图处理的问题上就有一些Tradeoff值得我们考虑:

  1. 要支持online query, offline analytic, 或者两者都支持?
  2. 要针对吞吐量(throughput),还是在响应时间(response time)上做优化?
  3. scale "out" 还是 "up"?
  4. 是否需要事务支持?

在online or offline的选择上,online查询更加注重响应速度,而offline分析则更加注重吞吐量。通常意义来说,online查询更加难以优化。我们上面提到了,在图处理时,数据存取局部性较弱,很难普遍提高响应速度。

【未完待续,迭代发布...】

上一篇:JS脚本语言(全称java script:网页里使用的脚本语言:非常强大的语言):基础语法


下一篇:Python脚本控制的WebDriver 常用操作 <二十四> 定位frame中的元素