鑽石舞台

Apache Spark 是目前應用最廣泛的大數據分析計算工具之一。它擅長於批處理和實時流處理，並支持機器學習、人工智能、自然語言處理和數據分析應用。隨着 Spark 越來越受歡迎，使用量越來越大，狹義上的 Hadoop (MR) 技術棧正在收縮。另外，普遍的觀點和實踐經驗證明，除了大數據相關的工作負載，Hadoop (YARN) 不具備相應的靈活性去跟更廣泛的企業技術棧融合與集成。比如去承載一些在線業務，而這正是 Kubernetes（K8s) 所擅長的領域。事實上，Kubernetes 的出現為 Spark 的改進打開了一個新世界的大門，創造了更多機遇。如果能用統一的一套集群去運行所有在線和離線的作業，也是十分吸引人的事情。

Spark on Kubernetes 於 Spark 2.3[1] 版本引入開始，到 Spark 3.1[2] 社區標記 GA，基本上已經具備了在生產環境大規模使用的條件。

在業內，蘋果[3], 微軟[4], 谷歌，網易，華為、滴滴，京東等公司都已經有內部大規模落地或者對外服務的經典成功案例。

從 Spark 整體計算框架層面來看，只是在資源管理層面多支持了一種調度器，其他接口都可以完全復用。一方面 Kubernetes 的引入和 Spark Standalone、YARN、 Mesos 及 Local 等組件形成了一個更為豐富的資源管理體系。

另一方面，Spark 社區在支持 Kubernetes 特性的同時，對用戶 API 的兼容度也得到了最大化的保留，極大程度上方便了用戶任務的遷移。比如對於一個傳統的 Spark 作業而言，我們通過簡單的指定 --master 參數為 yarn 或者 k8s://xxx，即可完成兩個調度平台的運行時切換。其他參數諸如鏡像、隊列、Shuffle 本地盤等配置， yarn 和 k8s 之間都是隔離的，可以很方便地統一在配置文件中統一維護。

Spark Native API

以 spark-submit 這種傳統提交作業的方式來說，如前文中提到的通過配置隔離的方式，用戶可以很方便地提交到 k8s 或者 YARN 集群上運行，基本上一樣的簡單和易用。這種方式對於熟悉 Spark API 及生態的用戶而言是十分友好的，基本上沒有對 k8s 技術棧的硬性要求。

可以看到，如果我們忽略 K8s 或者 YARN 的底層細節，基本上還是熟悉的配方熟悉的味道。

Spark Operator

另外，除了這種方式， Kubernetes 在 API 上更加豐富。我們可以通過 Spark Operator[6]的方式， 如 kubectl apply -f來創建和管理 Spark on k8s 應用。這種方式對於 Kubernetes 集群本身及用戶而言無疑是最優雅的，而對沒有 Kubernetes 經驗的這部分 Spark 用戶而言，有一定的學習成本。這種方式另一個好處是，Spark 的相關 lib 都可以通過 Docker 倉庫來 Deploy，不需要單獨的 Spark Client 環境來提交作業。單獨的 Client 環境，容易造成版本和 Docker 不一致，增加運維成本，也會埋下引發一些不必要的線上問題的隱患。

Serverless SQL

當然，無論是 Spark 原生的還是 Operator 的方式，對大部分用戶來說還是太原始了，不可避免的需要去感知一些底層的細節。在 Datalake/Lakehouse 場景下，數據變得民主，數據應用變得多樣，很難去大範圍地推廣。在易用性上想更進一步，可以考慮使用 Apache Kyuubi (Incubating)[7]來構建 Serverless Spark/SQL 服務。大部分情況下，用戶都可以直接使用 BI 工具或者 SQL 來直接操作數據即可。

一般而言，大部分企業都會有很多離線的 Hive 或者 Spark 任務跑在 YARN 集群上，如何將大量的歷史任務平滑地遷移到 Kubernetes 上也是讓人頭疼的問題。Kyuubi 的服務化方案，可以通過服務發現機制，提供負載均衡節點，在服務高可用的基礎上，來平滑地過渡。對於個別異常遷移任務，我們也可以方便地 Rollback 到 老集群上保障執行，也留給我們定位問題的時間和空間。

