Pinterest 最近將其基於 Hadoop 的資料平臺替換為 Moka，這是一個在 AWS EKS 上執行 Spark 的 Kubernetes 原生系統。Moka 實現了容器化作業隔離，支援基於 ARM 的例項，透過 YuniKorn 改進排程，並簡化部署，同時降低基礎設施成本，提高了資料處理工作負載的效率。
Pinterest 做出了一個戰略性決定，從傳統的基於 Hadoop 的架構轉型到基於 Kubernetes 的 Spark 模型，更好地與現代基礎設施實踐保持一致。它選擇 Kubernetes 是因為它對容器編排和安全性的原生支援，以及它在部署混合例項型別（如 ARM 和 x86）方面的靈活性：
憑藉這些需求，我們在 2022 年對在各種平臺上執行 Spark 進行了全面評估。我們傾向於 Kubernetes 為中心的框架，因為它們提供了以下優勢：基於容器的隔離性和安全性，作為平臺的一等公民，易於部署，內建了框架和效能調整選項。
此外，Moka 在傳統平臺上引入了關鍵的成本和效率改進。透過利用基於容器的隔離，Pinterest 將具有不同安全要求的工作負載整合到共享叢集中，從而減少了對多個叢集的需求。
Pinterest 的工程師也承認，“基於容器的系統提供了更強的隔離，允許移除專用但利用率低的 Hadoop 環境，轉而在同一 Moka 叢集上執行具有不同安全要求的作業。”該平臺支援 基於 ARM 的例項 和機會式自動擴充套件，在非高峰時段擴充套件叢集，進一步有助於基礎設施成本的節省。
替換 Hadoop 需要重新設計與作業提交、排程、儲存和可觀測性相關的幾個關鍵元件——“多年來，Hadoop 和 Monarch （Pinterest 的 Hadoop 平臺）已經涵蓋了大量的功能。構建一個替代方案意味著開發替代品…”。Pinterest 開發了新的服務，如用於作業提交的 Archer，採用 Apache YuniKorn 進行基於佇列的排程，將儲存從 HDFS 遷移到 S3，並集成了 Apache Celeborn 遠端混洗服務，以保持大規模的效能。
Moka 最初的高階設計（來源）
在 Moka 的初始設計中，Spinner，Pinterest 基於 Airflow 的編排系統，將計劃的工作流程分解為單獨的作業提交，併發送給 Archer，即 EKS 作業提交服務。Archer 將每個作業轉換為 Kubernetes 自定義資源，並提交給支援 Spark 的 EKS 叢集。Archer 處理作業排隊、狀態跟蹤和與 Kubernetes API 的整合，實現跨叢集的可靠部署和高效資源路由，同時保持與現有工作流程的相容性。
Spark Operator（來源）
Pinterest 的工程師選擇使用 Spark Operator 在 Kubernetes 上原生執行 Spark，並使用 Apache YuniKorn 進行批次排程。Spark Operator 公開了 SparkApplication 自定義資源定義（Custom Resource Definition，CRD），允許以宣告方式的定義 Spark 應用程式，並將所有底層提交細節留給 Spark Operator 處理。在內部，Spark Operator 仍然使用原生的 spark-submit 命令。
Moka 資源管理（來源）
YuniKorn 提供基於佇列的排程、應用程式配額和搶佔，並使 Pinterest 能夠在團隊之間強制執行資源隔離，並根據工作負載層和業務關鍵性動態調整作業的優先順序。
一旦 YuniKorn 排程作業，SparkSQL 作業就會連線到 Hive Metastore，然後使用來自 AWS ECR 的容器映象執行工作負載。在執行過程中，Archer 跟蹤作業狀態，系統將日誌上傳到 S3，將指標上傳到內部儀表板。使用者可以透過網路代理訪問正在執行的作業 UI，也可以透過 Spark History Server 檢索歷史日誌，所有這些都可以透過只讀的 Moka UI 呈現出來。
原文連結：
https://www.infoq.com/news/2025/07/pinterest-spark-kubernetes/
宣告：本文由 InfoQ 翻譯，未經許可禁止轉載。
點選底部閱讀原文訪問 InfoQ 官網，獲取更多精彩內容！