架構師進階：從傳統Hadoop大資料架構到雲原生架構改造

以Hadoop為中心的大資料生态系統從2006年開源以來，一直是大部分公司建構大資料平台的選擇，但這種傳統選擇随着人們深入地使用，出現越來越多的問題，比如：資料開發疊代速度不夠快，叢集資源利用效率過低、新的開發工具內建非常複雜。這些問題已經成為了困擾企業數字化轉型加速疊代和更新的主要障礙。另一方面，從2014年開始，以Docker和Kubernetes（K8s）為代表的雲原生技術蓬勃發展，雲原生的社群和機構迅速壯大，到現在，Kubernetes已經成為企業搭建容器雲平台的标配。

那麼，業界都在思考一個問題，高速發展的雲原生技術能不能解決傳統大資料平台的那些問題。答案是肯定的。

一、傳統大資料平台的問題

資料時代，傳統大資料平台遭遇四大窘迫問題

傳統大資料平台，是指以Hadoop為中心的大資料生态技術。一個Hadoop叢集包含HDFS分布式檔案系統和以Yarn為排程系統的MapReduce計算架構。圍繞Hadoop，有一系列的軟體來幫助人們進行大資料的存儲和計算，比如資料倉庫Hive、計算架構Spark、實時消息隊列Kafka等。

在大資料發展的初期，這樣的大資料生态技術架構是能基本滿足人們建設大資料平台的需要的。随着時代的發展，大資料技術使用逐漸地深入，大資料開發需求變得越來越旺盛，人們對多租戶環境下大資料開發的效率、大資料叢集資源使用率、新（計算和存儲）技術的內建速度提出了越來越高的要求，而傳統大資料平台在面對這些需求時則顯得有點束手無策，出現了無法克服的困難。我們仔細分析一下，就可以看到傳統大資料平台的技術架構決定了依靠它本身的發展是無法克服這些困難的：

1、傳統大資料平台難以實作資源的隔離。

多租戶環境下的資料開發效率提升，需要以資源隔離的方式來保證租戶之間的計算作業互相不影響，特别是不能出現某一個或幾個租戶獨占叢集資源的情況。但Hadoop系統本身的出發點就不是為了多租戶環境而設計的，其目前的資源隔離實作也不完善。在最近的Hadoop版本中，在一定程度上實作了記憶體資源和檔案資源的隔離，但是不夠完整，而磁盤I/O和網絡I/O的隔離還在社群讨論的過程中，短期内看不到解決的希望。

2、傳統大資料平台難以內建新的計算和存儲技術。

Hadoop系統在部署其他元件的時候，對這些元件與HDFS和Yarn的版本适配是有嚴格要求的。很多新的大資料元件是不适配老版本的Hadoop的，而更新Hadoop又會造成其他元件的失效。另外，部署新的元件還要考慮到Linux不同作業系統的相容性所帶來的額外複雜度。是以引入一個新的計算和存儲元件的難度是非常高的，往往需要幾天甚至是幾周的時間。

3、Hadoop存算合一的耦合架構決定了它的資源使用率無法提高。

在一個Hadoop叢集中，一個節點既是存儲節點（datanode），也是計算節點。當存儲資源不夠的時候，增加節點可以進行存儲擴容，但會造成計算資源的使用率下降；同樣，當計算資源不夠而進行擴容的時候，存儲資源使用率就會下降。同時，因為對于Yarn的依賴，不使用Yarn排程的其它元件很難內建到Hadoop的計算架構中。是以Hadoop的這種耦合架構決定了它的資源使用率不可能很高。

4、Hadoop叢集資源無法做到快速地彈性擴容和縮容。

彈性的擴容和縮容是提高叢集資源使用率的有效方法。很遺憾，Hadoop的節點擴容和縮容流程，導緻這個動作無法在很快的時間内完成，尤其是縮容過程，隻有當一個datanode的所有資料塊都在其他節點完成了備份以後，該節點才能被移出叢集，而由于資料備份是以較小的傳輸率運作在背景，往往要持續幾個小時以上。

總而言之，傳統大資料平台因為其結構性的缺陷導緻了多租戶環境下資料開發效率低、叢集資源使用率不高、以及內建新技術很複雜等問題，依靠Hadoop生态技術架構本身的發展是不可能解決這些問題的。

二、大資料平台的發展趨勢

業界新趨勢：大資料平台的雲原生化

既然不能夠依靠Hadoop生态技術本身的發展來解決傳統大資料平台帶來的難題，那麼我們就應該把注意力放到目前最新的技術發展趨勢之上，也就是以容器和Kubernetes為代表的雲原生技術。雲原生技術在2013年容器項目以及2014年Kubernetes項目正式釋出以後，發展非常迅猛。現在，各大公有雲廠商都支援K8s，還有上百家技術公司在持續投入K8s的疊代和更新工作。成立于2015年的雲原生計算基金會（CNCF），将K8s作為其托管的第一個項目，到目前該基金會已經托管了123個項目，近200個國家的16萬開發者在為這些項目開發代碼。更令人興奮的是，CNCF的生态全景圖目前包含了1000多個雲原生技術産品，覆寫了資料庫、消息級流處理、排程和任務編排、存儲系統等10多個技術領域。

2021年應該是雲原生大資料技術發展的裡程碑，在這一年，有兩個重大的技術進展被公布。一個是2021年3月，Apache宣布Spark 3.1正式支援了kubernetes，另外在2021年5月，Apache Kafka背後的商業公司Confluent 也釋出了Confluent on Kuberneters，一個能私有釋出的在K8s之上運作的Kafka生産叢集系統。

這兩個重要事件表明，大資料平台的雲原生化已是大勢所趨。按照這個趨勢，Hadoop也會逐漸遷移到K8s上。從技術角度來分析，常說的Hadoop三架馬車中，計算架構MapReduce會被更高效的Spark所取代，資源排程元件Yarn正在被K8s取代，最堅挺的HDFS也有了雲原生的對标方案。這意味着直接在K8s上運作所有現在的大資料工作負載已經成為了可能。

三、未來發展方向

讓雲原生大資料平台借力 K8s 發揮更大價值

這兩年以來，業界在大資料平台雲原生化這個方向做了大量嘗試，實作了大資料元件在K8s的穩定運作以及統一的資料安全機制，使資料應用開發平台能夠實作完整的雲原生化。接下來，仍需在多個方向繼續探索，推動大資料平台更高效更穩定地運作在K8s之上。