眾所周知， GPU 是大型機器學習（ ML ）應用程序的典型解決方案，但如果 GPU 應用于 AI 管道數(shù)據(jù)的早期階段，該怎么辦？

例如，如果不必為每個管道處理階段切換集群配置，則會更簡單。您可能仍然有一些問題：

從成本角度來看，這是否可行？

對于一些接近實時處理的數(shù)據(jù)處理時間預算，您還能滿足 SLA 嗎？

優(yōu)化這些 GPU 集群有多困難？

如果您為一個階段優(yōu)化了配置，那么其他階段也會這樣嗎？

在 At&T ，當我們的數(shù)據(jù)團隊在規(guī)模上平衡簡單性的同時管理云成本時，這些問題就出現(xiàn)了。我們還觀察到，我們的許多數(shù)據(jù)工程師和科學家同事都不知道 GPU 是一個有效和高效的基礎(chǔ)設施，可以在其上運行更普通的 ETL ，并具有工程階段的特點。

與 GPU 配置相比， CPU 的相對性能也不清楚。我們在 at & T 的目標是運行一些典型的配置示例以了解差異。

在本文中，我們將從速度、成本和完整管道的簡單性方面分享我們的數(shù)據(jù)管道分析。我們還提供有關(guān)設計考慮的見解，并解釋我們?nèi)绾蝺?yōu)化 GPU 集群的性能和價格。優(yōu)化來自于使用 RAPIDS accelerator for Apache Spark， 這一開源庫，它支持 GPU 加速 ETL 和特性工程。

SPOILER ALERT ：我們驚喜地發(fā)現(xiàn)，至少對于所研究的示例來說，在每個管道階段使用 GPU 證明是更快、更便宜、更簡單的！

用例

AI 管道的數(shù)據(jù)包括多個批處理階段：

數(shù)據(jù)準備或聯(lián)合

轉(zhuǎn)型

功能工程

數(shù)據(jù)提取

批處理涉及處理包含數(shù)萬億條記錄的大量數(shù)據(jù)。批處理作業(yè)通常針對成本或性能進行優(yōu)化，具體取決于該用例的 SLA 。

針對成本進行優(yōu)化的批處理作業(yè)的一個很好的例子是從調(diào)用記錄中創(chuàng)建功能，這些功能將用于訓練 ML 模型。另一方面，用于檢測欺詐的實時推理用例針對性能進行了優(yōu)化。 GPU 經(jīng)常被忽視，對于 AI / ML 管道的這些批處理階段來說，它被認為是昂貴的。

這些批處理作業(yè)通常涉及大型聯(lián)接、聚合、排名和轉(zhuǎn)換操作。可以想象， AT & T 有許多涉及批量處理的數(shù)據(jù)和 AI 用例：

網(wǎng)絡規(guī)劃和優(yōu)化

欺詐

銷售和營銷

稅

根據(jù)用例的不同，這些管道可以使用 NVIDIA GPU 和 RAPIDS Accelerator for Apache Spark 來優(yōu)化成本或提高性能。

為了進行此分析，我們查看了兩個到 AI 管道的數(shù)據(jù)。第一個用例將呼叫記錄的特征工程用于營銷用例，第二個用例執(zhí)行復雜稅務數(shù)據(jù)集的 ETL 轉(zhuǎn)換。

使用 GPU 加速特征工程和轉(zhuǎn)換

高效地將數(shù)據(jù)擴展到 AI 管道仍然是數(shù)據(jù)團隊的需要。高成本的管道每月、每周甚至每天都要處理數(shù)百 TB 到 PB 的數(shù)據(jù)。

在檢查效率時，重要的是確定所有 ETL 和特征工程階段的優(yōu)化機會，然后比較速度、成本和管道簡單性。

對于我們的數(shù)據(jù)管道分析，我們比較了三個選項：

各種基于 CPU 的 Spark 集群解決方案

GPU Spark 集群上的 RAPIDS accelerator for Apache Spark

使用 Databricks 最新發(fā)布的 Photon 引擎的 Apache Spark CPU 集群

為了衡量我們離最佳成本有多遠，我們使用 AT & T 的開源 GS-lite 解決方案比較了一個基本 VM 解決方案，該解決方案使您能夠編寫 SQL ，然后將其編譯為 C ++。

