HDF5与Avro存储Uint16灰度图像的优劣对比及选型咨询

两种选型适配性对比 #

HDF5 #

HDF5完全适配你的使用场景，优势非常明显：

• 原生支持n维数组类型，Uint16、2D矩阵不需要额外做序列化转换就可以直接写入，匹配你的二进制数据存储需求，无额外格式封装开销
• 写入性能够用：开启预分配文件空间、单帧分块存储配置后，持续写入200MB/s吞吐量无压力，完全可以支撑50Hz的逐帧写入频率
• 多语言支持完善：C有官方维护的HDF5 C API，Julia生态下有成熟的HDF5.jl包，调用简单，社区资料充足
• 大文件支持友好：原生支持TB级大文件存储，单次创建文件时直接预分配1-2GB空间是标准功能，不会产生磁盘碎片化
• 仅有的注意点：默认开启的校验和功能会占用少量CPU性能，高频写入场景下手动关闭即可。

Avro #

Avro适配性明显低于HDF5，不推荐用于该场景：

• 本身是面向结构化数据的行优先序列化格式，存储2D Uint16数组需要先自定义schema做数据封装，会额外产生序列化/反序列化的CPU开销，高频写入场景下实际吞吐量比同配置的HDF5低15%~25%
• 多语言生态不完善：C++的avro-cpp库维护尚可，但Julia的Avro.jl包活跃度很低，数组相关操作的封装非常少，需要自己写额外的适配逻辑
• 无原生大文件预分配功能，写入过程中动态扩容会产生磁盘碎片化，对持续写入速度有一定影响。

其他可选格式推荐 #

如果HDF5不符合你的额外隐含需求，可以考虑以下两种方案：

• BigTIFF：专门面向图像场景的标准格式，Uint16灰度图原生支持，多帧追加写入性能和HDF5接近，C++可以用libtiff库，Julia可以用TiffImages.jl包操作，优势是生成的文件可以直接用绝大多数图像查看工具打开，不需要额外写解析逻辑，适合需要直接预览采集数据的场景。
• 自定义裸二进制格式：性能最优的方案，直接将每帧的Uint16二进制数据按顺序写入文件，额外用一个极小的头文件存储图像分辨率、总帧数、数据类型等元数据即可，写入开销几乎为0，完全可以满足200MB/s的写入需求，不需要依赖任何第三方库，C++和Julia的原生IO接口就可以直接读写，缺点是没有通用解析标准，需要自己配套写读写逻辑。

落地优化建议 #

如果确定使用HDF5，做以下配置可以最大化写入性能：

1. 文件创建时直接预分配1-2GB的存储空间，避免运行时动态扩容的开销
2. 关闭默认开启的校验和功能，降低CPU占用
3. 分块存储的块大小设置为单帧图像的大小，完全匹配逐帧写入的模式

内容的提问来源于stack exchange，提问作者Julie96