結構化數據存儲，如何設計才能知足需求？

阿里妹導讀：任何應用系統都離不開對數據的處理，數據也是驅動業務創新以及向智能化發展最核心的東西。數據處理的技術已是核心競爭力。在一個完備的技術架構中，一般也會由應用系統以及數據系統構成。應用系統負責處理業務邏輯，而數據系統負責處理數據。本篇文章主要面向數據系統的研發工程師和架構師，但願對你有所啓發。

前言

傳統的數據系統就是所謂的『大數據』技術，這是一個被創造出來的名詞，表明着新的技術門檻。近幾年得益於產業的發展、業務的創新、數據的爆發式增加以及開源技術的普遍應用，經歷多年的磨鍊以及在廣大開發者的共建下，大數據的核心組件和技術架構日趨成熟。特別是隨着雲的發展，讓『大數據』技術的使用門檻進一步下降，愈來愈多的業務創新會由數據來驅動完成。

『大數據』技術會逐步向輕量化和智能化方向發展，最終也會成爲一個研發工程師的必備技能之一，而這個過程必須是由雲計算技術來驅動以及在雲平臺之上才能完成。應用系統和數據系統也會逐漸融合，數據系統再也不隱藏在應用系統以後，而是也會貫穿在整個業務交互邏輯。傳統的應用系統，重點在於交互。而現代的應用系統，在與你交互的同時，會慢慢地熟悉你。數據系統的發展驅動了業務系統的發展，從業務化到規模化，再到智能化。

• 業務化：完成最基本的業務交互邏輯。
• 規模化：分佈式和大數據技術的應用，知足業務規模增加的需求以及數據的積累。
• 智能化：人工智能技術的應用，挖掘數據的價值，驅動業務的創新。

向規模化和智能化的發展，仍然存在必定的技術門檻。成熟的開源技術的應用能讓一個大數據系統的搭建變得簡單，同時大數據架構也變得很廣泛，例如廣爲人知的Lambda架構，必定程度上下降了技術的入門門檻。可是對數據系統的後續維護，例如對大數據組件的規模化應用、運維管控和成本優化，須要掌握大數據、分佈式技術及複雜環境下定位問題的能力，仍然具有很高的技術門檻。

數據系統的核心組件包含數據管道、分佈式存儲和分佈式計算，數據系統架構的搭建會是使用這些組件的組合拼裝。每一個組件各司其職，組件與組件之間進行上下游的數據交換，而不一樣模塊的選擇和組合是架構師面臨的最大的挑戰。

本篇文章主要面向數據系統的研發工程師和架構師，咱們會首先對數據系統核心組件進行拆解，介紹每一個組件下對應的開源組件以及雲上產品。以後會深刻剖析數據系統中結構化數據的存儲技術，介紹阿里雲Tablestore選擇哪一種設計理念來更好的知足數據系統中對結構化數據存儲的需求。

數據系統架構

核心組件

上圖是一個比較典型的技術架構，包含應用系統和數據系統。這個架構與具體業務無關聯，主要用於體現一個數據應用系統中會包含的幾大核心組件，以及組件間的數據流關係。應用系統主要實現了應用的主要業務邏輯，處理業務數據或應用元數據等。數據系統主要對業務數據及其餘數據進行彙總和處理，對接BI、推薦或風控等系統。整個系統架構中，會包含如下比較常見的幾大核心組件：

關係數據庫：用於主業務數據存儲，提供事務型數據處理，是應用系統的核心數據存儲。

高速緩存：對複雜或操做代價昂貴的結果進行緩存，加速訪問。

搜索引擎：提供複雜條件查詢和全文檢索。

隊列：用於將數據處理流程異步化，銜接上下游對數據進行實時交換。異構數據存儲之間進行上下游對接的核心組件，例如數據庫系統與緩存系統或搜索系統間的數據對接。也用於數據的實時提取，在線存儲到離線存儲的實時歸檔。

非結構化大數據存儲：用於海量圖片或視頻等非結構化數據的存儲，同時支持在線查詢或離線計算的數據訪問需求。

