go 中不能直接用 arrow.array 做计算，因其仅定义内存布局（如 arrow.int64array），filter、sum 等需依赖功能有限的 arrow/compute 包；该包不支持向量化谓词与自定义 udf，且多数函数仅接受 arrow.array 而非 record/table；真实场景中需手动切片提取数组再喂入 compute，易引发 panic 或 gc 压力。
Go 原生不支持 Arrow 格式，直接用 github.com/apache/arrow/go/v14 是可行路径，但必须绕过几个关键坑才能真正跑通列式操作。
为什么不能直接用 arrow.Array 做计算？
Arrow 的核心是内存布局（如 arrow.Int64Array），它不提供 Filter、Sum 这类方法 —— 这些得靠 arrow/compute 包。但该包在 Go 中功能有限：缺少向量化谓词、不支持自定义 UDF，且多数函数只接受 arrow.Array 而非 arrow.Record 或 arrow.Table。
- 常见错误：调用
compute.Sum传入*arrow.Int64Array却忽略其Data()是否已Retain()，导致 panic：runtime error: invalid memory address - 真实场景：读 Parquet 文件后得到
arrow.Table，想按条件过滤行 → 必须先用table.Column(0).Data().NewSlice(...)提取数组，再喂给compute.Filter - 性能影响：每次
compute操作都新建数组，不复用 buffer；若反复切片 + 计算，GC 压力明显上升
如何从 Parquet 读取并保持 Arrow 内存零拷贝？
用 parquet-go 会把数据转成 struct slice，彻底丢失 Arrow layout；必须用 github.com/xitongsys/parquet-go 的 Arrow 后端，或更稳妥的 github.com/apache/arrow/go/v14/parquet/pqarrow。
- 关键配置：创建
pqarrow.Reader时传入pqarrow.WithAllocator(arrow.DefaultAllocator)，否则内部 buffer 用的是临时 allocator，生命周期无法对齐 - 容易踩的坑：
reader.ReadTable()返回的arrow.Table默认使用memory.NewGoAllocator()，和 Arrow C++ 兼容性差；需显式用arrow.WithAllocator构造 table - 路径注意：Parquet schema 中的
optional int64对应 Go 的*arrow.Int64Builder，但实际读出的是arrow.Int64Array加null mask，不能直接用Value(i)，得先IsValid(i)
怎样安全地把 Arrow 数据导出为 Go 原生结构？
别用 array.Len() 配 array.Value(i) 循环 —— null 值会 panic。Arrow 的「列式」本质决定了必须区分有效位与值位。
- 正确做法：对
arrow.Int64Array，用arr.Data().Buffers()[0]（values）和arr.Data().Buffers()[1]（null bitmap）分别处理；bitmap 需按 bit index 解析，不是 byte index - 工具建议：用
arrow/array.NewInt64Data手动构造新 array 时，务必检查data.Buffers长度 —— 缺少 null buffer 表示全 non-null，但 buffer[1] 为 nil 时不能直接 deref - 兼容性陷阱：Go 的
int64和 Arrow 的INT64二进制一致，但 timestamp 列（arrow.TimestampType）单位可能是 us/ms/ns，导出前必须确认arr.DataType().(*arrow.TimestampType).Unit
Arrow 在 Go 里不是开箱即用的“列式数据库”，它是内存协议层；所有计算逻辑仍要自己拼装 compute 函数链，且 null 处理、buffer 生命周期、allocator 绑定这三点，漏一个就 crash 或内存泄漏。
