什麼是存算分離架構？

隨著硬體技術的快速進步，尤其是網路和儲存裝置的效能迅速提升，以及雲端計算廠商推動軟硬體協同加速的雲端儲存服務，越來越多的企業開始基於雲端儲存來構建資料儲存服務，或資料湖，因此就需要單獨再建設一個獨立的計算層來提供資料分析服務，這也就是存算分離架構（Disaggregated Storage and Compute Architecture）。本文介紹存算分離架構。

— 背景介紹  —

Apache Hadoop開啟了分散式儲存的浪潮，其採用的架構是“存算一體”架構，即在一個叢集中實現計算和儲存功能，並且為了保證儘量減少橫向網路帶來的效能損失，計算引擎在設計上採用了“計算貼近儲存”的設計，即每個計算任務會選擇在對應的資料檔案所在的伺服器上執行，這樣就可以發揮本地IO的效能，避免大量點對點的資料傳輸導致的網路單點瓶頸問題。下圖描述了這個設計，每個工作節點上都有儲存服務和計算服務。

從一個抽象的角度，存算分離架構如下圖所示，其儲存層和計算層相對獨立，儲存層採用HDFS或其他與Hadoop相容儲存（HCFS）甚至是關係型資料庫，而計算層一般採用多樣化的計算引擎，如Spark、Presto、Flink等。這種架構帶來的的好處主要在以下三個方面：

• 更方便的為不同的業務提供資料分析服務，對接不同的計算引擎，避免熱門資料要在不同的業務都重複儲存的問題。
• 計算層和儲存層可以按照各自業務的需求來做獨立擴縮容，一般情況下計算資源的增長速度要顯式快於儲存增長，這種方式就可以減少儲存部分的成本。
• 計算服務與儲存服務相對資源隔離，對業務穩定性也有很好的提高

—  架構目標與技術要求  —

最近幾年，存算分離架構不僅在公有云上廣泛落地，在私有化場景下，也逐漸成為熱點。但是需要特別強調的是，存算分離架構並不等同於採用相容S3介面的物件儲存來構建資料湖，也不是採用容器化來實現資源隔離或者彈性伸縮，更好的滿足業務需求是存算架構升級的一個根本原因。由於學術界沒有對這個架構有過嚴謹的討論和定義，本文嘗試對存算分離架構做一個比較抽象的定義：

存算分離架構是一種新的資料架構的設計正規化，自上而下分為資料分析層、計算層和儲存層，其中計算層和儲存層解耦合，都是獨立的分散式服務。其設計的目標是要解決三個需求：資料可以靈活開放給不同業務做資料分析、計算和儲存獨立擴充套件以及計算與儲存的資源隔離，同時也提供與存算一體架構等同的存算效能。

存算分離的架構參考示意圖如下：

• 資料的靈活開放性

這是存算分離的一個最主要的業務目標，能夠將資料更好更靈活的開放給業務分析。每個業務團隊可能有自己的資料分析的技術棧和資料架構，譬如做互動式資料分析的團隊比較依賴資料庫和BI工具構建的資料集市，而做預測性分析的團隊則依賴機器學習和資料湖等，因此存算分離架構在儲存層提供相對統一的介面，而計算層能夠支援多種計算引擎，並且可以基於儲存層的資料介面來做資料查詢和分析。這種方式的好處是大部分資料僅儲存一份，而不是每個業務使用者都儲存一份自己需要的資料結果，另外使用者做資料分析可以採用Serverless模式按需申請資料和計算資源，降低專案啟動成本，為各個業務做資料創新提供靈活性和便利性。

• 計算與儲存層獨立的可擴充套件性

這是一個非常直接的技術需求，就是儲存層和計算層的服務相對獨立，尤其是計算服務可以在沒有資料儲存的伺服器上部署，可以按照業務的特點來靈活對計算資源還是對儲存資源做擴縮容。基於Hadoop的存算一體的框架，如果計算資源不足就需要擴容叢集，此時儲存也整體擴容，這樣可能會導致儲存資源使用率低的問題。而採用存算分離架構，計算資源不足就擴容專門用於計算的伺服器而儲存資源保持不動，或者儲存資源不足的時候對儲存池進行擴容，這樣可以提高整體的資源使用率，也可以更好的管理異構伺服器。

