云上應用系統的數據存儲架構演進
一、前言
回顧過去二十年的技術發展，整個應用形態和技術架構發生了很大的升級換代，而任何技術的發展都與幾個重要的變量相關。
1.應用形態的變遷，產生更多的場景和需求。整個應用形態從企業應用、互聯網服務再到移動應用，歷經了幾個不同階段的發展。從最早企業內應用系統，到通過移動互聯網技術覆蓋到每個人生活的方方面面，這個過程中產生了大量的場景和需求。而新的場景和需求，是推動產品和技術發展的主要因素。
2.更復雜的場景，更大規模的挑戰，推動技術的快速發展。新一代應用面臨更復雜的場景和更大的規模挑戰，老一代技術架構無法支撐業務的快速發展，所以急需推動新的技術的研究和發展。這是一個綜合的 ROI 的考慮，流量和數據到一定規模才能讓技術架構升級帶來更大的效率和成本的收益。
3.技術基礎設施的完善，提供了技術和產品發展的基礎。互聯網、4G/5G 等基礎設施的建立和完善，是新一代應用誕生和發展的基礎。分布式技術、云計算、新一代硬件等技術的成熟，是技術架構變革的基礎。
本篇文章會給大家分享應用系統數據架構的演進以及云上的架構最佳實踐，這里先對數據系統的分類做一個定義，數據系統如果按照主體來區分的話分為以下兩類：
- 應用為主體：常見的數據架構都是以『應用』為主體，數據主要產生自應用。數據架構圍繞業務來設計，通常是先定義業務模型后設計業務流程。由于業務之間區分度很大，每個業務都有截然不同的業務模型，所以數據系統需要具備高度『抽象』的能力，所以通常會選擇關系型數據庫這類抽象能力強的組件作為核心存儲。
- 數據為主體：這類數據系統通常圍繞『特定類型數據』進行構建，比如說圍繞云原生監控數據設計的以 Prometheus 為核心的監控數據系統，再比如圍繞日志數據分析設計的 ELK 數據系統。這類數據系統的設計過程通常是圍繞數據的收集、存儲、處理、查詢和分析等環節來設計整套數據系統，數據具備統一的『具象』的模型。不同的場景有不同的數據系統，當某個場景具備通用性以及得到一定規模的應用，通常在開源界會誕生一套成熟的、完整的解決方案，比如說云原生 Prometheus、ELK、Hadoop 等。
本篇文章介紹的數據架構主要是第一類，即以『應用為主體』的數據架構。
二、應用系統數據架構
應用系統數據架構歷經了多次迭代，從傳統的單一系統數據架構，到由多組件構成的現代數據架構。現代數據架構下包含不同的計算和存儲組件，這些組件在處理不同類型數據以及負載下各有優劣。現代數據架構通過合理選擇和組合這些組件，讓各個組件能發揮最大的能力，從而讓整個數據系統能滿足更多樣化的場景需求以及能支撐更大的數據規模。
1.傳統數據架構(單一系統)
LAMP 架構
一個應用系統的基本構成包括：API(提供服務接口)、應用(業務處理邏輯)、數據存儲(應用數據存儲)以及運行環境(應用和數據庫的運行環境)。互聯網早期最流行的 LAMP 架構就是典型的單一系統數據架構，其中使用 Apache Server 作為 API 層、使用 PHP 開發應用，使用 MySQL 作為應用數據存儲，所有組件均運行在 Linux 系統上。
整套架構采用開源軟件構建，相比商業軟件能提供更低的成本，所以能快速在互聯網早期的各大中小站點流行起來，成為最流行的建站技術架構。但隨著互聯網的流量越來越大，LAMP 架構面臨的最大的問題是可擴展性，需要解決應用和存儲的擴展問題。
如何進行擴展
關于擴展技術的幾個基本概念：
- Scale-up vs Scale-out
- Scale-up 即直接提升機器的配置規格，是最直接的擴展手段，計算和存儲均可通過 Scale-up 的方式來進行擴展，但擴展空間有限，相對成本較高。Scale-out 即增加更多的機器進來，是相對成本更低、更靈活的手段，但需要相關組件具備能 Scale-out 的能力。
- 存儲和計算分離
- 存儲和計算是兩個不同維度的資源，如果強綁定會極大限制擴展性。對數據系統來說，應用節點和存儲節點分離就是應用了存儲計算分離的設計思想，讓應用和存儲都能獨立擴展。
Scale-out 具備更好的靈活性和經濟性，計算和存儲進行 Scale-out 的常見技術手段包括：
- 存儲 Scale-out
- 通常采用數據分片技術，將數據分散到多臺機器上。
- 計算 Scale-out
- 基于狀態路由計算：通常用于狀態遷移代價大的數據架構，比如數據庫的分庫分表。分庫分表的擴展需要進行數據復制，所以通常需要提前規劃，根據數據所在分片來路由計算。
- 基于計算復制狀態：如果狀態能非常靈活的復制或者是共享，那可基于計算來復制狀態，是一種更靈活的計算擴展架構。比如說基于共享存儲的大數據計算架構，可靈活調度任意計算節點對數據進行處理。
- 無狀態計算：計算不依賴任何狀態，可以發生在任意節點上，所以計算節點可非常容易實現 Scale-out，但需要解決計算調度問題。常見 Web 應用中的 LoadBalancer 后置一堆 Web Server 就是一個簡單的無狀態計算擴展架構。
- 有狀態計算：計算依賴狀態，計算的擴展依賴狀態的遷移。如果狀態不可遷移，那計算的擴展只能采取 Scale-up 的方式。如果狀態可遷移，那計算就可實現 Scale-out，此時計算的可擴展性依賴于狀態遷移的靈活性。對于可 Scale-out 的計算我們分為兩類實現方式，分別是：
可擴展的傳統數據架構
LAMP 架構應用上面提到的擴展技術，演變成了上圖的可擴展的數據架構。應用側通常是無狀態計算，所以可以簡單采取 Scale-out 的擴展方式，前置 Load Balancer 來進行流量調度。存儲側采取分庫分表的方式來進行存儲和計算的擴展，以及只讀庫的方式來對查詢計算進行擴展。雖然各層具備了擴展能力，但該系統還存在一些問題：
- 存儲側擴展靈活性差，擴展成本較高：計算側通常是無狀態計算節點，擴展相對靈活。但存儲側的擴展需要進行數據復制遷移，擴展周期長且靈活性差。同時 MySQL 的分庫分表每次擴展需要雙倍資源，成本也較高。
- 單一存儲系統，提供的能力有限：MySQL 作為關系模型數據庫，在業務模型抽象上提供極強的抽象能力，所以可以說是一個萬能存儲。在互聯網早期應用負載不高的情況下，MySQL 是最優選擇，且已經擁有了成熟的擴展方案。但是隨著應用場景和負載不斷變化，MySQL 還是難以承載。
- 存儲成本高：簡單來說，關系數據庫是結構化數據存儲單位成本最高的存儲系統。
如何解決存儲側擴展問題
MySQL 不是萬能的，但 MySQL 對應用系統來說是不可替換的，到目前為止都是這樣。雖然現在有更多新的云原生關系數據庫出現來取代傳統 MySQL 的位置，但本質上都脫不了 MySQL 這個殼，只是更強大的 MySQL 而已。所以很多解決方案都是圍繞 MySQL 作為輔助方案而不是替換方案出現，比如說 Memcached/Redis 這類緩存系統，幫助 MySQL 抵御大部分查詢流量，來解決 MySQL 容易被查詢打崩的問題。
這個設計思想是『分而治之』，將原本 MySQL 所承擔的職責進行細分，能分離解決的就分離解決。現代數據架構就是基于此思路，仍然以 MySQL 作為應用交互和業務數據存儲的核心，但是使用一些輔助方案解決 MySQL 的問題。
2.現代數據架構(多樣化系統)
定義問題，分而治之
前面提到 MySQL 是應用系統數據架構的核心存儲，且是不可替換的組件。MySQL 直接承載業務數據和大部分業務交互，現代數據架構的演進思路是圍繞 MySQL 提供輔助解決方案，采用『分而治之』的設計思路。所以我們首先得羅列清楚在單一系統架構中 MySQL 所承擔的職責，以及明確哪些點是可以分而治之的。分而治之的具體手段包括：
- 流量卸載：承載和抵御 MySQL 的部分讀寫流量，讓 MySQL 有更多資源進行事務處理。由于讀和寫依賴 MySQL 內數據，所以在卸載流量的同時還會復制全部或者部分數據。
- 數據卸載：MySQL 內部分數據會用于事務處理，而部分數據僅存儲和查詢。不參與事務處理的數據可卸載，來降低表的存儲量，對降成本和減負載都是有極大好處的。
為方便理解對 MySQL 承載的職責的具體含義，我們對應到一個實際場景來解釋對應的職責，我們以『電商訂單』系統來進行舉例。
事務處理一般是需要根據數據庫內的一致的狀態決定操作的執行，必須要有 ACID 的保證，這部分只能由 MySQL 來承載。MySQL 的大部分查詢流量都是可被卸載的，最簡單的是創建只讀庫來卸載查詢流量，但某些復雜查詢操作只讀庫無法很高效的執行，必須依賴外部存儲來加速，比如說數據搜索和數據分析。所以這部分流量需要卸載，并且需要復制部分或者全部數據。另外 MySQL 內存儲的數據并不會都用于事務處理，很大一部分數據在生成后僅提供查詢或非事務型操作，這部分數據的查詢流量和存儲都是可被卸載的。
我們把職責給定義清楚后，也明確了哪些職責是 MySQL 主要承擔的，哪些職責是可以被卸載從而得以有效的『分而治之』的。
在理清了整個解決問題的思路后，接下來才是對架構師最大的挑戰：如何選擇合適的組件來卸載流量或者存儲?
選擇合適的存儲組件
1)根據場景定義需求
準確的定義需求是選對組件的前置條件，切勿僅根據功能性需求來進行匹配，還需考慮一些基礎性需求，例如存儲組件可提供的 SLA、數據可靠性、擴展性、可運維性等等。從上面的表中，我們能夠非常清晰的看到對各組件的功能性需求，那接下來我們再看看基礎性需求如何區分和選擇。
在做數據系統設計時可以把應用數據嘗試落在上圖的不同周期內，看下如何對存儲組件定義合適的基礎性需求。通常應用系統最先產生的是事務數據，事務數據會逐步向在線數據、離線數據轉換和流動，在線性逐步降低，從面向前臺逐步轉向后臺。再看從事務數據到離線數據，基礎性要求的具體變化：
- SLA 要求逐步從高到底，在線系統對穩定性要求極高，而后臺系統相對來說要求可放低。
- 從 TP 逐步轉向 AP，TP 對訪問延遲要求更高，而 AP 對分析能力要求更高。
- 數據的更新頻率逐步降低，逐步歸檔為不可變數據，所以很多離線系統都是基于數據的不可變性來做存儲和計算優化。
- 存儲成本逐步降低，數據規模逐步增大。
2)存儲組件的種類和差異
先從宏觀層面比較下數據庫類存儲組件的差異：
- 數據模型和查詢語言：這兩個點仍然是不同數據庫最顯著的區別。關系模型、文檔模型和寬表模型是相對抽象的模型，而類似時序模型和圖模型等其他非關系模型是相對具象的模型。抽象模型表達力更強，而具象模型更貼近具體場景。
- SQL vs NoSQL：SQL 類更適合事務處理，包含開源或商業關系數據庫;NoSQL 類更適合非事務數據處理，基本是以開源為主;場景使用上可以與 SQL 類配合使用，提供流量卸載和存儲卸載;另外 NoSQL 類更多是具象模型，貼近場景而生。
- 數據庫 vs 數據倉庫：數據倉庫更偏離線數據分析，提供更大規模存儲，但是在 SLA 和穩定性方面相比數據庫略差。
- 云托管 vs 云原生：云原生的本質是利用云上池化資源來實現更強的彈性，所以簡單把一個開源軟件托管在云上，并不能稱之為云原生。云原生帶來的優勢是更低使用成本、更低運維成本、更靈活的數據流轉以及更彈性的架構。
我們看下當前主流開源數據庫以及對應的云原生數據庫產品的對比：
在做存儲組件選型時，要考慮功能性需求和基礎性需求，選擇合適的存儲組件。以上表格只是列舉了部分場景和其中推薦的產品，這些產品不是唯一選擇也不一定是最適合的選擇，因業務不同發展階段和需求而異。選擇對存儲組件是一件很難的事，所以架構師在設計數據架構時，要提前考慮到存儲組件的新增或替換，數據架構必須具備這樣的靈活性，因為『構建快速迭代能力比應對未知需求的擴展性更重要』。
在一個復雜的應用系統中，必然會存在多套存儲組件的組合，而不是單一的存儲組件來支撐所有的場景和流量，所以架構師還得面臨下一個難題：如何合理的組合這些存儲組件?
合理的進行組合
1)派生數據架構
在數據系統架構中，我們可以看到會存在多套存儲組件。對于這些存儲組件中的數據，有些是來自應用的直寫，有些是來自其他存儲組件的數據復制。例如業務關系數據庫的數據通常是來自業務，而高速緩存和搜索引擎的數據，通常是來自業務數據庫的數據同步與復制。不同用途的存儲組件有不同類型的上下游數據鏈路，我們可以大概將其歸類為主存儲和輔存儲兩類，這兩類存儲有不同的設計目標，主要特征為：
- 主存儲：數據產生自業務或者是計算，通常為數據首先落地的存儲。在應用系統數據架構中，MySQL 就是主存儲。
- 輔存儲：數據主要來自主存儲的數據同步與復制，輔存儲是主存儲的某個視圖，通常面向數據查詢、檢索和分析做優化。在應用系統數據架構中，承擔流量卸載或存儲卸載的存儲組件，就是輔存儲。
這種主與輔的存儲組件相輔相成的架構設計，我們稱之為『派生數據體系』。在這個體系下，最大的技術挑戰是數據如何在主與輔之間進行同步與復制。
上圖我們可以看到幾個常見的數據復制方式：
- 應用層多寫：這是實現最簡單、依賴最少的一種實現方式，通常采取的方式是在應用代碼中先向主存儲寫數據，后向輔存儲寫數據。這種方式不是很嚴謹，通常用在對數據可靠性要求不是很高的場景。因為存在的問題有很多，一是很難保證主與輔之間的數據一致性，無法處理數據寫入失效問題;二是數據寫入的消耗堆積在應用層，加重應用層的代碼復雜度和計算負擔，不是一種解耦很好的架構;三是擴展性較差，數據同步邏輯固化在代碼中，比較難靈活添加輔存儲。
- 異步隊列復制：這是目前被應用比較廣的架構，應用層將派生數據的寫入通過隊列來異步化和解耦。這種架構下可將主存儲和輔存儲的數據寫入都異步化，也可僅將輔存儲的數據寫入異步化。第一種方式必須接受主存儲可異步寫入，否則只能采取第二種方式。而如果采用第二種方式的話，也會遇到和上一種『應用層多寫』方案類似的問題，應用層也是多寫，只不過是寫主存儲與隊列，隊列來解決多個輔存儲的寫入和擴展性問題。
- CDC(Change Data Capture)技術：這種架構下數據寫入主存儲后會由主存儲再向輔存儲進行同步，對應用層是最友好的，只需要與主存儲打交道。主存儲到輔存儲的數據同步，則可以再利用異步隊列復制技術來做。不過這種方案對主存儲的能力有很高的要求，必須要求主存儲能支持 CDC 技術。
『派生數據體系』是一個比較重要的技術架構設計理念，其中 CDC 技術是更好的驅動數據流動的關鍵手段。具備 CDC 技術的存儲組件，才能更好的支撐數據派生體系，從而能讓整個數據系統架構更加靈活，降低了數據一致性設計的復雜度，從而來面向高速迭代設計。MySQL 的 CDC 技術是比較成熟的，也演化出來一些中間件和云產品，比如 Canal 以及阿里云的 DTS。所以在我們的現代應用系統數據架構中，也主要是基于 MySQL 的 CDC 技術來進行數據派生。
現代應用系統數據架構
上圖就是一個典型的現代應用系統數據架構，我們來系統的看下：
1.由多存儲組件構成，每個存儲組件各司其職：
- MySQL：承載事務處理，為整個數據架構的主存儲，其余組件承擔流量卸載和存儲卸載的職責。
- Redis：作為 MySQL 的查詢結果集緩存，幫助 MySQL 來抵御大部分的查詢流量，但 Redis 如果失效，則會有擊穿 MySQL的風險。
- Elasticsearch：倒排索引和搜索引擎技術能提供 MySQL 索引所無法支持的高效模糊查詢、全文檢索和多字段組合條件過濾的能力，所以主要是承擔復雜查詢的流量卸載。
- HBase：分布式 KV 存儲，提供寬表模型。可用于卸載 MySQL 內非事務性數據，可存儲 MySQL 內所有表的全量數據，提供低成本的存儲卸載。HBase 也是一個在線系統，所以也能提供簡單查詢的流量卸載。
- ClickHouse：MPP 架構的開源數倉，具備非常優異的分析性能，主要職責是分析流量卸載。
2.基于 MySQL CDC 的派生數據架構，由開源產品 Canal 來做實時數據同步。但這里 ClickHouse 的數據同步并不一定需要是實時增量的，也可采用 T+1 的全量同步方式。
3.應用系統需要與這些不同組件分別進行交互，且交互接口各不相同。
這個架構具備一定的靈活性，通過 Canal 來解決異構存儲間的數據同步問題，通過插件機制可靈活增加新的存儲組件來應對未來的新的需求。每個組件都是開源界打磨多年的成熟產品，也有一些中間件來降低應用與這些組件的交互成本。但也存在一些明顯的問題：
- 運維成本極大：運維是一門技術活，需要對組件的原理有比較清楚的了解才能更好的運維，以及進行線上問題的排查和優化。這些開源產品已經將使用成本降的足夠低，但是運維成本還是很高，比如 HBase 組件的運維還需要額外運維 Zookeeper、HDFS 等。云托管產品降低了一定的運維成本，但仍無法做到免運維，業務 OPS 仍需要花大量精力在性能調優、容量規劃等工作上。另外多組件會比單組件運維成本更高，因為還需要管理組件間的數據流。
- 多 API 交互復雜：每個組件都提供了不盡相同的 API，應用與不同組件的交互很難抽象和解耦。
- 成本高：每一個新的組件的引入都需要額外的存儲和計算成本，但各組件的偏向不一樣，有的更重計算有的更重存儲。如果多組件間能共享計算或存儲，那能極大的降低成本。而在當前的架構中，每個組件都是相互獨立的，需要獨享存儲和計算資源。
三、云上數據架構實踐
把現代數據架構搬到云上，可利用云的優勢來優化整套架構：一是找到合適的云原生產品替換開源產品，最大好處是降低運維成本，其次能獲得更強的穩定性和性能;二是用更少的組件做更多的事，來降低管理和使用成本，也能降低應用交互開發復雜度。
以上就是完整的云上數據架構，重點講下替換開源組件的幾個云產品：
- DTS(數據傳輸服務)：原理與 Canal 類似，能對接更多數據庫上游和下游，全托管的 MySQL 實時數據同步中間件。
- Tair(Redis 企業版)：阿里自研企業級緩存，兼容 Redis 協議，具備更強的性能。
- Tablestore(表格存儲)：阿里自研 Bigtable，提供兼容 HBase 的寬表引擎，以及能力和性能都優于 Elasticsearch 的索引引擎。純 Serverless 免運維能最大程度降低運維成本，同時提供 API 和 SQL 的接口降低應用開發成本。
- ADB(分析型數據庫)：阿里自研實時數倉，具備強大的分析性能，完全兼容 MySQL 協議。
接下來我們再重點提下 Tablestore，因為在應用系統在線場景，Tablestore 承載了流量卸載和存儲卸載的重要職責。Tair 的使用和定位與 Redis 完全一致，而 Tablestore 相比 HBase 和 Elasticsearch 有更大的差異性。
1.表格存儲 Tablestore
表格存儲 Tablestore 是阿里云自研的面向海量結構化和半結構化數據存儲的 Serverless 多模型結構化數據存儲，被廣泛用于社交、物聯網、人工智能、元數據和大數據等業務場景。采用與 Google Bigtable 類似的寬表模型，天然的分布式架構，能支撐高吞吐的數據寫入以及 PB 級數據存儲，具體產品介紹可以參考官網以及權威指南。
Tablestore 提供兼容 HBase 的寬表引擎，以及能力和性能都優于 Elasticsearch 的索引引擎，它的核心能力包括：
- 多模型：提供抽象模型 WideColumn 寬表模型，以及具象模型 Timeline 消息模型以及 Timestream 時序模型。具象模型更適合應用與應用系統，而具象模型是圍繞具體場景的數據架構而設計和深度優化。
- 多元化索引：提供二級索引和多元索引，不同查詢加速場景提供不同的索引實現，其中多元索引能提供全文檢索、地理位置檢索以及靈活的多條件組合查詢，功能和性能都優于 Elasticsearch。
- 存儲計算分離架構：提供計算和存儲側的靈活擴展能力，不僅體現在架構上，也體現在產品形態上。用戶可以單獨為存儲付費或為計算付費，提供更靈活的資源組合，獲得最低的成本。
- Serverless 服務：純 Serverless 服務，提供完全免運維的服務，全球部署、即開即用。零成本即可接入，最大可擴展至千萬 TPS 服務能力以及 PB 級存儲。
- 計算生態：能夠與開源計算引擎對接，融合流批一體計算能力。同時自身提供 CDC 能力，讓數據能夠更靈活的進行流轉。
- CDC 技術：Tablestore 的 CDC 技術名為 Tunnel Service，支持全量和增量的實時數據訂閱，并且能無縫對接 Flink 流計算引擎來實現表內數據的實時流計算。
- SQL 支持：提供 SQL 支持，大大降低使用和應用開發門檻。
四、總結
技術架構的選擇沒有統一標準答案，是一個綜合的權衡考慮。本文主要介紹了應用系統數據架構的變遷，相信隨著應用場景越來越復雜、更多需求的提出，隨著底層基礎設施的完善，會有更多新技術和產品出現，而數據架構也會繼續演進。但是一些經典的設計思想會保留，例如分而治之、派生數據架構、如何靈活的選擇和組合存儲和計算組件等。以通過以下二維碼關注。轉載本文請聯系C you again公眾號。
【本文為51CTO專欄作者“阿里巴巴官方技術”原創稿件，轉載請聯系原作者】
