如何實現Spark on Kubernetes？

簡介： 大數據時代，以Oracle爲表明的數據庫中間件已經逐漸沒法適應企業數字化轉型的需求，Spark將會是比較好的大數據批處理引擎。而隨着Kubernetes愈來愈火，不少數字化企業已經把在線業務搬到了Kubernetes之上，並但願在此之上建設一套統一的、完整的大數據基礎架構。那麼Spark on Kubernetes面臨哪些挑戰？又該如何解決？

雲原生背景介紹與思考

「數據湖」正在被愈來愈多人提起，儘管定義並不統一，但企業已紛紛投入實踐，不管是在雲上自建仍是使用雲產品。

阿里雲大數據團隊認爲：數據湖是大數據和AI時代融合存儲和計算的全新體系。爲何這麼說？在數據量爆發式增加的今天，數字化轉型成爲IT行業的熱點，數據須要更深度的價值挖掘，所以確保數據中保留的原始信息不丟失，應對將來不斷變化的需求。當前以Oracle爲表明的數據庫中間件已經逐漸沒法適應這樣的需求，因而業界也不斷地產生新的計算引擎，以便應對大數據時代的到來。企業開始紛紛自建開源Hadoop數據湖架構，原始數據統一存放在對象存儲OSS或HDFS系統上，引擎以Hadoop和Spark開源生態爲主，存儲和計算一體。

圖1是基於ECS底座的EMR架構，這是一套很是完整的開源大數據生態，也是近10年來每一個數字化企業必不可少的開源大數據解決方案。

主要分爲如下幾層：

• ECS物理資源層，也就是Iaas層。
• 數據接入層，例如實時的Kafka，離線的Sqoop。
• 存儲層，包括HDFS和OSS，以及EMR自研的緩存加速JindoFS。
• 計算引擎層，包括熟知的Spark，Presto、Flink等這些計算引擎。
• 數據應用層，如阿里自研的Dataworks、PAI以及開源的Zeppelin，Jupyter。

每一層都有比較多的開源組件與之對應，這些層級組成了最經典的大數據解決方案，也就是EMR的架構。咱們對此有如下思考：

• 是否可以作到更好用的彈性，也就是客戶能夠徹底按照本身業務實際的峯值和低谷進行彈性擴容和縮容，保證速度足夠快，資源足夠充足。
• 不考慮現有情況，看將來幾年的發展方向，是否還須要支持全部的計算引擎和存儲引擎。這個問題也很是實際，一方面是客戶是否有能力維護這麼多的引擎，另外一方面是某些場景下是否用一種通用的引擎便可解決全部問題。舉個例子來講，Hive和Mapreduce，誠然現有的一些客戶還在用Hive on Mapreduce，並且規模也確實不小，可是將來Spark會是一個很好的替代品。
• 存儲與計算分離架構，這是公認的將來大方向，存算分離提供了獨立的擴展性，客戶能夠作到數據入湖，計算引擎按需擴容，這樣的解耦方式會獲得更高的性價比。

基於以上這些思考，咱們考慮一下雲原生的這個概念，雲原生比較有前景的實現就是Kubernetes，因此有時候咱們一提到雲原生，幾乎就等價因而Kubernetes。隨着Kubernetes的概念愈來愈火，客戶也對該技術充滿了興趣，不少客戶已經把在線的業務搬到了Kubernetes之上，而且但願在這種相似操做系統上，建設一套統一的、完整的大數據基礎架構。因此咱們總結爲如下幾個特徵：

但願可以基於Kubernetes來包容在線服務、大數據、AI等基礎架構，作到運維體系統一化。

存算分離架構，這個是大數據引擎能夠在Kubernetes部署的前提，將來的趨勢也都在向這個方向走。

經過Kubernetes的天生隔離特性，更好的實現離線與在線混部，達到降本增效目的。

Kubernetes生態提供了很是豐富的工具，咱們能夠省去不少時間搞基礎運維工做，從而能夠專心來作業務。

EMR計算引擎 on ACK

圖2是EMR計算引擎 on ACK的架構。ACK就是阿里雲版本的Kubernetes，在兼容社區版本的API同時，作了大量的優化。在本文中不會區分ACK和Kubernetes這兩個詞，能夠認爲表明同一個概念。

