Apache Arrow 格式规范变更流程指南从 DISCUSS 讨论、双参考实现到 VOTE 表决与版本推进【免费下载链接】arrowApache Arrow is a multi-language toolbox for accelerated data interchange and in-memory processing项目地址: https://gitcode.com/gh_mirrors/arrow12/arrow本文聚焦 Apache Arrow 仓库中格式Format规范的治理机制系统讲解在 format/ 目录下的二进制协议定义FlatBuffers / Protocol Buffers 文件发生变更时项目如何通过公开邮件列表讨论、社区表决、双参考实现与集成测试来确保跨语言兼容性并配套说明格式版本号Format Version的演进规则。读完本文你将掌握提交一个 Arrow 格式变更提案所需的完整流程、邮件主题规范、参考实现要求以及如何借助 Archery 集成测试工具验证格式改动在各语言实现间的一致性。为什么格式变更需要一套治理流程Apache Arrow 的核心承诺是跨语言Cross-language兼容同一份列式数据无论由 C、Java、Go 还是其他语言生成其他语言实现都应能无歧义地读取。这一承诺直接体现在文档 Changing.rst 的开篇论断中——兼容性是项目的第一优先级。format/目录下存放着决定数据格式的权威定义文件它们共同构成 Arrow 的二进制协议文件作用format/Schema.fbs定义内置数据类型Int、FloatingPoint、Decimal、Timestamp、List、Union 等format/Message.fbs定义消息封装FieldNode、RecordBatch、BodyCompression 等format/File.fbs定义文件File与流Stream两种 IPC 封装格式format/SparseTensor.fbs、format/Tensor.fbs张量序列化定义format/Flight.proto、format/FlightSql.protoFlight RPC 与 Flight SQL 协议format/adbc.hADBCArrow Database Connectivity接口定义正因这些文件被所有语言实现共同引用任何改动都可能波及每个实现。为此Changing.rst 规定了针对格式文件的强制流程必须在公开邮件列表上讨论并投票表决改动至少要有两个参考实现及配套的集成测试用于验证改动的跨语言兼容性与一致性。这两条要求不必按顺序执行且多数情况下先产出一份草稿参考实现反而有助于设计讨论——实现过程中的真实约束字节对齐、缓冲区分割、端序处理等远比纸面讨论更能暴露问题。此外文档还明确提醒同步更新 docs/source/format/ 目录下的规范文档同样是必须的不能让规范文本与代码实现脱节。讨论与表决流程邮件列表上的 [DISCUSS] 与 [VOTE]格式变更的全部正式讨论都发生在公开邮件列表上任何社区成员都可以参与无需特殊身份。流程分两阶段第一阶段[DISCUSS] 讨论线程讨论应通过发送至devarrow.apache.org的邮件线程发起主题必须以[DISCUSS]作为前缀。文档特别说明社区偶尔也会使用[Discuss]、DISCUSS:等变体写法但[DISCUSS]是推荐的标准格式。文档给出的两个真实案例[Discuss][Format] Add 32-bit and 64-bit Decimals新增 32 位与 64 位 Decimal 类型[DISCUSS][Format] Starting to do some concrete work on the new StringView columnar data typeStringView 列式数据类型的落地工作。第二阶段[VOTE] 表决线程在 DISCUSS 线程中达成共识consensus后即可发起表决线程主题前缀为[VOTE]。表决的目的在于正式确认社区对格式变更已达成一致意见其流程参照 Apache 基金会的通用投票机制Apache Voting Process。一个完整的格式变更提案生命周期可归纳为提出想法 → [DISCUSS] 公开讨论 草稿实现辅助设计 → 达成共识 → [VOTE] 表决通过 → 更新 docs/source/format/ 规范文档 → 按格式版本规则递增版本号见下文 → 以集成测试持续守护兼容性双参考实现门槛什么才算完整实现格式变更必须有至少两个参考实现及其配套的集成测试以确认改动跨语言兼容且行为一致。这里的关键约束是参考实现必须是完整的 Arrow 实现。文档给出了一个重要反例——Python 库不合格因为它本质上是 C 库的包装层wrapper不能作为独立参考实现。当前文档认可的候选实现清单为C 实现Java 实现Rustarrow-rs实现Go 实现也就是说在仓库内实际上对应着 cpp/、java/、go/ 三大源码目录Rust 的 arrow-rs 为独立仓库不在本仓库内。如果社区认为有必要可以通过讨论与表决把更多实现加入该清单。判断某个实现是否完整可以参考 docs/source/status.rst 中的功能矩阵——该文件以表格形式列出了各语言对每种数据类型、每种 IPC 能力的支持情况例如 Binary View / Utf8 View、ListView、Run-End Encoded 等新特性在不同语言中的支持状态一目了然是评估参考实现完备性的直接依据。集成测试验证跨语言一致性的自动化护栏参考实现 集成测试中的集成测试在仓库中由Archery工具承担。集成测试的完整策略、JSON 测试数据格式与运行方法记录在 docs/source/format/Integration.rst 中。测试策略JSON 数据 生产者/消费者矩阵测试的核心思路是用人类可读的 JSON 描述 Arrow 内存数据让各语言实现充当生产者producer与消费者consumer在 IPC、Flight、C Data Interface 三种格式下两两配对互测生产者读取 JSON 文件 → 转换为内存中的 Arrow 数据 → 以被测格式如 IPC 文件导出消费者读取同一 JSON 文件 → 转换为内存 Arrow 数据 → 同时读取生产者产出的文件 → 校验两份数据集完全一致。以 IPC 测试为例C 可执行程序读取 JSON 生成 IPC 文件Java 程序读取同一 JSON 并校验 IPC 文件内容与自身内存数据相等。C Data Interface 场景下测试框架在堆上分配ArrowArray结构Go 进程内入口导出 record batchC# 进程内入口导入并比对必要时还断言内存占用未变化以检测泄漏。JSON 测试数据格式JSON 集成文件的顶层结构为{ schema: /*Schema*/, batches: [ /*RecordBatch*/ ], dictionaries: [ /*DictionaryBatch*/ ] }其中schema与batches必有dictionaries仅在存在字典类型字段时出现。仓库提供了可直接阅读的示例 docs/source/format/integration_json_examples/simple.json其内容如下节选自首个 batch{ schema: { fields: [ {name: foo, type: {name: int, isSigned: true, bitWidth: 32}, nullable: true, children: []}, {name: bar, type: {name: floatingpoint, precision: DOUBLE}, nullable: true, children: []}, {name: baz, type: {name: utf8}, nullable: true, children: []} ] }, batches: [ { count: 5, columns: [ {name: foo, count: 5, VALIDITY: [1, 0, 1, 1, 1], DATA: [1, 2, 3, 4, 5]}, {name: bar, count: 5, VALIDITY: [1, 0, 0, 1, 1], DATA: [1.0, 2.0, 3.0, 4.0, 5.0]}, {name: baz, count: 5, VALIDITY: [1, 0, 0, 1, 1], OFFSET: [0, 2, 2, 2, 5, 9], DATA: [aa, , , bbb, cccc]} ] } ] }要点说明缓冲区分VALIDITY1 有效 / 0 为空、OFFSET变长类型的偏移数组、TYPE_IDunion 判别值、DATA等类型非 nullable 字段仍会携带全为 1 的VALIDITY数组64 位整数、64 位偏移量以JSON 字符串形式书写以避免精度丢失浮点数限 3 位小数二进制数据以大写十六进制字符串表示嵌套类型list、struct 等通过children递归描述fixedsizelist无OFFSET由listSize隐含扩展类型extension type按其底层存储类型表示并辅以ARROW:extension:name、ARROW:extension:metadata元数据还原。运行集成测试首先安装带integration组件的 Archery$ pip install -e dev/archery[integration]然后运行archery integration命令。CLI 的完整选项定义在 dev/archery/archery/cli.py核心选项包括选项说明--run-ipc/--run-flight/--run-c-data选择要测试的格式至少启用一种--with-cpp/--with-java/--with-csharp/--with-js/--with-go/--with-nanoarrow/--with-rust/--with-all选择参与测试的语言实现至少启用一种--random-seed测试数据生成所用的随机种子默认12345保证可复现-k/--match按名称子串过滤测试用例例如-k primitive--gold-dirs指定 gold 集成测试文件目录-x/--stop-on-error首个错误即停止--serial串行执行默认并行文档给出的几个典型用法# 仅 C 参与运行 IPC 集成测试 archery integration --run-ipc --with-cpp1 # C 与 Java 共同参与 VERSION14.0.0-SNAPSHOT export ARROW_JAVA_INTEGRATION_JAR$JAVA_DIR/tools/target/arrow-tools-$VERSION-jar-with-dependencies.jar archery integration --run-ipc --with-cpp1 --with-java1 # 运行全部格式与全部语言 archery integration --with-all --run-flight --run-ipc --run-c-data注意事项运行前需要先构建好各语言组件例如 C 需在 cmake 命令中加入-DARROW_BUILD_INTEGRATIONON若未启用任何格式或任何语言CLI 会直接报UsageError提示见 cli.py 中的校验逻辑。数据生成器与 Gold 文件两类测试用例集成测试用例分为两类数据生成器用例由 dev/archery/archery/integration/datagen.py 中的get_generated_json_files()动态生成覆盖场景包括基础类型无 batch、多种值、零长度 batch、大偏移、Null 类型、Decimal128/Decimal256、各时间单位、Duration、各类 IntervalMonthDayNano 单列、Map含非规范 map、嵌套类型list/struct/大偏移/递归、Union、自定义元数据、重复字段名、字典类型有符号/无符号索引、嵌套字典、Run-End Encoded、Binary/Utf8 View、ListView/LargeListView、扩展类型。生成时通过.skip_tester(Java)、.skip_format(SKIP_C_SCHEMA, C)等机制跳过暂未支持的实现或格式维度——这些跳过声明本身正是各语言实现能力边界的最直观标注。Gold 文件用例预先在 arrow-testing 仓库中生成好的 JSON 与 IPC 文件file 与 stream 两种格式由runner.py引用作为基准数据覆盖0.14.1 与 0.17.1 格式的向后兼容性、大小端自动转换含 custom metadata、decimal256、扩展类型、递归嵌套、union 等几十种场景、LZ4/ZSTD 压缩、共享字典的 batch 等。测试运行器 dev/archery/archery/integration/runner.py 中的run_ipc()通过itertools.product对所有启用的生产者×消费者组合做笛卡尔积配对run_flight()则让每个 Flight 服务器与每个客户端组合互测——这就是双参考实现要求落在代码层面的执行形态。版本号演进格式版本与库版本分离格式变更通过表决后还需要递增格式版本号Format Version。需要注意格式版本独立于库版本Library Version。docs/source/format/Versioning.rst 对此有明确规定。自 1.0.0 起每个库版本都对应一个格式版本且多个库版本可以跟踪同一个格式版本例如库版本 2.0.0 与 3.0.0 可能都对应格式版本 1.0.0。库版本遵循语义化版本Semantic Versioning约定而格式版本则承载三项兼容性承诺向后兼容Backward Compatibility只要格式主版本不变新库一定能读取旧库产生的数据与元数据向前兼容Forward Compatibility旧库要么能读取新库产生的数据要么能检测出自己无法正确读取。格式次版本递增如 1.0.0 → 1.1.0表示新增了特性只要这些新特性未被使用例如未使用新数据类型向前兼容性就得到保留长期稳定Long-Term Stability格式主版本变更如 1.0.0 → 2.0.0意味着兼容性保证被打破这属于罕见的例外事件项目会以不损害生产应用为前提谨慎推进。仓库记录了 1.0.0 以来的全部格式次版本演进Post-1.0.0 Format Versions一节格式版本新增特性1.1256 位 Decimal 类型1.2MonthDayNano 间隔类型1.3Run-End Encoded 布局1.4变长二进制视图BinaryView / Utf8View、ListView / LargeListView、变长缓冲区Variadic Buffers截至当前仓库内容已有四个新次版本、零个新主版本。对照 docs/source/status.rst 可以看到这些新特性在不同语言中的落地进度例如 Binary View 目前仅 C、Go、C# 支持ListView 的支持面则更窄——这正是格式版本号之外、以功能矩阵形式呈现的软兼容层。因此当一个格式提案走完讨论、表决、实现、测试全流程后还应在 docs/source/format/Versioning.rst 的版本表中追加一条记录并同步 docs/source/status.rst 的功能支持矩阵。给格式变更贡献者的一张行动清单综合 Changing.rst 与上文各环节提交一项 Arrow 格式变更的完整路径为讨论向devarrow.apache.org发送主题为[DISCUSS][Format] ...的邮件说明变更动机、设计草案与影响面草稿实现在 C、Java、Go或 Rust arrow-rs中至少其一先行实现一个草稿版本用真实约束检验设计此步可与第 1 步并行集成测试借助 Archeryarchery integration参考 dev/archery/archery/cli.py在至少两个完整实现之间跑通新特性的 JSON 数据生成与生产者/消费者互测表决共识达成后发起[VOTE]线程并按 Apache 投票流程确认文档更新 docs/source/format/ 下的规范文档如 Columnar.rst、Layout.rst补充新版本文档版本号版本与状态在 docs/source/format/Versioning.rst 的次版本表中登记新特性并在 docs/source/status.rst 中标注各语言的实现进度。这套公开讨论 双实现互证 表决确认 版本登记的机制正是 Apache Arrow 在十多种语言、数十个独立代码库之间维持单一数据语义的根基任何格式变更都必须经得起至少两个独立实现的相互验证也因此在设计阶段就排除了绝大多数实现歧义。【免费下载链接】arrowApache Arrow is a multi-language toolbox for accelerated data interchange and in-memory processing项目地址: https://gitcode.com/gh_mirrors/arrow12/arrow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Apache Arrow 格式规范变更流程指南：从 DISCUSS 讨论、双参考实现到 VOTE 表决与版本推进
Apache Arrow 格式规范变更流程指南从 DISCUSS 讨论、双参考实现到 VOTE 表决与版本推进【免费下载链接】arrowApache Arrow is a multi-language toolbox for accelerated data interchange and in-memory processing项目地址: https://gitcode.com/gh_mirrors/arrow12/arrow本文聚焦 Apache Arrow 仓库中格式Format规范的治理机制系统讲解在 format/ 目录下的二进制协议定义FlatBuffers / Protocol Buffers 文件发生变更时项目如何通过公开邮件列表讨论、社区表决、双参考实现与集成测试来确保跨语言兼容性并配套说明格式版本号Format Version的演进规则。读完本文你将掌握提交一个 Arrow 格式变更提案所需的完整流程、邮件主题规范、参考实现要求以及如何借助 Archery 集成测试工具验证格式改动在各语言实现间的一致性。为什么格式变更需要一套治理流程Apache Arrow 的核心承诺是跨语言Cross-language兼容同一份列式数据无论由 C、Java、Go 还是其他语言生成其他语言实现都应能无歧义地读取。这一承诺直接体现在文档 Changing.rst 的开篇论断中——兼容性是项目的第一优先级。format/目录下存放着决定数据格式的权威定义文件它们共同构成 Arrow 的二进制协议文件作用format/Schema.fbs定义内置数据类型Int、FloatingPoint、Decimal、Timestamp、List、Union 等format/Message.fbs定义消息封装FieldNode、RecordBatch、BodyCompression 等format/File.fbs定义文件File与流Stream两种 IPC 封装格式format/SparseTensor.fbs、format/Tensor.fbs张量序列化定义format/Flight.proto、format/FlightSql.protoFlight RPC 与 Flight SQL 协议format/adbc.hADBCArrow Database Connectivity接口定义正因这些文件被所有语言实现共同引用任何改动都可能波及每个实现。为此Changing.rst 规定了针对格式文件的强制流程必须在公开邮件列表上讨论并投票表决改动至少要有两个参考实现及配套的集成测试用于验证改动的跨语言兼容性与一致性。这两条要求不必按顺序执行且多数情况下先产出一份草稿参考实现反而有助于设计讨论——实现过程中的真实约束字节对齐、缓冲区分割、端序处理等远比纸面讨论更能暴露问题。此外文档还明确提醒同步更新 docs/source/format/ 目录下的规范文档同样是必须的不能让规范文本与代码实现脱节。讨论与表决流程邮件列表上的 [DISCUSS] 与 [VOTE]格式变更的全部正式讨论都发生在公开邮件列表上任何社区成员都可以参与无需特殊身份。流程分两阶段第一阶段[DISCUSS] 讨论线程讨论应通过发送至devarrow.apache.org的邮件线程发起主题必须以[DISCUSS]作为前缀。文档特别说明社区偶尔也会使用[Discuss]、DISCUSS:等变体写法但[DISCUSS]是推荐的标准格式。文档给出的两个真实案例[Discuss][Format] Add 32-bit and 64-bit Decimals新增 32 位与 64 位 Decimal 类型[DISCUSS][Format] Starting to do some concrete work on the new StringView columnar data typeStringView 列式数据类型的落地工作。第二阶段[VOTE] 表决线程在 DISCUSS 线程中达成共识consensus后即可发起表决线程主题前缀为[VOTE]。表决的目的在于正式确认社区对格式变更已达成一致意见其流程参照 Apache 基金会的通用投票机制Apache Voting Process。一个完整的格式变更提案生命周期可归纳为提出想法 → [DISCUSS] 公开讨论 草稿实现辅助设计 → 达成共识 → [VOTE] 表决通过 → 更新 docs/source/format/ 规范文档 → 按格式版本规则递增版本号见下文 → 以集成测试持续守护兼容性双参考实现门槛什么才算完整实现格式变更必须有至少两个参考实现及其配套的集成测试以确认改动跨语言兼容且行为一致。这里的关键约束是参考实现必须是完整的 Arrow 实现。文档给出了一个重要反例——Python 库不合格因为它本质上是 C 库的包装层wrapper不能作为独立参考实现。当前文档认可的候选实现清单为C 实现Java 实现Rustarrow-rs实现Go 实现也就是说在仓库内实际上对应着 cpp/、java/、go/ 三大源码目录Rust 的 arrow-rs 为独立仓库不在本仓库内。如果社区认为有必要可以通过讨论与表决把更多实现加入该清单。判断某个实现是否完整可以参考 docs/source/status.rst 中的功能矩阵——该文件以表格形式列出了各语言对每种数据类型、每种 IPC 能力的支持情况例如 Binary View / Utf8 View、ListView、Run-End Encoded 等新特性在不同语言中的支持状态一目了然是评估参考实现完备性的直接依据。集成测试验证跨语言一致性的自动化护栏参考实现 集成测试中的集成测试在仓库中由Archery工具承担。集成测试的完整策略、JSON 测试数据格式与运行方法记录在 docs/source/format/Integration.rst 中。测试策略JSON 数据 生产者/消费者矩阵测试的核心思路是用人类可读的 JSON 描述 Arrow 内存数据让各语言实现充当生产者producer与消费者consumer在 IPC、Flight、C Data Interface 三种格式下两两配对互测生产者读取 JSON 文件 → 转换为内存中的 Arrow 数据 → 以被测格式如 IPC 文件导出消费者读取同一 JSON 文件 → 转换为内存 Arrow 数据 → 同时读取生产者产出的文件 → 校验两份数据集完全一致。以 IPC 测试为例C 可执行程序读取 JSON 生成 IPC 文件Java 程序读取同一 JSON 并校验 IPC 文件内容与自身内存数据相等。C Data Interface 场景下测试框架在堆上分配ArrowArray结构Go 进程内入口导出 record batchC# 进程内入口导入并比对必要时还断言内存占用未变化以检测泄漏。JSON 测试数据格式JSON 集成文件的顶层结构为{ schema: /*Schema*/, batches: [ /*RecordBatch*/ ], dictionaries: [ /*DictionaryBatch*/ ] }其中schema与batches必有dictionaries仅在存在字典类型字段时出现。仓库提供了可直接阅读的示例 docs/source/format/integration_json_examples/simple.json其内容如下节选自首个 batch{ schema: { fields: [ {name: foo, type: {name: int, isSigned: true, bitWidth: 32}, nullable: true, children: []}, {name: bar, type: {name: floatingpoint, precision: DOUBLE}, nullable: true, children: []}, {name: baz, type: {name: utf8}, nullable: true, children: []} ] }, batches: [ { count: 5, columns: [ {name: foo, count: 5, VALIDITY: [1, 0, 1, 1, 1], DATA: [1, 2, 3, 4, 5]}, {name: bar, count: 5, VALIDITY: [1, 0, 0, 1, 1], DATA: [1.0, 2.0, 3.0, 4.0, 5.0]}, {name: baz, count: 5, VALIDITY: [1, 0, 0, 1, 1], OFFSET: [0, 2, 2, 2, 5, 9], DATA: [aa, , , bbb, cccc]} ] } ] }要点说明缓冲区分VALIDITY1 有效 / 0 为空、OFFSET变长类型的偏移数组、TYPE_IDunion 判别值、DATA等类型非 nullable 字段仍会携带全为 1 的VALIDITY数组64 位整数、64 位偏移量以JSON 字符串形式书写以避免精度丢失浮点数限 3 位小数二进制数据以大写十六进制字符串表示嵌套类型list、struct 等通过children递归描述fixedsizelist无OFFSET由listSize隐含扩展类型extension type按其底层存储类型表示并辅以ARROW:extension:name、ARROW:extension:metadata元数据还原。运行集成测试首先安装带integration组件的 Archery$ pip install -e dev/archery[integration]然后运行archery integration命令。CLI 的完整选项定义在 dev/archery/archery/cli.py核心选项包括选项说明--run-ipc/--run-flight/--run-c-data选择要测试的格式至少启用一种--with-cpp/--with-java/--with-csharp/--with-js/--with-go/--with-nanoarrow/--with-rust/--with-all选择参与测试的语言实现至少启用一种--random-seed测试数据生成所用的随机种子默认12345保证可复现-k/--match按名称子串过滤测试用例例如-k primitive--gold-dirs指定 gold 集成测试文件目录-x/--stop-on-error首个错误即停止--serial串行执行默认并行文档给出的几个典型用法# 仅 C 参与运行 IPC 集成测试 archery integration --run-ipc --with-cpp1 # C 与 Java 共同参与 VERSION14.0.0-SNAPSHOT export ARROW_JAVA_INTEGRATION_JAR$JAVA_DIR/tools/target/arrow-tools-$VERSION-jar-with-dependencies.jar archery integration --run-ipc --with-cpp1 --with-java1 # 运行全部格式与全部语言 archery integration --with-all --run-flight --run-ipc --run-c-data注意事项运行前需要先构建好各语言组件例如 C 需在 cmake 命令中加入-DARROW_BUILD_INTEGRATIONON若未启用任何格式或任何语言CLI 会直接报UsageError提示见 cli.py 中的校验逻辑。数据生成器与 Gold 文件两类测试用例集成测试用例分为两类数据生成器用例由 dev/archery/archery/integration/datagen.py 中的get_generated_json_files()动态生成覆盖场景包括基础类型无 batch、多种值、零长度 batch、大偏移、Null 类型、Decimal128/Decimal256、各时间单位、Duration、各类 IntervalMonthDayNano 单列、Map含非规范 map、嵌套类型list/struct/大偏移/递归、Union、自定义元数据、重复字段名、字典类型有符号/无符号索引、嵌套字典、Run-End Encoded、Binary/Utf8 View、ListView/LargeListView、扩展类型。生成时通过.skip_tester(Java)、.skip_format(SKIP_C_SCHEMA, C)等机制跳过暂未支持的实现或格式维度——这些跳过声明本身正是各语言实现能力边界的最直观标注。Gold 文件用例预先在 arrow-testing 仓库中生成好的 JSON 与 IPC 文件file 与 stream 两种格式由runner.py引用作为基准数据覆盖0.14.1 与 0.17.1 格式的向后兼容性、大小端自动转换含 custom metadata、decimal256、扩展类型、递归嵌套、union 等几十种场景、LZ4/ZSTD 压缩、共享字典的 batch 等。测试运行器 dev/archery/archery/integration/runner.py 中的run_ipc()通过itertools.product对所有启用的生产者×消费者组合做笛卡尔积配对run_flight()则让每个 Flight 服务器与每个客户端组合互测——这就是双参考实现要求落在代码层面的执行形态。版本号演进格式版本与库版本分离格式变更通过表决后还需要递增格式版本号Format Version。需要注意格式版本独立于库版本Library Version。docs/source/format/Versioning.rst 对此有明确规定。自 1.0.0 起每个库版本都对应一个格式版本且多个库版本可以跟踪同一个格式版本例如库版本 2.0.0 与 3.0.0 可能都对应格式版本 1.0.0。库版本遵循语义化版本Semantic Versioning约定而格式版本则承载三项兼容性承诺向后兼容Backward Compatibility只要格式主版本不变新库一定能读取旧库产生的数据与元数据向前兼容Forward Compatibility旧库要么能读取新库产生的数据要么能检测出自己无法正确读取。格式次版本递增如 1.0.0 → 1.1.0表示新增了特性只要这些新特性未被使用例如未使用新数据类型向前兼容性就得到保留长期稳定Long-Term Stability格式主版本变更如 1.0.0 → 2.0.0意味着兼容性保证被打破这属于罕见的例外事件项目会以不损害生产应用为前提谨慎推进。仓库记录了 1.0.0 以来的全部格式次版本演进Post-1.0.0 Format Versions一节格式版本新增特性1.1256 位 Decimal 类型1.2MonthDayNano 间隔类型1.3Run-End Encoded 布局1.4变长二进制视图BinaryView / Utf8View、ListView / LargeListView、变长缓冲区Variadic Buffers截至当前仓库内容已有四个新次版本、零个新主版本。对照 docs/source/status.rst 可以看到这些新特性在不同语言中的落地进度例如 Binary View 目前仅 C、Go、C# 支持ListView 的支持面则更窄——这正是格式版本号之外、以功能矩阵形式呈现的软兼容层。因此当一个格式提案走完讨论、表决、实现、测试全流程后还应在 docs/source/format/Versioning.rst 的版本表中追加一条记录并同步 docs/source/status.rst 的功能支持矩阵。给格式变更贡献者的一张行动清单综合 Changing.rst 与上文各环节提交一项 Arrow 格式变更的完整路径为讨论向devarrow.apache.org发送主题为[DISCUSS][Format] ...的邮件说明变更动机、设计草案与影响面草稿实现在 C、Java、Go或 Rust arrow-rs中至少其一先行实现一个草稿版本用真实约束检验设计此步可与第 1 步并行集成测试借助 Archeryarchery integration参考 dev/archery/archery/cli.py在至少两个完整实现之间跑通新特性的 JSON 数据生成与生产者/消费者互测表决共识达成后发起[VOTE]线程并按 Apache 投票流程确认文档更新 docs/source/format/ 下的规范文档如 Columnar.rst、Layout.rst补充新版本文档版本号版本与状态在 docs/source/format/Versioning.rst 的次版本表中登记新特性并在 docs/source/status.rst 中标注各语言的实现进度。这套公开讨论 双实现互证 表决确认 版本登记的机制正是 Apache Arrow 在十多种语言、数十个独立代码库之间维持单一数据语义的根基任何格式变更都必须经得起至少两个独立实现的相互验证也因此在设计阶段就排除了绝大多数实现歧义。【免费下载链接】arrowApache Arrow is a multi-language toolbox for accelerated data interchange and in-memory processing项目地址: https://gitcode.com/gh_mirrors/arrow12/arrow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考