图计算系统发展简史（五）

本文是“图计算系统发展简史”系列文章的第五篇也是最后一篇，将介绍之前没有提及的图计算系统相关或是细分领域的一些工作。

图计算语言

之前我们提到的所有图计算系统都需要用户使用如C++、Java等程序设计语言来描述计算过程，很多时候不得不写比较长的代码，并且不同的系统通常有不同的API，可移植性非常低。因此，一个很自然的想法出现了：为什么不创建一套专门面向图计算的领域专用语言呢？

Green-Marl是首个这样的尝试，并且已被Oracle采纳用于部分产品/场景。除了编程语言所需的基本元素，Green-Marl补充了很多图计算需要的特定功能，例如顶点/边的描述，基于DFS/BFS的算子等等。根据用户的需要，同一个Green-Marl程序可以经由不同的编译器变成不同的可执行程序。

GraphIt与Green-Marl类似，但是将图计算程序分成了两个部分：计算和调度。计算部分描述图计算过程；调度部分用于对部分变量/算子使用可选的优化来提高计算效率。

SociaLite的目标则有较大不同，旨在用DataLog——一种描述式的逻辑编程语言来表达图计算过程；Grail与SociaLite有些类似，但是描述的语言换成了SQL，从而让用户可以使用关系型数据库进行图计算，无需再部署专门的图计算系统和学习相应的编程接口[1]。

[1] 需要注意的是，使用SQL描述的图计算过程会不可避免地涉及大量表与表之间的Join操作，尽管关系型数据库对此有了相当深入的优化，其效率依然无法与最先进的图计算系统相比。

动态图计算

很多时候，我们需要分析和处理的图数据并不是一成不变的：顶点和边上的属性会发生变化；拓扑结构也会发生改变。这种场景下，我们处理的就不再是一个静态图，而是可能在不断发展和变化的动态图。

为了能同时接受源源不断的更新并调度需要的图分析算法在最新的数据上进行计算，很多动态图计算系统应运而生。KineoGraph是第一个这样的系统：数据更新流式地进入存储，并定期地转换为全局快照用于分析；对于部分应用场景，用户也可以选择使用增量计算的方式减少工作量。LLAMA和GraphOne则主要面向动态图的存储管理，通过将增量更新记录在与主存储分离的位置来实现高效的更新，并尽可能地减少对图计算效率的影响。

Chronos的目标略有不同，主要关注点放在计算部分，通过面向局部性的批量调度方式来强化动态图上同时对多个快照的并行处理效率[2]。

[2] 费马科技的创始人中包含了“Chronos”的作者。

GPU/加速器

有不少使用GPU或者其它加速器来进行/辅助图计算任务的系统。Medusa是最早的这一类尝试，借鉴了很多Pregel的思想并针对GPU的特点做了相应的调整。CuSha的编程接口则更接近PowerGraph采用的GAS模型，将图数据进行划分以减少不规则的显存访问。Gunrock则进一步了探索了调度策略对性能的影响，获得了显著优于之前同类系统的结果[3]。

[3] 尽管GPU的显存具有相比内存更高的带宽，然而由于图计算中大量存在的随机访问，基于GPU的图计算系统不一定能获得相比CPU更好的性能（这通常还是在不考虑内存与显存之间数据传输时间的前提下）。

然而，显存在容量方面很难与内存相比。为了让处理的图数据规模不再受限于显存大小，使用CPU和GPU协同处理图计算任务是更合理的一种方案。gGraph是这方面最早的尝试，通过将数据划分为若干更小的子图，并将计算任务分配给CPU和GPU同时完成来提高资源的利用率。Garaph则针对图计算中大量存在的写竞争提出了更好的解决方案，并且能够通过合理地使用CPU/GPU以及显存/内存/外存进一步提升资源的使用效率。

除了使用GPU外，还有一些图计算系统使用其它类型的加速器来辅助图计算，例如：Mosaic使用Intel Xeon Phi来加速图计算任务；FPGP及其后继者ForeGraph则使用FPGA来完成图计算；“神图”面向国产众核处理器申威26010设计和实现，并且具备分布式扩展的能力，设置了图计算系统领域的性能记录：在秒级时间内遍历边数高达70万亿边的超大规模图数据[4]。

[4] 费马科技的创始人中包含了“神图”的主要作者。

系列总结

图计算在学术界和工业界都是目前十分热门的话题。本系列文章简单地回顾了图计算系统的发展历史，介绍了其中具有里程碑意义或是具有较高代表性/知名度的图计算系统。限于篇幅，我们无法面面俱到地介绍所有的图计算系统，如果有任何相关需要了解和咨询的与图数据处理有关的问题，请随时联系我们，并关注我们的官网/公众号参与互动！

本系列其他文章：
图计算系统发展简史（一）
图计算系统发展简史（二）
图计算系统发展简史（三）
图计算系统发展简史（四）