開發十年，就只剩下這套架構體系了！ >>>   

         表格儲存TableStore是阿里雲自研的面向海量結構化和半結構化資料儲存的Serverless NoSQL多模型資料庫，被廣泛用於社交、物聯網、人工智慧、元資料和大資料等業務場景。表格儲存TableStore採用與Google Bigtable類似的寬表模型，天然的分散式架構，能支撐高吞吐的資料寫入以及PB級資料儲存。

         原生的寬表資料模型，存在一些天然的缺陷，例如無法很好的支援屬性列的多條件組合查詢，或者更高階的全文檢索或空間檢索。另外在與計算系統的對接上，特別是流計算場景，傳統的大資料Lambda架構，需要使用者維護多套儲存和計算系統，沒法很天然的支援資料在儲存和計算系統之間的流轉。以上這些問題，均在表格儲存TableStore在支援阿里巴巴集團內、阿里雲公共雲以及專有云等業務中逐漸暴露出來。

         表格儲存TableStore簡單可靠的資料模型和架構，開始承擔越來越豐富的不同型別的資料儲存，例如時序時空資料、元資料、訊息資料、使用者行為資料和軌跡溯源資料等。越來越多的客戶也開始把表格儲存TableStore當做一個統一的線上大資料儲存平臺，所以我們迫切需要支援海量資料中對資料的高效查詢、分析和檢索。同時也需要考慮如何更貼近業務，抽象出更貼近業務的資料模型，讓資料的接入變得更加簡單。

         在2019年3月6日的阿里雲新品釋出會上，表格儲存TableStore對以下幾個方面做了重大升級:

• 提供多種資料模型，滿足不同資料場景的需求，簡化資料建模和開發。
• 提供多元化索引，滿足不同場景下簡單或複雜條件查詢的功能需求。
• 提供實時資料通道，無縫對接流計算引擎，支援表內資料的實時更新訂閱。

多模型

         表格儲存TableStore在選擇要支援的資料模型的時候，更多的綜合了當前業務現狀以及使用者畫像，提取大部分客戶的通用需求，總結和定義了產品適合的幾大類核心資料場景，來抽象和定義資料模型。資料模型的定義分為『具象』和『抽象』：抽象模型是類似於關係模型或者文件模型的能滿足大部分型別資料的抽象，屬於比較通用的資料模型；具象模型是對某一具體特徵場景資料的抽象，適合單一垂直類的資料場景。表格儲存TableStore同時提供抽象和具象模型，當然在介紹這些模型之前，先來明確我們的核心資料場景。

核心場景

​

         表格儲存TableStore的核心場景包含這五大類，分別對應不同型別的應用系統，以及每類資料場景下資料有典型的特徵和對儲存和計算的特殊的需求，簡單來說：

• 時序資料：時序資料解決的是對包含4W（Who, When, Where, What）元素資料的抽象，資料量相對比較龐大，需要儲存引擎支援對時間線的索引以及對時間線的時間範圍查詢。
• 時空資料：時空資料是基於時序資料加上了空間的維度，同時可能沒有時序資料的連續性。總的來說，特徵和時序資料比較類似。
• 訊息資料：訊息資料廣泛存在於訊息系統，例如即時通訊訊息系統或者Feeds流訊息系統內。訊息的儲存和傳遞更像是訊息佇列模型，但是要求訊息佇列能夠提供海量級訊息儲存以及海量Topic，這是傳統專業級訊息佇列產品所無法支撐的。
• 元資料：這類元資料屬於非關係類元資料，例如歷史訂單資料、圖片智慧標籤元資料點。特點是量級比較大，每個資料存在的屬性比較多且是稀疏的，要求儲存能夠支援對各種維度屬性的條件過濾，對查詢可用性有比較高的要求。
• 大資料：這是Bigtable模型所對應的最主要資料場景，特點是資料量極其龐大，需要很好的支援批量計算。

TableStore多模型

基於以上總結的表格儲存TableStore所針對的核心資料場景，我們從業務需求中抽象出三大類資料模型，分別是：WideColumn（寬行模型）、Timeline（訊息模型）和Timestream（時序模型）。

