解構成為架構潮流的“存算分離”

存算分離，作為一種架構潮流，在架構設計和專案規劃的時候經常被提及。現如今，數字化轉型已經從選擇題變成了必修課，企業IT架構的重塑也勢在必行，所以我們有必要把這些所謂潮流的東西解構清楚。翻閱了不少資料，也參考了網上一些文章，我們簡單來分析一下。

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

在計算機中，我們所說的計算其實指的是由CPU和記憶體組成的算力單元，儲存指的是持久化的資料存放單元。從單體計算機的角度來講，計算儲存分離其實並不現實。我試想一下，如果將計算機的計算和儲存單元分開，指令都需要透過網路來傳輸，以目前網路的速度是很難與CPU計算速度相匹配的，所以從單體計算機的角度來講，計算與儲存分離是一個偽概念。

不管我們承認與否，其實是網路一直在制約基礎IT架構的演進和發展，過去由於網路頻寬的限制，我們習慣性的把計算和儲存偶合在一起，以減少網路傳輸的壓力、比較典型的就是MapReduce和Hadoop，就是用本地IO代替網路傳輸，是計算和儲存耦合在一起的典型場景。但是隨著網路技術的發展，網路頻寬和網路質量已經不再是瓶頸，磁碟IO反而沒有明顯的增長，計算和儲存耦合在架構上的缺點也逐漸暴露出來：

1、耦合帶來資源浪費：作為底層的資源平臺，基礎IT環境的資源總是有限的，站在業務的角度是計算先達到瓶頸，還是儲存先達到瓶頸，他們的時間點是不一樣的。由於計算和儲存的耦合設計，無論擴計算還是擴儲存，都在會造成資源的浪費;

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

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

從上面的分析來看，架構不是一成不變的，會根據技術的發展和業務的發展進行演進和升級，計算和儲存的分離設計，就是在這樣一個背景下進入大家視野的。

二、計算與儲存分離的應用場景

計算和儲存分離主要應用在哪些方面呢，主要是資料庫和訊息佇列：

1、資料庫

以傳統的主從結構的資料庫系統為例，主庫接收資料變更，從庫讀取binlog，透過重放binlog以實現資料複製。在這種架構下，當主庫負載較大的時候，由於複製的是binlog，需要走完相關事務，所以主從複製就會變得很慢。當主庫資料量比較大的時候，我們增加從庫的速度也會變慢，同時資料庫備份也會變慢，我們的擴容成本也隨之增加。因此我們也逐漸開始接受走計算和儲存分離的道路，讓所有的節點都共享一個儲存。也許我們對這樣的場景習以為常，其實這就是典型的計算和儲存分離設計，現在很多的資料庫都在逐漸向“計算和儲存分離”靠攏，包括現在的PolarDB、OceanBase ，TiDB等等。所以“計算和儲存分離”應該是未來資料庫的主要發展方向。

2、訊息佇列

訊息佇列不論是Kafka還是RocketMQ其設計思想都是利用本地機器的磁碟來進行儲存訊息佇列，這樣其實是由一定的弊端的。首先容量有限，本地空間畢竟容量有限很容易造成訊息堆積，會導致我們要追溯一些歷史資料的時候就會導致無法查詢，然後在擴容的時候只能擴容新節點，擴充套件成本也比較高。針對這些問題ApachePulsar出現了。

在Pulsar的架構中，資料計算和資料儲存是單獨的兩個結構。資料計算也就是Broker，其作用和Kafka的Broker類似，用於負載均衡，處理consumer和producer等，如果業務上consumer和producer特別的多，我們可以單獨擴充套件這一層。資料儲存也就是Bookie，pulsar使用了Apache Bookkeeper儲存系統，並沒有過多的關心儲存細節。這樣做的好處就是，只需要關係計算層的細節和邏輯，儲存部分採用成熟的方案和系統。

其實Kafka也在向這些方面靠攏，比如也在討論是否支援分層儲存，但是是否會實現儲存節點的單獨設定也不一定，但“計算和儲存分離”的方向應該是訊息佇列未來發展的主要方向。

三、大資料架構中的存算分離應用

傳統的大資料架構中，資料計算和儲存的資源都是共用的，比如CDH的叢集配置，每個節點既是YARN計算節點又是HDFS儲存節點，其實這種設計也是源於Google的GFS。在Hadoop面世之初，網路頻寬很低，為了減少大資料量的網路傳輸，Hadoop採用了儘量使用節點本地儲存的設計，這就形成了計算和儲存耦合的架構。

近年來CPU算力和網路速度增速遠快於儲存，資料中心有足夠的頻寬來傳輸資料，隨著資料量的增長，多副本的設計和考慮也造成了成本的飆升，計算和儲存繫結的設計實用性開始變差。隨著Spark和Flink等框架逐漸代替MapReduce，批處理和流處理同時共存，也改變了舊有的業務模型，這些都需要新的大資料架構去適配。計算和儲存分離的大資料架構開始進入視野。

現在很多新的大資料引擎都支援計算儲存分離，可以透過外部儲存引用的方式進行資料對接，而不是透過ETL載入到本地。Hadoop生態圈也開始擁抱計算與儲存分離，Hadoop除了HDFS之外還支援S3，使用者可以在私有云或者是公有云上執行Hadoop計算叢集，連線共享儲存和雲端儲存。

這樣做的好處也是顯而易見的，首先是可以實現計算和儲存資源的單獨擴容，然後原本分散的資料實現集中儲存，打造統一資料湖。更重要的一點，可以真正實現大資料混合雲，資料儲存保留在本地，機器學習等計算資源部署在公有云，既考慮了安全性，又實現了計算的敏捷。計算儲存的分離，也可以方便實現軟體版本的靈活管理，儲存部分求穩，要保持軟體版本的穩定，計算部分求快，可以透過資料沙盒和容器技術，實現不同算力模型的快速交付，各部分獨立升級互不影響。這樣我們積極可以，構建以企業資料湖為核心的穩態資料資源服務，構建以資料計算為核心的敏態資料能力服務，在實現資料治理的基礎上實現資料運營。

其實計算與儲存分離這個提法，多少有點噱頭的意思，沒有那麼複雜，當然也沒那麼簡單。還是那句話：沒有一成不變的架構，只有不變的以業務為核心的架構意識。