常见问题解答

通用问题

Apache Arrow 是什么？

Apache Arrow 是一个多语言工具箱，用于构建处理和传输大型数据集的高性能应用程序。它旨在同时提高分析算法的性能以及在不同系统（或编程语言）之间移动数据的效率。

Apache Arrow 的一个关键组成部分是其内存列式格式，这是一个标准化的、语言无关的规范，用于在内存中表示结构化的、表格状的数据集。这种数据格式具有丰富的数据类型系统（包括嵌套类型和用户定义类型），旨在支持分析型数据库系统、数据帧库等的需要。

该项目还包含多种语言实现的 Arrow 列式格式，以及用于读写多种常见存储格式的工具。这些官方库使得第三方项目无需自行实现 Arrow 列式格式即可使用 Arrow 数据。对于那些只想实现格式的小部分功能的开发者，Arrow 项目提供了一些工具，例如 C 数据接口，以协助与官方 Arrow 库的互操作性。

Arrow 库包含许多软件组件，可协助解决与从远程存储系统获取数据以及通过网络接口移动 Arrow 格式数据相关的系统问题。即使在完全不使用列式格式的场景中，也可以使用其中的一些组件。

最后，除了协助处理数据访问和 I/O 相关问题的软件外，还有用于对 Arrow 数据集执行分析操作或查询的算法库。

为什么要为内存列式格式定义一个标准？

传统上，数据处理引擎的开发者会创建自定义的数据结构来表示正在处理中的内存数据集。考虑到这些数据结构的“自定义”特性，他们还必须开发序列化接口，以便在这些数据结构与不同的文件格式、网络线协议、数据库客户端及其他数据传输接口之间进行转换。这最终导致开发人员时间和 CPU 周期上的巨大浪费，这些时间都花在将数据从一种格式序列化到另一种格式上。

Arrow 的内存列式数据格式的基本原理是为几个相互关联的问题提供一个开箱即用的解决方案。

  • 一种通用的表格数据表示形式，在现代硬件上处理效率极高，同时也适用于广泛的使用场景。我们相信，未来会有越来越少的系统创建自己的数据结构，而会直接使用 Arrow。
  • 支持随机访问以及流式/扫描式工作负载。
  • 标准化的内存格式有助于算法库的重用。当使用自定义的内存数据格式时，通常需要重写通用算法以适配这些自定义的数据格式。
  • 使用或支持 Arrow 的系统之间可以以极小的代价传输数据。这极大地减少了分析工作负载中的序列化开销，而序列化开销通常占计算成本的 80-90%。
  • Arrow 格式的语言无关设计使得用不同编程语言编写的系统（甚至运行在 JVM 上的系统）能够在没有序列化开销的情况下交换数据集。例如，一个 Java 应用程序可以在源自 JVM 的数据上调用 C 或 C++ 算法。

项目状态

Arrow 格式稳定吗？在我的应用程序中使用它安全吗？

Arrow 列式格式和协议被认为是稳定的，我们只打算进行向后兼容的更改，例如增加数据类型。它已被许多应用程序使用，您可以相信兼容性不会被破坏。有关 Arrow 格式版本控制和稳定性的详细信息，请参阅文档。

Arrow 库稳定吗？

请参考实现矩阵。

Arrow 数据相关的 MIME 类型 (IANA 媒体类型)

已为 Apache Arrow IPC 协议数据（包括流式和文件变体）注册了官方 IANA 媒体类型 (MIME 类型)

我们推荐使用“.arrow”作为 IPC 文件格式的文件扩展名

对于 IPC 流式格式，推荐使用“.arrows”作为文件扩展名

入门指南

我在哪里可以获取 Arrow 库？

可以通过常用的包管理器获取多种语言的 Arrow 库。请参阅安装页面获取具体信息。

参与贡献

我有一些问题。如何获得帮助？

Arrow 邮件列表是提问的最佳场所。请不要犹豫——我们随时准备提供帮助。

我尝试使用 Arrow 但它没有工作。你们能修复吗？

希望如此！请提交详细的 Bug 报告——这对项目本身来说是一个宝贵的贡献。有关如何提交报告，请参阅贡献指南。

Arrow 看起来很棒，如果它能实现 X 功能，我肯定会用。这个功能什么时候能完成？

我们使用 GitHub 作为问题追踪系统。请搜索与您需求匹配的问题。如果您找到了，请随意评论并描述您的使用场景——这将有助于接手该任务的人。如果您找不到，请创建一个新的问题。

最终，Arrow 是一个由社区编写并为社区服务的软件。如果您没有看到社区中有人正在解决您的问题，最好的办法就是自己动手。我们非常乐意帮助您成功地为项目做出贡献。

如何报告安全漏洞？

请发送电子邮件至 private@arrow.apache.org。更多信息请参阅安全页面。

