結構化資料儲存，如何設計才能滿足需求？

阿里技術發表於2019-09-04

結構化資料儲存，如何設計才能滿足需求？

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

前言

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

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

  • 業務化：完成最基本的業務互動邏輯。
  • 規模化：分散式和大資料技術的應用，滿足業務規模增長的需求以及資料的積累。
  • 智慧化：人工智慧技術的應用，挖掘資料的價值，驅動業務的創新。

向規模化和智慧化的發展，仍然存在一定的技術門檻。成熟的開源技術的應用能讓一個大資料系統的搭建變得簡單，同時大資料架構也變得很普遍，例如廣為人知的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內的結構化大資料派生更多的便於分析的能力。會與開源計算生態做更多整合，接入更多主流計算引擎。

相關文章