十億行挑戰賽 (One Billion Row Challenge) 是一個有趣的基準測試，旨在展示基本的數據處理操作。它最初是作為純 Java 競賽發起的，現已聚集了其他語言（包括 Python、Rust、Go、Swift 等）的開發者社區。對于許多有興趣探索文本文件閱讀細節、基于哈希的算法和 CPU 優化的軟件工程師來說，這項挑戰賽非常有用。截至 2024 年年中，One Billion Row Challenge GitHub 存儲庫已經吸引了超過 1.8K 個分叉，獲得了超過 6K 顆星，并啟發了數十篇博客文章和視頻。
本文將展示如何使用 RAPIDS cuDF pandas 加速器模式完成處理十億行數據的挑戰。具體而言，我們將展示 cuDF pandas 加速器版本 24.08 中的兩項新功能 —— 大字符串支持和帶預取的托管內存 —— 如何借助 GPU 加速的數據處理工作流程提高大數據的性能。
使用 RAPIDS cuDF pandas 加速器模式進行數據處理
pandas 是一個基于 Python 構建的開源軟件庫，專門用于數據處理和分析。這是一個靈活的數據處理工具，支持完成一億行挑戰賽所需的操作，包括解析文本文件、按組聚合數值數據以及對表格進行排序。
RAPIDS cuDF 是一個 GPU DataFrame 庫，可提供類似于 pandas 的 API，用于加載、過濾和操作數據。RAPIDS cuDF pandas 加速器模式通過統一的 CPU/GPU 用戶體驗，為 pandas 工作流帶來加速計算，且無需更改代碼。如需了解更多信息，請參閱 RAPIDS cuDF 將 pandas 的速度提升近 150 倍，無需更改代碼。
以下 pandas 腳本足以完成一億行挑戰：
import pandas as pddf = pd.read_csv( “measurements.txt”, sep=';', header=None, names=["station", "measure"])df = df.groupby("station").agg(["min", "max", "mean"])df = df.sort_values("station") |
在 cuDF pandas 加速器模式下運行此腳本需要在 Python 或 Jupyter Notebooks 中導入 pandas 之前添加單行命令，該命令為 %load_ext cudf.pandas。
%load_ext cudf.pandasimport pandas as pd |
詳細了解 RAPIDS cuDF pandas 加速器模式，包括在 Python 中使用此模式的不同方式，例如使用 Python 模塊標志，或通過導入顯式啟用。
RAPIDS cuDF pandas 加速器模式下的新大型數據處理功能 24.08
24.08 版本的 RAPIDS cuDF pandas 加速器模式包括兩個關鍵功能，可實現更高效的數據處理：大字符串支持和帶預取的托管內存池。這些功能共同支持大型 DataFrame 處理 – 多達 2.1億行的數據，即使在總 GPU 內存為 2-3 倍的情況下也能保持出色的性能。請注意，適用于 Linux 的 Windows 子系統 (WSL2) 對 GPU 超額認購的支持有限，本文中介紹的結果收集于 Ubuntu 22.04。
大字符串支持
大字符串支持使 RAPIDS cuDF 能夠在 32 位和 64 位索引之間動態切換。與 PyArrow 中存在字符串和大字符串類型不同，cuDF 中的字符串只有當列數據超過 2.1億個字符時才會切換到 64 位索引。這使得 cuDF 能夠保持較低的內存占用，并提高對小于 2.1億個字符的列的處理速度，同時仍然支持對大字符串列進行高效處理。
以前，在版本 24.06 中，當 GPU 上的字符串列超過 2.1億個字符時，會出現字符串溢出，而由此產生的溢出錯誤會導致數據復制回主機并回退至 pandas 處理。現在，在版本 24.08 中，DataFrames 可能包含大大小小的字符串列，并且每列都會正確處理 cuDF 中的字符串列類型。
帶預提取的托管內存池
具有預取功能的受管理內存池使 cuDF 能夠同時使用 GPU 和主機內存來存儲數據并避免內存不足錯誤。受管理內存（也稱為 CUDA 統一虛擬內存）可維護由 GPU 和主機內存支持的單個地址空間。當 GPU 內核啟動時，任何數據如果不可被 GPU 訪問，將從主機內存分頁（遷移）到 GPU 內存。使用具有受管理內存的內存池可減少每次分配的開銷，并減少總體執行時間。預取對于使用受管理內存觀察良好性能也很重要，因為它有助于確保數據可用于 GPU 內核，而無需在計算時對數據進行分頁，這可能“為時已晚”。
以前，在版本 24.06 中，較大的數據集更有可能耗盡總 GPU 內存，而由此產生的內存不足錯誤還將導致數據復制回主機并返回 cuDF pandas 處理。現在，在版本 24.08 中，cuDF pandas 加速器模式使用啟用預取的托管內存池。請注意，大數據的最佳性能可能取決于數據和工作流程，我們歡迎您的反饋。
使用 NVIDIA GPU 運行一億行挑戰賽
您可以在高顯存和低顯存的 GPU 上運行挑戰，這顯示了 RAPDIS cuDF 24.08 中大數據功能對性能的影響。在行數為 10 億的情況下，挑戰始于一個 13.1 GB 的文本文件。在 cuDF 中，這將轉化為 16 GB 的字符串數據和 8 GB 的 float64 數據。read_csv 操作的峰值顯存占用率約為 76 GB，groupby 聚合操作的峰值顯存占用率約為 56 GB。
請注意，輸入文件是根據 One Billion Row Challenge GitHub 存儲庫生成的，存儲在本地 NVMe SSD 上，并在基準測試期間由操作系統緩存。Wall 時間是在 Python 中執行完成 subprocess.run 命令的時間，包括所有初始化和加載步驟。
NVIDIA A100 Tensore Core GPU
在使用 RAPIDS cuDF pandas 加速器模式和具有足夠內存的 GPU 運行挑戰時，大字符串支持對于保持出色性能至關重要。第一個硬件集使用 NVIDIA A100 Tensor Core 80 GB PCIe GPU、 Arm Neoverse-N1 CPU（RAM 為 500 GiB）和 Samsung MZ1L23T8HBLA SSD。對于 200 million 行的行數，cuDF 顯示的運行時間約為 6 秒，而 pandas 僅 CPU 的運行時間約為 50 秒。但是，對于 300 million 行，cuDF 24.06 中的字符串溢出會導致 pandas 回退，并將運行時間增加到約 240 秒。
借助 cuDF 24.08 中的大字符串支持，我們觀察到運行時間為 17 秒，達到十億行，遠快于 pandas 運行時間（260 秒）和 cuDF 24.06 運行時間（800 秒）。如圖 1 中的綠色所示。請注意，由于 GPU 顯存不足，正常回退到 CPU 會導致 cuDF 24.06 上的運行時間更長。
NVIDIA Tesla T4 GPU
我們還可以評估 2018 年在 Colab 和 Kaggle 等筆記本電腦平臺上廣泛使用的舊代 GPU 的性能。在這種情況下，帶預取的托管內存池對于良好的性能至關重要。第二個硬件集使用 NVIDIA Tesla T4 14 GB PCIe GPU、具有 376 GiB RAM 的 Intel Xeon Gold 6130 CPU 和 Dell Express Flash PM1725a SSD。對于 200 million 行的行數，RAPIDS cuDF pandas 加速器模式顯示的運行時間約為 10 秒，而 pandas 運行時間約為 130 秒。當我們擴展到 1 billion 行時，T4 GPU 的超額認購率約為 5 倍，運行時間仍為 200 秒，而 pandas 的運行時間為 660 秒（圖 2）。
總體而言，大字符串支持和帶管理內存池與 RAPIDS cuDF pandas 加速器模式 24.08 中的預取相結合，消除了在版本 24.06 中影響性能的數據大小限制。在 24.08 中，NVIDIA A100 GPU 的內存容量更大，導致運行速度更快，主機到 GPU 的數據移動也更少。您可以根據成本效率和性能來決定適合您工作流程的 GPU。現在，使用 cuDF 擴展數據大小的障礙更少，運行時間更可預測。
優化 libcudf 中的挑戰
如果您要構建 GPU 加速的數據處理應用程序，并且需要更低的開銷和更快的運行時，我們建議使用 RAPIDS libcudf（cuDF 的 CUDA C++ 計算核心）。libcudf 可加速數據庫和 DataFrame 操作，從數據攝取和解析到連接、聚合等。
我們發布了一個名為 billion_rows 的新 C++ 示例模塊。這些示例展示了使用 libcudf 進行單線程數據分塊和多線程數據流水線處理。brc 示例展示了對 13 GB “One Billion Row Challenge” 輸入文件的簡單單批處理。brc_chunks 示例展示了一種分塊模式，該模式讀取來自輸入文件的字節范圍，計算部分聚合，然后合并最終結果。brc_pipeline 示例展示了一種流水線模式，該模式使用多個主機線程和設備 CUDA 流完成分塊工作，同時使復制帶寬和計算能力飽和。
通過比較 NVIDIA A100 GPU 上的這些方法，我們發現 brc_pipeline 實現了最快的運行時間，使用 256 個塊和四個線程，運行時間約為 5.2 秒（圖 3）。在 A100 GPU 上的 80 GB GPU 內存中，這三種方法都可以以一億行的速度完成挑戰。分塊和流水線可提供更快的運行時間，并大幅降低峰值內存占用。對于一億行，brc 使用 55 GB 的峰值內存，而 brc_chunks 和 brc_pipeline 使用不到 1 GB 的峰值內存。libcudf billion_rows 示例模塊中的技術展示了如何在高效飽和 GPU 資源和 PCIe 帶寬的同時完成大型工作流程。
轉移到 NVIDIA T4 GPU 后，我們發現 brc_pipeline 方法也實現了最快的運行時間，使用 256 個塊和 4 個線程，運行時間約為 5.7 秒（圖 4）。對于優化的 brc_pipeline 案例，由于通過 PCIe 從主機到 GPU 的數據傳輸的限制，T4 和 A100 GPU 的結果看起來都很相似。T4 具有 16 GB 的內存容量，因此 brc 示例在執行 2000 萬行后顯存不足，無法完成挑戰。即使在 T4 等內存容量較低的 GPU 中，也可以有效地完成挑戰。
開始使用
在 RAPIDS cuDF pandas 加速器模式下，處理大型數據集比以往更輕松。借助大字符串支持，您的字符串處理工作流可以擴展到超過先前的 2.1億個字符限制。借助新的托管內存池，您的數據處理內存占用可以超出 GPU 內存限制。要開始使用 cuDF pandas 加速器模式，請查看 RAPIDS cuDF 在 Google Colab 上即時將 pandas 加速 50 倍。
RAPIDS cuDF pandas 加速器模式使用 RAPIDS libcudf (用于 GPU 數據處理的 CUDA C++ 庫) 構建。要開始使用 RAPIDS libcudf，請嘗試構建和運行一些 C++ 示例。RAPIDS Docker 容器也可用于發行版和夜間構建，以便更輕松地進行測試和部署。
?
