GUM: 基于负载迁移的高效多 GPU 图分析

《GUM: Efficient Multi-GPU Graph Processing with Remote Work Stealing》是 GraphScope 团队最新发表在数据库领域顶级国际会议 ICDE 2023 上的工作。GUM 通过利用负载迁移（Work Stealing）来解决图计算任务在多 GPU 环境下的动态负载不均和长尾问题。本文即介绍 GUM 的技术原理与细节。

背景

图分析任务是大数据场景下的一类关键基础任务，可以支持广泛的大数据应用，例如网络安全、医疗信息学、数据增值、社交网络和符号网络等。在大数据时代，传统的单设备处理复杂算法已经不能满足实际需求，因此需要采用分布式图处理进行更高效的计算。分布式图处理将大型图划分为多个子图，并在不同计算设备（例如CPU、GPU）上并行地执行每个子图的过程。目前学术界和工业界存在许多分布式图处理引擎，例如 PowerGraph、Spark GraphX、Gemini 和 GRAPE 等。尽管分布式图处理具有显著的优势，但与共享内存的图系统相比，其设备利用率较低。研究表明，随着从单个节点向分布式实现的转变，系统的设备利用率可降低接近三分之一。这是因为在分布式图计算中，计算设备往往需要等待其他设备进行同步，必须等待消息在通信之前进行序列化，这些操作需要额外的开销，而计算设备必须等待数据移动完成才能进入下一轮。

GPU加速图分析任务

长久以来，图分析任务这类数据密集型的负载一直在 CPU 上进行。但是近年来，随着各种新兴硬件的出现，人们逐渐意识到利用加速卡（例如 FPGA、GPU）搭建异构计算平台的潜力。这些加速卡拥有更高的并行度和更高的取数能力，例如一块 Nvidia V100 GPU 能提供 5K+ 的计算核心和近 1TB/s 的内存带宽。许多任务已经利用这类加速卡获得了巨大的性能提升，例如深度学习和图像处理。图计算也不例外，在学术界中有不少研究致力于利用 GPU 加速图算法，如 Gunrock 和 Groute 等。然而，GPU 的单个核相比 CPU 算力较弱，且 GPU 之间同步的开销更高，因此 GPU 更容易受到负载不均衡的影响，导致多 GPU 图计算系统的效率和可扩展性很难令人满意，甚至经常出现使用多个 GPU 反而不如单个 GPU 快的情况。

下图展示了一个典型的多 GPU 节点的通信拓扑，8 块 Nvidia V100 GPU 通过 NVLink 高效地连接起来，每个 GPU 拥有自己独立的内存。将图数据划分到每个 GPU 上之后，图算法以 BSP 的模式逐步迭代收敛。在计算的每一轮中，只有图的部分节点会收到上一轮迭代发送的消息而被激活，被激活的节点将处理自己的消息并更新自己的状态，随后遍历自己的邻居节点发送新的一轮消息。然而，我们发现 GPU 之间的拓扑具有一些之前的图计算系统未注意到的特征：

• GPU 对之间的连接往往是非对称的，例如可能存在两条 NVLink 巷道（50 GB/s）或一条 NVLink 巷道（25 GB/s），或者任何两个 GPU 之间没有链接，这种连接速度差异很大，导致某些 GPU 对之间的通信比其他 GPU 对之间的通信更加昂贵。
• GPU 对之间存在多个通信路径，例如 $GP{U}_0$ 可以通过将 $GP{U}_1$ 或 $GP{U}_6$ 作为中间转移，和 $GP{U}_7$ 进行通信，不同通信路径的性能可能会有很大差异，因为每个路径上可用的带宽和拥堵程度在图算法的每一轮迭代都不同。

问题分析

在真实的图数据上运行图计算系统确实产生了如同上文所分析的计算效率下降。下图展示了 Gunrock 在一个 8 GPU 配置的节点上运行最短路径算法时 GPU 的利用率随时间变化的情况。我们发现有两个问题导致了 GPU 的利用率低下：（1）动态负载不均衡（dynamic load imbalance）问题和（2）长尾（long tail）问题。

动态负载不均衡问题

在图计算的每一轮迭代中，只有部分顶点被激活并参与当前的计算，这些被激活的顶点通常被称为“活跃点”（Frontiers）。随着迭代的进行，Frontiers 的大小会快速变化。然而，由于图结构的不规则性和图算法的动态特性，Frontiers 的增长会导致工作负载不平衡的问题。以第 9 次迭代为例，最慢的计算设备（$GP{U}_2$）相对于最快的计算设备（$GP{U}_4$）需要 2.6 倍的运行时间。但在第 10 次迭代中，最慢的计算设备（ G