這是描述預測客戶流失的端到端藍圖的系列文章的第三部分。在前幾期文章中，我們已經(jīng)討論了機器學習系統(tǒng)的一些挑戰(zhàn)，這些挑戰(zhàn)直到您投入生產(chǎn)時才會出現(xiàn)：在 第一期付款 中，我們介紹了我們的用例，并描述了一個加速的數(shù)據(jù)聯(lián)合管道；在 第二期 中，我們展示了高級分析如何適應機器學習生命周期的其余部分。

在第三期文章中，我們將介紹應用程序的分析和聯(lián)合組件，并解釋如何充分利用 Apache Spark 和 RAPIDS Apache 加速器 Spark 的一些最佳實踐。

架構（ Architecture ）評審

圖 1 ：我們的藍圖架構的高級概述。

回想一下，我們的 blueprint 應用程序（圖 1 ）包括一個聯(lián)邦工作負載和一對分析工作負載。

聯(lián)合工作負載 生成了一個關于每個客戶的非規(guī)范化寬數(shù)據(jù)表，這些數(shù)據(jù)來自于五個與客戶賬戶不同方面相關的規(guī)范化觀察表的數(shù)據(jù)匯總。

第一次分析工作量 為每個特性生成一個機器可讀的值分布和域的摘要報告。

第二次分析工作量 生成一系列關于客戶結果的說明性業(yè)務報告 我們的第一期 包含有關聯(lián)合工作負載的其他詳細信息， 我們的第二期 包含有關分析工作負載的其他詳細信息。

我們將這三個工作負載作為一個具有多個階段的 Spark 應用程序來實現(xiàn)：

應用程序?qū)?HDFS 中多個表（存儲為拼花文件）的原始數(shù)據(jù)聯(lián)合到一個寬表中。

因為寬表比原始數(shù)據(jù)小得多，所以應用程序然后通過合并到較少的分區(qū)并將數(shù)值轉(zhuǎn)換為適合 ML 模型訓練的類型來重新格式化寬輸出。此階段的輸出是 ML 模型訓練的源數(shù)據(jù)。

然后，應用程序針對合并和轉(zhuǎn)換的寬表運行分析工作負載，首先生成機器可讀的摘要報告，然后生成匯總和數(shù)據(jù)立方體報告的集合。

性能注意事項

并行執(zhí)行

50 多年來，提高并行執(zhí)行的適用性一直是計算機系統(tǒng)高性能最重要的考慮因素之一 （ 我們有點武斷地選擇在 1967 年確定 托馬蘇洛算法 的開發(fā)，它為無處不在的超標量處理奠定了基礎，因為在這一點上，對并行性的關注變得實用而不僅僅是理論上的。）在分析員、數(shù)據(jù)科學家、數(shù)據(jù)和 ML 工程師以及應用程序開發(fā)人員的日常工作中，對并行性的關注通常表現(xiàn)為以下幾種方式之一；我們現(xiàn)在來看看。

向外擴展時，在集群上執(zhí)行工作

如果您使用的是橫向擴展框架，請盡可能在集群上而不是在單個節(jié)點上執(zhí)行工作。在 Spark 的情況下，這意味著在執(zhí)行器上執(zhí)行 Spark 作業(yè)中的代碼，而不是在驅(qū)動程序上執(zhí)行串行代碼。 一般來說，在驅(qū)動程序中使用 Spark 的 API 而不是宿主語言代碼將使您獲得大部分的成功，但是您需要確保所使用的 Spark API 實際上是在執(zhí)行器上并行執(zhí)行的。

操作集合，而不是元素；在列上，而不是行上

開發(fā)并行性和提高性能的一般最佳實踐是使用一次對集合執(zhí)行操作的專用庫，而不是一次對元素執(zhí)行操作。在 Spark 的情況下，這意味著使用數(shù)據(jù)幀和列操作，而不是迭代 rdd 分區(qū)中的記錄；在 Python 數(shù)據(jù)生態(tài)系統(tǒng)和 RAPIDS 。 ai 中，這意味著使用在單個庫調(diào)用中對整個數(shù)組和矩陣進行操作的 矢量化操作 ，而不是在 Python 中使用顯式循環(huán)。最關鍵的是，這兩種方法也適用于 GPU 加速。

分攤 I / O 和數(shù)據(jù)加載的成本

I / O 和數(shù)據(jù)加載成本很高，因此在盡可能多的并行操作中分攤它們的成本是有意義的。 我們可以通過直接降低數(shù)據(jù)傳輸成本和在數(shù)據(jù)加載后盡可能多地處理數(shù)據(jù)來提高性能。在 Spark 中，這意味著使用列格式，在從穩(wěn)定存儲導入時只過濾一次關系，并在 I / O 或無序操作之間執(zhí)行盡可能多的工作。

通過抽象提高性能

一般來說，提高分析師和開發(fā)人員在應用程序、查詢和報表中使用的抽象級別，可以讓運行時和框架找到開發(fā)人員沒有（或無法）預料到的并行執(zhí)行機會。

使用 Spark 的數(shù)據(jù)幀

