用RDMA重新思考有状态流处理

摘要

远程直接内存访问 (RDMA) 硬件弥合了网络和主要内存速度之间的差距，从而验证了网络通常是分布式数据处理系统中的瓶颈的常见假设。然而，高速网络并没有提供“即插即用”的性能（例如，使用 IP-overInfiniBand），并且需要仔细共同设计系统和应用逻辑。因此，系统设计者需要重新思考其数据管理系统的架构，以从 DMA 加速中受益。

在本文中，我们专注于加速流处理引擎，这受到实时约束和状态一致性保证的挑战。为此，我们提出了 Slash，这是一种新颖的流处理引擎，它使用高速网络和 RDMA 来有效地执行分布式流计算。Slash 包含一个适用于 RDMA 加速的处理模型，并通过省略大规模 SPE 的昂贵数据重新分区需求来进行扩展。虽然 scale-out SPE 依赖于数据重新分区来执行对许多节点的查询，但 Slash 使用 RST 在节点之间共享可更改状态。总体而言，与部署在不定式网络上的现有系统相比，Slash 实现了高达两个数量级的吞吐量改进。此外，它比依赖基于 RST 的数据重新分区以扩展查询处理的自开发解决方案快 22 倍。

1 介绍

在过去的十年中，数据中心网络技术的进步弥合了网络和主要内存数据率之间的差距 [9, 25]。事实上，今天可以购买或租提供超级计算机级网络带宽的服务器 [ 45]。例如，高速网络接口控制器 （NIC） 支持高达 25 GB/s 作为网络吞吐量和每个端口 600 ns 延迟，而现代开关支持多达 40 TB/s 作为整体网络吞吐量 [44]。双数据速率 4 （DDR4） 模块支持每个通道高达 19.2 GB/s 和 13 个 CAS 延迟，而主要内存带宽高达 24.8 GB/s [ 3 ]。这种改进是由于远程直接内存访问 （RDMA）：可以实现高吞吐量数据传输的高速网络的功能微秒延迟。因此，网络通常是分布式设置中的瓶颈的常见假设不再成立[60]。研究表明，RDMA硬件不能为现有的数据管理系统[9]提供“即插即用”的性能增益。因此，有必要修改他们的架构来使用全带宽[9]。最近的研究提出了许多架构修订来加速 OLAP [9， 40]、OLTP [69]、索引 [74] 和键值存储 [19， 31]，在机架级部署中使用 RDMA。在本文中，我们使得流处理引擎 （SPE） 也需要架构更改才能真正受益于 RDMA 硬件的情况。为此，我们表明当前的向外扩展 SPE 没有准备好用于 RDMA 加速，并且现有的 RDMA 解决方案不适合流处理范式。因此，我们提出了一种与 RDMA 本地集成的 SPE 架构，以有效地摄取和处理机架级部署中的数据。

