本文來(lái)自微信公眾號(hào)“twt企業(yè)IT社區(qū)”，作者/鄭金輝。
存算分離，作為一種架構(gòu)潮流，在架構(gòu)設(shè)計(jì)和項(xiàng)目規(guī)劃的時(shí)候經(jīng)常被提及?，F(xiàn)如今，數(shù)字化轉(zhuǎn)型已經(jīng)從選擇題變成了必修課，企業(yè)IT架構(gòu)的重塑也勢(shì)在必行，所以我們有必要把這些所謂潮流的東西解構(gòu)清楚。翻閱了不少資料，也參考了網(wǎng)上一些文章，我們簡(jiǎn)單來(lái)分析一下。
一、計(jì)算與存儲(chǔ)為何要分離
在計(jì)算機(jī)中，我們所說(shuō)的計(jì)算其實(shí)指的是由CPU和內(nèi)存組成的算力單元，存儲(chǔ)指的是持久化的數(shù)據(jù)存放單元。從單體計(jì)算機(jī)的角度來(lái)講，計(jì)算存儲(chǔ)分離其實(shí)并不現(xiàn)實(shí)。我試想一下，如果將計(jì)算機(jī)的計(jì)算和存儲(chǔ)單元分開(kāi)，指令都需要通過(guò)網(wǎng)絡(luò)來(lái)傳輸，以目前網(wǎng)絡(luò)的速度是很難與CPU計(jì)算速度相匹配的，所以從單體計(jì)算機(jī)的角度來(lái)講，計(jì)算與存儲(chǔ)分離是一個(gè)偽概念。
不管我們承認(rèn)與否，其實(shí)是網(wǎng)絡(luò)一直在制約基礎(chǔ)IT架構(gòu)的演進(jìn)和發(fā)展，過(guò)去由于網(wǎng)絡(luò)帶寬的限制，我們習(xí)慣性的把計(jì)算和存儲(chǔ)偶合在一起，以減少網(wǎng)絡(luò)傳輸?shù)膲毫?，比較典型的就是MapReduce和Hadoop，就是用本地IO代替網(wǎng)絡(luò)傳輸，是計(jì)算和存儲(chǔ)耦合在一起的典型場(chǎng)景。但是隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，網(wǎng)絡(luò)帶寬和網(wǎng)絡(luò)質(zhì)量已經(jīng)不再是瓶頸，磁盤(pán)IO反而沒(méi)有明顯的增長(zhǎng)，計(jì)算和存儲(chǔ)耦合在架構(gòu)上的缺點(diǎn)也逐漸暴露出來(lái)：
1、耦合帶來(lái)資源浪費(fèi)：作為底層的資源平臺(tái)，基礎(chǔ)IT環(huán)境的資源總是有限的，站在業(yè)務(wù)的角度是計(jì)算先達(dá)到瓶頸，還是存儲(chǔ)先達(dá)到瓶頸，他們的時(shí)間點(diǎn)是不一樣的。由于計(jì)算和存儲(chǔ)的耦合設(shè)計(jì)，無(wú)論擴(kuò)計(jì)算還是擴(kuò)存儲(chǔ)，都在會(huì)造成資源的浪費(fèi)；
2、服務(wù)器款型繁雜，維護(hù)難度大：從運(yùn)維的角度來(lái)講，降低服務(wù)器的款型是降低運(yùn)維難度和工作量的有效手段。但是由于計(jì)算和存儲(chǔ)的耦合設(shè)計(jì)，隨著業(yè)務(wù)復(fù)雜度的增加和新業(yè)務(wù)線上的加快，對(duì)服務(wù)器資源配比的要求也會(huì)隨之增加，維護(hù)一個(gè)繁雜的服務(wù)器款型表可以是一件好玩的事情；
3、耦合造成擴(kuò)容不便：計(jì)算和存儲(chǔ)耦合在一起還有另外一個(gè)壞處，那就是每次擴(kuò)弄都需要考慮數(shù)據(jù)的遷移，給本來(lái)簡(jiǎn)單的擴(kuò)容工作帶來(lái)很多風(fēng)險(xiǎn)和不可控因素。
從上面的分析來(lái)看，架構(gòu)不是一成不變的，會(huì)根據(jù)技術(shù)的發(fā)展和業(yè)務(wù)的發(fā)展進(jìn)行演進(jìn)和升級(jí)，計(jì)算和存儲(chǔ)的分離設(shè)計(jì)，就是在這樣一個(gè)背景下進(jìn)入大家視野的。
二、計(jì)算與存儲(chǔ)分離的應(yīng)用場(chǎng)景
計(jì)算和存儲(chǔ)分離主要應(yīng)用在哪些方面呢，主要是數(shù)據(jù)庫(kù)和消息隊(duì)列：
1、數(shù)據(jù)庫(kù)
以傳統(tǒng)的主從結(jié)構(gòu)的數(shù)據(jù)庫(kù)系統(tǒng)為例，主庫(kù)接收數(shù)據(jù)變更，從庫(kù)讀取binlog，通過(guò)重放binlog以實(shí)現(xiàn)數(shù)據(jù)復(fù)制。在這種架構(gòu)下，當(dāng)主庫(kù)負(fù)載較大的時(shí)候，由于復(fù)制的是binlog，需要走完相關(guān)事務(wù)，所以主從復(fù)制就會(huì)變得很慢。當(dāng)主庫(kù)數(shù)據(jù)量比較大的時(shí)候，我們?cè)黾訌膸?kù)的速度也會(huì)變慢，同時(shí)數(shù)據(jù)庫(kù)備份也會(huì)變慢，我們的擴(kuò)容成本也隨之增加。因此我們也逐漸開(kāi)始接受走計(jì)算和存儲(chǔ)分離的道路，讓所有的節(jié)點(diǎn)都共享一個(gè)存儲(chǔ)。也許我們對(duì)這樣的場(chǎng)景習(xí)以為常，其實(shí)這就是典型的計(jì)算和存儲(chǔ)分離設(shè)計(jì)，現(xiàn)在很多的數(shù)據(jù)庫(kù)都在逐漸向“計(jì)算和存儲(chǔ)分離”靠攏，包括現(xiàn)在的PolarDB、OceanBase，TiDB等等。所以“計(jì)算和存儲(chǔ)分離”應(yīng)該是未來(lái)數(shù)據(jù)庫(kù)的主要發(fā)展方向。
2、消息隊(duì)列
消息隊(duì)列不論是Kafka還是RocketMQ其設(shè)計(jì)思想都是利用本地機(jī)器的磁盤(pán)來(lái)進(jìn)行保存消息隊(duì)列，這樣其實(shí)是由一定的弊端的。首先容量有限，本地空間畢竟容量有限很容易造成消息堆積，會(huì)導(dǎo)致我們要追溯一些歷史數(shù)據(jù)的時(shí)候就會(huì)導(dǎo)致無(wú)法查詢，然后在擴(kuò)容的時(shí)候只能擴(kuò)容新節(jié)點(diǎn)，擴(kuò)展成本也比較高。針對(duì)這些問(wèn)題ApachePulsar出現(xiàn)了。
在Pulsar的架構(gòu)中，數(shù)據(jù)計(jì)算和數(shù)據(jù)存儲(chǔ)是單獨(dú)的兩個(gè)結(jié)構(gòu)。數(shù)據(jù)計(jì)算也就是Broker，其作用和Kafka的Broker類似，用于負(fù)載均衡，處理consumer和producer等，如果業(yè)務(wù)上consumer和producer特別的多，我們可以單獨(dú)擴(kuò)展這一層。數(shù)據(jù)存儲(chǔ)也就是Bookie，pulsar使用了Apache Bookkeeper存儲(chǔ)系統(tǒng)，并沒(méi)有過(guò)多的關(guān)心存儲(chǔ)細(xì)節(jié)。這樣做的好處就是，只需要關(guān)系計(jì)算層的細(xì)節(jié)和邏輯，存儲(chǔ)部分采用成熟的方案和系統(tǒng)。
其實(shí)Kafka也在向這些方面靠攏，比如也在討論是否支持分層存儲(chǔ)，但是是否會(huì)實(shí)現(xiàn)存儲(chǔ)節(jié)點(diǎn)的單獨(dú)設(shè)置也不一定，但“計(jì)算和存儲(chǔ)分離”的方向應(yīng)該是消息隊(duì)列未來(lái)發(fā)展的主要方向。
三、大數(shù)據(jù)架構(gòu)中的存算分離應(yīng)用
傳統(tǒng)的大數(shù)據(jù)架構(gòu)中，數(shù)據(jù)計(jì)算和存儲(chǔ)的資源都是共用的，比如CDH的集群配置，每個(gè)節(jié)點(diǎn)既是YARN計(jì)算節(jié)點(diǎn)又是HDFS存儲(chǔ)節(jié)點(diǎn)，其實(shí)這種設(shè)計(jì)也是源于Google的GFS。在Hadoop面世之初，網(wǎng)絡(luò)帶寬很低，為了減少大數(shù)據(jù)量的網(wǎng)絡(luò)傳輸，Hadoop采用了盡量使用節(jié)點(diǎn)本地存儲(chǔ)的設(shè)計(jì)，這就形成了計(jì)算和存儲(chǔ)耦合的架構(gòu)。
近年來(lái)CPU算力和網(wǎng)絡(luò)速度增速遠(yuǎn)快于存儲(chǔ)，數(shù)據(jù)中心有足夠的帶寬來(lái)傳輸數(shù)據(jù)，隨著數(shù)據(jù)量的增長(zhǎng)，多副本的設(shè)計(jì)和考慮也造成了成本的飆升，計(jì)算和存儲(chǔ)綁定的設(shè)計(jì)實(shí)用性開(kāi)始變差。隨著Spark和Flink等框架逐漸代替MapReduce，批處理和流處理同時(shí)共存，也改變了舊有的業(yè)務(wù)模型，這些都需要新的大數(shù)據(jù)架構(gòu)去適配。計(jì)算和存儲(chǔ)分離的大數(shù)據(jù)架構(gòu)開(kāi)始進(jìn)入視野。
現(xiàn)在很多新的大數(shù)據(jù)引擎都支持計(jì)算存儲(chǔ)分離，可以通過(guò)外部存儲(chǔ)引用的方式進(jìn)行數(shù)據(jù)對(duì)接，而不是通過(guò)ETL加載到本地。Hadoop生態(tài)圈也開(kāi)始擁抱計(jì)算與存儲(chǔ)分離，Hadoop除了HDFS之外還支持S3，用戶可以在私有云或者是公有云上運(yùn)行Hadoop計(jì)算集群，連接共享存儲(chǔ)和云存儲(chǔ)。
這樣做的好處也是顯而易見(jiàn)的，首先是可以實(shí)現(xiàn)計(jì)算和存儲(chǔ)資源的單獨(dú)擴(kuò)容，然后原本分散的數(shù)據(jù)實(shí)現(xiàn)集中存儲(chǔ)，打造統(tǒng)一數(shù)據(jù)湖。更重要的一點(diǎn)，可以真正實(shí)現(xiàn)大數(shù)據(jù)混合云，數(shù)據(jù)存儲(chǔ)保留在本地，機(jī)器學(xué)習(xí)等計(jì)算資源部署在公有云，既考慮了安全性，又實(shí)現(xiàn)了計(jì)算的敏捷。計(jì)算存儲(chǔ)的分離，也可以方便實(shí)現(xiàn)軟件版本的靈活管理，存儲(chǔ)部分求穩(wěn)，要保持軟件版本的穩(wěn)定，計(jì)算部分求快，可以通過(guò)數(shù)據(jù)沙盒和容器技術(shù)，實(shí)現(xiàn)不同算力模型的快速交付，各部分獨(dú)立升級(jí)互不影響。這樣我們積極可以，構(gòu)建以企業(yè)數(shù)據(jù)湖為核心的穩(wěn)態(tài)數(shù)據(jù)資源服務(wù)，構(gòu)建以數(shù)據(jù)計(jì)算為核心的敏態(tài)數(shù)據(jù)能力服務(wù)，在實(shí)現(xiàn)數(shù)據(jù)治理的基礎(chǔ)上實(shí)現(xiàn)數(shù)據(jù)運(yùn)營(yíng)。
其實(shí)計(jì)算與存儲(chǔ)分離這個(gè)提法，多少有點(diǎn)噱頭的意思，沒(méi)有那么復(fù)雜，當(dāng)然也沒(méi)那么簡(jiǎn)單。還是那句話：沒(méi)有一成不變的架構(gòu)，只有不變的以業(yè)務(wù)為核心的架構(gòu)意識(shí)。
原題：談?wù)動(dòng)?jì)算與存儲(chǔ)分離架構(gòu)；作者個(gè)人公眾號(hào)：向云而生