与其他项目的关系

Apache Arrow 和 Apache Parquet 有什么区别？

Parquet 不是一种“运行时内存格式”；一般来说，文件格式几乎总是需要反序列化到某种内存数据结构才能进行处理。我们希望 Arrow 成为那种内存数据结构。

Parquet 是一种旨在最大化空间效率的存储格式，使用了高级压缩和编码技术。它非常适合在存储千兆字节或更多数据时最小化磁盘使用。这种效率的代价是将数据读入内存的成本相对较高，因为 Parquet 数据不能直接操作，而必须以大块进行解码。

相反，Arrow 是一种内存格式，主要用于计算目的的直接和高效使用。Arrow 数据通常不进行压缩，而是以 CPU 的自然格式布局，以便可以全速访问任意位置的数据。（但是，Arrow 也提供了一些有限的选项来提高空间效率，包括字典编码、游程长度编码和缓冲区压缩。）

因此，Arrow 和 Parquet 相辅相成，常在应用程序中一起使用。使用 Parquet 将数据存储在磁盘上，并以 Arrow 格式读入内存，将使您能够充分利用计算硬件。

那么“Arrow 文件”是什么呢？

Apache Arrow 定义了一种进程间通信 (IPC) 机制，用于传输一组 Arrow 列式数组（称为“记录批次”）。它可以使用 Arrow 的“流式格式”在进程之间同步使用，或者首先使用 Arrow 的“文件格式”将数据持久化到存储上来实现异步使用。

Arrow IPC 机制基于 Arrow 的内存格式，因此磁盘上的表示与内存中的表示之间无需转换。因此，对 Arrow IPC 文件执行分析时可以使用内存映射，避免了反序列化开销和额外的数据拷贝。

比较 Arrow IPC 文件格式和 Parquet 格式时需要记住的一些事项

  • Parquet 旨在用于长期存储和存档目的，这意味着如果您今天写入一个文件，可以期望任何声称能“读取 Parquet”的系统都能在 5 年或 10 年后读取该文件。虽然 Arrow 的磁盘格式是稳定的，并且未来版本的库可以读取，但它不优先考虑长期存档存储的要求。

  • 读取 Parquet 文件通常需要高效但相对复杂的解码，而读取 Arrow IPC 文件则无需任何解码，因为磁盘上的表示与内存中的表示相同。

  • Parquet 文件通常比 Arrow IPC 文件小得多，因为 Parquet 使用了列式数据压缩策略。如果您的磁盘存储或网络速度较慢，即使是短期存储或缓存，Parquet 也可能是一个更好的选择。

“Feather”文件格式是什么？

Feather v1 格式是在 Arrow IPC 文件格式开发之前，用于将 Arrow 格式的一个子集写入磁盘的简化自定义容器。“Feather 版本 2”现在与 Arrow IPC 文件格式完全相同，我们保留了“Feather”名称和 API 以保持向后兼容性。

Arrow 与 Protobuf 有什么关系？

Google 的 protocol buffers 库 (Protobuf) 不是一种“运行时内存格式”。与 Parquet 类似，Protobuf 的表示不适合直接处理。数据必须反序列化到像 Arrow 这样的内存表示中才能进行处理。

例如，Protobuf 中的无符号整数被编码为 varint，其中每个整数可能有不同的字节数，并且最后三位包含字段的线类型。您无法使用 CPU 以这种格式直接进行数字相加。

Protobuf 有执行这种反序列化的库，但它们的目的不是提供一个通用的内存格式。由 protoc 生成的 C# 代码反序列化的消息与由 protoc 生成的 Java 代码反序列化的消息表示形式不会相同。您需要将数据从一种语言封送到另一种语言。

Arrow 避免了这个问题，但这会以增加空间为代价。对于在线上传输特定类型的数据（如单个记录或包含许多可选字段的稀疏数据），Protobuf 可能是更好的选择。就像 Parquet 一样，这意味着 Arrow 和 Protobuf 很好地互补。例如，Arrow Flight 使用 gRPC 和 Protobuf 来序列化其命令，而数据则使用二进制 Arrow IPC 协议进行序列化。

Arrow 与 Flatbuffers 有什么关系？

Flatbuffers 是一个用于二进制数据序列化的低级构建块。它不适用于表示大型、结构化、同质的数据，并且不处于数据分析任务所需的适当抽象层。

Arrow 是一个直接面向数据分析需求的数​​据层，提供分析所需的数据类型集合，内置对“空”值（表示缺失数据）的支持，以及不断扩展的 I/O 和计算工具箱。

Arrow 文件格式在底层确实使用 Flatbuffers 来序列化实现 Arrow 二进制 IPC 协议所需的 schema 和其他元数据，但 Arrow 数据格式使用其自己的表示形式以实现最佳访问和计算。