Facebook针对图数据处理对Apache Giraph 和 Spark Graph

一支Facebook 团队近期发表了一份比较报告，比较对象是他们当前的基于 Giraph的图处理系统和更新的 GraphX (它是流行的 Spark 框架的一部分)。他们的结论是，GraphX当前无法满足他们对扩展性和性能的需要，不足以支撑起他们图处理的负载。

在Facebook，大规模图处理是数据设施服务的重要组成部分。他们的社会图有1.71十亿编辑顶点和数千亿的边，如果再把人们的爱好加进来那么该图就会有上十亿条边了。他们还有用于图数据分析的大量应用场景，包括通过智能数据分布和图压缩的网页和群组推荐、基础设施优化。

该团队基于Apache Giraph搭建了一个图分析平台，其在 VLDB '15 论文和一篇相应的博客文章中曾被介绍过。该团队描述了它们寻找替代者的动机，他们是这样写的：

自从诞生以来，Giraph已得到了持续的演进，不仅能简化用户的编程，还能让用户可以处理Facebook级的生产负载。在这段期间，涌现出了大量的其他图处理引擎。例如Spark框架，它是作为针对常规数据处理的平台得以应用的，此外它还提供了一个面向图的编程模型和执行引擎，即GraphX。

由于我们的目标是尽可能选择最佳方式处理内部负载，所以我们决定对Giraph和GraphX进行定量、定性的比较。

由于Facebook还有一个支撑生产负载的Spark cluster，所以他们决定比较一下这些图数据处理系统，看看这些系统处理大规模图会怎样。这项测试还可以看一下这两个系统在不同的资源分配策略下是怎么执行的，以及它们针对容错和用户界面提供了什么类型的支持。他们还测试了其他的一些影响因素，包括在这两个系统之间开始的可用性和易用性比较。

该测试方法涉及到三个在图数据分析领域流行的算法： PageRank、Connected Components以及更多信息负载的 Triangle Counting。为了与最初的 GraphX论文形成对照，他们使用了相同的两份公开可用的图数据集开始的测试，它们分别是Twitter图和英国网页图，前者有15亿条边，而后者有37亿条边。这项测试还包括一些人造图数据，它是使用Darwini图生成工具生成的。该基础软件配置是 Spark 1.6.1 和 Giraph 1.2.0，JDK版本为1.8 (8u60)。

他们发现在通常情况下Giraph能够更好地处理生产级负载，而Spark GraphX提供的几个特性，能使图数据处理解决方案的开发更简单。

该性能测试有如下关键发现：

• Giraph即使在较小规模的图数据集上执行得也更好些。

• Giraph的内存使用也更加高效。

• GraphX支持以SQL样式的查询从Hive中读取图，支持任意列转换。

• 使用shell环境中的Scala是一种测试GraphX简单应用的简便方式。

最后，该团队总结说，GraphX不足以支持他们图处理负载的扩展性和性能需要。

基于对当前结果的推测，我们应该需要订购更多数量级的机器去支持当前的生产负载。除此之外，即使GraphX能处理该图规模，其机器运转的时间也是效率方面很大的欠缺。然而，GraphX编程接口提供了许多简化应用开发的特性，比如SQL集成。我们希望Giraph在未来也能添加上这些特性。

该团队已经提供了重现本研究的相关细节，以及相关代码和数据。