在處理大型數據集時，數據處理工具的性能至關重要。Polars 作為一個以速度和效率著稱的開源數據處理庫，它提供了由 cuDF 驅動的 GPU 加速后端，能夠顯著提升性能。

然而，要想充分發(fā)揮 Polars GPU 后端的優(yōu)勢，優(yōu)化數據加載過程并有效地管理工作流所需的內存至關重要。隨著 GPU 后端開發(fā)的持續(xù)進展，在使用 GPU Parquet 讀取器處理不斷增大的數據集時，可以使用一些其他技術來保持高性能?，F有的 Polars GPU Parquet 讀取器（包括至 24.10 版本）無法針對更大的數據集進行擴展。

本文探討了分塊 Parquet 讀取器與統一虛擬內存（UVM）相結合，如何能夠超越非分塊讀取器和基于 CPU 的方法。

標度因數和非分塊讀取器帶來的挑戰(zhàn)

隨著標度因數（SF）的增加，非分塊 GPU Polars 讀取器（24.10 版）常常會遇到困難。當標度因數超過 200 時，性能會顯著下降。在 Query 9 等特定場景下，非分塊 GPU 讀取器甚至在標度因數達到 50 之前就會出問題。這種限制源于將大型 Parquet 文件加載到 GPU 內存時的內存限制。非分塊 Parquet 讀取器圖表會缺失數據，這凸顯了在標度因數較高時遇到的內存溢出（OOM）錯誤。

圖 1. Query 13 執(zhí)行的可靠性，對比 24.10 版和 24.1 2版 Parquet 讀取器

通過分塊 Parquet 讀取提升 I/O 和峰值內存性能

為了突破這些內存限制，分塊 Parquet 讀取器就變得至關重要。通過將 Parquet 文件切分為較小數據塊進行讀取，可以減少內存占用，使 Polars GPU 能夠處理更大的數據集。對于任何給定的查詢，與非分塊讀取器相比，使用單次讀取限制為 16GB 的分塊 Parquet 讀取器能夠執(zhí)行更多的標度因數。對于 Query 9，必須使用 16GB 或 32GB 的分塊 Parquet 讀取方式才能執(zhí)行并實現更高的吞吐量。

圖 2. 針對 Query 9，通過改變標度因數不同分塊大小（pass_read_limit）進行吞吐量對比

借助統一虛擬內存讀取更大的數據集

雖然分塊讀取優(yōu)化了內存管理，但統一虛擬內存將性能提升到了新的高度。統一虛擬內存使 GPU 能夠直接訪問系統內存，進一步緩解了內存限制并提高了數據傳輸效率。

相比之下，未配備統一虛擬內存的分塊讀取器在標度因數達到 100 之前就會觸發(fā)內存溢出錯誤。分塊讀取器與統一虛擬內存相結合，可以在更高的標度因數下成功地執(zhí)行查詢，不過吞吐量會受到影響。

圖 3 顯示了這一顯著優(yōu)勢。與非分塊 Parquet 讀取器相比，配備統一虛擬內存的分塊 Parquet 讀取器能夠成功地執(zhí)行標度因數更高的查詢。

圖 3. 配備統一虛擬內存的分塊讀取器、CPU 以及未配備統一虛擬內存時的 Query 13 吞吐量（數值越高性能表現越好）

穩(wěn)定性和吞吐量

在選擇最佳的pass_read_limit時，需要重點考慮穩(wěn)定性和吞吐量之間的平衡。圖 1-圖 3 表明，16GB 或 32GB 的pass_read_limit實現了兩者最優(yōu)的平衡。

32GBpass_read_limit：除了 Query 9 和 Query 19 因內存溢出異常遭遇失敗外，所有其他查詢均成功完成。

16GBpass_read_limit：所有查詢均成功完成。

分塊 GPU 與 CPU 的比較

觀察結果顯示，每次查詢的吞吐量通常高于 CPU Polars，這使得許多在未分塊時無法完成的查詢得以完成。建議將pass_read_limit參數設置為 16GB 或 32GB，該閾值設定具有合理性。與非分塊 Parquet 讀取器相比，16GB 或 32GB 的pass_read_limit能夠在更高的標度因數下成功地執(zhí)行查詢。

結論

對于 Polars GPU 而言，配備統一虛擬內存的分塊 Parquet 讀取器通常優(yōu)于 Polars CPU 和非分塊Parquet 讀取器，尤其是在處理大規(guī)模數據集和高標度因數場景時。通過優(yōu)化數據加載過程，可以充分發(fā)揮 Polars GPU 的潛力，顯著提升性能。作為最新的cudf-polars（24.12 版及更高版本）的一部分，分塊 Parquet 讀取器和統一虛擬內存是讀取 Parquet 文件的默認方式。這使得所有查詢和標度因數都實現了像上述的性能提升。