【摘要】 Spark社區在2.3版本開始，已經可以很好的支持跑着Kubernetes上了。這樣對於統一資源池，提高整體資源利用率，降低運維成本（特別是技術棧歸一）有着非常大的幫助。這些趨勢是一個大數據人不得不重視的信號，所以提前開始了解並考慮起來吧:-)
1 大數據邂逅雲計算
相信玩Spark的你已經注意到最新的Spark版本已經支持不做任何修改可以直接跑在K8S上了，即以kubernetes容器集群作為Cluster Manager的實現。其實早在2017年底Spark 2.2版本開始的時候，Spark社區就開始合入用k8s管理spark集群的能力了，只是那時候功能上還沒有很完善。另外那個時候Kubernetes還沒有像現在這么普及，被廣泛地接受成為應用基礎設施層。經過了2年了持續迭代，Spark on Kubernetes已經成為帥氣的小伙，大家可以圍觀起來了。
其實，大數據和雲計算一直分屬兩個不同的領域，大數據主要關注怎么將數據集中起來，挖掘數據的價值。雲計算主要關注怎么更高效地使用資源，提升資源的利用效率。當大數據發展到一定階段的時候，它就會和雲計算不期而遇。
2 現狀並不美麗
在技術層面上，當前的大數據計算如Hadoop和Spark將計算和存儲結合在一起的模式，是分布式架構構建的一種嘗試。但是當社區修改HDFS以支持Hadoop 3.0的ErasureCode（糾刪碼）時，即接受了：不(Wu)再(Fa)支持就近讀取的策略。它就代表了一種新趨勢。數據層面，為取代 HDFS，可以用大規模的基於雲的對象存儲，構建在 AWS S3 模型上。計算層面，要能夠根據需要啟動計算，也可以考慮使用類似 Kubernetes 的虛擬化技術，而不是綁定 YARN。
曾經，數據處理任務從遠程物理機讀取數據開銷大。以數據為“中心”，將數據處理任務遷移到數據所在的物理機上，能有效降低網絡帶寬，保證了整體性能。這就是存算一體的大數據技術架構。經過十多年的發展，網絡性能已經提升了100倍，內存容量也提升了數十倍。大數據處理的瓶頸逐漸從網絡轉移到CPU上，上述存算一體架構的缺點也逐漸突顯出來。
（1）不同場景需要的存儲空間和算力配比是不一樣的。實際使用中要么計算資源達到瓶頸，要么是存儲容量不足，只能對集群進行剛性擴容，造成集群資源浪費。（2）不同時期需要的算力是不固定的，存在波峰和波谷。物理機中存儲數據造成無法大規模關閉閑置節點，造成算力閑置和能源浪費。（3）不同業務對運行環境需求不一樣。Spark應用需要綁定Spark集群運行。Web類型需要實例快速水平擴展。所以通過統一平台來混合部署提升資源利用率的需求強烈。
容器技術的出現，給了IT行業統一運行環境一線希望。它以自己的build once，run every where的旗幟揮舞到各個IT行業。可以說如果還不考慮使用容器技術，你的基礎平台的靈活性是絕對不夠的。
3 統一的ABC平台
當前大數據的實現代表了構建分布式系統的一種方法：計算和存儲以及基礎架構結合在一起。但是這條路是否暢通也不好說，畢竟近期有好多文章在說大數據已死。不過話說回來，大數據的數據量是越來越大，大數據的業務需求也只增不減，只是在實現大數據需求的途徑上，方向發生了些偏移。所以並不是大數據本身已死，而是原來的大數據框架底層設施有了新的方向，雲原生大數據已經嶄露頭角。
所謂的ABC就是指AI + Bigdata + Cloud，一般由於業務部門的划分，或者歷史遺留，各廠家做法普遍都是不同的研發部門維護不同的資源池。這就帶來了計算、存儲資源不均衡，資源調度最佳利用率和基礎設施能力共享的問題。特別的基礎設施技術不需要維護多套，降低研發人力成本。
如果想提高整體資源利用率，那就得有統一infrastructure平台。而且，不同業務類型對資源述求不一樣，比如AI以GPU為主，Web業務以CPU為主等。所以要求基礎設施平台，必須能夠支持多種計算資源，統一調度能力。並且業務也得有統一的運行環境的標准，保證開發&生產的運行一致性。
很明顯，以Docker+Kubernetes技術打造雲原生計算平台具備這樣的氣質。特別是，以Docker的普適性，真的在各領域勢如破竹。中國聯通數據中心總經理王志軍在2019年6月分享的《中國聯通容器化大數據平台的探索與實踐》中，提到各省公司的AI訓練，大數據，容器化應用都統一在以Kubernetes+Docker為底座的統一平台上，目前擁有節點437個，大量任務同時跑在該平台上。也是這一趨勢的實踐。
4 Kubernetes as Infrastructure
大數據領域，計算資源會越來越多容器化。以前容器化主要是被 DevOps和微服務所使用，最近隨着大數據應用的依賴越來越復雜，需要用容器化做更好的依賴管理和資源隔離。容器的一次構建，隨處可運行的特點，非常契合應用運行環境的一致性述求。
大規模容器集群管理，現在Kubernetes已經是無可爭議的事實標准。作為Mesos商業化的重要推手，Mesosphere 在2019年8月宣布正式更名為 D2IQ，關注點也隨即轉向 Kubernetes 及雲原生領域。VMware則在VMworld 2019宣布推出新的產品和服務品牌VMware Tanza，全面擁抱K8s。各個領域也是遍地開花，基因數據分析，高性能計算HPC，AI機器學習，傳統互聯網紛紛擁抱容器技術，無不選擇K8s作為容器計算平台。真的是踐行了Docker誕生時的理念，不僅僅是build once，而且真的是run every where。現在已經到處都是容器了，該輪到大數據了，幸運的是Spark社區已經上車了，那么你呢？ spakr on k8s可以有。
5 Volcano（增強型K8S資源調度器）
K8S自帶的的資源調度器，有一個明顯的特點是，依次調度每個容器。但是當AI訓練，大數據計算，這樣必須多個容器同時配合執行的情況下。依次調度是無法滿足需要的。因為這些計算任務包含的容器們想要的是，要么同時都成功，要么就都別執行。
比如，某個大數據應用需要跑1個Driver容器+10個Executor容器。如果容器是一個一個的調度，假設在啟動最后一個executor容器時，由於資源不足而調度失敗無法啟動。那么前面的9個executor容器雖然運行着，其實也是浪費的。AI訓練也是一樣的道理，必須所有的Worker都同時運行，才能進行訓練，壞一個，其他的容器就等於白跑。要知道GPU被容器霸占着卻不能開始計算，成本是非常高的。
所以當你的（1）總體資源需求<集群資源的時候，普通的K8S自帶調度器可以跑，沒問題。但是當（2）總體資源需求>集群資源的時候，K8S自帶調度器會因為隨機依次調度容器，使得部分容器無法調度，從而導致業務占着資源又不能開始計算，死鎖着浪費資源。那么場景（1）和場景（2）誰說常態呢？不用想，肯定是（2）了，誰能大方到一直讓集群空着呢對吧。這個時候就必須需要增強型的K8s資源調度器Volcano了。
Volcano首先要解決的問題就是Gang Scheduling的問題，即一組容器要么都成功，要么都別調度。這個是最基本的用來解決資源死鎖的問題，可以很好的提高資源利用率。除此之外，它還提供了多種調度算法，例如priority優先級，DRF（dominant resource fairness）， binpack，task-topology親和，GPU感知，batchwisepack等。多種調度算法插件，根據權重條件，就可以很好的滿足各種復雜場景需求。真正做到統一資源平台，最佳資源利用率。
6 結束語
統一的資源池，統一的計算平台，統一的基礎設施技術棧，這樣資源利用和人力成本都是最優的，可以聚焦到業務創新方向。那么所有的技術都已經ready了，時候讓你的Spark跑在K8S上了。