最近跟好幾個用戶在交流的時候都提到了大數(shù)據(jù)的存算分離，有的是云廠商給他們推薦的方案，比如：某某運(yùn)營商說最近xx云一直在給他們推薦存算分離化改造，背景是有個幾十臺的HDFS小集群，存儲的文件數(shù)量比較多，經(jīng)常性出問題，xx云的商務(wù)就跟他們說用對象存儲如何如何來解決問題，聽起來感覺有點(diǎn)道理，但是又拿不定主意，畢竟整個改造過程動靜大、周期長，而且需要很大的投入，無論從建設(shè)周期還是成本投入上來看，都需要慎重考慮。有的是為了技術(shù)棧統(tǒng)一，比如：某某醫(yī)藥類企業(yè)，在整體技術(shù)架構(gòu)重構(gòu)時，已經(jīng)引入了xx對象存儲，基于技術(shù)棧統(tǒng)一的角度，想了解下大數(shù)據(jù)基于對象存儲下存算分離是否可行，如果可行，有沒有什么潛在的風(fēng)險？

上面的兩個例子，都是最近碰到的，相信有類似疑問的用戶還有很多，正好最近2年，我們在內(nèi)部也在做集群的存算分離化改造，接下去，我們就來談?wù)剬τ诖髷?shù)據(jù)做存算分離這件事到底應(yīng)該怎么來考慮。個人認(rèn)為：大數(shù)據(jù)集群是否適合做存算分離，主要從兩個方面來考慮：

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

成本層面：存算分離能否在計算性能、存儲空間等方面帶來成本上的優(yōu)勢。

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

相信早期的大數(shù)據(jù)集群的建設(shè)，都是采用存算一體化的形式進(jìn)行的，購買幾臺即包含計算資源又帶一定存儲的機(jī)型來搭建整個大數(shù)據(jù)集群，如下圖：

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

隨著業(yè)務(wù)的發(fā)展，我們發(fā)現(xiàn)，類似上述存算一體化的架構(gòu)，在發(fā)展到一定階段的時候，整體集群中的資源需求會打破原來存儲計算之間的比例平衡，造成某一類資源的利用率一直無法提升。比如：內(nèi)部某業(yè)務(wù)在兩年的時間內(nèi)數(shù)據(jù)存儲量上漲到原來的4倍，而計算資源只上漲到原來的2倍，數(shù)據(jù)存儲量需求明顯比計算資源增長快，這時，如果繼續(xù)采用存算一體化的機(jī)型就意味著我要滿足存儲資源增長的同時，計算資源也會增長4倍，而實(shí)際的需求只要2倍，計算資源存在過剩的情況。

除了業(yè)務(wù)外，技術(shù)上的不斷革新帶來計算能力的提升，也會導(dǎo)致原先的存算一體化資源配置出現(xiàn)比例失調(diào)的現(xiàn)象。就拿大數(shù)據(jù)領(lǐng)域離線計算來說，從最初的Hive發(fā)展到Spark，而Spark從Spark1.x到當(dāng)前的Spark3.x，相比于最早初的框架的能力，整體性能上有數(shù)量級的提升。

綜上，業(yè)務(wù)和技術(shù)的不斷發(fā)展，會造成原先存算一體化體系下存儲和計算的比例不斷發(fā)生變化，我們很難找到一種合適的機(jī)型來滿足不斷變化的需求。因此，我們在后續(xù)的采購過程中，進(jìn)行了部分存算分離采購的調(diào)整：計算資源和存儲資源進(jìn)行單獨(dú)的方式采購，并且存儲和計算都分別采用了更高密度的機(jī)型，從而把線上集群調(diào)整到一種合適的存算比例。

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

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

2.存算分離和多層存儲

基于業(yè)務(wù)和技術(shù)的發(fā)展，對集群進(jìn)行存算分離化改造能夠提升整體的計算資源利用率，在此基礎(chǔ)之上，根據(jù)業(yè)務(wù)自身發(fā)展的特性，還可以對業(yè)務(wù)的存儲做多層存儲拆分，進(jìn)一步降低數(shù)據(jù)存儲的成本。

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

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

