聊聊大資料的存算分離

導讀：大資料叢集從最初開始建設時，一般都採用存算一體化的架構，主要是考慮部署簡單、管理起來也方便。但是隨著叢集規模的不斷擴大，在整個叢集的資源規劃和穩定性上都遭受到了不同程度的挑戰。業務資料不斷增長和技術框架的不斷革新，導致叢集資源無法始終維護在一個儲存和計算比較均衡的狀態。因此，對叢集適當做一些儲存和計算的拆分，一方面可以提升叢集的穩定性和效能，另外一方面，也可以降低整體的成本。達到降本增效的效果。

最近跟好幾個使用者在交流的時候都提到了大資料的存算分離，有的是雲廠商給他們推薦的方案，比如：某某運營商說最近xx雲一直在給他們推薦存算分離化改造，背景是有個幾十臺的HDFS小叢集，儲存的檔案數量比較多，經常性出問題，xx雲的商務就跟他們說用物件儲存如何如何來解決問題，聽起來感覺有點道理，但是又拿不定主意，畢竟整個改造過程動靜大、週期長，而且需要很大的投入，無論從建設週期還是成本投入上來看，都需要慎重考慮。有的是為了技術棧統一，比如：某某醫藥類企業，在整體技術架構重構時，已經引入了xx物件儲存，基於技術棧統一的角度，想了解下大資料基於物件儲存下存算分離是否可行，如果可行，有沒有什麼潛在的風險?

上面的兩個例子，都是最近碰到的，相信有類似疑問的使用者還有很多，正好最近2年，我們在內部也在做叢集的存算分離化改造，接下去，我們就來談談對於大資料做存算分離這件事到底應該怎麼來考慮。個人認為：大資料叢集是否適合做存算分離，主要從兩個方面來考慮：

技術層面：存算分離是否能夠簡化我們的技術棧，或者解決某些瓶頸問題。

成本層面：存算分離能否在計算效能、儲存空間等方面帶來成本上的優勢。

1、存算分離和存算一體化

相信早期的大資料叢集的建設，都是採用存算一體化的形式進行的，購買幾臺即包含計算資源又帶一定儲存的機型來搭建整個大資料叢集，如下圖：

存算一體化的叢集中每個節點都具備相同的硬體配置，我們早期內部典型的配置基本上是：48核，256GB記憶體，12塊8T SATA盤，整體提供約48個CU(1CU包含1核，4GB記憶體)和96TB的儲存。

隨著業務的發展，我們發現，類似上述存算一體化的架構，在發展到一定階段的時候，整體叢集中的資源需求會打破原來儲存計算之間的比例平衡，造成某一類資源的利用率一直無法提升。比如：內部某業務在兩年的時間內資料儲存量上漲到原來的4倍，而計算資源只上漲到原來的2倍，資料儲存量需求明顯比計算資源增長快，這時，如果繼續採用存算一體化的機型就意味著我要滿足儲存資源增長的同時，計算資源也會增長4倍，而實際的需求只要2倍，計算資源存在過剩的情況。

除了業務外，技術上的不斷革新帶來計算能力的提升，也會導致原先的存算一體化資源配置出現比例失調的現象。就拿大資料領域離線計算來說，從最初的Hive發展到Spark，而Spark從Spark1.x到當前的Spark3.x，相比於最早初的框架的能力，整體效能上有數量級的提升。

綜上，業務和技術的不斷髮展，會造成原先存算一體化體系下儲存和計算的比例不斷髮生變化，我們很難找到一種合適的機型來滿足不斷變化的需求。因此，我們在後續的採購過程中，進行了部分存算分離採購的調整：計算資源和儲存資源進行單獨的方式採購，並且儲存和計算都分別採用了更高密度的機型，從而把線上叢集調整到一種合適的存算比例。

存算分離改造帶來的另外一大好處是把原先大資料計算過程中的離散I/O(shuffle資料)和順序I/O(資料塊)進行了很好的拆分，解決了計算過程中的I/O瓶頸，從而進一步提升了CPU的利用率。

透過上述存算分離化改造，叢集中大部分節點的資源利用率有了大幅度提升，全天CPU 95峰值維持在90%左右，平均CPU利用率從25%提升到55%以上。

2、存算分離和多層儲存

基於業務和技術的發展，對叢集進行存算分離化改造能夠提升整體的計算資源利用率，在此基礎之上，根據業務自身發展的特性，還可以對業務的儲存做多層儲存拆分，進一步降低資料儲存的成本。