基於最開始的討論，咱們認爲比較有但願的大數據批處理引擎是Spark和Presto，固然咱們也會隨着版本迭代逐步的加入一些比較有前景的引擎。

EMR計算引擎提供以Kubernetes爲底座的產品形態，本質上來講是基於CRD+Operator的組合，這也是雲原生最基本的哲學。咱們針對組件進行分類，分爲service組件和批處理組件，好比Hive Metastore就是service組件，Spark就是批處理組件。

圖中綠色部分是各類Operator，技術層面在開源的基礎上進行了多方面的改進，產品層面針對ACK底座進行了各方面的兼容，可以保證用戶在集羣中很方便的進行管控操做。右邊的部分，包括Log、監控、數據開發、ECM管控等組件，這裏主要是集成了阿里雲的一些基礎設施。咱們再來看下邊的部分：

• 引入了JindoFS做爲OSS緩存加速層，作計算與存儲分離的架構。
• 打通了現有EMR集羣的HDFS，方便客戶利用已有的EMR集羣數據。
• 引入Shuffle Service來作Shuffle 數據的解耦，這也是EMR容器化區別於開源方案的比較大的亮點，以後會重點講到。

這裏明確一下，因爲自己Presto是無狀態的MPP架構，在ACK中部署是相對容易的事情，本文主要討論Spark on ACK的解決方案。

Spark on Kubernetes的挑戰

總體看，Spark on Kubernetes面臨如下問題：

• 我我的認爲最重要的，就是Shuffle的流程，按照目前的Shuffle方式，咱們是沒辦法打開動態資源特性的。並且還須要掛載雲盤，雲盤面臨着Shuffle數據量的問題，掛的比較大會很浪費，掛的比較小又支持不了Shuffle Heavy的任務。
• 調度和隊列管理問題，調度性能的衡量指標是，要確保當大量做業同時啓動時，不該該有性能瓶頸。做業隊列這一律唸對於大數據領域的同窗應該很是熟悉，他提供了一種管理資源的視圖，有助於咱們在隊列之間控制資源和共享資源。
• 讀寫數據湖相比較HDFS，在大量的Rename，List等場景下性能會有所降低，同時OSS帶寬也是一個不可避免的問題。

針對以上問題，咱們分別來看下解決方案。

Spark on Kubernetes的解決方案

Remote Shuffle Service架構

Spark Shuffle的問題，咱們設計了Shuffle 讀寫分離架構，稱爲Remote Shuffle Service。首先探討一下爲何Kubernetes不但願掛盤呢，咱們看一下可能的選項：

• 若是用是Docker的文件系統，問題是顯而易見的，由於性能慢不說，容量也是極其有限，對於Shuffle過程是十分不友好的。
• 若是用Hostpath，熟悉Spark的同窗應該知道，是不可以啓動動態資源特性的，這個對於Spark資源是一個很大的浪費，並且若是考慮到後續遷移到Serverless K8s，那麼從架構上自己就是不支持Hostpath的。
• 若是是Executor掛雲盤的PV，一樣道理，也是不支持動態資源的，並且須要提早知道每一個Executor的Shuffle數據量，掛的大比較浪費空間，掛的小Shuffle數據又不必定可以容納下。

因此Remote Shuffle架構針對這一痛點、對現有的Shuffle機制有比較大的優化，圖3中間有很是多的控制流，咱們不作具體的討論。主要來看數據流，對於Executor全部的Mapper和Reducer，也就是圖中的藍色部分是跑在了K8s容器裏，中間的架構是Remote Shuffle Service，藍色部分的Mapper將Shuffle數據遠程寫入service裏邊，消除了Executor的Task對於本地磁盤的依賴。Shuffle Service會對來自不一樣Mapper的同一partition的數據進行merge操做，而後寫入到分佈式文件系統中。等到Reduce階段，Reducer經過讀取順序的文件，能夠很好地提高性能。這套系統最主要的實現難點就是控制流的設計，還有各方面的容錯，數據去重，元數據管理等等工做。

簡而言之，咱們總結爲如下3點：