結構化大數據存儲：在線數據庫也可做爲結構化數據存儲，但這裏提到的結構化數據存儲模塊，更偏在線到離線的銜接，特徵是能支持高吞吐數據寫入以及大規模數據存儲，存儲和查詢性能可線性擴展。可存儲面向在線查詢的非關係型數據，或者是用於關係數據庫的歷史數據歸檔，知足大規模和線性擴展的需求，也可存儲面向離線分析的實時寫入數據。

批量計算：對非結構化數據和結構化數據進行數據分析，批量計算中又分爲交互式分析和離線計算兩類，離線計算須要知足對大規模數據集進行復雜分析的能力，交互式分析須要知足對中等規模數據集實時分析的能力。

流計算：對非結構化數據和結構化數據進行流式數據分析，低延遲產出實時視圖。

對於數據存儲組件咱們再進一步分析，當前各種數據存儲組件的設計是爲知足不一樣場景下數據存儲的需求，提供不一樣的數據模型抽象，以及面向在線和離線的不一樣的優化偏向。咱們來看下下面這張詳細對比表：

派生數據體系

在數據系統架構中，咱們能夠看到會存在多套存儲組件。對於這些存儲組件中的數據，有些是來自應用的直寫，有些是來自其餘存儲組件的數據複製。例如業務關係數據庫的數據一般是來自業務，而高速緩存和搜索引擎的數據，一般是來自業務數據庫的數據同步與複製。不一樣用途的存儲組件有不一樣類型的上下游數據鏈路，咱們能夠大概將其歸類爲主存儲和輔存儲兩類，這兩類存儲有不一樣的設計目標，主要特徵爲：

• 主存儲：數據產生自業務或者是計算，一般爲數據首先落地的存儲。ACID等事務特性多是強需求，提供在線應用所需的低延遲業務數據查詢。
• 輔存儲：數據主要來自主存儲的數據同步與複製，輔存儲是主存儲的某個視圖，一般面向數據查詢、檢索和分析作優化。

爲什麼會有主存儲和輔存儲的存在？能不能統一存儲統一讀寫，知足全部場景的需求呢？目前看尚未，存儲引擎的實現技術有多種，選擇行存仍是列存，選擇B+tree仍是LSM-tree，存儲的是不可變數據、頻繁更新數據仍是時間分區數據，是爲高速隨機查詢仍是高吞吐掃描設計等等。數據庫產品目前也是分兩類，TP和AP，雖然在往HTAP方向走，但實現方式仍然是底層存儲分爲行存和列存。

再來看主輔存儲在實際架構中的例子，例如關係數據庫中主表和二級索引表也能夠看作是主與輔的關係，索引表數據會隨着主表數據而變化，強一致同步而且爲某些特定條件組合查詢而優化。關係數據庫與高速緩存和搜索引擎也是主與輔的關係，採用知足最終一致的數據同步方式，提供高速查詢和檢索。在線數據庫與數倉也是主與輔的關係，在線數據庫內數據集中複製到數倉來提供高效的BI分析。

這種主與輔的存儲組件相輔相成的架構設計，咱們稱之爲『派生數據體系』。在這個體系下，最大的技術挑戰是數據如何在主與輔之間進行同步與複製。

上圖咱們能夠看到幾個常見的數據複製方式：

• 應用層多寫：這是實現最簡單、依賴最少的一種實現方式，一般採起的方式是在應用代碼中先向主存儲寫數據，後向輔存儲寫數據。這種方式不是很嚴謹，一般用在對數據可靠性要求不是很高的場景。由於存在的問題有不少，一是很難保證主與輔之間的數據一致性，沒法處理數據寫入失效問題；二是數據寫入的消耗堆積在應用層，加劇應用層的代碼複雜度和計算負擔，不是一種解耦很好的架構；三是擴展性較差，數據同步邏輯固化在代碼中，比較難靈活添加輔存儲。
• 異步隊列複製：這是目前被應用比較廣的架構，應用層將派生數據的寫入經過隊列來異步化和解耦。這種架構下可將主存儲和輔存儲的數據寫入都異步化，也可僅將輔存儲的數據寫入異步化。第一種方式必須接受主存儲可異步寫入，不然只能採起第二種方式。而若是採用第二種方式的話，也會遇到和上一種『應用層多寫』方案相似的問題，應用層也是多寫，只不過是寫主存儲與隊列，隊列來解決多個輔存儲的寫入和擴展性問題。
• CDC（Change Data Capture）技術：這種架構下數據寫入主存儲後會由主存儲再向輔存儲進行同步，對應用層是最友好的，只須要與主存儲打交道。主存儲到輔存儲的數據同步，則能夠再利用異步隊列複製技術來作。不過這種方案對主存儲的能力有很高的要求，必需要求主存儲能支持CDC技術。一個典型的例子就是MySQL+Elasticsearch的組合架構，Elasticsearch的數據經過MySQL的binlog來同步，binlog就是MySQL的CDC技術。