例如，在 Spark 中使用數(shù)據(jù)幀并主要針對高級數(shù)據(jù)幀 API 進行開發(fā)有許多好處，包括執(zhí)行速度更快、查詢的語義保持優(yōu)化、對存儲和 I / O 的需求減少，以及相對于使用基于 RDD 的代碼顯著改善了內(nèi)存占用。但除了這些好處之外，還有一個更深層次的優(yōu)勢：因為數(shù)據(jù)幀接口是高級的，而且 Spark 允許插件改變查詢優(yōu)化器的行為，所以 RAPIDS Apache 加速器 Spark 有可能用在 GPU 上運行的等效但實際上更快的操作替換某些數(shù)據(jù)幀操作。

透明加速 Spark 查詢

用插件替換 Spark 的查詢規(guī)劃器的一些功能是抽象能力的一個特別引人注目的例子：在能夠在 GPU 上運行 Spark 查詢之前幾年編寫的應用程序仍然可以通過使用 Spark 3 。 1 和 RAPIDS 加速器來利用 GPU 加速。

保持清晰的抽象

盡管使用新的運行時加速未修改的應用程序的潛力是針對高級抽象進行開發(fā)的一個主要優(yōu)勢，但實際上，對于開發(fā)團隊來說，維護清晰的抽象很少比按時交付工作項目更重要。由于多種原因，抽象背后的細節(jié)常常會泄漏到產(chǎn)品代碼中；雖然這可能會引入技術債務并產(chǎn)生無數(shù)工程后果，但它也會限制高級運行時的適用性，以優(yōu)化干凈地使用抽象的程序。

考慮適合 GPU 加速的操作

為了從 Spark 中獲得最大的收益，在圍繞 Spark 的數(shù)據(jù)幀抽象的應用程序中償還技術債務（例如，通過將部分查詢實現(xiàn)為 RDD 操作）是有意義的。 不過，為了充分利用先進的基礎設施，在不破壞抽象的情況下考慮執(zhí)行環(huán)境的細節(jié)通常是有意義的。 為了從 NVIDIA GPU 和 RAPIDS Apache 加速器 Spark 獲得盡可能好的性能，首先要確保您的代碼不會圍繞抽象工作，然后考慮或多或少適合 GPU 執(zhí)行的類型和操作，這樣您就可以確保盡可能多的應用程序在 GPU 上運行。下面我們將看到一些這樣的例子。

類型和操作

并不是每一個操作都能被 GPU 加速。當有疑問時，運行作業(yè)時將 spark.rapids.sql.explain 設置為 NOT_ON_GPU 并檢查記錄到標準輸出的解釋總是有意義的。在本節(jié)中，我們將指出一些常見的陷阱，包括需要配置支持的十進制算法和操作。

小心十進制算術

十進制計算機算法支持高達給定精度限制的精確運算，可以避免和檢測溢出，并像人類在執(zhí)行鉛筆和紙張計算時那樣舍入數(shù)字。盡管十進制算法是許多數(shù)據(jù)處理系統(tǒng)（尤其是金融數(shù)據(jù)）的重要組成部分，但它對分析系統(tǒng)提出了特殊的挑戰(zhàn)。為了避免溢出，十進制運算的結果必須擴大到包括所有可能的結果；在結果比系統(tǒng)特定限制更寬的情況下，系統(tǒng)必須檢測溢出。在 cpu 上使用 Spark 的情況下，這涉及將操作委托給 Java 標準庫中的 BigDecimal 類 ，并且精度限制為 38 位十進制數(shù)字或 128 位。 Apache 的 RAPIDS 加速器 Spark 目前可以加速計算多達 18 位或 64 位的十進制值。

我們已經(jīng)評估了客戶流失藍圖的兩種配置：一種使用浮點值表示貨幣金額（如我們在 第一期 中所描述的那樣），另一種使用十進制值表示貨幣金額（這是我們當前報告的性能數(shù)字所針對的配置）。由于其語義和健壯性，十進制算法比浮點算法成本更高，但只要所涉及的所有十進制類型都在 64 位以內(nèi)，就可以通過 RAPIDS 加速器插件來加速。

配置 RAPIDS 加速器以啟用更多操作

RAPIDS 加速器對于在 GPU 上執(zhí)行 MIG ht 表現(xiàn)出較差性能或返回與基于 CPU 的加速器略有不同的結果的操作持保守態(tài)度。因此，一些可以加速的操作在默認情況下可能不會加速，許多實際應用程序需要使這些操作能夠看到最佳性能。我們在 我們的第一期 中看到了這種現(xiàn)象的一個例子，其中我們必須通過將 true 設置為 true ，在 Spark 配置中顯式啟用浮點聚合操作。類似地，當我們將工作負載配置為使用十進制算法時，我們需要通過將 spark.rapids.sql.decimalType.enabled 設置為 true 來啟用十進制加速。

插件文檔 列出了配置支持或不支持的操作，以及在默認情況下啟用或禁用某些操作的原因。除了浮點聚合和十進制支持之外，生產(chǎn) Spark 工作負載極有可能受益于以下幾類操作：

鑄造作業(yè) ，特別是從字符串到日期或數(shù)字類型，或從浮點類型到十進制類型。