寬行模型

​

寬行模型是由Bigtable提出，特徵是：

• 三維資料結構：對比MySQL的二維資料結構，在屬性列這一維度上多了版本屬性。同一列資料可以儲存多個不同版本，並可定義不同的生命週期，主要用於資料的自動化生命週期管理。
• 稀疏列：表不需要有強格式定義，可以任意的對每一行定義列和型別。
• 大表：一張表可以儲存萬億行資料，大表資料根據分割槽鍵的範圍來分割槽，不同的分割槽由不同的機器來載入和提供服務，能比較簡單的實現分散式。

寬行模型主要應用於元資料和大資料場景，一些典型應用場景可參考：

• 《TableStore實戰：智慧元資料管理方案》
• 《TableStore實戰：億量級訂單管理解決方案》
• 《百億級全網輿情分析系統儲存設計》
• 《基於雲上分散式NoSQL的海量氣象資料儲存和查詢方案》

我們也提供HBase API相容的Client：《使用HBase Client訪問阿里雲NoSQL資料庫表格儲存》。

訊息模型

​

訊息模型是表格儲存TableStore針對訊息資料所抽象的資料模型，主要適用於訊息系統中海量訊息儲存和同步，特徵是：

• 輕量級訊息佇列：大表中能模擬海量訊息佇列，雖然不能完全模擬一個真正訊息佇列的所有能力，但是能滿足對訊息最基本的儲存和同步能力。
• 訊息永久儲存：能保證對資料的永久儲存，訊息寫入和同步的效能不會受到資料規模的影響。
• 模型同步模型：對訊息同步模型沒有嚴格要求，應用層可以根據自己的業務特徵，同時實現推模型或者拉模型。

訊息模型主要應用於訊息資料場景，一些典型應用場景可參考：

• 《現代IM系統中訊息推送和儲存架構的實現》
• 《TableStore Timeline：輕鬆構建千萬級IM和Feed流系統》
• 《如何打造千萬級Feed流系統》
• 《基於TableStore構建簡易海量Topic訊息佇列》
• 《如何快速開發一個IM系統》

時序模型

​

時序模型主要應用與時序和時空場景，也是表格儲存TableStore綜合了業界主流的時序資料庫，所定義和抽象的資料模型，特徵是：

• 海量資料儲存：能提供PB級資料儲存，可打造多租戶的時序資料庫底層儲存，寫入和查詢效能不受資料規模的影響。
• 時間線索引：提供對時間線的索引，能滿足對時間線Tag的任何條件組合過濾，並且能夠支援比較海量的時間線規模。
• 完整的模型定義：在業界標杆的時序資料庫模型定義上，補充了空間維度的定義並且提供空間索引，以及支援多列值支援，不限制只對數值型別的支援。

時序模型主要應用於時序和時空資料，一些典型應用場景可參考：

• 《TableStore時序資料儲存 - 架構篇》
• 《TableStore實戰：輕鬆實現軌跡管理與地理圍欄》

查詢優化

上述場景中提到的對於表內資料的查詢優化，最基本手段就是需要對資料建立索引。表格儲存TableStore選擇的做法是，對於不同型別的查詢場景，我們需要提供不同型別的索引。業界對海量資料建立索引的方案有多種，在傳統技術架構中應用比較多的主要包括Phoenix SQL二級索引或者Elasticsearch搜尋引擎。二級索引能提供高效的固定維度的條件查詢，查詢效能不受資料規模的影響，而Elasticsearch搜尋引擎能提供比較靈活的多條件組合查詢、全文索引和空間索引。兩種型別的索引實現，有不同的優缺點，以及適用於不同的場景。表格儲存TableStore的做法是同時實現和這兩類索引原理類似的索引，來滿足不同場景下對查詢的不同需求。

全域性二級索引

​