『派生數據體系』是一個比較重要的技術架構設計理念，其中CDC技術是更好的驅動數據流動的關鍵手段。具有CDC技術的存儲組件，才能更好的支撐數據派生體系，從而能讓整個數據系統架構更加靈活，下降了數據一致性設計的複雜度，從而來面向高速迭代設計。惋惜的是大多數存儲組件不具有CDC技術，例如HBase。而阿里雲Tablestore具有很是成熟的CDC技術，CDC技術的應用也推進了架構的創新，這個在下面的章節會詳細介紹。

一個好的產品，在產品內部會採用派生數據架構來不斷擴充產品的能力，能將派生的過程透明化，內部解決數據同步、一致性及資源配比問題。而現實中大多數技術架構採用產品組合的派生架構，須要本身去管理數據同步與複製等問題，例如常見的MySQL+Elasticsearch，或HBase+Solr等。這種組合一般被忽視的最大問題是，在解決CDC技術來實時複製數據後，如何解決數據一致性問題？如何追蹤數據同步延遲？如何保證輔存儲與主存儲具有相同的數據寫入能力？

存儲組件的選型

架構師在作架構設計時，最大的挑戰是如何對計算組件和存儲組件進行選型和組合，同類的計算引擎的差別化相對不大，一般會優先選擇成熟和生態健全的計算引擎，例如批量計算引擎Spark和流計算引擎Flink。而對於存儲組件的選型是一件很是有挑戰的事，存儲組件包含數據庫（又分爲SQL和NoSQL兩類，NoSQL下又根據各種數據模型細分爲多類）、對象存儲、文件存儲和高速緩存等不一樣類別。帶來存儲選型複雜度的主要緣由是架構師須要綜合考慮數據分層、成本優化以及面向在線和離線的查詢優化偏向等各類因素，且當前的技術發展仍是多樣化的發展趨勢，不存在一個存儲產品能知足全部場景下的數據寫入、存儲、查詢和分析等需求。有一些經驗能夠分享給你們：

• 數據模型和查詢語言仍然是不一樣數據庫最顯著的區別，關係模型和文檔模型是相對抽象的模型，而相似時序模型、圖模型和鍵值模型等其餘非關係模型是相對具象的抽象，若是場景能匹配到具象模型，那選擇範圍能縮小點。
• 存儲組件一般會劃分到不一樣的數據分層，選擇面向規模、成本、查詢和分析性能等不一樣維度的優化偏向，選型時須要考慮清楚對這部分數據存儲所要求的核心指標。
• 區分主存儲仍是輔存儲，對數據複製關係要有明確的梳理。（主存儲和輔存儲是什麼在下一節介紹）
• 創建靈活的數據交換通道，知足快速的數據搬遷和存儲組件間的切換能力，構建快速迭代能力比應對未知需求的擴展性更重要。

另外關於數據存儲架構，我認爲最終的趨勢是：

1. 數據必定須要分層
2. 數據最終的歸屬地必定是OSS
3. 會由一個統一的分析引擎來統一分析的入口，並提供統一的查詢語言

結構化大數據存儲

定位

