一支 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 在未来也能添加上这些特性。
该团队已经提供了重现本研究的相关细节，以及相关代码和数据。
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论