Apache Arrow Flight:快速数据传输框架

在过去 18 个月,Apache Arrow 社区一直忙于设计和实施 Flight,这是一个新的通用客户端服务器框架,用于简化大型数据集通过网络接口的高性能传输。本文介绍了 Apache Arrow Flight 的起源、基础知识、优点、示例及对未来的展望。

Flight 最初专注于 Arrow Columnar Format(比如,Arrow record batch)通过 gRPC 传输的优化,gRPC 是谷歌流行的基于 HTTP/2 的通用 RPC 库和框架。尽管专注于集成 gRPC,但作为开发框架,Flight 并不专用于 gRPC。

Flight 与其他数据传输框架最大的区别是并行传输,其允许数据以流的形式同时进出服务器集群,这让开发人员可以更轻松地创建可扩展的数据服务,为不断增长的客户群提供服务。

在 0.15.0 Apache Arrow 版本中,提供了 C++(具有 Python 绑定)和 Java 的即用型 Flight 实现。这些库适用于 beta 版用户,他们习惯 API 或协议更改,而我们将继续完善 Flight 内部的底层细节。

开发契机

很多开发者都体会过通过网络访问大型数据集的痛苦。有很多不同的传输协议和工具用于从远程数据服务中读取数据集,这些远程数据服务包括 ODBC 和 JDBC 等。在过去 10 年,基于文件的数据仓库,比如 CSV、Avro 和 Parquet 的格式已经变得很受欢迎,但也带来了挑战,因为原始数据必须在反序列化之前传输到本地主机。

自 Apache Arrow 诞生以来,我们完成的工作为用多种方式加速数据传输带来了不错的前景 。 Arrow Columnar Format 是其中的关键特性:

  • 它是表数据的“在线”表示,不需要在接收时进行反序列化。
  • 它的自然模式是“流批量(streaming batches)”,较大的数据集一次多行地进行传输,在 Arrow 用语中称为“记录批量(record batches)”。本文将讨论“数据流(data streams)”,这些是使用项目的二进制协议的 Arrow 记录批量的序列。
  • 这种格式与语言无关,现在 11 种编程语言(持续增加中)中具有库支持。

标准协议(如 ODBC)的实现通常实现自定义在线二进制协议,这些协议必须编组进出每个库的公共接口。ODBC 或 JDBC 库的性能因情况而异。

我们设计 Flight 的目标是为数据服务创建新的协议,这些数据服务使用 Arrow Columnar Format 作为在线的数据表示和提供给开发人员的公共 API。为了实现这一点,我们减少或消除了与数据传输相关的序列化成本,并提高了分布式数据系统的整体效率。此外,已经把 Apache Arrow 用于其他目的的两个系统可以极其高效地相互通信数据。

Flight 基础知识

Arrow Flight 库为实现可以发送和接收数据流的服务提供开发框架。Flight 服务支持几个基本类型的请求:

  • Handshake :一个简单请求,用于确定客户段是否得到授权,并且在某些情况下,用于建立实现定义的会话令牌,以用于未来的请求
  • ListFlights :返回可用数据流的列表
  • GetSchema :返回数据流的模式
  • GetFlightInfo :返回感兴趣的数据集的“访问计划”,可能需要使用多个数据流。该请求可以接受包含如特定应用程序参数的自定义序列化命令。
  • DoGet :给客户端发送一个数据流
  • DoPut :从客户端接收一个数据流
  • DoAction :执行特定于实现的行动,并返回任何结果,即:广义函数调用
  • ListActions :返回可用操作类型的列表

我们利用 gRPC 出色的“双向”流支持(构建于 HTTP/2 流 之上),以允许客户端和服务器在处理请求的同时,互相发送数据和元数据。一个简单的 Flight 设置可能包含一个单独的服务器,客户端可以连接到此服务器并发出 DoGet 请求。

通过 gRPC 优化数据吞吐量

尽管使用通用消息传递库(如 gRPC)有着很多明显的益处 (利用谷歌在这个问题上完成的所有工程设计),但是,还是需要做些工作来改善传输大型数据集的性能。例如,很多类型的 gRPC 用户只处理相对较小的消息。

使用 gRPC 的最佳支持方式是,在 Protocol Buffers (也叫“Portobuf”).proto 文件中定义服务。用于 gRPC 的 Protobuf 插件会生成 gRPC 服务存根,可以用来实现应用程序。RPC 命令和数据消息使用 Protobuf 有线格式 序列化。因为我们使用“vanilla Grpc 和 Protocol Buffers ”,所以,无视 Arrow Columnar Format 的 gRPC 客户端仍然可以和 Flight 服务进行交互且不透明地处理 Arrow 数据。

在 Flight 中,与数据相关的 Protobuf 主要类型被称为 FlightData。读写 Protobuf 消息通常不是免费的,因此,在 gRPC 中,我们在 C++ 和 Java 中实现了一些低层次的优化,以实现以下目的:

为 FlightData 生成 Protobuf 有线格式,其中包括要发送的 Arrow 记录批量而无需执行任何中间内存复制或序列化步骤。

从 FlightData 的 Protobuf 表示重新构建 Arrow 记录批量,而无需任何内存复制或序列化工作。事实上,我们拦截了编码数据的有效载荷,而不允许 Protocol Buffers 库接触它们。