結構化大數據存儲在數據系統中是一個很是關鍵的組件，它起的一個很大的做用是鏈接『在線』和『離線』。做爲數據中臺中的結構化數據彙總存儲，用於在線數據庫中數據的彙總來對接離線數據分析，也用於離線數據分析的結果集存儲來直接支持在線查詢或者是數據派生。根據這樣的定位，咱們總結下對結構化大數據存儲的幾個關鍵需求。

關鍵需求

大規模數據存儲：結構化大數據存儲的定位是集中式的存儲，做爲在線數據庫的彙總（大寬表模式），或者是離線計算的輸入和輸出，必需要能支撐PB級規模數據存儲。

高吞吐寫入能力：數據從在線存儲到離線存儲的轉換，一般是經過ETL工具，T+1式的同步或者是實時同步。結構化大數據存儲須要能支撐多個在線數據庫內數據的導入，也要能承受大數據計算引擎的海量結果數據集導出。因此必須能支撐高吞吐的數據寫入，一般會採用一個爲寫入而優化的存儲引擎。

豐富的數據查詢能力：結構化大數據存儲做爲派生數據體系下的輔存儲，須要爲支撐高效在線查詢作優化。常見的查詢優化包括高速緩存、高併發低延遲的隨機查詢、複雜的任意字段條件組合查詢以及數據檢索。這些查詢優化的技術手段就是緩存和索引，其中索引的支持是多元化的，面向不一樣的查詢場景提供不一樣類型的索引。例如面向固定組合查詢的基於B+tree的二級索引，面向地理位置查詢的基於R-tree或BKD-tree的空間索引或者是面向多條件組合查詢和全文檢索的倒排索引。

存儲和計算成本分離：存儲計算分離是目前一個比較熱的架構實現，對於通常應用來講比較難體會到這個架構的優點。在雲上的大數據系統下，存儲計算分離才能徹底發揮優點。存儲計算分離在分佈式架構中，最大的優點是能提供更靈活的存儲和計算資源管理手段，大大提升了存儲和計算的擴展性。對成本管理來講，只有基於存儲計算分離架構實現的產品，才能作到存儲和計算成本的分離。

存儲和計算成本的分離的優點，在大數據系統下會更加明顯。舉一個簡單的例子，結構化大數據存儲的存儲量會隨着數據的積累愈來愈大，可是數據寫入量是相對平穩的。因此存儲須要不斷的擴大，可是爲了支撐數據寫入或臨時的數據分析而所需的計算資源，則相對來講比較固定，是按需的。

數據派生能力：一個完整的數據系統架構下，須要有多個存儲組件並存。而且根據對查詢和分析能力的不一樣要求，須要在數據派生體系下對輔存儲進行動態擴展。因此對於結構化大數據存儲來講，也須要有能擴展輔存儲的派生能力，來擴展數據處理能力。而判斷一個存儲組件是否具有更好的數據派生能力，就看是否具有成熟的CDC技術。

計算生態：數據的價值須要靠計算來挖掘，目前計算主要劃爲批量計算和流計算。對於結構化大數據存儲的要求，一是須要可以對接主流的計算引擎，例如Spark、Flink等，做爲輸入或者是輸出；二是須要有數據派生的能力，將自身數據轉換爲面向分析的列存格式存儲至數據湖系統；三是自身提供交互式分析能力，更快挖掘數據價值。
知足第一個條件是最基本要求，知足第二和第三個條件纔是加分項。

開源產品

目前開源界比較知名的結構化大數據存儲是HBase和Cassandra，Cassandra是WideColumn模型NoSQL類別下排名Top-1的產品，在國外應用比較普遍。但這裏咱們重點提下HBase，由於在國內的話相比Cassandra會更流行一點。

HBase是基於HDFS的存儲計算分離架構的WideColumn模型數據庫，擁有很是好的擴展性，能支撐大規模數據存儲，它的優勢爲：

• 存儲計算分離架構：底層基於HDFS，分離的架構可帶來存儲和計算各自彈性擴展的優點，與計算引擎例如Spark可共享計算資源，下降成本。
• LSM存儲引擎：爲寫入優化設計，能提供高吞吐的數據寫入。
• 開發者生態成熟，接入主流計算引擎：做爲發展多年的開源產品，在國內也有比較多的應用，開發者社區很成熟，對接幾大主流的計算引擎。