3.存算分離和計算混部

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

2021年，杭研大數(shù)據(jù)聯(lián)合云計算、傳媒數(shù)據(jù)團(tuán)隊在傳媒大數(shù)據(jù)場景下進(jìn)行了在線/離線計算混合部署試點(diǎn)，試著把業(yè)務(wù)的Spark任務(wù)調(diào)度到輕舟K8s上，使得大數(shù)據(jù)任務(wù)在業(yè)務(wù)在線業(yè)務(wù)低峰實(shí)現(xiàn)混部，從而減少整個BU大數(shù)據(jù)計算的節(jié)點(diǎn)數(shù)量。

4.云環(huán)境下的存算分離

大數(shù)據(jù)私有場景下的存算分離一般通過把存儲和計算拆開，分別采用更高密度的存儲/計算機(jī)型來節(jié)省整個成本，存儲依舊采用HDFS的方式來搭建集群。而在云環(huán)境下，本身提供了對象存儲服務(wù)(如：S3，OSS，OBS等)，在搭建大數(shù)據(jù)平臺的時候，是否可以選用對象存儲來做大數(shù)據(jù)存儲的底層。答案當(dāng)然是可以，而且大多數(shù)云上大數(shù)據(jù)方案都是這么做的，如：AWS的EMR、阿里云的MaxCompute、華為的MRS等等。杭研大數(shù)據(jù)團(tuán)隊針對不同的客戶需求，也設(shè)計了云上部署方案，如下：

在上述整個云上部署方案中，我們采用了云平臺的云主機(jī)來搭建計算引擎，同時使用了各家云平臺的對象存儲來作為底層數(shù)據(jù)存儲。云上部署平臺相比于云下私有化部署的大數(shù)據(jù)平臺來說，最顯著的一個變化就是用對象存儲+Block Cache的方式替換了原來的HDFS存儲，之所以引入Block Cache主要有兩方面的因素考慮：Block Cache通過標(biāo)準(zhǔn)協(xié)議，能夠屏蔽底層不同對象存儲，使得整體對上層計算無感知 Block Cache兼具緩存功能，能夠盡量減少遠(yuǎn)程對象存儲訪問延遲對計算任務(wù)的影響。

除了架構(gòu)上有些許不同之外，采用云原生對象存儲作為大數(shù)據(jù)的存儲層，需要考慮性能上的影響，比如，對象存儲對于像remove之類的命令，整體性能會比較低下，特別是在對大目錄的remove上，而大數(shù)據(jù)計算場景下，會有較多的insert overwrite操作，會頻繁的去刪除老的數(shù)據(jù)后寫入新的數(shù)據(jù)。因此對于像remove類的接口，如果性能很差，會大幅度影響計算性能。

5.總結(jié)

回過頭來看看開頭的兩個問題：集群經(jīng)常出問題，需要做存算分離改造，其實(shí)還可以有較大的優(yōu)化空間，比如：增加NameNode JVM的內(nèi)存，或者合并小文件減少元數(shù)據(jù)信息等等，一般情況下，幾十臺的規(guī)模遠(yuǎn)不會達(dá)到HDFS性能瓶頸。

至于第二個，為了技術(shù)棧的統(tǒng)一，需要衡量對象存儲給大數(shù)據(jù)計算造成的性能影響后再來綜合考慮。

作者簡介

蔣鴻翔，服務(wù)端開發(fā)專家。2011年加入網(wǎng)易杭州研究院，主要負(fù)責(zé)大數(shù)據(jù)基礎(chǔ)設(shè)施類工作，同時承擔(dān)內(nèi)部業(yè)務(wù)線上大數(shù)據(jù)集群穩(wěn)定性保障、協(xié)助業(yè)務(wù)線上技術(shù)框架落地，解決業(yè)務(wù)實(shí)際生產(chǎn)過程中的各種問題，與業(yè)務(wù)一起改進(jìn)線上技術(shù)框架，從而實(shí)現(xiàn)降本增效等目的。