• Shuffle數據經過網絡寫出，中間數據計算與存儲分離架構
• DFS 2副本，消除Fetch Failed引發的重算，Shuffle Heavy做業更加穩定
• Reduce階段順序讀磁盤，避免現有版本的隨機IO，大幅提高性能

Remote Shuffle Service性能

咱們在這裏展現一下關於性能的成績，圖4和圖5是Terasort Benchmark。之因此選取Terasrot這種workload來測試，是由於它只有3個stage，並且是一個大Shuffle的任務，你們能夠很是有體感的看出關於Shuffle性能的變化。

圖4中，藍色部分是Shuffle Service版本的運行時間，橙色部分是原版Shuffle的運行時間。咱們測試了2T，4T，10T的數據，能夠觀察到隨着數據量愈來愈大，Shuffle Service優點就愈來愈明顯。圖5紅框部分說明了做業的性能提高主要體如今Reduce階段，可見10T的Reduce Read從1.6小時降低到了1小時。緣由前邊已經解釋的很清楚了，熟悉Spark shuffle機制的同窗知道，原版的sort shuffle是M*N次的隨機IO，在這個例子中，M是12000，N是8000，而Remote Shuffle就只有N次順序IO，這個例子中是8000次，因此這是提高性能的根本所在。

圖4 Remote Shuffle Service性能

圖5 Terasort做業的stage圖

其餘方面的重點優化

這裏講一下EMR在其餘方面作的優化。

調度性能優化，咱們解決了開源的Spark Operator的一些不足，對於Executor pod的不少配置Spark Operator把他作到了Webhook裏邊，這個對調度來講是十分不友好的，由於至關於在API Server上繞了一圈，實際測試下來性能損耗很大。咱們把這些工做直接作到Spark內核裏邊，這樣避免了這方面的調度性能瓶頸。而後從調度器層面上，咱們保留了兩種選擇給客戶，包括ACK提供的Scheduler FrameworkV2實現方式和Yunicorn實現方式。

讀寫OSS性能優化，咱們這裏引入了JindoFS做爲緩存，解決帶寬問題，同時EMR爲OSS場景提供了Jindo Job Committer，專門優化了job commit的過程，大大減小了Rename和List等耗時操做。

針對Spark自己，EMR積累了多年的技術優點，也在TPCDS官方測試中，取得了很好的成績，包括Spark性能、穩定性，還有Delta lake的優化也都有集成進來。

咱們提供了一站式的管控，包括Notebook做業開發，監控日誌報警等服務，還繼承了NameSpace的ResourceQuota等等。

整體來講，EMR版本的Spark on ACK，不管在架構上、性能上、穩定性上、易用性方面都有着很大的提高。

Spark雲原生後續展望

從個人視角來觀察，Spark雲原生容器化後續的方向，一方面是達到運維一體化，另外一方面主要但願作到更好的性價比。咱們總結爲如下幾點：

• 能夠將Kubernetes計算資源分爲固定集羣和Serverless集羣的混合架構，固定集羣主要是一些包年包月、資源使用率很高的集羣，Serverless是作到按需彈性。
• 能夠經過調度算法，靈活的把一些SLA不高的任務調度到Spot實例上，就是支持搶佔式ECI容器，這樣能夠進一步下降成本。
• 因爲提供了Remote Shuffle Service集羣，充分讓Spark在架構上解耦本地盤，只要Executor空閒就能夠銷燬。配合上OSS提供的存算分離，一定是後續的主流方向。
• 對於調度能力，這方面須要特別的加強，作到可以讓客戶感覺不到性能瓶頸，短期內調度起來大量的做業。同時對於做業隊列管理方面，但願作到更強的資源控制和資源共享。

隨着阿里雲2.0時代的到來，雲原生已經逐漸成爲新的主角，愈來愈多的企業將會享受到雲原生所帶來的紅利。數據湖計算引擎雲原生容器化，可以極大地方便客戶上雲，提高性價比。可是總體上來說：大數據雲原生的落地是十分具備挑戰性的，阿里雲EMR團隊會和社區同伴、合做夥伴一塊兒打造技術和生態，共同打造「存算分離，按需擴展」、「極致彈性，隨用隨得」、「運維閉環，高性價比」的願景。