北京
当数据工程师还在为Apache Parquet文件的读取性能发愁时，一个开源项目用基准测试给出了答案：在8个虚拟CPU的配置下，Hardwood读取器达到了每秒1650万行的吞吐量。这个由Gunnar Morling启动的项目，目标很明确——给传统的Apache Parquet Java实现提供一个更快、更轻量的替代方案。
传统方案的问题出在哪？一方面，它们往往带来沉重的依赖开销，光引入一个读取库就可能拖进来半棵树；另一方面，核心读取器依赖单线程处理，CPU资源利用率上不去。Hardwood的做法完全不同：多线程页面解码被分散到所有可用的CPU核心上，序列化页面处理的延迟被压低，同时实现了几乎零强制依赖。
“JVM上处理Parquet的性能瓶颈，很大程度上来自串行解码”，项目发起人Gunnar Morling在阐述设计理念时提到。Hardwood通过将Parquet页面解码分布到所有CPU核心上，减少串行解码导致的延迟。这种设计让库能够随着硬件规模线性扩展——单线程配置下性能受限于序列化解码，而多线程方案能更有效地饱和使用主机的I/O与CPU带宽。
Hardwood提供了两套面向不同需求的API。一套是结构化Row Reader，适合通用记录访问场景，开发者可以像使用标准JDBC结果集那样逐行读取字段。另一套是批量化Column Reader，面向高吞吐分析型工作负载，更适合大规模数据扫描。与传统按顺序处理数据的实现不同，这两套API在设计上充分考虑了现代CPU的多核特性。
零强制依赖策略是另一个亮点。为了避免供应链攻击风险和类路径冲突，Hardwood使用自Java 9起提供的最小日志抽象，不引入外部日志依赖。对于LZ4、GZip等压缩算法的支持，以及对S3等对象存储的适配，都通过可选依赖提供，用户按需引入即可。Andres Almiray和Bruno Borges等Java领域资深贡献者也加入了项目，社区已有约20名参与者。
性能优化不仅停留在解码层面。Hardwood在过滤扫描时实现了无分支、按批次评估的谓词评估方法，减少因分支预测失败带来的CPU开销。这一点在现代分析型数据处理场景中尤为关键——当扫描大量数据并进行条件过滤时，传统逐行判断的方式会让CPU不断预测错误，浪费计算周期。
项目还提供了一个命令行工具，内建交互式文本用户界面。数据工程师无需编写样板代码或引入重型数据处理框架，就能直接在终端里检查Parquet文件的schema与元数据。这个功能定位为开发诊断工具，用于验证文件完整性和结构。
从2026年初启动到1.0版本发布，Hardwood只花了五个月时间。目前库仅提供读取能力，写入支持已列入路线图。社区反馈总体正面，潜在用户普遍期待写入功能的加入。虽然项目在编码过程中使用了AI辅助，但设计决策和代码评审仍由人类主导，模块化设计和明确的能力规划让这个轻量替代方案具备了成为JVM生态基础工具的潜力。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