如前所述，在優(yōu)化每個解決方案后，我們發(fā)現(xiàn)在 GPU 集群上運行的 Apache Spark 加速器具有最佳的總體速度、成本和設計簡單性權(quán)衡。

在下面的部分中，我們將討論為每種類型選擇的優(yōu)化和設計注意事項。

優(yōu)化 AI / ML 管道解決方案的設計考慮

為了比較這三個潛在解決方案的性能，我們進行了兩個實驗，每個實驗針對選定的用例。對于每種情況，我們都優(yōu)化了不同的參數(shù)，以深入了解速度、成本和設計是如何受到影響的。

示例 1 ：通過聚合為呼叫記錄優(yōu)化簡單組用例

對于第一個特性工程示例，我們選擇從每月包含近 3 萬億條記錄（行）的調(diào)用記錄數(shù)據(jù)集創(chuàng)建特性（表 1 ）。此數(shù)據(jù)預處理用例是幾個銷售和營銷 AI 管道中的基本構(gòu)建塊，例如客戶細分、預測客戶流失以及預測客戶趨勢和情緒。在這個用例中有各種各樣的數(shù)據(jù)轉(zhuǎn)換，但其中許多都涉及簡單的“分組”聚合，例如下面的聚合，我們希望對其進行優(yōu)化處理。

res=spark.sql("""
Select DataHour, dev_id, 
    sum(fromsubbytes) as fromsubbytes_total, 
    sum(tosubbytes) as tosubbytes_total, 
From df
Group By DataHour, dev_id
""")

從數(shù)據(jù)中獲取見解并進行數(shù)據(jù)分析仍然是許多企業(yè)的最大痛點之一。這并不是因為缺乏數(shù)據(jù)，而是因為在數(shù)據(jù)準備和分析上花費的時間仍然是數(shù)據(jù)工程師和數(shù)據(jù)科學家的障礙。

以下是此預處理示例中的一些關(guān)鍵基礎(chǔ)架構(gòu)挑戰(zhàn)：

CPU 集群上的查詢執(zhí)行時間過長，導致超時問題。

計算成本昂貴。

此外，這個調(diào)用記錄用例在壓縮類型方面有額外的實驗維度。數(shù)據(jù)通過某種形式的壓縮從網(wǎng)絡邊緣到達云端，我們可以指定并評估折衷。因此，我們試驗了幾種壓縮方案，包括 txt / gzip 、 Parquet / Z 標準和 Parquet / Snappy 。

Z 標準壓縮的文件大小最小（在本例中約為一半）。正如我們稍后所展示的，我們發(fā)現(xiàn)了與 Parquet / Snappy 更好的速度/成本權(quán)衡。

接下來，我們考慮了集群的類型，包括每個 VM 的內(nèi)核數(shù)、 VM 數(shù)、工作節(jié)點的分配，以及是使用 CPU 還是 GPU 。

對于 CPU 集群，我們選擇了能夠處理工作負載的最低數(shù)量的核心，即 VM 和工人的最低數(shù)量，以防止資源過度分配。

對于 GPU ，我們使用了 RAPIDS Accelerator 調(diào)優(yōu)指南［spark rapids tuning］，該指南針對每個執(zhí)行器的并發(fā)任務、 maxPartitionBytes 、 shuffle 分區(qū)和并發(fā) GPU 任務提供了分級建議。

在 GPU 上實施數(shù)據(jù)處理后的一個目標是確保所有關(guān)鍵特征工程步驟都保留在 GPU 上（圖 1 ）。

圖 1. GPU 物理處理計劃

示例 2 ：為稅務數(shù)據(jù)集優(yōu)化多個 ETL 和功能創(chuàng)建階段

示例 2 的用例允許我們比較 ETL 、特性創(chuàng)建和 AI 的許多不同轉(zhuǎn)換和處理階段。每個階段有不同的記錄體積大小（圖 2 ）。

圖 2.ETL / AI 流量和記錄體積大小

這種具有多個階段的 ETL 管道是數(shù)據(jù)存儲在豎井中的企業(yè)中的常見瓶頸。大多數(shù)情況下，海量數(shù)據(jù)處理需要使用模糊邏輯查詢和連接來自兩個或多個數(shù)據(jù)源的數(shù)據(jù)。如圖 2 所示，盡管我們一開始只有 2000 萬行數(shù)據(jù)，但隨著數(shù)據(jù)處理階段的推移，數(shù)據(jù)量呈指數(shù)級增長。

