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

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

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

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

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

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

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

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

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

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

用例

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

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

轉(zhuǎn)型

功能工程

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

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

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

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

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

欺詐

銷售和營銷

稅

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

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

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

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

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

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

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

GPU Spark 集群上的 RAPIDS accelerator for Apache Spark

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

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

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

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

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

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

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

對于第一個(gè)特性工程示例，我們選擇從每月包含近 3 萬億條記錄（行）的調(diào)用記錄數(shù)據(jù)集創(chuàng)建特性（表 1 ）。此數(shù)據(jù)預(yù)處理用例是幾個(gè)銷售和營銷 AI 管道中的基本構(gòu)建塊，例如客戶細(xì)分、預(yù)測客戶流失以及預(yù)測客戶趨勢和情緒。在這個(gè)用例中有各種各樣的數(shù)據(jù)轉(zhuǎn)換，但其中許多都涉及簡單的“分組”聚合，例如下面的聚合，我們希望對其進(jì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ù)中獲取見解并進(jìn)行數(shù)據(jù)分析仍然是許多企業(yè)的最大痛點(diǎn)之一。這并不是因?yàn)槿狈?shù)據(jù)，而是因?yàn)樵跀?shù)據(jù)準(zhǔn)備和分析上花費(fèi)的時(shí)間仍然是數(shù)據(jù)工程師和數(shù)據(jù)科學(xué)家的障礙。

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

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

計(jì)算成本昂貴。

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

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

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

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

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

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

圖 1. GPU 物理處理計(jì)劃

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

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

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

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

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

后果

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

示例 1 結(jié)果

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

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

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

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

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

示例 2 結(jié)果

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

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

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

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

結(jié)論

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

關(guān)于作者

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

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

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

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

審核編輯：郭婷