• 提高存算的資源隔離性

存算資源的隔離性是另外一個推動存算分離架構的技術需求，在存算一體的架構中，如果計算需求增加，那麼只能在伺服器上增加計算服務，而如果資源隔離性不足，那麼計算服務和儲存服務就會爭搶同一份記憶體或計算資源，從而導致服務的穩定性下降。而如果透過架構升級保證了存算服務的資源隔離性，資料平臺本身的穩定性和可運維性就可以得到較大的提升

• 與存算一體等同的效能

除了業務目標以外，需要注意的一點，存算一體透過“計算貼近儲存”的方式來保證效能，而存算分離框架就不可避免會導致資料分析過程中有更大量的網路和儲存流量，從而需要做更多的技術創新來保證資料分析效能可以與存算一體處於同一等級，可以實現的方式可以包括更好的網路/儲存硬體以及配套的管理策略，或者是透過更好的雲排程演算法，亦或是更好的資料快取策略等方式來實現。業內已經有很多的企業在探索存算分離架構的落地，目前該架構在公有云領域落地較多，而在私有化領域該技術還在快速發展中，推動相關技術發展的有幾個流派，包括大資料平臺廠商、雲廠商、儲存廠商以及資料庫廠商。這些不同的路線在技術實現上有很多的相似性，也有各自的獨特性。

— 星環大資料平臺的存算分離—

星環科技從2015年開始探索大資料的雲化，並且選擇了Kubernetes和Docker技術來實現這一路徑，並且在2018年完成了產品化Transwarp Data Cloud並完成生產落地。在當時存算分離架構還沒有被正式提出來，而基於K8S實現的資料雲架構在技術架構上也實現了存算分離，因此我們也對相關架構設計做個詳細的闡述。

在設計上，我們將大資料平臺與服務總體抽象為四層：雲作業系統層、資料儲存層、計算層和資料應用服務層。

雲作業系統層負責將 CPU、GPU、記憶體、SSD 和 HDD 等資源抽象為一個統一的資源池，這樣無論各個伺服器的配置異構差異情況，都可以被有效的實時利用起來，提高資源有效利用率。雲作業系統層對上層遮蔽底層硬體細節，以宣告式的方式對外暴露儲存卷、CPU、GPU、記憶體等資源介面，上層資料儲存或者計算引擎可以透過宣告式的增刪資源來實現雲化的彈性擴充套件，而無需做出程式碼上的變化，這個也是當前比較流行的Infrastructure as Code的設計理念。

應用服務層同樣採用容器技術，支援微服務、傳統應用、.Net 應用等容器化並在雲平臺上執行。應用可以設定排程最佳化屬性，貼合計算或儲存來實現最最佳化效能。

在資料儲存層，我們將 HDFS、Search 等分散式儲存進一步細化為各個子服務，並將這些子服務逐步的容器化，同時為了支援高效能的資料儲存，採用了本地儲存卷的方式來支援資料儲存，而沒有使用分散式雲端儲存。這樣做的好處可以讓儲存服務的部署、運維都變得比較簡單，擴縮容與跨節點遷移雖然不能像微服務那樣平滑，但是操作因為容器化而相對比較標準化。在實際部署時，TDC允許企業內每個業務部門採用獨立租戶的方式按需啟動內部的分散式儲存，也可以讓多個租戶全域性共享同一個分散式儲存例項。由於使用本地儲存，同一個磁碟在排程上被限制為只允許一個高IO吞吐的儲存服務來使用。

在分散式計算層，TDC將資料庫計算節點和人工智慧框架Spark、TensorFlow等相關計算服務容器化，實現線上的動態排程、彈性擴縮容等。為了保證資料分析效能，我們還是延續了存算一體的思想，儘量讓計算貼近儲存，這個最佳化的思路是分散式儲存層直接提供後設資料介面讓計算引擎瞭解資料檔案的分佈情況，並將相關資訊暴露給雲作業系統排程器，排程器會透過為服務打tag等方式，將計算服務儘量貼近資料節點來執行，從而實現最最佳化的分析效率。

