存算分離，作為一種架構(gòu)潮流，在架構(gòu)設(shè)計和項目規(guī)劃的時候經(jīng)常被提及。現(xiàn)如今，數(shù)字化轉(zhuǎn)型已經(jīng)從選擇題變成了必修課，企業(yè)IT架構(gòu)的重塑也勢在必行，所以我們有必要把這些所謂潮流的東西解構(gòu)清楚。翻閱了不少資料，也參考了網(wǎng)上一些文章，我們簡單來分析一下。

一、計算與存儲為何要分離

在計算機中，我們所說的計算其實指的是由CPU和內(nèi)存組成的算力單元，存儲指的是持久化的數(shù)據(jù)存放單元。從單體計算機的角度來講，計算存儲分離其實并不現(xiàn)實。我試想一下，如果將計算機的計算和存儲單元分開，指令都需要通過網(wǎng)絡(luò)來傳輸，以目前網(wǎng)絡(luò)的速度是很難與CPU計算速度相匹配的，所以從單體計算機的角度來講，計算與存儲分離是一個偽概念。

不管我們承認與否，其實是網(wǎng)絡(luò)一直在制約基礎(chǔ)IT架構(gòu)的演進和發(fā)展，過去由于網(wǎng)絡(luò)帶寬的限制，我們習(xí)慣性的把計算和存儲偶合在一起，以減少網(wǎng)絡(luò)傳輸?shù)膲毫?，比較典型的就是MapReduce和Hadoop，就是用本地IO代替網(wǎng)絡(luò)傳輸，是計算和存儲耦合在一起的典型場景。但是隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，網(wǎng)絡(luò)帶寬和網(wǎng)絡(luò)質(zhì)量已經(jīng)不再是瓶頸，磁盤IO反而沒有明顯的增長，計算和存儲耦合在架構(gòu)上的缺點也逐漸暴露出來：

1、耦合帶來資源浪費：作為底層的資源平臺，基礎(chǔ)IT環(huán)境的資源總是有限的，站在業(yè)務(wù)的角度是計算先達到瓶頸，還是存儲先達到瓶頸，他們的時間點是不一樣的。由于計算和存儲的耦合設(shè)計，無論擴計算還是擴存儲，都在會造成資源的浪費；

2、服務(wù)器款型繁雜，維護難度大：從運維的角度來講，降低服務(wù)器的款型是降低運維難度和工作量的有效手段。但是由于計算和存儲的耦合設(shè)計，隨著業(yè)務(wù)復(fù)雜度的增加和新業(yè)務(wù)線上的加快，對服務(wù)器資源配比的要求也會隨之增加，維護一個繁雜的服務(wù)器款型表可以是一件好玩的事情；

3、耦合造成擴容不便：計算和存儲耦合在一起還有另外一個壞處，那就是每次擴弄都需要考慮數(shù)據(jù)的遷移，給本來簡單的擴容工作帶來很多風(fēng)險和不可控因素。

從上面的分析來看，架構(gòu)不是一成不變的，會根據(jù)技術(shù)的發(fā)展和業(yè)務(wù)的發(fā)展進行演進和升級，計算和存儲的分離設(shè)計，就是在這樣一個背景下進入大家視野的。

二、計算與存儲分離的應(yīng)用場景

計算和存儲分離主要應(yīng)用在哪些方面呢，主要是數(shù)據(jù)庫和消息隊列：

1、數(shù)據(jù)庫

以傳統(tǒng)的主從結(jié)構(gòu)的數(shù)據(jù)庫系統(tǒng)為例，主庫接收數(shù)據(jù)變更，從庫讀取binlog，通過重放binlog以實現(xiàn)數(shù)據(jù)復(fù)制。在這種架構(gòu)下，當(dāng)主庫負載較大的時候，由于復(fù)制的是binlog，需要走完相關(guān)事務(wù)，所以主從復(fù)制就會變得很慢。當(dāng)主庫數(shù)據(jù)量比較大的時候，我們增加從庫的速度也會變慢，同時數(shù)據(jù)庫備份也會變慢，我們的擴容成本也隨之增加。因此我們也逐漸開始接受走計算和存儲分離的道路，讓所有的節(jié)點都共享一個存儲。也許我們對這樣的場景習(xí)以為常，其實這就是典型的計算和存儲分離設(shè)計，現(xiàn)在很多的數(shù)據(jù)庫都在逐漸向“計算和存儲分離”靠攏，包括現(xiàn)在的PolarDB、OceanBase ，TiDB等等。所以“計算和存儲分離”應(yīng)該是未來數(shù)據(jù)庫的主要發(fā)展方向。

