解構“存算分離”
存算分離,作為一種架構潮流,在架構設計和項目規劃的時候經常被提及。現如今,數字化轉型已經從選擇題變成了必修課,企業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計算集群,連接共享存儲和云存儲。
這樣做的好處也是顯而易見的,首先是可以實現計算和存儲資源的單獨擴容,然后原本分散的數據實現集中存儲,打造統一數據湖。更重要的一點,可以真正實現大數據混合云,數據存儲保留在本地,機器學習等計算資源部署在公有云,既考慮了安全性,又實現了計算的敏捷。計算存儲的分離,也可以方便實現軟件版本的靈活管理,存儲部分求穩,要保持軟件版本的穩定,計算部分求快,可以通過數據沙盒和容器技術,實現不同算力模型的快速交付,各部分獨立升級互不影響。這樣我們積極可以,構建以企業數據湖為核心的穩態數據資源服務,構建以數據計算為核心的敏態數據能力服務,在實現數據治理的基礎上實現數據運營。