当前 SPE，例如 Apache Flink [ 11 ]、Storm [58 ]、TimelyDataflow [47） 和 Spark [68 ]，不能完全受益于 RDMA 硬件。由于以下原因，他们的设计选择从根本上阻止他们以全数据中心网络速度处理数据。首先，RDMA-unfriendly，当前的 SPE 依赖于基于套接字的网络，例如 CP/IP，摄取和交换数据流。尽管基于套接字的网络在 RST 硬件上运行，但它无法充分利用其潜力，例如，使用 IP-over-InfiniBand （IPoIB） [9]。其次，昂贵的消息传递，当前的 SPE 依赖于消息传递来处理遵循类似 Map/Reduce 的范式 [16 ] 的数据。这导致了性能回归，因此在由次优数据和代码局部性引起的低效执行 [ 70, 71]。特别是，消息传递在网络和数据处理线程之间引入了昂贵的基于队列的同步 [30]。此外，在考虑数据密集型工作负载时，类似 Map/Reduce 的范式是基于相对较慢的基于插槽的连接的网络绑定。然而，它们在存在快速网络的情况下成为计算界限 [9, 60]。因此，它们不会从高速网络的数据率中受益。最后，昂贵的大规模执行，当前的缩放 SPE 依赖于算子裂变 [27 ] 来实现数据并行计算。这使每个 SPE 执行器能够处理流的不相交分区并管理本地状态。然而，裂变涉及连续数据重新分区，它以高成本 [17]。

此外，上述问题无法通过以前的数据密集型系统的 RST 解决方案来解决。事实上，SPE 需要对航班内记录进行状态分析，并对操作员状态进行点更新和范围扫描。然而，在不可变数据集上加速 OLAP 系统加速批量分析 [7， 20， 40，5}。对于包括点查找和插入 [1， 31] 在内的事务工作负载，基于 RST 的键值存储是设计的。因此，SPE 的数据访问模式和处理模型需要专门的 RD-加速解决方案。

为了在延迟非常低的全网络带宽上实现有状态流处理，我们提出了Slash，这是我们用于机架级部署的RDMA加速SPE。我们设计了一个新的架构来实现一种省略数据重新分区的处理模型，并在摄取的流上应用有状态查询逻辑。Slash 包括以下构建块：RDMA Channel、有状态查询执行器和 Slasash State Backend （SSB）。首先，我们设计了一个 RDMA 友好的协议，通过专用的 RDMA 数据通道支持节点之间的流。这使得Slash能够利用所有NIC的聚合带宽，以完整的RDMA网络速度在节点之间执行数据摄取和数据交换。其次，我们设计了一个有状态执行器，它省略了消息传递，并在后期合并技术[70]之后运行查询。最后，我们用 SSB 替换重新分区，从而实现跨分布式节点的一致状态共享。这使得多个节点能够同时更新状态的相同键值对（例如，一组窗口聚合）。为了确保一致性，我们引入了一个基于 epoch 的协议来懒惰地使用 RDMA 同步状态更新。

总体而言，Slash 执行器通过在数据流上急切应用有状态运算符来计算部分状态来扩展计算。为此，执行器将部分状态存储到SSB中，这确保了所有Slash执行器的状态一致视图。我们对常见流工作负载的评估表明，Slash 优于基于数据重新分区的基线方法，并且与偏斜无关。特别是，我们将 Slasash 与 IPoIB 网络上的 scale-out SPE （Apache Flink） 进行比较，IPoIB 网络上的 scale-up SPE 称为 LightSaber 的 scale-up SPE 和一个名为 RDMA UpPar 的自行开发的稻草人解决方案，它通过基于 RDMA 的数据重新分区扩展查询执行。Slash 的吞吐量分别比 RDMA UpPar 和 LightSaber high 25 倍和 11.6 倍。此外，Slash 通过实现一个数量级的吞吐量优于 Flink。总体而言，这表明仅 RDMA 不能在不重新设计 SPE 内部的情况下实现峰值性能。

在本文中，我们做出了以下贡献：

• 为了原生集成高速 RDMA 网络，我们提出了 Slasash，这是一种新颖的 RDMA 加速 SPE。
• 我们设计了一个有状态查询执行器，以在 RDMA 网络上进行 Slasash 向外扩展数据流处理。
• 我们为 Slasash 定义了一个 RDMA 流协议，以使用 RDMA 通道以线速率传输数据。
• 我们构建了 SSB，可以在 RDMA 互连上实现分布式一致状态。
• 我们在高端 RDMA 集群上的公共流基准上验证了 Slasash 的设计，并表明比我们最强的基线提高了 25 倍的吞吐量。

我们将本文的结构如下。在第 2 节中，我们介绍了有关 RDMA 和数据流处理的背景概念。在第 3 节中，我们对 SPE 进行了 RDMA 加速的情况，并列出了挑战和机遇。在第 4 节中，我们介绍了 Slasash 的系统架构，并提供了每个组件的概述。之后，我们描述了有状态执行器（第 5 节）、RDMA 通道（第 6 节）和 SSB（第 7 节）。然后，我们在第8节中对Slash进行了广泛的评估。我们在第9节中描述了SPEs和支持rdma的数据库系统领域的相关工作。最后，我们总结了本文的研究结果，并讨论了第10节中未来工作的想法。

2 背景

在本节中，我们将为我们的论文提供背景。我们在第2.1节中描述了RDMA，并在第2.2节中概述了流处理的当前方法。

2.1 远程直接内存访问 RDMA

RDMA是由Infiniband （IB）、RoCE （RDMA在收敛以太网上）和iWarp （Internet广域RDMA协议）网络[32]提供的通信堆栈。RDMA 能够以最少的远程 CPU 参与访问远程节点的主要内存。因此，RDMA 实现了高带宽（每个端口 [43] 高达 200 Gbps）和低延迟（每轮往返 [32] 高达 2μs）。RDMA 通过零拷贝提供双向数据传输，绕过了内核网络堆栈。相比之下，基于套接字的协议，如TCP，涉及用户和内核空间[9]之间昂贵的系统调用和数据副本。RDMA 支持的 NIC 还通过 IP-over-InfiniBand （IPoIB） 支持基于套接字的通信。然而，这种方法会导致较低的效率[9]。RDMA 为通信提供了两个 API（所谓的动词）：单边和双边动词 API [32]。此外，RDMA 提供了可靠、不可靠和数据报连接。可靠的连接使单边动词和有序数据包传递成为可能，而不可靠和数据报连接可能会丢弃数据包。使用双边动词（Send-Recv），发送方和接收方积极参与通信。接收方轮询传入消息，这需要 CPU 参与。相比之下，单边动词涉及一个主动发送者和一个被动接收者（RDMA WRITE）或被动发送者和一个主动接收者（RDMA READ）。它们可以实现更有效的数据传输，但需要同步来检测入站的消息。

RDMA 提供了两个主要好处：它 1) 可以实现快速数据传输，以及 2) 在节点之间共享内存区域 []。但是，启用 DMA 的系统需要仔细设计，因为 RST 不提供本地内存和远程内存之间的连贯性。相反，这转移到了应用程序中。此外，NIC 内存、主要内存和 CPU 之间的一致性取决于供应商 [ 9]。动词和参数的选择，例如消息大小，是应用程序敏感的，需要仔细调整 [32]。

2.2 有状态流处理引擎

最近的 SPE（流处理引擎）使用放大或缩小的处理模型。Scaleup SPE 专注于单节点效率，而 scale-out SPE 的目标是集群可扩展性。放大spe，如LightSaber[56]、BriskStream[72]和Grizly[23]，针对多套接字多核cpu的单节点部署。向外扩展 SPE，例如 Flink [11]、Storm [58]、Spark Streaming [68]、Millwheel [4]、Google Dataflow [5] 和 TimelyDataflow [47]，对无共享架构并行化查询。Scale-up 和 scale-out SPE 假设公共数据和查询模型，但它们以不同的方式执行查询。我们在下面总结了它们的数据、查询和处理模型。

数据和查询模型。我们遵循 Fernandez 等人介绍的定义。[ 12 ] 并假设数据流由不可变、无界的记录组成。记录包含时间戳 t、主要密钥 k 和一组属性。时间戳是严格单调递增的，用于窗口相关操作以及进度跟踪。流查询被建模为有向无环图，其中有状态运算符作为顶点，数据流为边缘。流运算符的输出取决于输入记录的内容、时间戳或到达顺序及其中间状态。一般来说，运算符必须在时间戳