這是 SafeGraph 技術(shù)主管經(jīng)理 Nan Zhu 與亞馬遜云科技高級解決方案架構(gòu)師 Dave Thibault 共同撰寫的特約文章。

SafeGraph 是一家地理空間數(shù)據(jù)公司，管理著全球超過 4100 萬個興趣點(diǎn)（POI，Point of Interest），提供品牌隸屬關(guān)系、高級類別標(biāo)簽、開放時間，以及人們?nèi)绾闻c這些場所互動等方面的詳細(xì)信息。我們使用 Apache Spark 作為主要數(shù)據(jù)處理引擎，每天有 1000 多款 Spark 應(yīng)用程序運(yùn)行海量的數(shù)據(jù)。這些 Spark 應(yīng)用程序?qū)嵤┪覀兊臉I(yè)務(wù)邏輯，包括數(shù)據(jù)轉(zhuǎn)換、機(jī)器學(xué)習(xí)（ML）模型推理和運(yùn)維任務(wù)等廣泛的應(yīng)用。

SafeGraph 發(fā)現(xiàn)其現(xiàn)有 Spark 供應(yīng)商的 Spark 環(huán)境并不理想。他們的成本不斷上升。在競價型實例終止時，其作業(yè)會頻繁重試。開發(fā)人員花費(fèi)太多的時間進(jìn)行故障排除和更改作業(yè)配置，沒有足夠的時間來開發(fā)具有業(yè)務(wù)價值的代碼。SafeGraph 需要控制成本、提高開發(fā)人員迭代速度和改進(jìn)作業(yè)可靠性。最終，SafeGraph 選擇 Amazon EKS 上的 Amazon EMR 來滿足他們的需求，與之前的 Spark 托管服務(wù)供應(yīng)商相比，成本節(jié)省了 50%。

所謂“工欲善其事必先利其器”，在為產(chǎn)品構(gòu)建 Spark 應(yīng)用程序時，Spark 平臺就是這個“器”。下圖展示了使用 Spark 時的工程設(shè)計工作流，Spark 平臺需要支持和優(yōu)化工作流中的每個操作。工程師通常先編寫和構(gòu)建 Spark 應(yīng)用程序代碼，然后將應(yīng)用程序提交到計算基礎(chǔ)設(shè)施，最后調(diào)試 Spark 應(yīng)用程序來結(jié)束循環(huán)。此外，平臺和基礎(chǔ)設(shè)施團(tuán)隊需要持續(xù)運(yùn)維，并優(yōu)化工程設(shè)計工作流中的三個步驟。

構(gòu)建 Spark 平臺時，每個操作都涉及多種挑戰(zhàn)：

• 可靠的依賴項管理?– 復(fù)雜的 Spark 應(yīng)用程序通常會引入許多依賴項。要運(yùn)行 Spark 應(yīng)用程序，我們需要確定所有依賴項，解決任何沖突，可靠地打包依賴項庫，并將它們傳輸?shù)?Spark 集群。依賴項管理是工程師面臨的最大挑戰(zhàn)之一，尤其是在他們使用 PySpark 應(yīng)用程序時。

• 可靠的計算基礎(chǔ)設(shè)施?– 托管 Spark 應(yīng)用程序的計算基礎(chǔ)設(shè)施必須具有可靠性，這是整個 Spark 平臺的基礎(chǔ)。不穩(wěn)定的資源預(yù)置不僅會對工程設(shè)計效率造成負(fù)面影響，而且還會因重新運(yùn)行 Spark 應(yīng)用程序而增加基礎(chǔ)設(shè)施成本。

• 面向 Spark 應(yīng)用程序的便捷調(diào)試工具?– 工程師能否在 Spark 應(yīng)用程序上快速進(jìn)行迭代，調(diào)試工具的作用非常關(guān)鍵。要想提高開發(fā)人員迭代速度，高性能訪問 Spark 歷史服務(wù)器（SHS，Spark History Server）是一個必要條件。反過來說，糟糕的 SHS 性能會減慢開發(fā)人員的速度，并增加軟件公司銷售產(chǎn)品的成本。

