Apache Arrow 各语言库实现状态全景：数据类型、IPC、Flight 与第三方格式支持矩阵详解

• 数据工程
• 大数据
• 序列化
• 数据分析

Apache Arrow 是一个面向加速数据交换与内存处理的跨语言工具箱，其核心价值在于"同一套列式内存格式，多种语言一致支持"。本文基于仓库文档 docs/source/status.rst（Implementation Status）展开，系统梳理 C++、Java、Go、JavaScript、C#、Rust、Julia、Swift、nanoarrow 以及 Python、R、Ruby、C/GLib 等官方库对 Arrow 格式各项能力的实现现状：从基础数据类型、嵌套类型、IPC 序列化、Flight RPC / Flight SQL 远程过程调用，到 C Data Interface 零拷贝互操作与 Avro/CSV/ORC/Parquet 等第三方格式的读写支持。读完本文，你将掌握各语言实现之间的能力差异、格式版本兼容性约定，以及在实际选型与跨语言集成时如何利用这张能力矩阵。

一、矩阵的前提：格式版本与库版本的对应关系

理解状态矩阵前，必须先明确 Arrow 的版本机制。根据 docs/source/format/Versioning.rst，自 1.0.0 起 Apache Arrow 对每次发布同时使用两个版本来描述：

• 格式版本（Format Version）：描述 Arrow 列式内存格式本身（如 flatbuffers 元数据布局、类型定义）的版本；
• 库版本（Library Version）：描述某个具体语言实现的发布版本。

一个格式版本可以对应多个库版本，例如库版本 2.0.0 与 3.0.0 都可能追踪格式版本 1.0.0。1.0.0 之前的版本不提供向前/向后兼容保证，而从 1.0.0 起遵循语义化版本（Semantic Versioning）。格式版本至今没有出过新的大版本，而是在 1.0.0 基础上递增了四个小版本：

这些新特性在不被使用的前提下与格式 1.0.0 兼容，因此所有官方库都遵循格式 1.0.0 或与其兼容的后续小版本。此外，状态文档明确指出：除非另有说明，Python、R、Ruby 与 C/GLib 库跟随 C++ Arrow 库的实现能力——这是阅读后续矩阵的一个捷径：这四门语言（及 C/GLib）的能力下限由 C++ 库决定。

矩阵本身不罗列全部语言，而是以"实现本体的官方库"为核心，覆盖：C++、Java、Go、JS（TypeScript）、C#、Rust、Julia、Swift、nanoarrow（轻量级 C 实现，作为对照），Python/R/Ruby/C/GLib 通过跟随关系间接覆盖。

二、数据类型支持矩阵

状态文档将数据类型分为三张表：基础类型（primitive）、嵌套类型（nested）与特殊类型（special），并对每一行标注各库的 ✓（支持）与空白（不支持）。这是判断"某类型能否在 A、B 两门语言间无缝互换"的第一手依据。

2.1 基础（标量）类型

表中三个注记（Notes）需要特别留意：

1. Java 不支持与 Float16 之间的类型转换（casting）——即使能存储 Float16 数组，也无法直接安全转换；
2. C# 的 Float16 支持仅在面向 .NET 6+ 时可用，即受目标框架版本约束；
3. Java 与 Rust 的 Dictionary 类型不支持嵌套字典（见下文特殊类型表）。

观察这张表可以得出几个结论：基础类型覆盖面最全的是 C++ 与 nanoarrow（除 Interval 外几乎全绿）；Swift 缺失较多（无 Decimal、Timestamp、Duration、Interval、变长视图、Large 系列等）；而格式 1.4 引入的 Binary View / Utf8 View / Large 视图系列目前仅 C++ 与 Go 完整支持，C# 支持除 Large 外的视图类型。仓库中这些类型在 C++ 侧由 cpp/src/arrow/type.h 统一声明，例如Decimal128Type、LargeStringType、BinaryViewType等，并以Type::type枚举驱动内存布局与 IPC 序列化。

2.2 嵌套类型

嵌套类型是 Arrow 表达"表中表"、"键值对"、"变长结构体"等复杂列的基础。List View / Large List View 与 Binary View 同属于格式 1.4 引入的视图布局（见 docs/source/format/Versioning.rst），目前同样只由 C++、Go（及 C# 的 List View）提供实现；Swift 对全部嵌套类型均未覆盖。

2.3 特殊类型

Dictionary（字典编码）用于压缩高基数字符串列，Java 与 Rust 的注记 (3) 表示不支持嵌套字典（即字典值本身不能是字典类型）。Extension（扩展类型）允许在标准类型上附加自定义语义（如arrow.fixed_shape_tensor），JS、C#、Swift 尚未实现。Run-End Encoded 属格式 1.3 新增布局，仅 C++ 与 Go 支持——这与 C++ 侧的RunEndEncodedType及 go/arrow 中的对应实现保持一致。