2、消息隊列

消息隊列不論是Kafka還是RocketMQ其設(shè)計思想都是利用本地機器的磁盤來進行保存消息隊列，這樣其實是由一定的弊端的。首先容量有限，本地空間畢竟容量有限很容易造成消息堆積，會導(dǎo)致我們要追溯一些歷史數(shù)據(jù)的時候就會導(dǎo)致無法查詢，然后在擴容的時候只能擴容新節(jié)點，擴展成本也比較高。針對這些問題ApachePulsar出現(xiàn)了。

在Pulsar的架構(gòu)中，數(shù)據(jù)計算和數(shù)據(jù)存儲是單獨的兩個結(jié)構(gòu)。數(shù)據(jù)計算也就是Broker，其作用和Kafka的Broker類似，用于負載均衡，處理consumer和producer等，如果業(yè)務(wù)上consumer和producer特別的多，我們可以單獨擴展這一層。數(shù)據(jù)存儲也就是Bookie，pulsar使用了Apache Bookkeeper存儲系統(tǒng)，并沒有過多的關(guān)心存儲細節(jié)。這樣做的好處就是，只需要關(guān)系計算層的細節(jié)和邏輯，存儲部分采用成熟的方案和系統(tǒng)。

其實Kafka也在向這些方面靠攏，比如也在討論是否支持分層存儲，但是是否會實現(xiàn)存儲節(jié)點的單獨設(shè)置也不一定，但“計算和存儲分離”的方向應(yīng)該是消息隊列未來發(fā)展的主要方向。

三、大數(shù)據(jù)架構(gòu)中的存算分離應(yīng)用

傳統(tǒng)的大數(shù)據(jù)架構(gòu)中，數(shù)據(jù)計算和存儲的資源都是共用的，比如CDH的集群配置，每個節(jié)點既是YARN計算節(jié)點又是HDFS存儲節(jié)點，其實這種設(shè)計也是源于Google的GFS。在Hadoop面世之初，網(wǎng)絡(luò)帶寬很低，為了減少大數(shù)據(jù)量的網(wǎng)絡(luò)傳輸，Hadoop采用了盡量使用節(jié)點本地存儲的設(shè)計，這就形成了計算和存儲耦合的架構(gòu)。

近年來CPU算力和網(wǎng)絡(luò)速度增速遠快于存儲，數(shù)據(jù)中心有足夠的帶寬來傳輸數(shù)據(jù)，隨著數(shù)據(jù)量的增長，多副本的設(shè)計和考慮也造成了成本的飆升，計算和存儲綁定的設(shè)計實用性開始變差。隨著Spark和Flink等框架逐漸代替MapReduce，批處理和流處理同時共存，也改變了舊有的業(yè)務(wù)模型，這些都需要新的大數(shù)據(jù)架構(gòu)去適配。計算和存儲分離的大數(shù)據(jù)架構(gòu)開始進入視野。

現(xiàn)在很多新的大數(shù)據(jù)引擎都支持計算存儲分離，可以通過外部存儲引用的方式進行數(shù)據(jù)對接，而不是通過ETL加載到本地。Hadoop生態(tài)圈也開始擁抱計算與存儲分離，Hadoop除了HDFS之外還支持S3，用戶可以在私有云或者是公有云上運行Hadoop計算集群，連接共享存儲和云存儲。

這樣做的好處也是顯而易見的，首先是可以實現(xiàn)計算和存儲資源的單獨擴容，然后原本分散的數(shù)據(jù)實現(xiàn)集中存儲，打造統(tǒng)一數(shù)據(jù)湖。更重要的一點，可以真正實現(xiàn)大數(shù)據(jù)混合云，數(shù)據(jù)存儲保留在本地，機器學(xué)習(xí)等計算資源部署在公有云，既考慮了安全性，又實現(xiàn)了計算的敏捷。計算存儲的分離，也可以方便實現(xiàn)軟件版本的靈活管理，存儲部分求穩(wěn)，要保持軟件版本的穩(wěn)定，計算部分求快，可以通過數(shù)據(jù)沙盒和容器技術(shù)，實現(xiàn)不同算力模型的快速交付，各部分獨立升級互不影響。這樣我們積極可以，構(gòu)建以企業(yè)數(shù)據(jù)湖為核心的穩(wěn)態(tài)數(shù)據(jù)資源服務(wù)，構(gòu)建以數(shù)據(jù)計算為核心的敏態(tài)數(shù)據(jù)能力服務(wù)，在實現(xiàn)數(shù)據(jù)治理的基礎(chǔ)上實現(xiàn)數(shù)據(jù)運營。