• 可管理的 Spark 基礎(chǔ)設(shè)施?– 成功的 Spark 平臺工程設(shè)計涉及到多個方面，例如 Spark 分發(fā)版本管理、計算資源 SKU 管理和優(yōu)化等。這在很大程度上取決于 Spark 服務(wù)供應(yīng)商是否為平臺團(tuán)隊提供了合適的底層供他們使用。例如，對分發(fā)版本和計算資源的錯誤抽象化可能會顯著降低平臺工程設(shè)計的 ROI。

SafeGraph 遇到了上述所有挑戰(zhàn)。為了解決這些問題，我們探索了市場，發(fā)現(xiàn)依托 Amazon EKS 上的 Amazon EMR 來構(gòu)建新的 Spark 平臺，這種方法可以解決我們面臨的障礙。在這篇文章中，我們分享了構(gòu)建最新 Spark 平臺的旅程，以及 EKS 上的 EMR 如何為這個旅程提供了強(qiáng)大而有效的底層。

可靠的 Python 依賴項管理

用戶在編寫和構(gòu)建 Spark 應(yīng)用程序代碼時，面臨的最大挑戰(zhàn)之一是難以可靠地管理依賴項，尤其是對于 PySpark 應(yīng)用程序。我們大多數(shù)與機(jī)器學(xué)習(xí)相關(guān)的 Spark 應(yīng)用程序都是使用 PySpark 構(gòu)建的。之前的 Spark 服務(wù)供應(yīng)商只支持一種管理 Python 依賴項的方法，那就是使用 wheel 文件。盡管基于 wheel 的依賴項管理得到了廣泛的應(yīng)用，但它其實很脆弱。下圖顯示了基于 wheel 的依賴項管理面臨的兩種類型的可靠性問題：

• 未固定的直接依賴項?– 如果 .whl 文件無法確定某個直接依賴項的版本（在此示例中為 Pandas），它將始終從上游拉取最新版本，其中可能包含破壞性的更改并導(dǎo)致 Spark 應(yīng)用程序中斷。

• 未固定的傳遞依賴項– 第二種可靠性問題更是我們無法控制的。即使我們在構(gòu)建 .whl 文件時固定了直接依賴項版本，但直接依賴項本身可能無法確定傳遞依賴項版本（在本例中為 MLFlow）。在這種情況下，直接依賴項總是會拉取這些傳遞依賴項的最新版本，而這些依賴項中可能包含破壞性的更改并可能導(dǎo)致管道中斷。

我們遇到的另一個問題是，在每次 Spark 應(yīng)用程序初始化時，會不必要地安裝 wheel 文件引用的所有 Python 包。在我們之前的設(shè)置中，需要在啟動時運(yùn)行安裝腳本來為每個 Spark 應(yīng)用程序安裝 wheel 文件，即使依賴項沒有變化。此安裝將 Spark 應(yīng)用程序的啟動時間從 3 到 4 分鐘延長到至少 7 到 8 分鐘。這種拖沓的速度非常影響體驗，尤其是我們的工程師正在積極迭代變更時。

通過遷移到 EKS 上的 EMR，我們能夠使用 pex（Python 可執(zhí)行文件）來管理 Python 依賴項。.pex 文件考慮到虛擬環(huán)境，打包 PySpark 應(yīng)用程序在可執(zhí)行 Python 環(huán)境中的所有依賴項（包括直接依賴項和傳遞依賴項）。

下圖展示了將上圖中的 wheel 文件轉(zhuǎn)換為.pex 文件后的文件結(jié)構(gòu)。與基于 wheel 的工作流相比，我們不再有傳遞依賴項拉取或自動獲取最新版本的操作。構(gòu)建 .pex 文件時，依賴項的所有版本都固定為 x.y.z、a.b.c 等。對于給定的.pex 文件，所有依賴項都已固定，這樣我們就不會再遇到基于 wheel 的依賴項管理中的緩慢或脆弱性問題。構(gòu)建 .pex 文件的成本也是一次性成本。

可靠、高效的資源預(yù)置