2.4 规范扩展类型（Canonical Extension Types）

除通用 Extension 类型外，Arrow 还维护一批跨系统统一的规范扩展类型（定义见 docs/source/format/CanonicalExtensions.rst）。其标准化有明确门槛：扩展名必须以arrow.开头、参数与序列化方式必须在提案中说明、且至少提交一个实现（非平凡实现建议两个）。目前官方列表中的实现情况为：

唯一的已标准化条目是Fixed shape tensor（arrow.fixed_shape_tensor）：其存储类型为FixedSizeList（list_size等于张量形状各维度乘积），扩展参数包括value_type、shape，可选dim_names描述各维度的逻辑名称（须与物理行主序布局对应）。而 Variable shape tensor 在所有语言中均未实现。这也再次印证了状态文档的价值——它连"尚无人实现"的能力都如实标注。

三、IPC 格式支持矩阵

IPC（Interprocess Communication）是 Arrow 的序列化与进程间通信协议，分为流格式（stream format，可无限追加 batch 的消息流）与文件格式（file format，带 magic number 与 footer 的可随机访问文件），协议细节见 docs/source/format/Columnar.rst 中的 Serialization 章节及 format/Message.fbs、format/File.fbs 等 Flatbuffers 定义。

对应注记：

1. 增量字典不支持嵌套字典；
2. 遇到非本机字节序的数据，读取时会自动做字节交换（byte-swap），因此跨大端/小端平台传输无需手动处理；
3. Java 的 LZ4 编解码器目前效率较低，官方用 JIRA 编号 ARROW-11901 追踪性能改进；
4. nanoarrow 的 IPC 实现仅支持读取流格式（即只实现了 reader 端）。

在 C++ 侧，这些能力集中在 cpp/src/arrow/ipc/reader.h（RecordBatchStreamReader、RecordBatchFileReader）与writer.h（对应RecordBatchStreamWriter、RecordBatchFileWriter）中，包括字典读取、压缩缓冲（LZ4、ZSTD 等，可配合 cpp/src/arrow/ipc/options.h 的IpcWriteOptions::codec配置）、自动字节序转换等逻辑。JS 不支持缓冲区压缩，Swift 除流格式、文件格式与 Record batches 外其余 IPC 能力均空白，而 Tensors / Sparse tensors（Tensor 与稀疏张量的 IPC 传输）目前只有 C++ 提供。

四、Flight RPC：高性能数据服务框架的支持现状

Arrow Flight 是构建在 gRPC 之上、面向 Arrow 数据的 RPC 框架（规范见 docs/source/format/Flight.rst，协议消息定义见 format/Flight.proto）。其核心对象包括FlightDescriptor（数据流标识，可取PATH路径或CMD二进制命令两种形态）、FlightInfo（含 schema、描述符与若干FlightEndpoint）、Ticket（服务器端识别数据的不透明令牌），客户端通过GetFlightInfo获取数据位置、再用DoGet(Ticket)拉取记录批次流，或通过DoPut上传。

4.1 传输层支持

JS、Julia、Swift 尚未提供 Flight 传输层实现；UCX（高性能网络传输库）路径仅 C++ 支持。

4.2 gRPC 传输下的功能支持

gRPC 传输下的注记：

1. C# 不支持Handshake与DoExchange两个方法，其余 RPC 方法可用；
2. C# 使用 AspNetCore 的认证处理器实现认证；
3. 该行表示"单个客户端是否支持多个并发调用"，gRPC 下并发调用在单条连接上多路复用。

4.3 UCX 传输下的功能支持

UCX 传输下的注记：

4. 仅支持DoExchange、DoGet、DoPut与GetFlightInfo四个方法，且不支持认证、超时、取消与中间件；
5. 每个并发调用在 UCX 下是到服务器的独立连接（与 gRPC 的多路复用相反），通常吞吐更好，但会同时消耗更多服务器与客户端资源。

这意味着：若追求 Flight 的完整功能矩阵（认证、超时、取消、中间件、错误码），应优先选择 C++、Java、Go 或 Rust 的 gRPC 实现；UCX 传输适合对极致吞吐有要求、且可接受功能裁剪的 C++ 场景。仓库内java/flight、c_glib/arrow-flight-glib、ruby/red-arrow-flight等目录均可找到对应语言绑定的落地代码。

五、Flight SQL：SQL 元数据与语句执行协议（实验性）

Flight SQL 是在 Flight 之上定义的 SQL 交互协议（规范见 docs/source/format/FlightSql.rst，消息定义见 format/FlightSql.proto）。状态文档特别注明：

• Flight SQL 仍处于实验阶段；
• 表中"功能支持"仅指客户端/服务器库本身；实际数据库对单个功能是否可用，取决于数据库对 Flight SQL 协议的实现情况。