一般來說，業務的資料量是一直不斷在增長的，而應用使用的資料，都具有一定的時效性，更多的會集中在最近一兩個月甚至最近一兩週的資料，大量歷史資料更多的是在某些特殊的場景下會被利用到，比如：幾個月前的使用者行為資料。大量的儲存空間被這種重要但已經“過期”的資料所佔據。在大部分的儲存系統中，經常被訪問的資料(熱資料)一般只佔了15% ~ 25%，而不經常被訪問的資料(冷資料)卻佔了75% ~ 85%。由於冷資料不活躍的特點，如果對冷資料的儲存進行一定的改造，將會取得較為不錯的成本收益。

上圖中，我們對原本存在IDC1中的儲存叢集做了一定的拆分，把原本一個叢集拆分成兩個叢集，分別稱之為：熱叢集和冷叢集，熱叢集的搭建與原先一致，而冷叢集在搭建的時候，我們採用了EC(糾刪碼)的方式進行了改造，使得大量的冷資料在保證原來的高可用性的同時，儲存成本降至原來的50%，在業務具有較大規模冷資料的情況下，該種方式也可以為業務減少大量資料儲存成本。

3、存算分離和計算混部

儲存上可以根據資料冷熱做到多層儲存，計算層也可以透過一定的混部措施來提升業務整體計算的利用率。按照業務的特性，一般線上的業務高峰期每天的10:00-24:00，而離線計算的高峰期在24:00-8:00，從時間分佈來看，線上業務與離線業務存在較好的互補特性。因此，如果能夠把部分離線的任務在線上業務的低峰期，能跑在線上業務的伺服器上，做到線上離線業務混合部署，也是可以節省離線計算伺服器。

2021年，杭研大資料聯合雲端計算、傳媒資料團隊在傳媒大資料場景下進行了線上/離線計算混合部署試點，試著把業務的Spark任務排程到輕舟K8s上，使得大資料任務在業務線上業務低峰實現混部，從而減少整個BU大資料計算的節點數量。

4、雲環境下的存算分離

大資料私有場景下的存算分離一般透過把儲存和計算拆開，分別採用更高密度的儲存/計算機型來節省整個成本，儲存依舊採用HDFS的方式來搭建叢集。而在雲環境下，本身提供了物件儲存服務(如：S3，OSS，OBS等)，在搭建大資料平臺的時候，是否可以選用物件儲存來做大資料儲存的底層。答案當然是可以，而且大多數雲上大資料方案都是這麼做的，如：AWS的EMR、阿里雲的MaxCompute、華為的MRS等等。杭研大資料團隊針對不同的客戶需求，也設計了雲上部署方案，如下：

在上述整個雲上部署方案中，我們採用了雲平臺的雲主機來搭建計算引擎，同時使用了各家雲平臺的物件儲存來作為底層資料儲存。雲上部署平臺相比於雲下私有化部署的大資料平臺來說，最顯著的一個變化就是用物件儲存+Block Cache的方式替換了原來的HDFS儲存，之所以引入Block Cache主要有兩方面的因素考慮：Block Cache透過標準協議，能夠遮蔽底層不同物件儲存，使得整體對上層計算無感知 Block Cache兼具快取功能，能夠儘量減少遠端物件儲存訪問延遲對計算任務的影響。

除了架構上有些許不同之外，採用雲原生物件儲存作為大資料的儲存層，需要考慮效能上的影響，比如，物件儲存對於像remove之類的命令，整體效能會比較低下，特別是在對大目錄的remove上，而大資料計算場景下，會有較多的insert overwrite操作，會頻繁的去刪除老的資料後寫入新的資料。因此對於像remove類的介面，如果效能很差，會大幅度影響計算效能。

5、總結

回過頭來看看開頭的兩個問題：叢集經常出問題，需要做存算分離改造，其實還可以有較大的最佳化空間，比如：增加NameNode JVM的記憶體，或者合併小檔案減少後設資料資訊等等，一般情況下，幾十臺的規模遠不會達到HDFS效能瓶頸。

至於第二個，為了技術棧的統一，需要衡量物件儲存給大資料計算造成的效能影響後再來綜合考慮。

作者簡介：蔣鴻翔，服務端開發專家。2011年加入網易杭州研究院，主要負責大資料基礎設施類工作，同時承擔內部業務線上大資料叢集穩定性保障、協助業務線上技術框架落地，解決業務實際生產過程中的各種問題，與業務一起改進線上技術框架，從而實現降本增效等目的。