任何應用系統(tǒng)都離不開對數(shù)據(jù)的處理，數(shù)據(jù)也是驅(qū)動業(yè)務創(chuàng)新以及向智能化發(fā)展最核心的東西。數(shù)據(jù)處理的技術已經(jīng)是核心競爭力。在一個完備的技術架構(gòu)中，通常也會由應用系統(tǒng)以及數(shù)據(jù)系統(tǒng)構(gòu)成。應用系統(tǒng)負責處理業(yè)務邏輯，而數(shù)據(jù)系統(tǒng)負責處理數(shù)據(jù)。本篇文章主要面向數(shù)據(jù)系統(tǒng)的研發(fā)工程師和架構(gòu)師，希望對你有所啟發(fā)。
前言
傳統(tǒng)的數(shù)據(jù)系統(tǒng)就是所謂的『大數(shù)據(jù)』技術，這是一個被創(chuàng)造出來的名詞，代表著新的技術門檻。近幾年得益于產(chǎn)業(yè)的發(fā)展、業(yè)務的創(chuàng)新、數(shù)據(jù)的爆發(fā)式增長以及開源技術的廣泛應用，經(jīng)歷多年的磨煉以及在廣大開發(fā)者的共建下，大數(shù)據(jù)的核心組件和技術架構(gòu)日趨成熟。特別是隨著云的發(fā)展，讓『大數(shù)據(jù)』技術的使用門檻進一步降低，越來越多的業(yè)務創(chuàng)新會由數(shù)據(jù)來驅(qū)動完成。
『大數(shù)據(jù)』技術會逐步向輕量化和智能化方向發(fā)展，最終也會成為一個研發(fā)工程師的必備技能之一，而這個過程必須是由云計算技術來驅(qū)動以及在云平臺之上才能完成。應用系統(tǒng)和數(shù)據(jù)系統(tǒng)也會逐漸融合，數(shù)據(jù)系統(tǒng)不再隱藏在應用系統(tǒng)之后，而是也會貫穿在整個業(yè)務交互邏輯。傳統(tǒng)的應用系統(tǒng)，重點在于交互。而現(xiàn)代的應用系統(tǒng)，在與你交互的同時，會慢慢地熟悉你。數(shù)據(jù)系統(tǒng)的發(fā)展驅(qū)動了業(yè)務系統(tǒng)的發(fā)展，從業(yè)務化到規(guī)?；?，再到智能化。
業(yè)務化：完成最基本的業(yè)務交互邏輯。
規(guī)?；悍植际胶痛髷?shù)據(jù)技術的應用，滿足業(yè)務規(guī)模增長的需求以及數(shù)據(jù)的積累。
智能化：人工智能技術的應用，挖掘數(shù)據(jù)的價值，驅(qū)動業(yè)務的創(chuàng)新。
向規(guī)模化和智能化的發(fā)展，仍然存在一定的技術門檻。成熟的開源技術的應用能讓一個大數(shù)據(jù)系統(tǒng)的搭建變得簡單，同時大數(shù)據(jù)架構(gòu)也變得很普遍，例如廣為人知的Lambda架構(gòu)，一定程度上降低了技術的入門門檻。但是對數(shù)據(jù)系統(tǒng)的后續(xù)維護，例如對大數(shù)據(jù)組件的規(guī)?；瘧谩⑦\維管控和成本優(yōu)化，需要掌握大數(shù)據(jù)、分布式技術及復雜環(huán)境下定位問題的能力，仍然具備很高的技術門檻。
數(shù)據(jù)系統(tǒng)的核心組件包含數(shù)據(jù)管道、分布式存儲和分布式計算，數(shù)據(jù)系統(tǒng)架構(gòu)的搭建會是使用這些組件的組合拼裝。每個組件各司其職，組件與組件之間進行上下游的數(shù)據(jù)交換，而不同模塊的選擇和組合是架構(gòu)師面臨的最大的挑戰(zhàn)。
本篇文章主要面向數(shù)據(jù)系統(tǒng)的研發(fā)工程師和架構(gòu)師，我們會首先對數(shù)據(jù)系統(tǒng)核心組件進行拆解，介紹每個組件下對應的開源組件以及云上產(chǎn)品。之后會深入剖析數(shù)據(jù)系統(tǒng)中結(jié)構(gòu)化數(shù)據(jù)的存儲技術，介紹阿里云Tablestore選擇哪種設計理念來更好的滿足數(shù)據(jù)系統(tǒng)中對結(jié)構(gòu)化數(shù)據(jù)存儲的需求。
數(shù)據(jù)系統(tǒng)架構(gòu)
核心組件
上圖是一個比較典型的技術架構(gòu)，包含應用系統(tǒng)和數(shù)據(jù)系統(tǒng)。這個架構(gòu)與具體業(yè)務無關聯(lián)，主要用于體現(xiàn)一個數(shù)據(jù)應用系統(tǒng)中會包含的幾大核心組件，以及組件間的數(shù)據(jù)流關系。應用系統(tǒng)主要實現(xiàn)了應用的主要業(yè)務邏輯，處理業(yè)務數(shù)據(jù)或應用元數(shù)據(jù)等。數(shù)據(jù)系統(tǒng)主要對業(yè)務數(shù)據(jù)及其他數(shù)據(jù)進行匯總和處理，對接BI、推薦或風控等系統(tǒng)。整個系統(tǒng)架構(gòu)中，會包含以下比較常見的幾大核心組件：
關系數(shù)據(jù)庫：用于主業(yè)務數(shù)據(jù)存儲，提供事務型數(shù)據(jù)處理，是應用系統(tǒng)的核心數(shù)據(jù)存儲。
高速緩存：對復雜或操作代價昂貴的結(jié)果進行緩存，加速訪問。
搜索引擎：提供復雜條件查詢和全文檢索。
隊列：用于將數(shù)據(jù)處理流程異步化，銜接上下游對數(shù)據(jù)進行實時交換。異構(gòu)數(shù)據(jù)存儲之間進行上下游對接的核心組件，例如數(shù)據(jù)庫系統(tǒng)與緩存系統(tǒng)或搜索系統(tǒng)間的數(shù)據(jù)對接。也用于數(shù)據(jù)的實時提取，在線存儲到離線存儲的實時歸檔。
非結(jié)構(gòu)化大數(shù)據(jù)存儲：用于海量圖片或視頻等非結(jié)構(gòu)化數(shù)據(jù)的存儲，同時支持在線查詢或離線計算的數(shù)據(jù)訪問需求。
結(jié)構(gòu)化大數(shù)據(jù)存儲：在線數(shù)據(jù)庫也可作為結(jié)構(gòu)化數(shù)據(jù)存儲，但這里提到的結(jié)構(gòu)化數(shù)據(jù)存儲模塊，更偏在線到離線的銜接，特征是能支持高吞吐數(shù)據(jù)寫入以及大規(guī)模數(shù)據(jù)存儲，存儲和查詢性能可線性擴展?？纱鎯γ嫦蛟诰€查詢的非關系型數(shù)據(jù)，或者是用于關系數(shù)據(jù)庫的歷史數(shù)據(jù)歸檔，滿足大規(guī)模和線性擴展的需求，也可存儲面向離線分析的實時寫入數(shù)據(jù)。
批量計算：對非結(jié)構(gòu)化數(shù)據(jù)和結(jié)構(gòu)化數(shù)據(jù)進行數(shù)據(jù)分析，批量計算中又分為交互式分析和離線計算兩類，離線計算需要滿足對大規(guī)模數(shù)據(jù)集進行復雜分析的能力，交互式分析需要滿足對中等規(guī)模數(shù)據(jù)集實時分析的能力。
流計算：對非結(jié)構(gòu)化數(shù)據(jù)和結(jié)構(gòu)化數(shù)據(jù)進行流式數(shù)據(jù)分析，低延遲產(chǎn)出實時視圖。
對于數(shù)據(jù)存儲組件我們再進一步分析，當前各類數(shù)據(jù)存儲組件的設計是為滿足不同場景下數(shù)據(jù)存儲的需求，提供不同的數(shù)據(jù)模型抽象，以及面向在線和離線的不同的優(yōu)化偏向。我們來看下下面這張詳細對比表：
派生數(shù)據(jù)體系
在數(shù)據(jù)系統(tǒng)架構(gòu)中，我們可以看到會存在多套存儲組件。對于這些存儲組件中的數(shù)據(jù)，有些是來自應用的直寫，有些是來自其他存儲組件的數(shù)據(jù)復制。例如業(yè)務關系數(shù)據(jù)庫的數(shù)據(jù)通常是來自業(yè)務，而高速緩存和搜索引擎的數(shù)據(jù)，通常是來自業(yè)務數(shù)據(jù)庫的數(shù)據(jù)同步與復制。不同用途的存儲組件有不同類型的上下游數(shù)據(jù)鏈路，我們可以大概將其歸類為主存儲和輔存儲兩類，這兩類存儲有不同的設計目標，主要特征為：
主存儲：數(shù)據(jù)產(chǎn)生自業(yè)務或者是計算，通常為數(shù)據(jù)首先落地的存儲。ACID等事務特性可能是強需求，提供在線應用所需的低延遲業(yè)務數(shù)據(jù)查詢。
輔存儲：數(shù)據(jù)主要來自主存儲的數(shù)據(jù)同步與復制，輔存儲是主存儲的某個視圖，通常面向數(shù)據(jù)查詢、檢索和分析做優(yōu)化。
為何會有主存儲和輔存儲的存在？能不能統(tǒng)一存儲統(tǒng)一讀寫，滿足所有場景的需求呢？目前看還沒有，存儲引擎的實現(xiàn)技術有多種，選擇行存還是列存，選擇B+tree還是LSM-tree，存儲的是不可變數(shù)據(jù)、頻繁更新數(shù)據(jù)還是時間分區(qū)數(shù)據(jù)，是為高速隨機查詢還是高吞吐掃描設計等等。數(shù)據(jù)庫產(chǎn)品目前也是分兩類，TP和AP，雖然在往HTAP方向走，但實現(xiàn)方式仍然是底層存儲分為行存和列存。
再來看主輔存儲在實際架構(gòu)中的例子，例如關系數(shù)據(jù)庫中主表和二級索引表也可以看做是主與輔的關系，索引表數(shù)據(jù)會隨著主表數(shù)據(jù)而變化，強一致同步并且為某些特定條件組合查詢而優(yōu)化。關系數(shù)據(jù)庫與高速緩存和搜索引擎也是主與輔的關系，采用滿足最終一致的數(shù)據(jù)同步方式，提供高速查詢和檢索。在線數(shù)據(jù)庫與數(shù)倉也是主與輔的關系，在線數(shù)據(jù)庫內(nèi)數(shù)據(jù)集中復制到數(shù)倉來提供高效的BI分析。
這種主與輔的存儲組件相輔相成的架構(gòu)設計，我們稱之為『派生數(shù)據(jù)體系』。在這個體系下，最大的技術挑戰(zhàn)是數(shù)據(jù)如何在主與輔之間進行同步與復制。
上圖我們可以看到幾個常見的數(shù)據(jù)復制方式：
應用層多寫：這是實現(xiàn)最簡單、依賴最少的一種實現(xiàn)方式，通常采取的方式是在應用代碼中先向主存儲寫數(shù)據(jù)，后向輔存儲寫數(shù)據(jù)。這種方式不是很嚴謹，通常用在對數(shù)據(jù)可靠性要求不是很高的場景。因為存在的問題有很多，一是很難保證主與輔之間的數(shù)據(jù)一致性，無法處理數(shù)據(jù)寫入失效問題；二是數(shù)據(jù)寫入的消耗堆積在應用層，加重應用層的代碼復雜度和計算負擔，不是一種解耦很好的架構(gòu)；三是擴展性較差，數(shù)據(jù)同步邏輯固化在代碼中，比較難靈活添加輔存儲。
異步隊列復制：這是目前被應用比較廣的架構(gòu)，應用層將派生數(shù)據(jù)的寫入通過隊列來異步化和解耦。這種架構(gòu)下可將主存儲和輔存儲的數(shù)據(jù)寫入都異步化，也可僅將輔存儲的數(shù)據(jù)寫入異步化。第一種方式必須接受主存儲可異步寫入，否則只能采取第二種方式。而如果采用第二種方式的話，也會遇到和上一種『應用層多寫』方案類似的問題，應用層也是多寫，只不過是寫主存儲與隊列，隊列來解決多個輔存儲的寫入和擴展性問題。
CDC（Change Data Capture）技術：這種架構(gòu)下數(shù)據(jù)寫入主存儲后會由主存儲再向輔存儲進行同步，對應用層是最友好的，只需要與主存儲打交道。主存儲到輔存儲的數(shù)據(jù)同步，則可以再利用異步隊列復制技術來做。不過這種方案對主存儲的能力有很高的要求，必須要求主存儲能支持CDC技術。一個典型的例子就是MySQL+Elasticsearch的組合架構(gòu)，Elasticsearch的數(shù)據(jù)通過MySQL的binlog來同步，binlog就是MySQL的CDC技術。
『派生數(shù)據(jù)體系』是一個比較重要的技術架構(gòu)設計理念，其中CDC技術是更好的驅(qū)動數(shù)據(jù)流動的關鍵手段。具備CDC技術的存儲組件，才能更好的支撐數(shù)據(jù)派生體系，從而能讓整個數(shù)據(jù)系統(tǒng)架構(gòu)更加靈活，降低了數(shù)據(jù)一致性設計的復雜度，從而來面向高速迭代設計?？上У氖谴蠖鄶?shù)存儲組件不具備CDC技術，例如HBase。而阿里云Tablestore具備非常成熟的CDC技術，CDC技術的應用也推動了架構(gòu)的創(chuàng)新，這個在下面的章節(jié)會詳細介紹。
一個好的產(chǎn)品，在產(chǎn)品內(nèi)部會采用派生數(shù)據(jù)架構(gòu)來不斷擴充產(chǎn)品的能力，能將派生的過程透明化，內(nèi)部解決數(shù)據(jù)同步、一致性及資源配比問題。而現(xiàn)實中大多數(shù)技術架構(gòu)采用產(chǎn)品組合的派生架構(gòu)，需要自己去管理數(shù)據(jù)同步與復制等問題，例如常見的MySQL+Elasticsearch，或HBase+Solr等。這種組合通常被忽視的最大問題是，在解決CDC技術來實時復制數(shù)據(jù)后，如何解決數(shù)據(jù)一致性問題？如何追蹤數(shù)據(jù)同步延遲？如何保證輔存儲與主存儲具備相同的數(shù)據(jù)寫入能力？
存儲組件的選型
架構(gòu)師在做架構(gòu)設計時，最大的挑戰(zhàn)是如何對計算組件和存儲組件進行選型和組合，同類的計算引擎的差異化相對不大，通常會優(yōu)先選擇成熟和生態(tài)健全的計算引擎，例如批量計算引擎Spark和流計算引擎Flink。而對于存儲組件的選型是一件非常有挑戰(zhàn)的事，存儲組件包含數(shù)據(jù)庫（又分為SQL和NoSQL兩類，NoSQL下又根據(jù)各類數(shù)據(jù)模型細分為多類）、對象存儲、文件存儲和高速緩存等不同類別。帶來存儲選型復雜度的主要原因是架構(gòu)師需要綜合考慮數(shù)據(jù)分層、成本優(yōu)化以及面向在線和離線的查詢優(yōu)化偏向等各種因素，且當前的技術發(fā)展還是多樣化的發(fā)展趨勢，不存在一個存儲產(chǎn)品能滿足所有場景下的數(shù)據(jù)寫入、存儲、查詢和分析等需求。有一些經(jīng)驗可以分享給大家：
數(shù)據(jù)模型和查詢語言仍然是不同數(shù)據(jù)庫最顯著的區(qū)別，關系模型和文檔模型是相對抽象的模型，而類似時序模型、圖模型和鍵值模型等其他非關系模型是相對具象的抽象，如果場景能匹配到具象模型，那選擇范圍能縮小點。
存儲組件通常會劃分到不同的數(shù)據(jù)分層，選擇面向規(guī)模、成本、查詢和分析性能等不同維度的優(yōu)化偏向，選型時需要考慮清楚對這部分數(shù)據(jù)存儲所要求的核心指標。
區(qū)分主存儲還是輔存儲，對數(shù)據(jù)復制關系要有明確的梳理。（主存儲和輔存儲是什么在下一節(jié)介紹）
建立靈活的數(shù)據(jù)交換通道，滿足快速的數(shù)據(jù)搬遷和存儲組件間的切換能力，構(gòu)建快速迭代能力比應對未知需求的擴展性更重要。
另外關于數(shù)據(jù)存儲架構(gòu)，我認為最終的趨勢是：
數(shù)據(jù)一定需要分層
數(shù)據(jù)最終的歸屬地一定是OSS
會由一個統(tǒng)一的分析引擎來統(tǒng)一分析的入口，并提供統(tǒng)一的查詢語言
結(jié)構(gòu)化大數(shù)據(jù)存儲
定位
結(jié)構(gòu)化大數(shù)據(jù)存儲在數(shù)據(jù)系統(tǒng)中是一個非常關鍵的組件，它起的一個很大的作用是連接『在線』和『離線』。作為數(shù)據(jù)中臺中的結(jié)構(gòu)化數(shù)據(jù)匯總存儲，用于在線數(shù)據(jù)庫中數(shù)據(jù)的匯總來對接離線數(shù)據(jù)分析，也用于離線數(shù)據(jù)分析的結(jié)果集存儲來直接支持在線查詢或者是數(shù)據(jù)派生。根據(jù)這樣的定位，我們總結(jié)下對結(jié)構(gòu)化大數(shù)據(jù)存儲的幾個關鍵需求。
關鍵需求
大規(guī)模數(shù)據(jù)存儲：結(jié)構(gòu)化大數(shù)據(jù)存儲的定位是集中式的存儲，作為在線數(shù)據(jù)庫的匯總（大寬表模式），或者是離線計算的輸入和輸出，必須要能支撐PB級規(guī)模數(shù)據(jù)存儲。
高吞吐寫入能力：數(shù)據(jù)從在線存儲到離線存儲的轉(zhuǎn)換，通常是通過ETL工具，T+1式的同步或者是實時同步。結(jié)構(gòu)化大數(shù)據(jù)存儲需要能支撐多個在線數(shù)據(jù)庫內(nèi)數(shù)據(jù)的導入，也要能承受大數(shù)據(jù)計算引擎的海量結(jié)果數(shù)據(jù)集導出。所以必須能支撐高吞吐的數(shù)據(jù)寫入，通常會采用一個為寫入而優(yōu)化的存儲引擎。
豐富的數(shù)據(jù)查詢能力：結(jié)構(gòu)化大數(shù)據(jù)存儲作為派生數(shù)據(jù)體系下的輔存儲，需要為支撐高效在線查詢做優(yōu)化。常見的查詢優(yōu)化包括高速緩存、高并發(fā)低延遲的隨機查詢、復雜的任意字段條件組合查詢以及數(shù)據(jù)檢索。這些查詢優(yōu)化的技術手段就是緩存和索引，其中索引的支持是多元化的，面向不同的查詢場景提供不同類型的索引。例如面向固定組合查詢的基于B+tree的二級索引，面向地理位置查詢的基于R-tree或BKD-tree的空間索引或者是面向多條件組合查詢和全文檢索的倒排索引。
存儲和計算成本分離：存儲計算分離是目前一個比較熱的架構(gòu)實現(xiàn)，對于一般應用來說比較難體會到這個架構(gòu)的優(yōu)勢。在云上的大數(shù)據(jù)系統(tǒng)下，存儲計算分離才能完全發(fā)揮優(yōu)勢。存儲計算分離在分布式架構(gòu)中，最大的優(yōu)勢是能提供更靈活的存儲和計算資源管理手段，大大提高了存儲和計算的擴展性。對成本管理來說，只有基于存儲計算分離架構(gòu)實現(xiàn)的產(chǎn)品，才能做到存儲和計算成本的分離。
存儲和計算成本的分離的優(yōu)勢，在大數(shù)據(jù)系統(tǒng)下會更加明顯。舉一個簡單的例子，結(jié)構(gòu)化大數(shù)據(jù)存儲的存儲量會隨著數(shù)據(jù)的積累越來越大，但是數(shù)據(jù)寫入量是相對平穩(wěn)的。所以存儲需要不斷的擴大，但是為了支撐數(shù)據(jù)寫入或臨時的數(shù)據(jù)分析而所需的計算資源，則相對來說比較固定，是按需的。
數(shù)據(jù)派生能力：一個完整的數(shù)據(jù)系統(tǒng)架構(gòu)下，需要有多個存儲組件并存。并且根據(jù)對查詢和分析能力的不同要求，需要在數(shù)據(jù)派生體系下對輔存儲進行動態(tài)擴展。所以對于結(jié)構(gòu)化大數(shù)據(jù)存儲來說，也需要有能擴展輔存儲的派生能力，來擴展數(shù)據(jù)處理能力。而判斷一個存儲組件是否具備更好的數(shù)據(jù)派生能力，就看是否具備成熟的CDC技術。
計算生態(tài)：數(shù)據(jù)的價值需要靠計算來挖掘，目前計算主要劃為批量計算和流計算。對于結(jié)構(gòu)化大數(shù)據(jù)存儲的要求，一是需要能夠?qū)又髁鞯挠嬎阋?，例如Spark、Flink等，作為輸入或者是輸出；二是需要有數(shù)據(jù)派生的能力，將自身數(shù)據(jù)轉(zhuǎn)換為面向分析的列存格式存儲至數(shù)據(jù)湖系統(tǒng)；三是自身提供交互式分析能力，更快挖掘數(shù)據(jù)價值。
滿足第一個條件是最基本要求，滿足第二和第三個條件才是加分項。
開源產(chǎn)品
目前開源界比較知名的結(jié)構(gòu)化大數(shù)據(jù)存儲是HBase和Cassandra，Cassandra是WideColumn模型NoSQL類別下排名Top-1的產(chǎn)品，在國外應用比較廣泛。但這里我們重點提下HBase，因為在國內(nèi)的話相比Cassandra會更流行一點。
HBase是基于HDFS的存儲計算分離架構(gòu)的WideColumn模型數(shù)據(jù)庫，擁有非常好的擴展性，能支撐大規(guī)模數(shù)據(jù)存儲，它的優(yōu)點為：
存儲計算分離架構(gòu)：底層基于HDFS，分離的架構(gòu)可帶來存儲和計算各自彈性擴展的優(yōu)勢，與計算引擎例如Spark可共享計算資源，降低成本。
LSM存儲引擎：為寫入優(yōu)化設計，能提供高吞吐的數(shù)據(jù)寫入。
開發(fā)者生態(tài)成熟，接入主流計算引擎：作為發(fā)展多年的開源產(chǎn)品，在國內(nèi)也有比較多的應用，開發(fā)者社區(qū)很成熟，對接幾大主流的計算引擎。
HBase有其突出的優(yōu)點，但也有幾大不可忽視的缺陷：
查詢能力弱：提供高效的單行隨機查詢以及范圍掃描，復雜的組合條件查詢必須使用Scan+Filter的方式，稍不注意就是全表掃描，效率極低。HBase的Phoenix提供了二級索引來優(yōu)化查詢，但和MySQL的二級索引一樣，只有符合最左匹配的查詢條件才能做索引優(yōu)化，可被優(yōu)化的查詢條件非常有限。
數(shù)據(jù)派生能力弱：前面章節(jié)提到CDC技術是支撐數(shù)據(jù)派生體系的核心技術，HBase不具備CDC技術。HBase Replication具備CDC的能力，但是僅為HBase內(nèi)部主備間的數(shù)據(jù)同步機制。有一些開源組件利用其內(nèi)置Replication能力來嘗試擴展HBase的CDC技術，例如用于和Solr同步的Lily Indexer，但是比較可惜的是這類組件從理論和機制上分析就沒法做到CDC技術所要求的數(shù)據(jù)保序、最終一致性保證等核心需求。
成本高：前面提到結(jié)構(gòu)化大數(shù)據(jù)存儲的關鍵需求之一是存儲與計算的成本分離，HBase的成本取決于計算所需CPU核數(shù)成本以及磁盤的存儲成本，基于固定配比物理資源的部署模式下CPU和存儲永遠會有一個無法降低的最小比例關系。即隨著存儲空間的增大，CPU核數(shù)成本也會相應變大，而不是按實際所需計算資源來計算成本。要達到完全的存儲與計算成本分離，只有云上的Serverless服務模式才能做到。
運維復雜：HBase是標準的Hadoop組件，最核心依賴是Zookeeper和HDFS，沒有專業(yè)的運維團隊幾乎無法運維。
熱點處理能力差：HBase的表的分區(qū)是Range Partition的方式，相比Hash Partition的模式最大的缺陷就是會存在嚴重的熱點問題。HBase提供了大量的最佳實踐文檔來指引開發(fā)者在做表的Rowkey設計的時候避免熱點，例如采用hash key，或者是salted-table的方式。但這兩種方式下能保證數(shù)據(jù)的分散均勻，但是無法保證數(shù)據(jù)訪問的熱度均勻。訪問熱度取決于業(yè)務，需要一種能根據(jù)熱度來對Region進行Split或Move等負載均衡的自動化機制。
國內(nèi)的高級玩家大多會基于HBase做二次開發(fā)，基本都是在做各種方案來彌補HBase查詢能力弱的問題，根據(jù)自身業(yè)務查詢特色研發(fā)自己的索引方案，例如自研二級索引方案、對接Solr做全文索引或者是針對區(qū)分度小的數(shù)據(jù)集的bitmap索引方案等等?？偟膩碚f，HBase是一個優(yōu)秀的開源產(chǎn)品，有很多優(yōu)秀的設計思路值得借鑒。
Tablestore
Tablestore是阿里云自研的結(jié)構(gòu)化大數(shù)據(jù)存儲產(chǎn)品，具體產(chǎn)品介紹可以參考官網(wǎng)以及權威指南。Tablestore的設計理念很大程度上顧及了數(shù)據(jù)系統(tǒng)內(nèi)對結(jié)構(gòu)化大數(shù)據(jù)存儲的需求，并且基于派生數(shù)據(jù)體系這個設計理念專門設計和實現(xiàn)了一些特色的功能。
★ 設計理念
Tablestore的設計理念一方面吸收了優(yōu)秀開源產(chǎn)品的設計思路，另一方面也是結(jié)合實際業(yè)務需求演化出了一些特色設計方向，簡單概括下Tablestore的技術理念：
存儲計算分離架構(gòu)：采用存儲計算分離架構(gòu)，底層基于飛天盤古分布式文件系統(tǒng)，這是實現(xiàn)存儲計算成本分離的基礎。
LSM存儲引擎：LSM和B+tree是主流的兩個存儲引擎實現(xiàn)，其中LSM專為高吞吐數(shù)據(jù)寫入優(yōu)化，也能更好的支持數(shù)據(jù)冷熱分層。
Serverless產(chǎn)品形態(tài)：基于存儲計算分離架構(gòu)來實現(xiàn)成本分離的最關鍵因素是Serverless服務化，只有Serverless服務才能做到存儲計算成本分離。大數(shù)據(jù)系統(tǒng)下，結(jié)構(gòu)化大數(shù)據(jù)存儲通常會需要定期的大規(guī)模數(shù)據(jù)導入，來自在線數(shù)據(jù)庫或者是來自離線計算引擎，在此時需要有足夠的計算能力能接納高吞吐的寫入，而平時可能僅需要比較小的計算能力，計算資源要足夠的彈性。另外在派生數(shù)據(jù)體系下，主存儲和輔存儲通常是異構(gòu)引擎，在讀寫能力上均有差異，有些場景下需要靈活調(diào)整主輔存儲的配比，此時也需要存儲和計算資源彈性可調(diào)。
多元化索引，提供豐富的查詢能力：LSM引擎特性決定了查詢能力的短板，需要索引來優(yōu)化查詢。而不同的查詢場景需要不同類型的索引，所以Tablestore提供多元化的索引來滿足不同類型場景下的數(shù)據(jù)查詢需求。
CDC技術：Tablestore的CDC技術名為Tunnel Service，支持全量和增量的實時數(shù)據(jù)訂閱，并且能無縫對接Flink流計算引擎來實現(xiàn)表內(nèi)數(shù)據(jù)的實時流計算。
擁抱開源計算生態(tài)：除了比較好的支持阿里云自研計算引擎如MaxCompute和Data Lake Analytics的計算對接，也能支持Flink和Spark這兩個主流計算引擎的計算需求，無需數(shù)據(jù)搬遷。
流批計算一體：能支持Spark對表內(nèi)全量數(shù)據(jù)進行批計算，也能通過CDC技術對接Flink來對表內(nèi)新增數(shù)據(jù)進行流計算，真正實現(xiàn)批流計算結(jié)合。
★ 特色功能
多元化索引
Tablestore提供多種索引類型可選擇，包含全局二級索引和多元索引。全局二級索引類似于傳統(tǒng)關系數(shù)據(jù)庫的二級索引，能為滿足最左匹配原則的條件查詢做優(yōu)化，提供低成本存儲和高效的隨機查詢和范圍掃描。多元索引能提供更豐富的查詢功能，包含任意列的組合條件查詢、全文搜索和空間查詢，也能支持輕量級數(shù)據(jù)分析，提供基本的統(tǒng)計聚合函數(shù)，兩種索引的對比和選型可參考這篇文章。
通道服務
通道服務是Tablestore的CDC技術，是支撐數(shù)據(jù)派生體系的核心功能，具體能力可參考這篇文章。能夠被利用在異構(gòu)存儲間的數(shù)據(jù)同步、事件驅(qū)動編程、表增量數(shù)據(jù)實時訂閱以及流計算場景。目前在云上Tablestore與Blink能無縫對接，也是唯一一個能直接作為Blink的stream source的結(jié)構(gòu)化大數(shù)據(jù)存儲。
大數(shù)據(jù)處理架構(gòu)
大數(shù)據(jù)處理架構(gòu)是數(shù)據(jù)系統(tǒng)架構(gòu)的一部分，其架構(gòu)發(fā)展演進了多年，有一些基本的核心架構(gòu)設計思路產(chǎn)出，例如影響最深遠的Lambda架構(gòu)。Lambda架構(gòu)比較基礎，有一些缺陷，所以在其基礎上又逐漸演進出了Kappa、Kappa+等新架構(gòu)來部分解決Lambda架構(gòu)中存在的一些問題，詳情介紹可以看下這篇文章的介紹。Tablestore基于CDC技術來與計算引擎相結(jié)合，基于Lambda架構(gòu)設計了一個全新的Lambda plus架構(gòu)。
Lambda plus架構(gòu)
Lambda架構(gòu)的核心思想是將不可變的數(shù)據(jù)以追加的方式并行寫到批和流處理系統(tǒng)內(nèi)，隨后將相同的計算邏輯分別在流和批系統(tǒng)中實現(xiàn)，并且在查詢階段合并流和批的計算視圖并展示給用戶?；赥ablestore CDC技術我們將Tablestore與Blink進行了完整對接，可作為Blink的stream source、dim和sink，推出了Lambda plus架構(gòu)：
Lambda plus架構(gòu)中數(shù)據(jù)只需要寫入Tablestore，Blink流計算框架通過通道服務API直讀表內(nèi)的實時更新數(shù)據(jù)，不需要用戶雙寫隊列或者自己實現(xiàn)數(shù)據(jù)同步。
存儲上，Lambda plus直接使用Tablestore作為master dataset，Tablestore支持用戶在線系統(tǒng)低延遲讀寫更新，同時也提供了索引功能進行高效數(shù)據(jù)查詢和檢索，數(shù)據(jù)利用率高。
計算上，Lambda plus利用Blink流批一體計算引擎，統(tǒng)一流批代碼。
展示層，Tablestore提供了多元化索引，用戶可自由組合多類索引來滿足不同場景下查詢的需求。
總結(jié)
本篇文章我們談了數(shù)據(jù)系統(tǒng)架構(gòu)下的核心組件以及關于存儲組件的選型，介紹了派生數(shù)據(jù)體系這一設計理念。在派生數(shù)據(jù)體系下我們能更好的理清存儲組件間的數(shù)據(jù)流關系，也基于此我們對結(jié)構(gòu)化大數(shù)據(jù)存儲這一組件提了幾個關鍵需求。阿里云Tablestore正是基于這一理念設計，并推出了一些特色功能，希望能通過本篇文章對我們有一個更深刻的了解。
在未來，我們會繼續(xù)秉承這一理念，為Tablestore內(nèi)的結(jié)構(gòu)化大數(shù)據(jù)派生更多的便于分析的能力。會與開源計算生態(tài)做更多整合，接入更多主流計算引擎。