某些 Unicode 字符不支持字符串大小寫（例如“ SELECT UPPER（name） FROM EMPLOYEES ”），更改大小寫也會更改字符寬度（以字節(jié)為單位），但許多應用程序不使用此類字符［或者通過將 Spark 。 RAPIDS 。 sql 。 compatibleops 。 enabled 設置為 true 來啟用它們和其他幾個。

從 CSV 文件中讀取特定類型；雖然插件（ Spark 。 RAPIDS 。 sql 。 format 。 CSV 。 enabled ）中當前默認啟用了讀取 CSV 文件，但讀取某些類型的無效值（尤其是數(shù)字類型、日期和小數(shù)）在 GPU 和 CPU 上會有不同的行為，因此需要單獨啟用每個類型的讀取。

加快從 CSV 文件接收數(shù)據(jù)

CSV 閱讀需要額外的注意：它是昂貴的，加速它可以提高許多工作的性能。然而，由于在 RAPIDS 加速器下讀取 CSV 的行為可能與在 cpu 上執(zhí)行時的 Spark 行為不同，并且由于實際 CSV 文件質(zhì)量的巨大動態(tài)范圍，因此驗證在 GPU 上讀取 CSV 文件的結果尤為重要。一個快速但有價值的健全性檢查是確保在 GPU 上讀取 CSV 文件返回的空值數(shù)與在 CPU 上讀取相同的文件返回的空值數(shù)相同。當然，如果可能的話，使用像 Parquet 或 ORC 這樣的自文檔結構化輸入格式而不是 CSV 有很多好處。

避免查詢優(yōu)化的意外后果

RAPIDS 加速器將 物理查詢計劃 轉(zhuǎn)換為將某些操作符委派給 GPU 。 但是，在 Spark 生成物理計劃時，它已經(jīng)對邏輯計劃執(zhí)行了幾個轉(zhuǎn)換，這可能涉及重新排序操作。 因此，開發(fā)人員或分析人員聲明的接近查詢或數(shù)據(jù)幀操作末尾的操作可能會從查詢計劃的葉移向根。

圖 2 ： 一種執(zhí)行數(shù)據(jù)幀查詢的描述，該查詢連接兩個數(shù)據(jù)幀，然后過濾結果。 如果謂詞具有足夠的選擇性，則大多數(shù)輸出元組將被丟棄。

圖 3 ： 執(zhí)行數(shù)據(jù)幀查詢的描述，在連接結果之前過濾兩個輸入關系。 如果可以對每個輸入關系獨立地計算謂詞，那么此查詢執(zhí)行將產(chǎn)生與圖 2 中的查詢執(zhí)行相同的結果，效率將大大提高。

一般來說，這種轉(zhuǎn)換可以提高性能。 例如，考慮一個查詢，該查詢連接兩個數(shù)據(jù)幀，然后過濾結果： 如果可能的話，在執(zhí)行連接之前執(zhí)行過濾器通常會更有效。 這樣做將減少連接的基數(shù)，消除最終不必要的比較，減少內(nèi)存壓力，甚至可能減少連接中需要考慮的數(shù)據(jù)幀分區(qū)的數(shù)量。 然而，這種優(yōu)化可能會產(chǎn)生違反直覺的后果： 如果向查詢計劃的根移動的操作僅在 CPU 上受支持，或者如果它生成的值的類型在 GPU 上不受支持，則主動查詢重新排序可能會對 GPU 的性能產(chǎn)生負面影響。 當這種情況發(fā)生時，在 CPU 上執(zhí)行的查詢計劃的百分比可能比嚴格需要的要大。 您通?？梢越鉀Q這個問題，并通過將查詢劃分為兩個分別執(zhí)行的部分來提高性能，從而強制在查詢計劃的葉子附近僅 CPU 的操作僅在原始查詢的可加速部分在 GPU 上運行之后執(zhí)行。

結論

在第三期文章中，我們詳細介紹了如何充分利用 Apache Spark 和 Apache RAPIDS 加速器 Spark 。 大多數(shù)團隊都會通過干凈地使用 Spark 的數(shù)據(jù)幀抽象來實現(xiàn)最大的好處。 但是，一些應用程序可能會受益于細微的調(diào)整，特別是考慮 RAPIDS 加速器的執(zhí)行模型并避免不受支持的操作的保留語義的代碼更改。 未來幾期文章將討論數(shù)據(jù)科學發(fā)現(xiàn)工作流和機器學習生命周期的其余部分。

關于作者

William Benton在NVIDIA數(shù)據(jù)科學產(chǎn)品小組工作，他熱衷于使機器學習從業(yè)人員可以輕松地從先進的基礎架構中受益，并使組織可以管理機器學習系統(tǒng)。 在擔任過以前的職務時，他定義了與數(shù)據(jù)科學和機器學習有關的產(chǎn)品戰(zhàn)略和專業(yè)服務產(chǎn)品，領導了數(shù)據(jù)科學家和工程師團隊，并為與數(shù)據(jù)，機器學習和分布式系統(tǒng)有關的開源社區(qū)做出了貢獻。

審核編輯：郭婷