當用戶建立一張表時，其所有PK列構成了該表的『一級索引』：即給定完整的行主鍵，可以迅速的查詢到該主鍵所在行的資料。但是越來越多的業務場景中，需要對錶的屬性列，或者非主鍵字首列進行條件上的查詢，由於沒有足夠的索引資訊，只能通過進行全表的掃描，配合條件過濾，來得到最終結果，特別是全表資料較多，但最終結果很少時，全表掃描將浪費極大的資源。表格儲存TableStore提供的全域性二級索引功能支援在指定列上建立索引，生成的索引表中資料按使用者指定的索引列進行排序，主表的每一筆寫入都將自動非同步同步到索引表。使用者只向主表中寫入資料，根據索引表進行查詢，在許多場景下，將極大的提高查詢的效率。更多的技術解讀，請參考這篇文章《通過全域性二級索引加速表格儲存上的資料查詢》。

多元索引

​

表格儲存TableStore多元索引是表格儲存TableStore重點打造的一個多功能索引能力，旨在補位二級索引無法覆蓋的場景，解決大資料場景下的複雜查詢和輕量級分析問題，比如多欄位組合查詢、字首查詢、萬用字元查詢、巢狀查詢、全文檢索（分詞）、地理位置查詢、排序和統計聚合等功能。關於對多元索引的更多解讀，可以閱讀這篇文章《TableStore多元索引，大資料查詢的利器》，關於多元索引的更多應用場景，可以參考以下文章：

• 《TableStore：交通資料的儲存、查詢和分析利器》
• 《TableStore：爬蟲資料儲存和查詢利器》

計算銜接

表格儲存TableStore已經與比較多的開源大資料計算引擎以及阿里雲端計算產品銜接，例如Hive、Spark、MaxCompute以及DataLakeAnalytics等，覆蓋了批量計算和互動式分析。可以由第三方產品提供的資料通道服務，將表格儲存TableStore上的資料全量或者增量複製到計算系統，也可以由計算系統通過Connector直接訪問表內的資料。

批量計算和互動式分析訪問資料儲存的方式是批量掃描，主要通過自定義資料Connector的方式。但是其他類計算系統例如流計算或者函式計算（Lambda架構），資料是需要流式的並且實時的從儲存系統到計算系統。這個能力是傳統開源Bigtable類資料庫所做不到的，例如HBase或Cassandra。

如果表內的資料可以實時的流動，那將給錶帶來更豐富的計算和處理場景，例如可以做跨域複製、備份，或者接入流計算引擎做實時分析或者函式計算做事件觸發式程式設計，也可以由應用方自定義資料處理，來做個性化資料處理。

表格儲存TableStore提供了全新的實時資料通道，能支援訂閱表內的實時資料更新，來擴充表格儲存TableStore的計算能力。

通道服務

​

TableStore 通道服務（Tunnel Service）是基於表格儲存資料介面之上的全增量一體化服務，通道服務為使用者提供了增量、全量、增量加全量三種類型的分散式資料實時消費通道。通過為資料表建立Tunnel Service資料通道，可以簡單地實現對錶中歷史存量和新增資料的消費處理。基於通道服務使用者可以輕鬆的實現如圖所示的場景架構：資料同步、搬遷和備份，流式資料處理以及事件驅動架構。

關於對通道服務TunnelService更多的技術解讀，可以參考這篇文章：《大資料同步利器: 表格儲存全增量一體消費通道》。基於通道服務的更多應用場景，可以參考以下文章：

• 《實時計算最佳實踐：基於表格儲存和Blink的大資料實時計算》
• 《TableStore: 海量結構化資料實時備份實戰 》
• 《TableStore: 海量結構化資料分層儲存方案》

總結

表格儲存TableStore通過同時提供具象和抽象的資料模型，來滿足不同核心資料場景的要求，更貼近業務抽象；提供多元化索引（全域性二級索引和多元索引）來滿足不同型別場景條件查詢需求；提供全新的實時資料通道，來擴充實時計算的能力以及可自定義的實時資料處理。這三大方面的新功能釋出，能夠讓我們在資料模型、靈活查詢以及資料分析層面，都有一定的提升，幫助打造統一的線上資料儲存平臺。

相關推薦