如上文
Apache Spark on ACK介紹，Spark on Kubernetes能給我們帶來諸多優點，但社群版的解決方案還不是那麼完善，存在以下幾個關鍵問題：
- Shuffle流程，按照目前的Shuffle方式，我們是沒辦法打開動态資源特性的。而且還需要挂載雲盤，雲盤面臨着Shuffle資料量的問題，挂的比較大會很浪費，挂的比較小又支援不了Shuffle Heavy的任務。
- 排程和隊列管理問題，排程性能的衡量名額是，要確定當大量作業同時啟動時，不應該有性能瓶頸。作業隊列這一概念對于大資料領域的同學來說應該非常熟悉，他提供了一種管理資源的視圖，有助于我們在隊列之間控制資源和共享資源。
- 讀寫資料湖相比較HDFS，在大量的rename，list等場景下性能會有所下降，同時OSS帶寬也是一個不可避免的問題。
為了讓在ACK上更好的運作Spark工作負載，阿裡雲EMR和ACK團隊做了大量優化工作，在架構、性能、穩定性、易用性方面都有着很大的提升。
EMR Spark on ACK解決方案
EMR Spark
EMR Spark是運作在阿裡雲平台上的大資料處了解決方案，在開源版Apache Spark的基礎上做了大量性能、功能以及穩定性方面的改造，并且在和阿裡雲基礎服務的适配上做了非常多的工作。主要有以下核心技術：
- 實作SparkSQL事務功能，支援update、delete語句。
- 實作PK、FK、NOT NULL等SQL Constraint，并應用在SQL優化中。
- 實作Relational Cache：SparkSQL的物化視圖。
- 實作多租戶高可用的SparkSQL JDBC Server。
- SparkSQL部分性能優化清單：
-
- 支援Runtime Filter。
- 使用Adaptive Execution，可在運作時調整作業行為。
- CBO Join Reorder進一步優化，支援遺傳算法。
- Shuffle流程優化，建構異步非阻塞的Shuffle IO。
Remote Shuffle Service
Spark on kubernetes時會面臨shuffle的問題，按照目前的shuffle方式，是沒辦法打開動态資源特性的。而且還需要挂載雲盤，面臨着shuffle資料量的問題，挂的大會很浪費，挂的小又支援不了shuffle heavy的任務。針對這個問題，我們設計了shuffle讀寫分離的架構，稱為Remote Shuffle Service，對現有的shuffle機制做了比較大的優化，解決了計算存儲分離和混合架構下的shuffle穩定性和性能問題。可以總結為以下3點：
- Shuffle資料通過網絡寫出，中間資料計算與存儲分離架構。
- DFS 2副本，消除fetch failed引起的重算，shuffle heavy作業更加穩定。
- Reduce階段順序讀磁盤，避免現有版本的随機IO，大幅提升性能。
JindoFS
計算存儲分離已經成為雲計算的一種發展趨勢。在計算存儲分離之前，普遍采用的是傳統的計算存儲互相融合的架構，但是這種架構存在一定的問題，比如在叢集擴容的時候會面臨計算能力和存儲能力互相不比對的問題。使用者在某些情況下隻需要擴容計算能力或者存儲能力，而傳統的融合架構不能滿足使用者的這種需求，進行單獨的擴充計算或者存儲能力；其次在縮容的時候可能會遇到人工幹預，人工幹預完後需要保證資料在多個節點中同步，而當有多個副本需要同步時候，可能會造成的資料丢失。計算存儲分離架構則可以很好的解決這些問題，使得使用者隻需要關心整個叢集的計算能力，但同時也會引入讀寫資料網絡延遲的問題。
JindoFS是一種雲原生的檔案系統，結合OSS和本地存儲，成為EMR産品的新一代存儲系統，為上層計算提供了高效可靠的存儲。JindoFS 提供了塊存儲模式（Block）和緩存模式（Cache）的存儲模式， 采用了本地存儲和OSS的異構多備份機制，Storage Service提供了資料存儲能力，首先使用OSS作為存儲後端，保證資料的高可靠性，同時利用本地存儲實作備援備份，利用本地的備份，可以加速資料讀取，解決了網絡延遲的問題；另外，JindoFS的中繼資料通過本地服務Namespace Service管理，進而保證了中繼資料操作的性能（和HDFS中繼資料操作性能相似）。
性能評測
為了驗證EMR Spark在ACK上的性能，我們通過TPC-DS進行對比評測。TPC-DS測試基準是TPC組織推出的一個決策支援系統測試基準，TPC-DS采用星型、雪花型等多元資料模式。它包含7張事實表，17張緯度表平均每張表含有18列。其工作負載包含99個SQL查詢，覆寫SQL99和2003的核心部分以及OLAP。這個測試集包含對大資料集的統計、報表生成、聯機查詢、資料挖掘等複雜應用，測試用的資料和值是有傾斜的，與真實資料一緻。可以說TPC-DS是與真實場景非常接近的一個測試集，也是難度較大的一個測試集。
測試環境
首先準備測試環境，在ACK上建立一個标準版叢集或标準專有叢集，安裝依賴的元件。
叢集配置
ACK叢集說明
| 參數 | |
|---|---|
| 叢集類型 | ACK标準叢集 |
| 叢集版本 | 1.16.9-aliyun.1 |
| ECS執行個體 | ECS規格：ecs.d1ne.6xlarge作業系統：CentOS 7.7 64位CPU: 24核記憶體：96G資料盤：5500GB HDD x 12 |
| Worker Node個數 | 20 |
ecs.d1ne.6xlarge 大資料機型，預設帶了12塊5500GB的HDD資料盤，需要mount一下才能使用。
元件配置
ack-spark-operator
在ACK應用目錄中安裝，用來送出SparkApplicaiton作業。
ack-spark-history-server （非必要）
在ACK應用目錄中安裝，記錄Spark執行任務過程中的event-log，并提供UI界面，友善排查問題。
在ACK應用目錄中安裝，用來實作資料的分布式緩存加速。
在社群版Apache Spark深度優化的版本。
Shuflle讀寫分離架構。
注意：EMR Spark 和 Remote Shuffle Service 可通過文章結尾處的釘釘群聯系我們擷取安裝方式。
測試資料
基于TPC-DS生成的1TB和10TB測試資料，生成資料的情況可參考
TPC-DS生成資料。
測試結果
1. EMR Spark vs Apache Spark
測試資料：10TB
縱軸機關：秒
在10TB資料上測試，EMR Spark相比社群版本Spark約有57%的性能提升，詳細測試過程參考
使用EMR Spark運作Spark工作負載2. EMR Spark vs EMR Spark + EMR Shuffle Service
在10TB資料上，增加Remote Shuffle Service後，相比直接使用EMR Spark，約有16%的性能提升。詳細測試過程請參考
使用EMR Spark + Remote Shuffle Service運作Spark工作負載3. EMR Spark vs EMR Spark + JindoFS
測試資料：1TB
在1TB資料上，使用JindoFS做資料分布式緩存後，相比直接使用EMR Spark，得到約15%性能提升。詳細測試過程請參考
使用EMR Spark + JindoFS運作Spark工作負載測試總結
通過上面幾組對比可以看到，EMR Spark相比社群版Spark有大幅度的性能提升，而通過Remote Shuffle Service和JindoFS也分别解決了存儲計算分離架構帶來的Shuffle和資料本地化問題。另外，需要說明的是Remote Shuffle Service和JindoFS在比較适用于資料量大的場景，使用者可以根據自己的需要靈活組合使用。
展望
對于Spark on ACK的後續發展，我們一方面是要達到運維一體化，另一方面主要希望做到更好的成本效益，主要有以下幾點工作：
- 可以将k8s計算資源分為固定叢集和Serverless叢集的混合架構，固定叢集主要是一些包年包月、資源使用率很高的叢集，Serverless是做到按需彈性。
- 可以通過排程算法，靈活的把一些SLA不高的任務排程到Spot執行個體上，就是支援搶占式ECI容器，這樣可以進一步降低成本。
- 由于提供了Remote Shuffle Service叢集，充分讓Spark在架構上解耦本地盤，隻要Executor空閑就可以銷毀。配合上OSS提供的存算分離，必定是後續的主流方向。
- 對于排程能力，這方面需要特别的增強，做到能夠讓客戶感受不到性能瓶頸，短時間内排程起來大量的作業。同時對于作業隊列管理方面，希望做到更強的資源控制和資源共享。
歡迎加入釘釘群溝通交流。