資料工程領域不斷發展，各種專為特定用例設計的專業工具層出不窮。DeepSeek 最近釋出的 smallpond 在開發者社群引起了廣泛討論，因為它旨在彌合本地資料處理和分散式計算需求之間的差距。
什麼是 Smallpond？
Smallpond 是一個基於 DuckDB 和 3FS 構建的輕量級資料處理框架。它專為訓練流程設計，而非通用資料處理。根據社群討論，該框架專注於向工作節點提供訓練資料批次，利用 Ray 實現並行化。它的核心優勢在於支援隨機讀取（這對於跨週期實現資料混洗至關重要）、支援 Arrow 以實現與 Pandas DataFrames 的零複製操作，以及高效的檢查點機制。
Smallpond 核心特點
- 由 DuckDB 提供支援的高效能資料處理
- 可擴充套件以處理 PB 級資料集
- 無需長時間執行服務的簡易操作
- 支援 Python 3.8 到 3.12 版本
- 與 Ray 整合實現並行化
- 專為機器學習訓練流程設計
GraySort 基準效能
- 已排序資料：110.5TiB
- 所需時間：30分鐘14秒
- 平均吞吐量：3.66TiB/分鐘
- 基礎設施：50個計算節點和25個儲存節點執行 3FS
與 3FS 的關聯
Smallpond 架構的關鍵元件是 3FS，這是一個早於 DeepSeek 本身的分散式檔案系統。社群成員指出，3FS 至少從2019年就已存在，在中文科技部落格中有所提及。這個檔案系統似乎是 smallpond 能夠處理 PB 級資料集的關鍵。然而，一些使用者指出，如果沒有 3FS，smallpond 的實用性可能會大大降低，因為網路檔案系統性能將成為瓶頸。
「我認為除非你的資料超過10TB或者你部署了3FS（這似乎很有挑戰性），否則相比單純使用duckdb沒有真正的優勢。」
3FS 的基礎設施需求是另一個限制因素。社群成員強調，美國主要雲服務提供商對 InfiniBand 的支援有限，而 InfiniBand 對 3FS 的效能似乎很重要。這可能會限制依賴公共雲基礎設施的公司採用 smallpond。
效能和基準測試
Smallpond 的效能宣告令人印象深刻，GraySort 基準測試顯示，使用50個計算節點和25個儲存節點的叢集，只需30多分鐘就能對110.5TiB的資料進行排序。這相當於平均吞吐量為3.66TiB/分鐘。有趣的是，社群對 smallpond 程式碼的分析發現，對於 GraySort 基準測試，它預設呼叫 Polars 來處理實際排序，而不是直接使用 DuckDB。
在資料生態系統中的定位
Smallpond 的出現反映了資料工程領域的一個更廣泛趨勢——為特定工作負載開發專門的查詢引擎。雖然像 DuckDB、Polars 和託管雲解決方案這樣的通用工具已經存在多年，但 smallpond 似乎針對的是需要分散式處理大型資料集用於機器學習的特定領域。
對於大多數資料集小於10TB的使用者，社群觀點認為 smallpond 相比現有工具（如單獨使用 DuckDB）的優勢可能有限。真正的優勢在於更大規模的場景，即必須進行分散式處理的情況。
隨著資料工程的不斷發展，像 smallpond 這樣的工具代表著向更專業、更有針對性的解決方案邁進的步伐，這些解決方案抽象了分散式資料處理的一些複雜性。正如一些社群成員所希望的那樣，這是否代表著後端技術更廣泛抽象化的開始，或者僅僅是另一個具有特定權衡的工具，還有待觀察。