可以看到能力分层的规律：C++ 与 Java 覆盖全部 23 项（包括事务/保存点、CancelQuery、以及 Substrait 计划相关的新接口CreatePreparedSubstraitPlan、StatementSubstraitPlan）；Go、C#、Rust 覆盖"查询/元数据/预编译语句"这一核心子集，但不含事务与 Savepoint 相关方法；JS、Julia、Swift 尚无 Flight SQL 实现。FlightSql.proto中的ActionCreatePreparedStatementRequest、ActionBeginTransactionRequest、TicketStatementQuery等消息即为这些功能的服务端动作载体。

六、C Data Interface 与 C Stream Interface：零拷贝互操作边界

C Data Interface（docs/source/format/CDataInterface.rst）定义了基于 C 结构体的、跨语言零拷贝交换 Schema 与 Array 的 ABI；C Stream Interface（docs/source/format/CStreamInterface.rst）则定义了生产者/消费者形式的流式传输 ABI。这两张表刻画了"哪些语言能直接通过 C ABI 互相传递 Arrow 数据而不经过序列化"。

C Data Interface

C Stream Interface

解读要点：Python（通过 pyarrow 的 Cython 绑定）、R、Ruby、C/GLib 因跟随 C++ 实现，在这两张表上全绿；C++、Rust、Go、C#、nanoarrow 也完整支持四类导出/导入（nanoarrow 本身即围绕 C Data Interface 设计的轻量 C 实现）；Java 支持 C Data Interface 的 Schema/Array 导出导入，但未实现 C Stream Interface；Julia、Swift 两类接口均未实现。这也解释了 Arrow 生态中"跨语言传数据零拷贝"的常见落地方式：只要语言支持 C Data Interface，就可在共享内存场景下直接传递指针，避免 IPC 序列化开销。

七、第三方数据格式支持矩阵

Arrow 库除了原生格式外，还为常见数据格式提供读写集成。表中R = 支持读取（Read），W = 支持写入（Write）。

对应注记：

1. Java 的 ORC 读取通过 JNI 绑定实现，由org.apache.arrow.orc:arrow-orc构件提供；
2. Java 的 CSV 与 Parquet 读取通过 JNI 绑定到 Arrow C++ Datasets，由org.apache.arrow:arrow-dataset构件提供。

这说明两点：其一，能力最强的仍是 C++（四种格式均可读写，CSV/ORC/Parquet 对应 cpp/src/arrow/csv、cpp/src/arrow/parquet 与cpp/src/arrow/adapters/orc等目录）；其二，Java 并非从零实现 CSV/ORC/Parquet，而是通过 JNI 复用 C++ 实现，因此其能力边界与 C++ Datasets 组件一致。Go 与 Rust 各自原生实现 CSV 与 Parquet 的读写，Julia 原生实现 CSV 读写；Avro 仅 Java 与 Go 提供只读支持；JS、C#、Swift 暂未提供上述第三方格式读写。

八、如何用好这张状态矩阵

综合全文，这张矩阵是跨语言选型与集成时的高价值"能力地图"，建议按以下方式使用：

1. 确定基准实现：Python、R、Ruby、C/GLib 一律以 C++ 库为基准，因此评估这些语言时直接查 C++ 行即可；
2. 核对格式版本：所有官方库均兼容格式 1.0.0 及后续小版本（1.1～1.4），只要不使用新版本特有的类型/布局（如 Binary View、Run-End Encoded、Decimal256、MonthDayNano），跨库互换就没有格式层面的障碍，细节见 docs/source/format/Versioning.rst；
3. 关注"新特性窗口"：格式 1.3/1.4 引入的视图类型与 Run-End 布局目前仅少数语言支持，若业务强依赖这些能力，可选项基本限定在 C++/Go（及部分 C#）；
4. 零拷贝集成选 C Data Interface：在支持该 ABI 的语言（C++、Python、R、Rust、Go、Java、C/GLib、Ruby、C#、nanoarrow）之间可直接互传 Schema/Array；需要流式生产-消费场景时再确认对方是否实现了 C Stream Interface（Java、Julia、Swift 缺失）；
5. Flight 选型关注功能裁剪：gRPC 传输的 C++/Java/Go/Rust 功能最全；C# 缺Handshake/DoExchange；UCX 传输仅有 C++ 且方法子集受限；Flight SQL 目前只有 C++/Java 支持事务、Savepoint 与 Substrait 计划类接口。

Apache Arrow 的状态文档本身也是一个"活文档"——随着格式小版本演进与新语言实现的完善，矩阵中的单元格会持续变化。阅读时建议以仓库内 docs/source/status.rst 的当前内容为准，并对照 docs/source/format/Columnar.rst 等规范原文理解每个能力项背后的格式定义。

• 数据工程
• 大数据
• 序列化
• 数据分析