HBase有其突出的優勢，但也有幾大不可忽視的缺陷：

查詢能力弱：提供高效的單行隨機查詢以及範圍掃描，複雜的組合條件查詢必須使用Scan+Filter的方式，稍不注意就是全表掃描，效率極低。HBase的Phoenix提供了二級索引來優化查詢，但和MySQL的二級索引同樣，只有符合最左匹配的查詢條件才能作索引優化，可被優化的查詢條件很是有限。

數據派生能力弱：前面章節提到CDC技術是支撐數據派生體系的核心技術，HBase不具有CDC技術。HBase Replication具有CDC的能力，可是僅爲HBase內部主備間的數據同步機制。有一些開源組件利用其內置Replication能力來嘗試擴展HBase的CDC技術，例如用於和Solr同步的Lily Indexer，可是比較惋惜的是這類組件從理論和機制上分析就無法作到CDC技術所要求的數據保序、最終一致性保證等核心需求。

成本高：前面提到結構化大數據存儲的關鍵需求之一是存儲與計算的成本分離，HBase的成本取決於計算所需CPU核數成本以及磁盤的存儲成本，基於固定配比物理資源的部署模式下CPU和存儲永遠會有一個沒法下降的最小比例關係。即隨着存儲空間的增大，CPU核數成本也會相應變大，而不是按實際所需計算資源來計算成本。要達到徹底的存儲與計算成本分離，只有雲上的Serverless服務模式才能作到。

運維複雜：HBase是標準的Hadoop組件，最核心依賴是Zookeeper和HDFS，沒有專業的運維團隊幾乎沒法運維。

熱點處理能力差：HBase的表的分區是Range Partition的方式，相比Hash Partition的模式最大的缺陷就是會存在嚴重的熱點問題。HBase提供了大量的最佳實踐文檔來指引開發者在作表的Rowkey設計的時候避免熱點，例如採用hash key，或者是salted-table的方式。但這兩種方式下能保證數據的分散均勻，可是沒法保證數據訪問的熱度均勻。訪問熱度取決於業務，須要一種能根據熱度來對Region進行Split或Move等負載均衡的自動化機制。

國內的高級玩家大多會基於HBase作二次開發，基本都是在作各類方案來彌補HBase查詢能力弱的問題，根據自身業務查詢特點研發本身的索引方案，例如自研二級索引方案、對接Solr作全文索引或者是針對區分度小的數據集的bitmap索引方案等等。總的來講，HBase是一個優秀的開源產品，有不少優秀的設計思路值得借鑑。

Tablestore

Tablestore是阿里雲自研的結構化大數據存儲產品，具體產品介紹能夠參考官網以及權威指南。Tablestore的設計理念很大程度上顧及了數據系統內對結構化大數據存儲的需求，而且基於派生數據體系這個設計理念專門設計和實現了一些特點的功能。

| 設計理念

Tablestore的設計理念一方面吸取了優秀開源產品的設計思路，另外一方面也是結合實際業務需求演化出了一些特點設計方向，簡單歸納下Tablestore的技術理念：

