Apache Arrow Flight：快速数据传输框架_语言 & 开发_Wes McKinney

在过去 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_stream 100000000Bytes read: 12800000000Nanos: 3900466413Speed: 3129.63 MB/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 Flight 的连接器，的性能比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 ∞