如示例 1 所示，在比較 CPU 和 GPU 時，設計考慮的是每個 VM 的內(nèi)核數(shù)、 VM 數(shù)和工作節(jié)點的分配。

后果

在為示例 1 和 2 中所示的用例嘗試了不同的核心、工作機和集群配置之后，我們收集了結(jié)果。我們確保在分配的時間內(nèi)完成任何特定 ETL 作業(yè)，以跟上數(shù)據(jù)輸入數(shù)據(jù)速率。兩者中最好的方法都具有最低的成本和最高的簡單性。

示例 1 結(jié)果

圖 3 顯示了調(diào)用記錄用例中簡單分組聚合的一系列設置之間的成本/速度權(quán)衡。您可以進行幾個觀察：

成本最低、最簡單的解決方案是使用具有 Snappy 壓縮功能的 GPU 集群，它比成本最低的 Photon 解決方案便宜約 33% ，比最快的 Photon 方案便宜近一半。

所有標準 Databricks 集群在成本和執(zhí)行時間方面都表現(xiàn)較差。光子是最好的 CPU 溶液。

雖然圖 3 中沒有顯示，但 GS-lite 解決方案實際上是最便宜的，只需要兩個 VM 。

圖 3.不同 Databricks 集群配置的成本/執(zhí)行和時間權(quán)衡

示例 2 結(jié)果

與示例 1 一樣，我們使用 Databricks 10.4 LTS ML 運行時為五個 ETL 和 AI 數(shù)據(jù)處理階段嘗試了幾個 CPU 和 GPU 集群配置。表 2 顯示了得到的最佳配置。

這些配置產(chǎn)生了有利于 GPU 的相對成本和執(zhí)行時間（速度）性能（圖 4 ）。

圖 4.成本和執(zhí)行時間權(quán)衡

雖然此處未顯示，但我們確認，示例 1 中使用 XGBoost 建模的 AI 管道的下一階段也受益于 GPU 和 RAPIDS Accelerator for Apache Spark 。這證實了 GPU 可能是最好的端到端解決方案。

結(jié)論

雖然并非所有 AT & T 數(shù)據(jù)和 AI 管道都詳盡無遺，但基于 GPU 的管道似乎在所有示例中都是有益的。在這些情況下，我們能夠減少數(shù)據(jù)準備、模型培訓和優(yōu)化的時間。這導致在更簡單的設計上花費更少的錢，因為沒有跨階段的配置切換。

關(guān)于作者

作為 at & T 數(shù)據(jù)科學副總裁， Mark Austin 博士領(lǐng)導了數(shù)百名數(shù)據(jù)科學家和工程師團隊，他們實施了新的創(chuàng)新技術(shù)，幫助 at & T 業(yè)務部門采用人工智能和機器學習技術(shù)。他獲得了馬里蘭大學和佐治亞理工大學的電氣和電子工程學士和碩士學位。奧斯汀博士還擁有佐治亞科技大學的電氣工程博士學位。

Satya Vivek Kanakadandila 是 at & T 的主要大數(shù)據(jù)軟件工程師，他利用自己在軟件開發(fā)方面的豐富經(jīng)驗為公司的數(shù)據(jù)驅(qū)動計劃構(gòu)建新功能。 Kanakadandila 擁有德克薩斯理工大學電氣和計算機工程碩士學位。他在 Hive 、 Apache Spark 、需求分析、數(shù)據(jù)工程和 shell 腳本編寫方面也有豐富的經(jīng)驗。

Abhay Dabholkar 是一位實踐經(jīng)驗豐富的 AI / ML 和大數(shù)據(jù)軟件工程主管，在大規(guī)模轉(zhuǎn)型、制定業(yè)務戰(zhàn)略和領(lǐng)導端到端數(shù)據(jù)科學/ AI 項目方面具有豐富經(jīng)驗。 Abhay 目前是 at & T 杰出的 AI / ML 企業(yè)架構(gòu)師，他建立并領(lǐng)導了全球分布的高績效團隊。 Abhay 還參與了數(shù)據(jù)科學和文本分析領(lǐng)域的多項專利。

Chris Vo 是 at & T 技術(shù)人員的主要成員。

審核編輯：郭婷