資源預(yù)置是 Spark 平臺為 Spark 應(yīng)用程序獲取計算資源的過程，是整個 Spark 平臺的基礎(chǔ)。在云中構(gòu)建 Spark 平臺時，使用競價型實例進(jìn)行成本優(yōu)化使得資源預(yù)置更具挑戰(zhàn)性。競價型實例是可供您使用的備用計算容量，相比按需價格最多可節(jié)省 90%。但是，當(dāng)對某些實例類型的需求突然增長時，可能會終止競價型實例以優(yōu)先滿足這些需求。由于這些終止，我們在之前版本的 Spark 平臺中遇到了一些挑戰(zhàn)：

• 不可靠的 Spark 應(yīng)用程序?– 當(dāng)競價型實例終止時，由于重試計算階段，Spark 應(yīng)用程序的運(yùn)行時間顯著延長。

• 糟糕的開發(fā)人員體驗?– 競價型實例不穩(wěn)定的供應(yīng)狀態(tài)導(dǎo)致 Spark 應(yīng)用程序的性能遇到不可預(yù)測和低成功率的問題，嚴(yán)重影響了工程師的體驗并減緩了開發(fā)迭代速度。

• 昂貴的基礎(chǔ)設(shè)施賬單?– 由于作業(yè)需要重試，我們的云基礎(chǔ)設(shè)施賬單大幅增加。為了緩解問題，我們不得不購買具有更大容量且在多個可用區(qū)中運(yùn)行的昂貴 Amazon Elastic Compute Cloud（Amazon EC2）實例，但這隨之又帶來了跨可用區(qū)流量的高成本。

Spark 服務(wù)提供商（SSP，Spark Service Provider），如 EKS 上的 EMR 或其他第三方軟件產(chǎn)品，是用戶和競價型實例池之間的中間人，在確保競價型實例的充足供應(yīng)方面發(fā)揮著關(guān)鍵作用。如下圖所示，用戶通過 SSP 使用作業(yè)編排工具、筆記本或服務(wù)啟動 Spark 作業(yè)。SSP 實施自己的內(nèi)部功能，以訪問亞馬遜云科技等云服務(wù)的競價型實例池中未使用的實例。使用競價型實例的最佳實踐之一是使用多樣化的實例類型（有關(guān)更多信息，請參閱使用 EC2 競價型實例進(jìn)行成本優(yōu)化：https://aws.github.io/aws-emr-containers-best-practices/cost-optimization/docs/cost-optimization/）。具體而言，SSP 可以通過兩個關(guān)鍵功能實現(xiàn)實例多樣化：

• SSP 應(yīng)該能夠訪問亞馬遜云科技的競價型實例池中所有類型的實例

• SSP 應(yīng)為用戶提供相應(yīng)的功能，讓他們能夠在啟動 Spark 應(yīng)用程序時使用盡可能多的實例類型

我們的上一個 SSP 沒有針對這兩點(diǎn)提供所需的解決方案。他們只支持一組有限的競價型實例類型，并且默認(rèn)情況下，在啟動 Spark 作業(yè)時，只允許選擇一種競價型實例類型。因此，每個 Spark 應(yīng)用程序只能運(yùn)行容量較小的競價型實例，并且容易受到競價型實例終止的影響。

EKS 上的 EMR 使用 Amazon Elastic Kubernetes Service（Amazon EKS）訪問亞馬遜云科技中的競價型實例。Amazon EKS 支持所有可用的 EC2 實例類型，為我們帶來了更高的容量池。我們使用 Amazon EKS 托管節(jié)點(diǎn)組、節(jié)點(diǎn)選擇器以及污點(diǎn)等功能，將每個 Spark 應(yīng)用程序分配到一個由多種實例類型組成的節(jié)點(diǎn)組。在遷移到 EKS 上的 EMR 后，我們看到了以下好處：

• 減少了競價型實例終止的頻率，縮短了 Spark 應(yīng)用程序的運(yùn)行時間并且保持穩(wěn)定。

• 工程師發(fā)現(xiàn)應(yīng)用程序行為的可預(yù)測性得到改善，因此能夠更快地進(jìn)行迭代。

• 基礎(chǔ)設(shè)施成本大幅下降，因為我們不再需要昂貴的解決方法，同時，我們在 Amazon EKS 的每個節(jié)點(diǎn)組中都有精打細(xì)算的實例選擇。我們能夠節(jié)省大約 50% 的計算成本，而無需采用在多個可用區(qū)中運(yùn)行之類的解決方法，同時提供預(yù)期的可靠性水平。

