前言
任何應用系統都離不開對資料的處理，資料也是驅動業務創新以及向智能化發展最核心的東西。這也是為何目前大多數企業都在建構資料中台的原因，資料處理的技術已經是核心競争力。在一個完備的技術架構中，通常也會由應用系統以及資料系統構成。應用系統負責處理業務邏輯，而資料系統負責處理資料。
傳統的資料系統就是所謂的『大資料』技術，這是一個被創造出來的名詞，代表着新的技術門檻。近幾年得益于産業的發展、業務的創新、資料的爆發式增長以及開源技術的廣泛應用，經曆多年的磨煉以及在廣大開發者的共建下，大資料的核心元件和技術架構日趨成熟。特别是随着雲的發展，讓『大資料』技術的使用門檻進一步降低，越來越多的業務創新會由資料來驅動完成。
『大資料』技術會逐漸向輕量化和智能化方向發展，最終也會成為一個研發工程師的必備技能之一，而這個過程必須是由雲計算技術來驅動以及在雲平台之上才能完成。應用系統和資料系統也會逐漸融合，資料系統不再隐藏在應用系統之後，而是也會貫穿在整個業務互動邏輯。傳統的應用系統，重點在于互動。而現代的應用系統，在與你互動的同時，會慢慢的熟悉你。資料系統的發展驅動了業務系統的發展，從業務化到規模化，再到智能化。
- 業務化：完成最基本的業務互動邏輯。
- 規模化：分布式和大資料技術的應用，滿足業務規模增長的需求以及資料的積累。
- 智能化：人工智能技術的應用，挖掘資料的價值，驅動業務的創新。
向規模化和智能化的發展，仍然存在一定的技術門檻。成熟的開源技術的應用能讓一個大資料系統的搭建變得簡單，同時大資料架構也變得很普遍，例如廣為人知的Lambda架構，一定程度上降低了技術的入門門檻。但是對資料系統的後續維護，例如對大資料元件的規模化應用、運維管控和成本優化，需要掌握大資料、分布式技術及複雜環境下定位問題的能力，仍然具備很高的技術門檻。
資料系統的核心元件包含資料管道、分布式存儲和分布式計算，資料系統架構的搭建會是使用這些元件的組合拼裝。每個元件各司其職，元件與元件之間進行上下遊的資料交換，而不同子產品的選擇群組合是架構師面臨的最大的挑戰。
本篇文章主要面向資料系統的研發工程師和架構師，我們會首先對資料系統核心元件進行拆解，介紹每個元件下對應的開源元件以及雲上産品。之後會深入剖析資料系統中結構化資料的存儲技術，介紹阿裡雲Tablestore選擇哪種設計理念來更好的滿足資料系統中對結構化資料存儲的需求。
資料系統架構
核心元件
上圖是一個比較典型的技術架構，包含應用系統和資料系統。這個架構與具體業務無關聯，主要用于展現一個資料應用系統中會包含的幾大核心元件，以及元件間的資料流關系。應用系統主要實作了應用的主要業務邏輯，處理業務資料或應用中繼資料等。資料系統主要對業務資料及其他資料進行彙總和處理，對接BI、推薦或風控等系統。整個系統架構中，會包含以下比較常見的幾大核心元件：
- 關系資料庫：用于主業務資料存儲，提供事務型資料處理，是應用系統的核心資料存儲。
- 高速緩存：對複雜或操作代價昂貴的結果進行緩存，加速通路。
- 搜尋引擎：提供複雜條件查詢和全文檢索。
- 隊列：用于将資料處理流程異步化，銜接上下遊對資料進行實時交換。異構資料存儲之間進行上下遊對接的核心元件，例如資料庫系統與緩存系統或搜尋系統間的資料對接。也用于資料的實時提取，線上存儲到離線存儲的實時歸檔。
- 非結構化大資料存儲：用于海量圖檔或視訊等非結構化資料的存儲，同時支援線上查詢或離線計算的資料通路需求。
- 結構化大資料存儲：線上資料庫也可作為結構化資料存儲，但這裡提到的結構化資料存儲子產品，更偏線上到離線的銜接，特征是能支援高吞吐資料寫入以及大規模資料存儲，存儲和查詢性能可線性擴充。可存儲面向線上查詢的非關系型資料，或者是用于關系資料庫的曆史資料歸檔，滿足大規模和線性擴充的需求，也可存儲面向離線分析的實時寫入資料。
- 批量計算：對非結構化資料和結構化資料進行資料分析，批量計算中又分為互動式分析和離線計算兩類，離線計算需要滿足對大規模資料集進行複雜分析的能力，互動式分析需要滿足對中等規模資料集實時分析的能力。
- 流計算：對非結構化資料和結構化資料進行流式資料分析，低延遲産出實時視圖。
對于資料存儲元件我們再進一步分析，目前各類資料存儲元件的設計是為滿足不同場景下資料存儲的需求，提供不同的資料模型抽象，以及面向線上和離線的不同的優化偏向。我們來看下下面這張詳細對比表：
| 分類 | 存儲成本 | 資料規模 | 資料通路特征 | 查詢性能 | 常見資料類型 | 典型産品 |
|---|---|---|---|---|---|---|
| 關系資料庫 | 高 | 中 | 強一緻事務型通路，關聯查詢 | 高，支援SQL查詢語言，關聯查詢和索引加速，對複雜條件過濾查詢和檢索支援較弱。 | 交易、賬單、應用中繼資料等關系資料 | Oracle，MySQL |
| 高速緩存 | 極高 | 低 | 低延遲Key-Value随機查詢 | 極高，滿足高速Key-Value形式結果資料查詢，或者是高速的記憶體資料交換通道。 | 複雜結果集資料，或者是需要通過記憶體高速交換的資料。 | Redis |
| 搜尋引擎 | 多字段聯合條件過濾，全文檢索 | 高，對複雜條件過濾查詢和檢索支援較好，支援資料相關性排序，也支援輕量級資料分析。 | 面向搜尋查詢的資料 | Elasticsearch，OpenSearch | ||
| 非結構化大資料存儲 | 讀取單個資料檔案，或者是大批量掃描檔案集 | 面向吞吐優化，為線上查詢和離線計算都提供高吞吐的資料讀取，提供極為出色的高吞吐資料寫入能力。 | 圖檔和視訊資料，資料庫歸檔資料 | OSS，HDFS | ||
| 結構化大資料存儲 | 單行随機通路，或者是大批量範圍掃描 | 首先滿足資料高吞吐寫入以及大規模存儲，資料緩存和索引技術提供高并發低延遲的資料通路，面向離線計算也提供高吞吐的資料掃描。 | 通常作為關系資料庫的補充，存儲曆史歸檔資料。或者是一些非關系模型資料，例如時序、日志等。 | HBase，Cassandra，Tablestore(OTS) |
派生資料體系
在資料系統架構中，我們可以看到會存在多套存儲元件。對于這些存儲元件中的資料，有些是來自應用的直寫，有些是來自其他存儲元件的資料複制。例如業務關系資料庫的資料通常是來自業務，而高速緩存和搜尋引擎的資料，通常是來自業務資料庫的資料同步與複制。不同用途的存儲元件有不同類型的上下遊資料鍊路，我們可以大概将其歸類為主存儲和輔存儲兩類，這兩類存儲有不同的設計目标，主要特征為：
- 主存儲：資料産生自業務或者是計算，通常為資料首先落地的存儲。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下又根據各類資料模型細分為多類）、對象存儲、檔案存儲和高速緩存等不同類别。帶來存儲選型複雜度的主要原因是架構師需要綜合考慮資料分層、成本優化以及面向線上和離線的查詢優化偏向等各種因素，且目前的技術發展還是多樣化的發展趨勢，不存在一個存儲産品能滿足所有場景下的資料寫入、存儲、查詢和分析等需求。有一些經驗可以分享給大家：
- 資料模型和查詢語言仍然是不同資料庫最顯著的差別，關系模型和文檔模型是相對抽象的模型，而類似時序模型、圖模型和鍵值模型等其他非關系模型是相對具象的抽象，如果場景能比對到具象模型，那選擇範圍能縮小點。
- 存儲元件通常會劃分到不同的資料分層，選擇面向規模、成本、查詢和分析性能等不同次元的優化偏向，選型時需要考慮清楚對這部分資料存儲所要求的核心名額。
- 區分主存儲還是輔存儲，對資料複制關系要有明确的梳理。（主存儲和輔存儲是什麼在下一節介紹）
- 建立靈活的資料交換通道，滿足快速的資料搬遷和存儲元件間的切換能力，建構快速疊代能力比應對未知需求的擴充性更重要。
另外關于資料存儲架構，我認為最終的趨勢是：
- 資料一定需要分層
- 資料最終的歸屬地一定是OSS
- 會由一個統一的分析引擎來統一分析的入口，并提供統一的查詢語言
定位
結構化大資料存儲在資料系統中是一個非常關鍵的元件，它起的一個很大的作用是連接配接『線上』和『離線』。作為資料中台中的結構化資料彙總存儲，用于線上資料庫中資料的彙總來對接離線資料分析，也用于離線資料分析的結果集存儲來直接支援線上查詢或者是資料派生。根據這樣的定位，我們總結下對結構化大資料存儲的幾個關鍵需求。
關鍵需求
大規模資料存儲
結構化大資料存儲的定位是集中式的存儲，作為線上資料庫的彙總（大寬表模式），或者是離線計算的輸入和輸出，必須要能支撐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架構：
- Lambda plus架構中資料隻需要寫入Tablestore，Blink流計算架構通過通道服務API直讀表内的實時更新資料，不需要使用者雙寫隊列或者自己實作資料同步。
- 存儲上，Lambda plus直接使用Tablestore作為master dataset，Tablestore支援使用者線上系統低延遲讀寫更新，同時也提供了索引功能進行高效資料查詢和檢索，資料使用率高。
- 計算上，Lambda plus利用Blink流批一體計算引擎，統一流批代碼。
- 展示層，Tablestore提供了多元化索引，使用者可自由組合多類索引來滿足不同場景下查詢的需求。
總結
本篇文章我們談了資料系統架構下的核心元件以及關于存儲元件的選型，介紹了派生資料體系這一設計理念。在派生資料體系下我們能更好的理清存儲元件間的資料流關系，也基于此我們對結構化大資料存儲這一元件提了幾個關鍵需求。阿裡雲Tablestore正是基于這一理念設計，并推出了一些特色功能，希望能通過本篇文章對我們有一個更深刻的了解。
在未來，我們會繼續秉承這一理念，為Tablestore内的結構化大資料派生更多的便于分析的能力。會與開源計算生态做更多整合，接入更多主流計算引擎。歡迎加入我們的釘釘公開群（釘釘号：11789671），與我們一起探讨。