從原理上，無論是 Kubernetes 和 YARN 都只起資源調度的作用，不涉及計算模型和任務調度的變化，所以在性能上的差異應該是不顯著的。從部署架構上，Spark on Kubernetes 一般選擇存算分離的架構，而 YARN 集群一般和 HDFS 耦合在一起，前者會F在讀寫 HDFS 時喪失「數據本地性」，這個由於網絡帶寬因素影響可能會影響性能。從存算耦合架構誕生之初經過 10 年左右的發展，隨着網絡的性能增長，各種高效的列式存儲格式及壓縮算法的加持，這點影響微乎其微。

Terasort 基準測試 (By Myself)

TPC-DS 基準測試（By Data mechanics）

TPC-DS 基準測試（By AWS）

雖然這些測試結果都不是來自 TPC-DS 組織認證的官方數據，但從測試結果來自不同的機構這個因素上也有足夠的說服力。我們屏蔽一些部署架構上的影響，兩者的性能差距可以說是基本不存在的。

將 Spark 作業遷移至 Kubernetes 集群上，可以實現離線和在線業務的混合部署，利用兩種業務特徵的對計算資源潮汐錯峰效應，極致的情況下光靠「離 / 在混部」就可實現 IT 總有用成本（TCO）的 50% 的節省。

另一方面，企業數據平台在不同的發展時期，集群所規劃的存儲算力比不同，導致服務器選型困難，而從存算分離的的角度，計算集群和存儲集群分開擴容，也可以更加合理地控制 IT 成本。

此外，Spark on Kubernetes 通過 Pod 分配 Executor 模式，執行線程數（spark.executor.cores）和 Pod 的 request cpu 是分離的，可以更加細粒度的在作業級別對控制，來提升計算資源的使用效率。在我們網易的實際實踐中，在不影響整體計算性能的條件下，Spark on Kubernetes 作業整體上 cpu 可以達到超 200% 的超售比。

當然，Spark on Kubernetes 在動態資源分配（Dynamic Resource Allocation）這個特性上的缺失或者不完善，可能會造成 Spark 占着資源不使用的情況。由於這個特性直接依賴外置的 Shuffle Service 服務來實現，這時候可能就需要自行去搭建 Remote/External Shuffle Service 服務。

在 Spark on Kubernetes 場景下，基於 RSS/ESS 可實現臨時存儲與計算過程相互解耦。第一，消除本地存儲依賴，使得計算節點可在異構節點上動態伸縮，在面對複雜物理或者虛擬環境時更加靈活的動態擴展。第二，離散式本地存儲優化為集中式服務化存儲，存儲容量所有計算節點共享，提高存儲資源利用率。第三，降低磁盤故障率，動態地減少標記為不可用計算節點，提升計算集群整體資源利用率。最後，轉移臨時存儲的血緣關係，使其不再由 Executor Pod 計算節點維護，使得閒置 Executor Pod 可以被及時地釋放回資源池，提升集群資源利用率。

Spark on Kubernetes 自 2018 年初隨 2.3.0 版本發布以來，不知不覺已經有四個年頭了，而到現在的 3.2 版本，也已經歷經 5 個大版本了。在社區和用戶的不斷打磨下已經成為了非常成熟的特性了。

隨着 Apache Spark 開源生態不斷發展，如 Apache Kyuubi 等，無論是哪個調度框架，易用性上都得到大幅提升。

IT 基礎設施的總擁有成本（Total Cost of Ownership, TCO） 逐年上漲，一直是困擾很多企業的難題。Spark + Kubernetes 的組合的靈活性和超高性價比，給了我們更多想象的空間。

作者介紹：

Kent Yao，網易數帆技術專家，Apache Kyuubi(Incubating) PPMC，Apache Spark Committer

參考資料：

[1]https://issues.apache.org/jira/browse/SPARK-18278[2]https://issues.apache.org/jira/browse/SPARK-33005[3]https://www.youtube.com/watch?v=xX2z8ndp_zg[4]https://www.youtube.com/watch?v=hcGdW_6xTKo[5]https://ieeexplore.ieee.org/document/9384578[6]https://github.com/GoogleCloudPlatform/spark-on-k8s-operator[7]https://github.com/apache/incubator-kyuubi[8]https://aws.amazon.com/cn/blogs/containers/optimizing-spark-performance-on-kubernetes/

點個在看少個 bug👇