計算服務的動態彈性是存算分離架構的一個核心目標，由於TDC已經將內部計算引擎微服務化後以容器方式編排，基於K8S的排程編排能力就可以根據業務需求靈活的增刪例項數量，保證秒級的擴縮容效率。我們設計了基於時間週期的計算單元彈性伸縮和基於工作負載的彈性伸縮兩種排程策略。

對於主要提供批處理服務的關係型分析引擎Inceptor或提供湖倉一體能力的ArgoDB，由於夜間批處理任務和日間資料分析存在明顯的潮汐效應，因此運維管理人員可以按照各自業務的特點來選擇合適的排程策略。基於時間週期的彈性伸縮比較適合業務時間非常確定的場景，而基於工作負載的彈性伸縮在理論上使用場景更廣，不過對相關的效能指標的要求也會更高。

從最終企業使用者部署落地的效果來看，星環TDC為企業提供了一個統一的基於容器技術的多租戶存算分離架構，不同租戶在網路層隔離，實現類似公有云上的VPC的效果。不同租戶之間資料隔離，但可以透過中心資料湖裡部署的資料儲存來做資料共享。一個物理節點上可以執行分屬於不同租戶的多個不同的有狀態應用，排程器會根據資源情況來做均衡，但儲存服務與計算服務獨立排程，每個租戶的計算服務支援預設彈性，在負載低時可以使用少量計算資源，而在負載高時作業系統將自動化擴容。

— Cloudera大資料平臺的存算分離—

在解決儲存層和計算層的資源隔離性的問題上，Cloudera期望藉助於Kubernetes和Docker技術來解決服務的隔離性以及滿足資料分析的靈活性問題。從2019年開始Cloudera和Redshift合作開始研發基於容器化的大資料平臺，並於2021年開始將其機器學習產品Cloudera Machine Learning（CML）部署到Kubernetes上，這樣就讓使用者比較方便的靈活的使用CML用於機器學習的工作，達到了部分效果。不過CDP的Private Cloud Base中的儲存和計算產品（如Hive、HDFS、Hbase、Kudu、Impala等）還沒有實現基於Kubernetes的雲化交付，因此還不能靈活開放給業務，並且資源隔離上做的也不好。在實際部署落地時，如果需要能夠執行一個雲化的機器學習或者資料工程產品，還需要單獨基於裸金屬部署一個Private Cloud Base，一般資料湖是構建在Private Cloud Base上，為上層的多租戶的算力服務提供資料介面。CDP拓撲架構如下圖所示，下層Private Cloud Base是主要的儲存層，上層Private Cloud Base是主要的計算層，其存算分離的抽象的粒度比較大，是多個元件構成的一系列服務。

此外，在資料湖層為了能夠更靈活的做分離，Cloudera研發了相容S3介面的Ozone儲存專案，作為HDFS的一個補充。HDFS採用的後設資料管理模型，導致其能夠處理的檔案數量與Namenode的服務記憶體密切相關，因此存在檔案數量的上限。Ozone重新設計了後設資料管理演算法，使得管理的檔案數量上限可以達到數十億個，並且底層的資料儲存基於Hadoop Distribution Data Store，複用了原來HDFS為了效能做的很多設計並且採用Raft協議來實現了分散式一致性。

Ozone的架構圖如上，它的介面層支援多種協議，包括相容Hadoop的Ofs和O3fs，以及S3協議，並且提供了Java API和命令列支援。由於Ozone來自Hadoop社群，因此原來基於Hive、Spark等Hadoop社群元件構建的應用程式是可以平緩遷移到Ozone上，此外新的採用S3協議的應用也同樣可以支援，這比類似Ceph的技術方案在生態相容上有很大的優勢。Ozone目前剛進入GA階段，還需要持續的接受生產案例的打磨來提高其成熟度、安全性等。