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

本文是一系列文章的第四篇，将介绍图计算系统领域在COST这篇文章出现后的发展。

Scalability! But at what COST?

《Scalability! But at what COST?》这篇文章为大数据平台提供了一个衡量指标——COST（the Configuration that Outperforms a Single Thread，即超过单线程的性能所需要的配置）。针对一个特定平台的一个特定问题，其COST指标的数值，就是该平台处理该问题的性能超过一个充分出色的单线程实现所需要的硬件配置。

这篇文章指出了一个现象：大多分布式大数据处理系统的工作过分沉迷于系统的扩展性，却很少甚至忽略了系统的处理效率与绝对性能。作者以两个常用的图计算应用PageRank和连通分量为例，指出最基本的单线程实现就能接近甚至超过一个集群能够达到的性能；如果再在此基础上改进数据布局，并使用更好的适合于单线程实现的串行算法，性能还可以更上一层楼：

诚然，单线程的实现不需要考虑多线程/多机并行计算引入的同步/通信开销，也不需要考虑使用的算法能否被有效地并行化^[1]，因此可以激进地使用所有可行的串行优化，以达到卓越的性能；另一方面，分布式系统针对面向的应用领域，通常会抽象出较为友好的编程模型以方便用户的使用，但这往往也限制了系统能够应用的优化方向。因此，分布式系统和优化的单线程实现相比，在使用相同硬件资源（即单核）的前提下，在处理某个特定问题时，前者的性能很难匹敌后者；然而，若在使用了上百倍资源的情况下，分布式系统的性能依然无法追上单线程实现，那么其中必然存在设计和实现上值得深思的问题。

[1] 有些算法天然就是串行的（或者说不具备并行度）。具体到图计算中，典型的例子包括计算最短路径的Dijkstra算法、计算强连通分量的Tarjan算法等。

## Gemini

很显然，我们需要既有扩展性（随着资源的增加能够处理更大规模的数据，或是更快地处理相同规模的数据）又不失高效性的分布式图计算系统（COST不能过大导致资源的严重浪费）。

Gemini这篇文章分析并探索了已有的分布式图计算系统会损失如此多性能的原因，主要可以归结于两方面：

• 过于重视通信和负载均衡带来的影响；
• 忽略了分布式场景下计算部分的影响。

通过对这些系统的性能分析，可以发现它们在计算过程中完成的通信量远远小于现有高速网络（如万兆网、Infiniband等）带宽能够容纳的上限；反倒是指令执行和内存访问次数远高于COST文章中提出的单线程实现，cache命中率和多核利用率上却又不甚理想。这些现象意味着通信并不是这些系统的瓶颈，反倒是计算拖了后腿。

因此，Gemini抛弃了传统分布式图计算系统以图划分质量为优化方向的观念，提出了以计算为中⼼的设计原则：

• 尽可能地避免分布式引入的开销；
• 尽可能地提升计算部分的效率。

一方面，Gemini采用了块式划分的策略，让每台机器负责一段连续区间的顶点，从而尽可能减少分布式相关的开销；另一方面，Gemini借鉴了很多单机图计算系统中提出的技术，将之应用并扩展到了分布式的场景下，尽可能地提高计算部分的效率。最终完成的系统COST值为3，显著地低于其它分布式解决方案；其单机的计算效率与最佳的单机解决方案不相上下，并在此基础上拥有良好的扩展性，与最好的分布式图计算系统相比有数量级的性能提升。

PandaGraph

PandaGraph是Gemini的商业化版本^[2]，在Gemini开源版的基础上增加了大量功能，例如：

[2]费马科技的创始人中包括了Gemini的主要作者。

• 与Hadoop生态系统的集成，包括：
  • 面向HDFS的输入/输出接口，文本格式文件的解析接口等；
  • 支持YARN来调度PandaGraph程序；
  • 基于MapReduce/Spark的预处理/后处理方案等；
• 部分组件的进一步优化，包括：
  • 更节省的内存空间使用；
  • 更鲁棒的通信效率；
  • 更快的图数据载入/划分等；
• 以及更多的算法实现等。

下篇预告

下篇文章是本系列文章的最后一篇，将介绍图计算系统相关或是细分领域的一些工作。

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