在某种意义上,我们是鱼和熊掌兼得。具有这些优化的 Flight 实现将有更好的性能,而简单的 gRPC 客户端仍然可以与 Flight 服务对话,并使用 Protobuf 库来反序列化 FlightData(尽管有些性能损失)。

至于性能,在 C++ 数据吞吐量基准测试中,在没有启用 TLS 的情况下,本地主机端到端 TCP 吞吐量超过 2-3GB/s。这个基准测试在大约 4 秒的时间里,传输了大约 12GB 的数据。

复制代码
$ ./arrow-flight-benchmark --records_per_stream100000000
Bytes read:12800000000
Nanos:3900466413
Speed:3129.63MB/s

由此,我们可以得出结论,Flight 和 gRPC 机制增加的开销相对较小,这意味着很多实际的 Flight 应用程序会在网络带宽上遇到瓶颈。

水平可扩展性:并行和分区数据访问

很多分布式数据库类型的系统都使用一种架构模式,其中客户端请求的结果通过“协调器(coordinator)”路由,并发送到客户端。除了在将数据集多次传输到客户端的过程中存在明显的效率问题外,它还带来了访问非常大的数据集时的可扩展性问题。

我们希望 Flight 使系统能够创建水平可扩展的数据服务,而不需要处理这些瓶颈问题。客户端使用 GetFlightInfo RPC 到数据集的请求,会返回一个端点列表,每个端点都包含服务器位置和一个票据,用于 DoGet 请求发送该服务器以获取完整数据集的一部分。为了访问整个数据集,必须使用所有端点。尽管 Flight 流不一定必须有序,但我们提供了应用程序定义的元数据,这些元数据可以用于序列化排序信息。

这种多端点模式有很多好处:

  • 客户端并行读取端点
  • 服务于 GetFlightInfo“计划(planning)”请求的服务可以把任务委托给同级服务,以利用数据的局部性或简单地帮助负载均衡。
  • 分布式集群中的节点可以扮演不同的角色。比如,节点子集可以负责计划查询,而其他节点专门满足数据流(DoGet 或 DoPut)请求。

以下是具有拆分服务角色的多节点架构的示例图:

Actions:使用应用程序业务逻辑扩展 Flight

在请求一个数据集时,尽管 GetFlighInfo 请求支持发送不透明的序列化命令,但是,客户端也许需要能够请求服务器执行其他类型的操作。比如,客户端可能请求一个特定的数据集,“固定”在内存中,以便来自其他客户端的后续请求会更快地得到服务。

这样,Flight 服务可以选择定义“actions”,由 DoAction RPC 执行。操作请求包含正在执行的 actions 名和进一步所需信息的可选序列化数据。actions 的结果是一个不透明的二进制 gRPC 流。

一些示例 actions:

  • 元数据发现,超越内置 ListFlights RPC 提供的能力
  • 设置特定于会话的参数和配置

注意,对服务器来说,并不要求实现任何 actions,也不需要返回结果

加密和身份验证

Flight 利用 gRPC 内置的 TLS/OpenSSL,支持开箱即用的加密

对于身份验证,有供客户端和服务器使用的可扩展身份验证处理程序,允许简单的身份验证方案(如用户名和密码),还有像更多涉及身份验证的 Kerberos。Flight 协议带有内置的 BasicAuth,因此,用户名 / 密码验证可以开箱即用地实施,无需定制开发。

中间件和跟踪

gRPC 具有“拦截器(interceptors)”的概念,它允许我们开发开发人员定义的“中间件”,中间件可以为传入和传出的请求提供检测或遥测。一个用于这类检测的框架是 OpenTracing。

请注意,中间件的功能是该项目的最新领域之一,并且,目前只在该项目的主分支可用。

gRPC,但不只是 gRPC

我们使用 RFC 3986 兼容的 URI,为 DoGet 请求指定服务器位置。比如,可以用 grpc+tls:// H O S T :

PORT 来指定受 TLS 保护的 gRPC。

虽然我们认为把 Grpc 用于 Flight 服务器的“命令(command)”层是有意义的,但是,我们还是希望支持 TCP 以外的数据传输层,如 RDMA 。虽然这需要一些设计和开发工作使其变得可行,但其思想是,gRPC 可用于协调在 TCP 以外的协议上执行的 get 和 put 传输。

未来规划

Flight 用户文档还在制作过程中,但是,库本身已经足够成熟,能够容忍来年有一些小的 API 或协议变化的 beta 版用户可以试用。通过 Flight 来试验的最简单的方法之一是使用 Python API,由于自定义服务器和客户端可以完全用 Python 来定义,不要求进行任何编译。我们可以在 Arrow 代码库中看到 用 Python 的 Flight 客户端和服务器示例

在实际使用中,Dremio 开发了 基于Arrow Fligh t 的连接器, 的性能比 ODBC 好 20-50 倍 。对于 Apache Spark 用户,Arrow 贡献者 Ryan Murray 创建了一个 数据源实现 来连接到支持 Flight 的端点。

至于 Flight“下一步要做什么”,对非 gRPC(或非 TCP)数据传输的支持也许是研究和开发工作一个有趣的方向。从这里,很多 Flight 工作将创建面向用户、支持 Flight 的服务。由于 Flight 是一个开发框架,我们期望面向用户的 API 会使用一层 API 饰面,用于隐藏很多常规的 Flight 细节以及与自定义数据服务中特定 Flight 应用程序相关的细节。

原文链接: Introducing Apache Arrow Flight: A Framework for Fast Data Transport ∞

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章