• 存儲計算分離架構：採用存儲計算分離架構，底層基於飛天盤古分佈式文件系統，這是實現存儲計算成本分離的基礎。
• LSM存儲引擎：LSM和B+tree是主流的兩個存儲引擎實現，其中LSM專爲高吞吐數據寫入優化，也能更好的支持數據冷熱分層。
• Serverless產品形態：基於存儲計算分離架構來實現成本分離的最關鍵因素是Serverless服務化，只有Serverless服務才能作到存儲計算成本分離。大數據系統下，結構化大數據存儲一般會須要按期的大規模數據導入，來自在線數據庫或者是來自離線計算引擎，在此時須要有足夠的計算能力能接納高吞吐的寫入，而平時可能僅須要比較小的計算能力，計算資源要足夠的彈性。另外在派生數據體系下，主存儲和輔存儲一般是異構引擎，在讀寫能力上均有差別，有些場景下須要靈活調整主輔存儲的配比，此時也須要存儲和計算資源彈性可調。
• 多元化索引，提供豐富的查詢能力：LSM引擎特性決定了查詢能力的短板，須要索引來優化查詢。而不一樣的查詢場景須要不一樣類型的索引，因此Tablestore提供多元化的索引來知足不一樣類型場景下的數據查詢需求。
• CDC技術：Tablestore的CDC技術名爲Tunnel Service，支持全量和增量的實時數據訂閱，而且能無縫對接Flink流計算引擎來實現表內數據的實時流計算。
• 擁抱開源計算生態：除了比較好的支持阿里雲自研計算引擎如MaxCompute和Data Lake Analytics的計算對接，也能支持Flink和Spark這兩個主流計算引擎的計算需求，無需數據搬遷。
• 流批計算一體：能支持Spark對錶內全量數據進行批計算，也能經過CDC技術對接Flink來對錶內新增數據進行流計算，真正實現批流計算結合。

| 特點功能

• 多元化索引

Tablestore提供多種索引類型可選擇，包含全局二級索引和多元索引。全局二級索引相似於傳統關係數據庫的二級索引，能爲知足最左匹配原則的條件查詢作優化，提供低成本存儲和高效的隨機查詢和範圍掃描。多元索引能提供更豐富的查詢功能，包含任意列的組合條件查詢、全文搜索和空間查詢，也能支持輕量級數據分析，提供基本的統計聚合函數，兩種索引的對比和選型可參考這篇文章。

• 通道服務

通道服務是Tablestore的CDC技術，是支撐數據派生體系的核心功能，具體能力可參考這篇文章。可以被利用在異構存儲間的數據同步、事件驅動編程、表增量數據實時訂閱以及流計算場景。目前在雲上Tablestore與Blink能無縫對接，也是惟一一個能直接做爲Blink的stream source的結構化大數據存儲。

大數據處理架構

大數據處理架構是數據系統架構的一部分，其架構發展演進了多年，有一些基本的核心架構設計思路產出，例如影響最深遠的Lambda架構。Lambda架構比較基礎，有一些缺陷，因此在其基礎上又逐漸演進出了Kappa、Kappa+等新架構來部分解決Lambda架構中存在的一些問題，詳情介紹能夠看下這篇文章的介紹。Tablestore基於CDC技術來與計算引擎相結合，基於Lambda架構設計了一個全新的Lambda plus架構。

Lambda plus架構

Lambda架構的核心思想是將不可變的數據以追加的方式並行寫到批和流處理系統內，隨後將相同的計算邏輯分別在流和批系統中實現，而且在查詢階段合併流和批的計算視圖並展現給用戶。基於Tablestore CDC技術咱們將Tablestore與Blink進行了完整對接，可做爲Blink的stream source、dim和sink，推出了Lambda plus架構：

1. Lambda plus架構中數據只須要寫入Tablestore，Blink流計算框架經過通道服務API直讀表內的實時更新數據，不須要用戶雙寫隊列或者本身實現數據同步。
2. 存儲上，Lambda plus直接使用Tablestore做爲master dataset，Tablestore支持用戶在線系統低延遲讀寫更新，同時也提供了索引功能進行高效數據查詢和檢索，數據利用率高。
3. 計算上，Lambda plus利用Blink流批一體計算引擎，統一流批代碼。
4. 展現層，Tablestore提供了多元化索引，用戶可自由組合多類索引來知足不一樣場景下查詢的需求。

總結

本篇文章咱們談了數據系統架構下的核心組件以及關於存儲組件的選型，介紹了派生數據體系這一設計理念。在派生數據體系下咱們能更好的理清存儲組件間的數據流關係，也基於此咱們對結構化大數據存儲這一組件提了幾個關鍵需求。阿里雲Tablestore正是基於這一理念設計，並推出了一些特點功能，但願能經過本篇文章對咱們有一個更深入的瞭解。

在將來，咱們會繼續秉承這一理念，爲Tablestore內的結構化大數據派生更多的便於分析的能力。會與開源計算生態作更多整合，接入更多主流計算引擎。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。