流暢的調(diào)試體驗

對于工程設(shè)計工作流循環(huán)的結(jié)束環(huán)節(jié)來說，有一個能夠支持工程師方便地調(diào)試 Spark 應(yīng)用程序的基礎(chǔ)設(shè)施至關(guān)重要。Apache Spark 使用事件日志記錄 Spark 應(yīng)用程序的活動，例如任務(wù)開始和完成。這些事件采用 JSON 格式，由 SHS 用來重新呈現(xiàn) Spark 應(yīng)用程序的 UI。工程師可以訪問 SHS 來調(diào)查任務(wù)故障原因或調(diào)試性能問題。

SafeGraph 工程師面臨的主要挑戰(zhàn)是 SHS 中的可擴(kuò)展性問題。如下圖左側(cè)所示，我們之前的 SSP 強(qiáng)制所有工程師共享同一個 SHS 實例。結(jié)果，由于許多工程師同時進(jìn)行訪問以調(diào)試應(yīng)用程序，或者如果 Spark 應(yīng)用程序需要渲染大型事件日志，SHS 面臨著巨大的資源壓力。在遷移到 EKS 上的 EMR 之前，我們經(jīng)常遇到 SHS 緩慢或 SHS 徹底崩潰的情況。

如下圖所示，對于每個查看 Spark 歷史記錄 UI 的請求，EKS 上的 EMR 都會在亞馬遜云科技管理的環(huán)境中啟動一個獨(dú)立的 SHS 實例容器。此架構(gòu)的好處有兩方面：

• 不同的用戶和 Spark 應(yīng)用程序不再爭奪 SHS 資源。因此，我們再也沒有遇到 SHS 緩慢或崩潰的情況。

• 所有 SHS 容器均由亞馬遜云科技管理；用戶無需支付額外的財務(wù)或運(yùn)維成本，就能享受到可擴(kuò)展的架構(gòu)。

易于管理的 Spark 平臺

如工程設(shè)計工作流所示，構(gòu)建 Spark 平臺不是一次性的工作，平臺團(tuán)隊需要管理 Spark 平臺并不斷優(yōu)化工程師開發(fā)工作流中的每個步驟。SSP 的作用是提供適當(dāng)?shù)谋憷?#xff0c;來盡可能減輕運(yùn)維負(fù)擔(dān)。盡管運(yùn)維任務(wù)有很多類型，但在本文中我們重點(diǎn)介紹其中的兩個：計算資源 SKU 管理和 Spark 發(fā)行版版本管理。

計算資源 SKU 管理是指 Spark 平臺在允許用戶選擇不同大小的計算實例方面，進(jìn)行的設(shè)計和處理。這樣的設(shè)計和處理在很大程度上依賴于 SSP 實施的相關(guān)功能。

下圖顯示了我們之前 SSP 的 SKU 管理。

下圖顯示了 EKS 上的 EMR 中的 SKU 管理。

在與我們之前的 SSP 合作時，作業(yè)配置僅允許明確指定單個競價型實例類型，如果該類型沒有可用的競價容量，則作業(yè)會切換到按需實例，或者出現(xiàn)可靠性問題。這讓平臺工程師要么選擇更改 Spark 作業(yè)實例集的設(shè)置，要么需要承擔(dān)預(yù)算和售出產(chǎn)品的成本意外飆升的風(fēng)險。

EKS 上的 EMR 使平臺團(tuán)隊可以更輕松地管理計算 SKU。在 SafeGraph，我們在用戶與 EKS 上的 EMR 之間嵌入了 Spark 服務(wù)客戶端。Spark 服務(wù)客戶端僅向用戶公開不同層級的資源（例如小型、中型和大型）。每一層級都映射到在 Amazon EKS 中配置的特定節(jié)點(diǎn)組。這種設(shè)計帶來了以下好處：

