在过去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 100000000
Bytes read: 12800000000
Nanos: 3900466413
Speed: 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://$HOST:$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 ∞

创作场景

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