图上的并行处理 Parallel Processing of Graphs
Graph
本次学术前沿讲座由邵斌老师主讲，标题已经揭示了主题：Graph。1.5h的talk，听完自觉意犹未尽。本来以为是一节自己没接触过的图形学的talk，没想到讲的很多内容都跟自己学过的很多东西能Match。这里记录了一些笔记与各位分享，希望各位园友一起跟着邵斌老师来感受一下Graph的魅力。
Lecture是以三个领域的对比娓娓道来的：Graph、Image与Graphics。直观上讲，Image象征图像处理，Graphics则是计算机图形学。
那么，Graph是什么呢？它其实一点也不神秘。对大多数程序员来说，它可能要比前两者更亲切，因为大部分人都曾在数据结构书中见过它。比如著名的七桥问题，抽象为图的结构，就是这样的：
这里的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值得我们考虑：
- 要支持online query, offline analytic, 或者两者都支持？
- 要针对吞吐量(throughput)，还是在响应时间(response time)上做优化？
- scale "out" 还是 "up"?
- 是否需要事务支持？
在online or offline的选择上，online查询更加注重响应速度，而offline分析则更加注重吞吐量。通常意义来说，online查询更加难以优化。我们上面提到了，在图处理时，数据存取局部性较弱，很难普遍提高响应速度。