• 在價格和容量發(fā)生變化時，我們很容易更新節(jié)點(diǎn)組中的配置，而用戶并不會知道。用戶不用執(zhí)行任何更改，甚至不會有任何感覺，就可以繼續(xù)享受穩(wěn)定的資源配置，同時我們還能盡可能降低成本和運(yùn)維開銷。

• 在為 Spark 應(yīng)用程序選擇合適的資源時，最終用戶無需進(jìn)行任何猜測，因為通過簡化的配置可以輕松進(jìn)行選擇。

我們從 EKS 上的 EMR 中獲得的另一個好處是改進(jìn)了 Spark 發(fā)行版管理。在使用 EKS 上的 EMR 之前，我們的 SSP 存在不透明發(fā)布 Spark 發(fā)行版的問題。每隔 1-2 個月，Spark 發(fā)行版就會向用戶發(fā)布一個新的補(bǔ)丁版本。這些版本都通過 UI 向用戶公開。這導(dǎo)致工程師選擇了各種版本的發(fā)行版，其中一些版本未經(jīng)過我們的內(nèi)部工具測試。這大幅增加了我們的管道和內(nèi)部系統(tǒng)的中斷率，并對平臺團(tuán)隊帶來了很大的支持負(fù)擔(dān)。我們希望在使用 EKS 上的 EMR 架構(gòu)后，Spark 發(fā)行版的風(fēng)險可降至最低，并且對用戶透明。

EKS 上的 EMR 遵循最佳實踐，使用包含固定版本的 Spark 發(fā)行版的穩(wěn)定基礎(chǔ) Docker 映像。對于 Spark 發(fā)行版的任何更改，我們都必須明確地重建并推出 Docker 映像。借助 EKS 上的 EMR，在使用內(nèi)部工具和系統(tǒng)對新版本的 Spark 發(fā)行版進(jìn)行測試并正式發(fā)布之前，我們可以對用戶隱藏該版本。

總結(jié)

在這篇文章中，我們分享了依托 EKS 上的 EMR 構(gòu)建 Spark 平臺的過程。將 EKS 上的 EMR 作為 SSP，為我們的 Spark 平臺奠定了堅實的基礎(chǔ)。借助 EKS 上的 EMR，我們得以解決了依賴項管理、資源預(yù)置和調(diào)試體驗等各種挑戰(zhàn)，并且得益于可用性更高的競價型實例類型和大小，我們還顯著降低了計算成本，削減達(dá)到 50%。

我們希望這篇文章能夠在社區(qū)中分享一些見解，幫助企業(yè)選擇合適的 SSP。詳細(xì)了解 EKS 上的 EMR（https://aws.amazon.com/emr/features/eks/），包括其益處、功能和入門方法。

Original URL:?

https://aws.amazon.com/blogs/big-data/how-safegraph-built-a-reliable-efficient-and-user-friendly-spark-platform-with-amazon-emr-on-amazon-eks/

本篇作者

Nan Zhu

SafeGraph 平臺團(tuán)隊的技術(shù)主管經(jīng)理。他領(lǐng)導(dǎo)團(tuán)隊構(gòu)建廣泛的基礎(chǔ)設(shè)施和內(nèi)部工具，以提高 SafeGraph 工程設(shè)計流程的可靠性、效率和生產(chǎn)力，例如內(nèi)部 Spark 生態(tài)系統(tǒng)、指標(biāo)存儲和大型單一存儲庫的 CI/CD 等。他還參與了多個開源項目，如 Apache Spark、Apache Iceberg、Gluten 等。

Dave Thibault

一位資深解決方案架構(gòu)師，為亞馬遜云科技的獨(dú)立軟件供應(yīng)商（ISV）客戶提供服務(wù)。他熱衷于使用無服務(wù)器技術(shù)和機(jī)器學(xué)習(xí)進(jìn)行構(gòu)建，推動亞馬遜云科技客戶加快實現(xiàn)業(yè)務(wù)成功。加入 亞馬遜云科技之前，Dave 在生命科學(xué)公司工作了 17 年，為研究、開發(fā)和臨床制造部門開展 IT 和信息學(xué)工作。他的愛好包括滑雪、戶外油畫寫生，還喜歡與家人共度時光。

聽說，點(diǎn)完下面4個按鈕

就不會碰到bug了！