在處理大數據分析時，Apache Parquet 是一種極其重要的列式儲存格式（Columnar Storage Format）。它的核心價值在於將數據按列儲存，讓分析系統在查詢時只需讀取必要的列，大幅減少 I/O 開銷。然而，對於使用 Java 或 Kotlin 等 JVM 語言的工程師來說，原生的 Apache Parquet Java 實作雖然功能完整，但在實務上常面臨兩個痛點：一是依賴庫過於龐大，容易導致類路徑衝突（Classpath Conflict）；二是核心讀取機制過於依賴單執行緒，無法充分發揮現代多核心 CPU 的效能。
為了改善這些問題，開源社群推出了 Hardwood。這是一個專為 JVM 環境設計的輕量化 Parquet 讀取庫，旨在提供更高吞吐量且低依賴的替代方案。
突破單執行緒的效能限制
傳統的 Parquet 讀取方式通常是循序處理數據頁（Page），這意味著即使你的伺服器擁有 32 個核心，讀取單個文件的過程可能依然只在一個核心上運作，導致 CPU 利用率低且延遲高。
Hardwood 引入了多執行緒頁面解碼（Multi-threaded Page Decoding）機制。它將 Parquet 文件的解碼工作分散到所有可用的 CPU 核心上，讓數據處理能與 I/O 並行。在 8 個 vCPU 的測試環境中，Hardwood 在處理扁平化數據集時能達到每秒 1,650 萬行的吞吐量。這種設計讓系統能真正飽和主機的 CPU 頻寬，大幅縮短大規模數據掃描的時間。
極簡依賴與供應鏈安全
在現代企業級開發中，依賴庫過多會增加供應鏈攻擊（Supply Chain Attack）的風險，且容易在整合不同框架時發生版本衝突。Hardwood 採取了零強制依賴（Zero Mandatory Dependencies）的設計哲學。
為了達成這一點，Hardwood 直接利用 Java 9 之後內建的輕量級日誌抽象，完全捨棄了外部日誌框架。至於 LZ4 或 GZip 等壓縮算法，以及 S3 等物件儲存服務的支援，則被設計為可選依賴（Optional Dependencies）。開發者只需根據實際需求引入對應的模組，確保了最終產出物的精簡與安全。
針對分析場景的 API 設計
Hardwood 提供了兩種不同的 API 模式，以適應不同的工程實務需求。第一種是結構化行讀取器（Row Reader API），適合一般的紀錄存取，讓工程師能像操作傳統物件一樣獲取數據。第二種是批次列讀取器（Column Reader API），專為高吞吐量的分析工作負載設計，適合需要對單一列進行大量運算的場景。
此外，Hardwood 在過濾掃描時採用了無分支（Branchless）的批次評估技術。在電腦底層，CPU 會嘗試預測程式碼的執行路徑（Branch Prediction），如果預測錯誤會導致流水線清空而產生效能損耗。透過無分支設計，Hardwood 減少了 CPU 分支預測失敗的機率，進一步壓榨出硬體效能。
開發工具與未來展望
除了程式庫本身，Hardwood 還提供了一個帶有文本使用者介面（TUI）的命令列工具（CLI）。這對數據工程師非常實用，因為不需要編寫冗長的樣板程式碼，就能快速檢查 Parquet 文件的 Schema（結構定義）與元數據（Metadata），將其作為開發生命週期中的診斷工具。
目前 Hardwood 1.0 版本專注於讀取（Read）功能的優化，而寫入（Write）支援已列入開發路線圖。值得注意的是，該專案在開發過程中結合了 AI 輔助編碼，但核心設計與代碼審查仍由經驗豐富的 Java 開發者把關，確保了穩定性。
總結來說，Hardwood 為 JVM 生態系提供了一個高性能、低耦合的數據處理選擇，對於追求資源利用率最大化且對依賴管理有嚴格要求的分析系統而言，是一個值得關注的工具。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。