在處理大型數據集時，數據處理工具的性能變得至關重要。 Polars 是一個以速度和效率聞名的開源數據操作庫，提供由 cuDF 驅動的 GPU 加速后端，可以顯著提高性能。
“但是，為了充分利用 Polars GPU 后端 的強大功能，必須優化數據加載過程并有效管理工作流程所需的內存。隨著 GPU 后端開發的不斷推進，在使用 GPU Parquet 閱讀器時，隨著數據集大小的增加，我們還可以使用一些其他技術來保持高性能。現有的 Polars GPU Parquet 讀取器 (到版本 24.10) 無法針對更高的數據集大小進行擴展。”
本文將探討分塊 Parquet Reader 與 Unified Virtual Memory (UVM) 相結合后，如何在性能上優于非分塊閱讀器和基于 CPU 的方法。
規模因素和非分塊讀取器帶來的挑戰
隨著規模系數 (SF) 的增加，非分塊 GPU Polars Reader (24.10) 往往難以實現。超過 SF200 后，性能會顯著下降。在某些情況下，例如 Query 9，非分塊 GPU 讀取器會出現故障，甚至在達到 SF50 之前。這種限制是由于在 GPU 的內存中加載大型 Parquet 文件時存在內存限制而產生的。非分塊 Parquet Reader 圖中的缺失數據突出顯示了在更高比例因子下遇到的 out-of-memory (OOM) 錯誤。
通過分塊 Parquet 讀取改善 IO 和峰值內存
為了克服這些內存限制，分塊的 Parquet Reader 變得至關重要。通過以較小的數據塊讀取 Parquet 文件，顯存占用減少，使 Polars GPU 能夠處理更大的數據集。與非分塊閱讀器相比，使用具有 16 GB 通過讀取限制的分塊 Parquet Reader 可為任何給定查詢執行更多的比例系數。對于 Query 9，必須使用 16 GB 或 32 GB 的分塊 Parquet 讀取數據，才能執行并獲得更好的吞吐量。
pass_read_limit) 進行吞吐量比較 使用 UVM 讀取更大的數據集
分塊讀取可改善內存管理，而 UVM 的集成可將性能提升至更高水平。UVM 使 GPU 能夠直接訪問系統內存，從而進一步緩解內存限制并提高數據傳輸效率。
為了進行比較，非 UVM 分塊在達到 SF100 之前會遇到 OOM 錯誤。分塊加 UVM 支持在更大規模的因素上成功執行查詢，但吞吐量會受到影響。
圖 3 顯示了明顯的優勢。與非分塊 Parquet Reader 相比，在啟用 UVM 的分塊 Parquet Reader 中成功執行的比例系數更多。
穩定性和吞吐量
選擇最佳 pass_read_limit 時，務必要考慮穩定性和吞吐量之間的平衡。圖 1-3 表明，16 GB 或 32 GB pass_read_limit 是穩定性和吞吐量的最佳組合。
- 32 GB
pass_read_limit：除 Query 9 和 Query 19 外，所有查詢均已成功，但因 OOM 異常而失敗 - 16 GB
pass_read_limit：所有查詢均已成功
GPU 分塊與 CPU 對比
當觀察到的每個查詢的吞吐量通常仍高于 CPU Polars 時，這允許許多查詢在不進行分塊的情況下無法完成。16 GB 或可能 32 GB 的 pass_read_limit 似乎是合理的。與非分塊 Parquet 相比，16 GB 或 32 GB pass_read_limit 可在更大規模的因子下成功執行。
總結
對于 Polars GPU 而言，采用 UVM 的分塊 Parquet Reader 通常優于 Polars CPU 和非分塊 Parquet Reader，尤其是在處理大型數據集和大規模因子時。通過優化數據加載過程，您可以充分發揮 Polars GPU 的潛力，并實現顯著的性能提升。作為最新 cudf-polars (24.12 及更高版本) 的一部分，分塊的 Parquet Reader 和 UVM 是讀取 Parquet 文件的默認方法。這使得上述所有查詢和規模因素都得到了改進。
要開始使用，請安裝 cuDF Polars。
