CPU 使用者定義函式可能中斷原本已加速 GPU 的 Apache Spark 查詢。cuDF 外掛程式通常無法轉譯任意 UDF 程式碼：它會將欄式資料轉成列，在 CPU 上執行函式，再把結果轉回來。NVIDIA 10 月 13 日指南說明可用於將 UDF 改寫為 Spark SQL、欄式 RapidsUDF、或以 RapidsUDF 搭配 CUDA 的技能。資料工程師真正要問的是：一次改寫能否產生相同答案、在相關計畫中維持 GPU 執行，並改善實際工作。

這是一份以文件為依據的指南。BIG CHANGE 並未執行這些技能、測試 UDF 或衡量 Spark 工作負載。

重大變化

  • 有何改變： NVIDIA 發布了一套分階段的代理工作流程，用於產生 UDF 測試、轉換函式、評估轉換結果、對 CPU 與 GPU 版本進行基準測試，並可選擇最佳化 cuDF 實作。
  • 適用對象： 使用具備 GPU 能力的 RAPIDS/cuDF Spark 流程，且有特定 CPU UDF 中斷流程的工程師。
  • 應驗證事項： 在具代表性的邊界案例中輸出一致、執行計畫不含目標 CPU 回退，並在預定硬體上測得可重複的工作層級效能。

開始之前

選擇一個你有權交給程式代理的 UDF。除非該代理及其環境獲准處理，否則不要在提示中提供憑證、敏感輸入列或專有資料集。提供 UDF 原始碼、註冊與呼叫位置、相關結構描述、預期的空值及錯誤行為，以及小型且允許使用的測試資料。記錄現有 Spark 工作的計畫與時間，作為比較基準。

這份 技能 README 是此工作流程的版本化起點。它要求使用 Maven 與 JDK 建置 UDF，並具備相容的 Spark/RAPIDS/cuDF/CUDA 技術堆疊及 GPU。安裝前請對照 目前的外掛相容性指南，確認與自己的 Spark 發行版、Scala 版本、驅動程式、CUDA 組建及 GPU 相容。雲端 GPU 可替代本機硬體，但供應商會按執行個體時間與儲存空間收費；代理或模型的使用也可能產生費用。README 提供專案骨架與範例，但無法證明你的叢集相容或效能如何。

改寫並檢查一個函式

  1. 先固定原始行為。請代理在選定的 UDF 上使用 udf-gen-test，並自行檢查產生的測試。依合約加入真實案例：適用時涵蓋 null、空字串或集合、格式錯誤的輸入、邊界值、數值精度、排序與錯誤行為。用這些案例執行原始 UDF。預期結果是基準測試套件全部通過，而不是立刻改寫。NVIDIA 的溫度函式範例明確規定 null 輸入回傳 null；只有在實際資料型別與 Spark 設定下也保留此行為時，SQL 改寫才適用。
  2. 選擇最簡單且受支援的目標。若邏輯能用 Spark SQL 或 DataFrame 運算式表達，請求使用 udf-convert-to-sql。這會讓運算式交由 Spark 規劃器處理，外掛程式或許能將受支援的運算替換成 GPU 對應項目。若 SQL 無法清楚表達所需邏輯，請求使用 udf-convert-to-cudf：其 RapidsUDF.evaluateColumnar 接收 GPU 欄向量並組合 cuDF 運算。只有在需要透過 JNI 撰寫自訂核心，且額外實作與維護負擔合理時，才考慮 udf-convert-to-cuda。這些是待評估的選項，並不保證每個運算都會在 GPU 執行。
  3. 接受前先審查轉換結果。比較改寫後的實作與原始版本，並在相同且已核准的測試案例上執行兩者。儲存庫也列出 udf-judge-conversion，可另行檢查測試缺口及轉換錯誤。檢查型別、null 傳遞、四捨五入、例外、排序與資源處理。若改寫使用 cuDF，請檢查暫存欄與純量的生命週期；教學中的 Scala 範例 使用作用域管理資源並回傳結果欄。產生的測試套件通過是有用證據，但仍須由人判斷它是否涵蓋函式合約。
  4. 檢查實際執行計畫。啟用 cuDF 外掛程式執行變更後的查詢，並檢查目標運算子及相鄰轉換的計畫與 RAPIDS 診斷。NVIDIA 的 外掛概覽 指出，不受支援的 SQL 運算會回退至 Spark CPU 執行。若計畫仍顯示 UDF 或周邊運算子在 CPU 執行，請找出不受支援的運算式或型別，並重新考慮目標選擇。保留變更前後計畫及測試結果。單看名為 RapidsUDF 的類別，不能證明整個工作都留在 GPU 上。
  5. 對預計執行的工作進行基準測試。使用 udf-benchmark，在相同輸入、叢集大小、設定及量測方法下比較原始與改寫版本。記錄工作經過時間、輸入規模、輸出等價性以及 GPU/CPU 資源使用。重複執行以辨識啟動、快取或資源競爭的影響。理想結果是可重現的比較，即使改寫較慢也一樣。若正確的 cuDF 版本速度較慢，儲存庫提供 udf-optimize-cudf 供剖析與修訂；每次變更後都要重新執行正確性與計畫檢查。

成功結果應具備的條件

若所選 UDF 在核准案例中的輸出符合文件所述行為、實際執行計畫不再包含目標 CPU 回退，而且具代表性的基準測試顯示端到端結果值得採用，候選改寫即可進入一般程式碼審查。若任何檢查失敗，保留原始實作，將改寫縮小到出問題的運算式，再重新執行該階段。語意不符比基準測試較快更重要；計畫未改變則表示尚未證實預期的 GPU 路徑。

NVIDIA 報告一個正式環境範例：啟用 cuDF 的 UDF 將一項運算子的時間從 274.55 降至 12.78 小時，工作負載為 6,000 億列。這些是供應商針對該工作負載回報的運算子時間，不是其他 UDF 的預測，也不是端到端工作結果。更廣泛的 22 倍說法應依此脈絡解讀。GPU 容量、資料搬移、不支援的運算、程式碼審查與雲端費用都可能改變你所用流程的結果。

來源與延伸閱讀