作者：邵賽賽
轉載自公衆号：資料湖技術
原文連結：
https://mp.weixin.qq.com/s/dgLrh2GqnMu1rRqYpCtjoA前言
在ABC (AI, BigData, Cloud)時代，傳統的大資料解決方案和廠商 (Cloudera, Hortonworks) 略顯頹勢，而雲廠商 (AWS, Azure, GCP) 和雲原生解決方案 (Databricks Cloud, Snowflake, ElasticSearch等) 則愈加迸發出活力。在這個雲原生的時代擁抱雲變成了不二之選，那麼對于Spark[1]來說它是如何在雲原生時代積極擁抱雲的呢？
背景
10多年前，Google的3篇論文拉開了大資料時代的大幕，這3篇論文不僅從理論上詳盡地闡述了分布式大資料的經典算法，更從工程上解決了普通商業硬體的分布式架構之道，同時也定義了未來多年内的普通商業硬體，尤其是大資料伺服器的設計架構。
當時一台典型的大資料伺服器通常包括一路或兩路CPU，核數從十幾核到幾十核不等 (Hyper Threading)；幾十G的記憶體；多塊SATA或SAS HDD硬碟。
受限于當時硬體的能力，軟體上的設計需要考慮到硬體的行為進而能更好地利用到硬體的性能：
•移動代碼而非移動資料：MapReduce架構在實作時非常強調的一點是移動代碼而非移動資料，因為代碼的大小相比于資料是小很多的，在網絡帶寬較小的時代移動資料會帶來巨大的開銷，相反将代碼放到資料所在節點去執行能帶來顯著的提升。
•資料和計算共存：正是由于移動代碼而非移動資料的設計思路而形成了資料和計算共存的架構。一個典型的Hadoop叢集通常會把資料叢集HDFS和計算叢集MapReduce (YARN) 部署在一起提高資料本地性 (Data Locality)。
•帶寬優先設計：大資料應用由于處理的資料量巨大通常需要較長的處理時間，在這樣的前提下在MapReduce設計之初就有了這樣一條假設：大資料任務通常對于響應的要求較低。是以在MapReduce設計中無論是任務分發還是資料傳輸優先考慮的是帶寬而非延遲。
•充分利用多盤優勢，避免随機讀寫：HDD由于機械結構的限制其順序讀寫的吞吐量一般在100~200MB左右，而随機讀寫的性能則會更差。相較于CPU的處理能力有量級的差距。為了比對速度差，通常會使用多塊HDD磁盤來并行化和分散IO，提高整體IO吞吐量。同時在IO設計的時候也會盡量把随機IO轉換成順序IO以提高吞吐量 (Sort based shuffle write/read就是一個典型的例子)。
當然還有其他許多的優化考量點不在這羅列了。重要的是在這10多年間，從軟體架構到硬體性能，從伺服器設計到資料中心架構都有了巨大的變化，這其中包括：
•容器化。随着docker的誕生，容器化技術在背景服務領域迅速推廣開來，容器化不僅能帶來devops的便捷性，同時也能更好地隔離資源。而Kubernetes的誕生，則将容器化應用和容器化排程推到了一個新的高度。
•存儲計算分離。随着網絡帶寬的提升和異構叢集技術的發展，存儲計算分離被再度提出了，尤其是在公有雲上存儲計算分離已成為常态，如何更好地适應存儲計算分離變得尤為重要。
•更快的儲存設備。更快的儲存設備近些年來不斷推出，如SSD，PMEM等，這些新的儲存設備不僅有更高的速率，而且大大優化了随機讀寫的性能。
•顯著提升的網絡帶寬。近10年中網絡帶寬得到了顯著的提升，從最早的1Gbps，到現在主流的10Gbps，25Gbps乃至40Gbps，100Gbps。同時RDMA，DPDK的應用也越來越廣泛。
這樣的變化對于現有的大資料軟體架構帶來了極大的挑戰，原先的設計在新的硬體和架構中變得不再有意義：
1.存儲計算分離使得我們所恪守的資料本地性不再有意義，所有的資料不再是本地的了，更快的網絡抹平了本地性帶來的優勢。
2.更高的網絡帶寬和更低的延遲使得我們不必再以帶寬優先來設計網絡傳輸，更低的延遲變得更有意義。
3.更快的儲存設備，更好的随機讀寫性能使得我們所做的對于順序讀寫的優化 (歸并排序) 變成了額外的負擔。
是以面向新的硬體和架構，面向雲原生的時代，大資料軟體的設計必須進行相應的調整和優化以發揮更好的性能。Spark作為目前最為主流的分布式計算架構，它又是如何在雲原生時代做出相應的改變的呢？
Spark演化的方向
容器化
容器化由于其優異的devops能力、資源隔離、統一排程等特性，在微服務和背景架構中有廣泛的應用，但是在大資料、Hadoop領域容器化卻沒有廣泛的采用，這其中制約大資料容器化的問題主要有哪些呢？
1.容器化排程和大資料應用所恪守的資料本地性相背離，會帶來一定的性能問題。
2.大資料應用對于系統性能、尤其是IO性能要求較高，而容器化有一定的性能開銷。
3.更為重要的是大資料系統架構之時容器化技術、容器化排程尚未興起，在融入容器化技術中需要與原有架構做較大的調整。
當然容器化技術的排程也是日新月異的，上面所列的問題在新的版本中可能已不複存在。既然有這樣那樣的問題，那為什麼大資料還需要容器化呢？
•首先在企業devops流程中，docker技術已是事實上的标準，同時前後端技術也已經全面docker化了，統一企業devops流程，将大資料應用docker化是一個自然的過程。
•其次容器化排程架構Kubernetes已成為企業資料中心統一的DCOS，所有的前背景部署都使用k8s統一進行排程。但大資料存儲和計算遊離在容器化排程之外，額外部署管理增加了管理負擔和資源開銷。
•容器化技術所提供的資源隔離對于大資料應用來說有很大的意義。大資料應用通常對于資源的需求是激進的，如果沒有很好的資源管理和隔離機制，會造成應用的互相影響，降低應用的穩定性，是以有效的資源隔離是非常必要的。
在這樣的背景下，容器化并支援容器化排程是現有大資料元件的趨勢之一。Spark在其設計之初将與資源管理架構的互動抽象化，并支援多種資源管理架構，如YARN，Mesos等。而從2.3版本開始官方适配了k8s，能夠以容器化的方式啟動Spark應用程式并排程executor。Spark on Kubernetes的主要架構如下所示：
在後續的版本中，Spark on Kubernetes也逐漸補齊了與其他資源管理架構支援上的差異，并預期在Spark 3.0中将其GA。相信随着Spark on Kubernetes的成熟，大資料容器化技術的進化，使用容器化會是不二之選。
存儲計算分離
在前面的背景中也提到了由于網絡帶寬的增加和異構叢集的流行，存儲計算分離再度流行，尤其是在雲上環境，塊存儲 (Blob Storage)、雲盤已經成為主流，主流的虛拟機配置中隻有少量的本地硬碟作為系統盤和本地緩存，同時配置雲盤作為資料盤。在這樣的情況下，資料中心的架構變為了如下的形态：
存儲計算分離對于現在的MR是架構的挑戰主要有：
1.資料本地性的限制已不複存在，所有的輸入資料都是通過遠端讀取的，是以針對資料本地性的任務排程政策已沒有多大意義。
2.所有的本地存儲 (比如shuffle，spill) 都會涉及到網絡傳輸，是以基于本地硬碟的shuffle方式已不是最佳選擇，會帶來額外的代價。
既然所有的資料都是通過遠端進行讀寫，那何不利用這樣的特性來設計一個更為合理的shuffle架構呢？為此Spark在3.0以後正式引入remote shuffle的方式，以适應存儲計算分離的架構。SPARK-25299[2]将Spark的shuffle讀寫與shuffle邏輯解耦并架構化，剝離出與本地系統互動的部分，後續可以基于SPARK-25299的架構來實作remote shuffle，例如Splash[3]。
對象存儲的支援
在雲上環境中，資料持久化已不再交由虛拟機的本地硬碟，更多的則是使用塊存儲或是對象存儲，而對于海量資料的存取，對象存儲是一個廉價而高效的解決方案。對象存儲，其高擴充性以及海量檔案存儲的能力，非常适合大資料存儲，但是另一方由于其原子性語義的缺失、較弱的一緻性、list, rename較高的代價，也會為大資料處理帶來一定的問題。
那如何來解決對象存儲帶來的問題，更好地支援對象存儲呢？
1.在Hadoop層面上實作更好的FileSystem API，如S3A[4]，來解決上面提到的問題。
2.在資料組織形态上設計更好的結構，來規避上述提到的問題，比如Spark所支援的Apache Iceberg[5]，Delta Lake[6]，Apache Hudi[7]。
彈性化排程
雲上環境的計算資源是易失的，像是AWS，Azure都會提供更為廉價的易失性執行個體，為了能更好地使用這些易失性執行個體，需要分布式計算架構将fault tolerance作為常态考慮。這樣就需要盡可能地将狀态的儲存從本地存儲遷移到遠端可靠叢集上去。SPARK-25299[8] remote shuffle的可以有效地避免本地狀态 (shuffle) 的儲存，是的計算節點變為無狀态的，更好地支援易失性的場景。
同時在雲上環境中，為了更好地利用計算資源，控制計算成本，分布式架構也需要及時主動地釋放資源，做到彈性擴縮容。Spark從1.2版本起就支援executor級别的彈性擴縮容來更好的利用executor資源。但是在雲上環境，光是釋放executor資源是不夠的，更進一步的是需要釋放計算執行個體，為此需要将Spark的彈性擴縮容政策進一步改進，以更好地支援雲上執行個體的動态擴縮容。
總結
本文從大資料的基本架構以及軟硬體演進的曆史介紹了大資料架構在雲原生時代下的挑戰。同時也從4方面詳細介紹了Spark在應對雲原生時代的進化。大資料架構在不斷地疊代演進中以适應新的基礎架構，在ABC時代擁抱雲、融入雲，打造更好的雲原生大資料架構必定會是未來的發展方向。
References
[1] Spark:
https://spark.apache.org/[2] SPARK-25299:
https://issues.apache.org/jira/browse/SPARK-25299[3] Splash:
https://github.com/MemVerge/splash[4] S3A:
https://hadoop.apache.org/docs/current/hadoop-aws/tools/hadoop-aws/index.html[5] Apache Iceberg:
https://iceberg.incubator.apache.org/[6] Delta Lake:
https://delta.io/[7] Apache Hudi:
https://hudi.incubator.apache.org/[8] SPARK-25299:
阿裡巴巴開源大資料技術團隊成立Apache Spark中國技術社群，定期推送精彩案例，技術專家直播，問答區近萬人Spark技術同學線上提問答疑，隻為營造純粹的Spark氛圍，歡迎釘釘掃碼加入！
對開源大資料和感興趣的同學可以加小編微信（下圖二維碼，備注“進群”）進入技術交流微信群。Apache
Spark技術交流社群公衆号，微信掃一掃關注