摘要：?背景 隨著近幾年物聯(lián)網(wǎng)的發(fā)展，時(shí)序數(shù)據(jù)迎來了一個(gè)不小的爆發(fā)。從DB-Engines上近兩年的數(shù)據(jù)庫類型增長(zhǎng)趨勢(shì)來看，時(shí)序數(shù)據(jù)庫的增長(zhǎng)是非常迅猛的。在去年我花了比較長(zhǎng)的時(shí)間去了解了一些開源時(shí)序數(shù)據(jù)庫，寫了一個(gè)系列的文章（綜述、HBase系、Cassandra系、InfluxDB、Prometheus），感興趣的可以瀏覽。

背景

隨著近幾年物聯(lián)網(wǎng)的發(fā)展，時(shí)序數(shù)據(jù)迎來了一個(gè)不小的爆發(fā)。從DB-Engines上近兩年的數(shù)據(jù)庫類型增長(zhǎng)趨勢(shì)來看，時(shí)序數(shù)據(jù)庫的增長(zhǎng)是非常迅猛的。在去年我花了比較長(zhǎng)的時(shí)間去了解了一些開源時(shí)序數(shù)據(jù)庫，寫了一個(gè)系列的文章（綜述、HBase系、Cassandra系、InfluxDB、Prometheus），感興趣的可以瀏覽。

這幾大開源時(shí)序數(shù)據(jù)庫的實(shí)現(xiàn)各有千秋，都不是很完美，但是如果可以取長(zhǎng)補(bǔ)短，倒是能實(shí)現(xiàn)一個(gè)比較完美的時(shí)序數(shù)據(jù)庫。

TableStore作為阿里云自研的分布式NoSQL數(shù)據(jù)庫，在數(shù)據(jù)模型上我們是多模型設(shè)計(jì)，包含和BigTable一樣的Wide Column模型以及針對(duì)消息數(shù)據(jù)的Timeline模型。在存儲(chǔ)模型、數(shù)據(jù)規(guī)模以及寫入和查詢能力上，都能比較好的滿足時(shí)序數(shù)據(jù)場(chǎng)景的需求。但我們作為一個(gè)通用模型數(shù)據(jù)庫，時(shí)序數(shù)據(jù)存儲(chǔ)要完全發(fā)揮底層數(shù)據(jù)庫的能力，在表Schema設(shè)計(jì)以及計(jì)算對(duì)接上，都要有比較特殊的設(shè)計(jì)，例如OpenTSDB針對(duì)HBase的RowKey設(shè)計(jì)以及UID編碼等。

本篇文章是架構(gòu)篇，主要探討時(shí)序數(shù)據(jù)的數(shù)據(jù)模型定義、核心處理流程以及基于TableStore來構(gòu)建時(shí)序數(shù)據(jù)存儲(chǔ)的架構(gòu)。之后還會(huì)有方案篇，會(huì)提供一個(gè)高效的時(shí)序數(shù)據(jù)和元數(shù)據(jù)存儲(chǔ)的表Schema設(shè)計(jì)以及索引設(shè)計(jì)方案。最后還會(huì)有計(jì)算篇，會(huì)提供幾個(gè)時(shí)序數(shù)據(jù)流計(jì)算和時(shí)序分析的方案設(shè)計(jì)。

?

什么是時(shí)序數(shù)據(jù)

時(shí)序數(shù)據(jù)主要?jiǎng)澐譃閮深?，一類是監(jiān)控類時(shí)序數(shù)據(jù)，另一類是狀態(tài)類時(shí)序數(shù)據(jù)。當(dāng)前開源的時(shí)序數(shù)據(jù)庫，針對(duì)的都是監(jiān)控類時(shí)序數(shù)據(jù)，針對(duì)該場(chǎng)景下數(shù)據(jù)特征做一些特定的優(yōu)化。但按照時(shí)序數(shù)據(jù)的特征來看，還有一類是狀態(tài)類時(shí)序數(shù)據(jù)。這兩類時(shí)序數(shù)據(jù)分別對(duì)應(yīng)不同的場(chǎng)景，監(jiān)控類顧名思義對(duì)應(yīng)的是監(jiān)控場(chǎng)景，而狀態(tài)類針對(duì)的是其他場(chǎng)景，例如軌跡溯源、異常狀態(tài)記錄等。我們最常見的包裹軌跡，就是狀態(tài)類時(shí)序數(shù)據(jù)。

但為何把這兩類數(shù)據(jù)都?xì)w類到時(shí)序，因?yàn)樵跀?shù)據(jù)模型定義、數(shù)據(jù)采集、數(shù)據(jù)存儲(chǔ)以及計(jì)算上，兩者是完全一致的，可以抽象出用同一個(gè)數(shù)據(jù)庫及同一套技術(shù)架構(gòu)。

?

時(shí)序數(shù)據(jù)模型

在定義時(shí)序數(shù)據(jù)模型之前，我們先對(duì)時(shí)序數(shù)據(jù)做一個(gè)抽象的表述。

• 個(gè)體或群體（WHO）：描述產(chǎn)生數(shù)據(jù)的物體，可以是人、監(jiān)控指標(biāo)或者物體。通常描述個(gè)體會(huì)有多維的屬性，可以通過某一類唯一ID來定位到個(gè)體，例如身份ID定位到人，設(shè)備ID定位到設(shè)備。也可以通過多維屬性來定位到個(gè)體，例如通過集群、機(jī)器ID、進(jìn)程名來定位到某個(gè)進(jìn)程。

• 時(shí)間（WHEN）：時(shí)間是時(shí)序數(shù)據(jù)最重要的特征，是區(qū)別于其他數(shù)據(jù)的關(guān)鍵屬性。

• 時(shí)空（WHERE）：通常是通過經(jīng)緯度二維坐標(biāo)定位到地點(diǎn)，在科學(xué)計(jì)算領(lǐng)域例如氣象，通過經(jīng)緯度和高度三維坐標(biāo)來定位。

• 狀態(tài)（WHAT）：用于描述特定個(gè)體在某一刻的狀態(tài)，監(jiān)控類時(shí)序數(shù)據(jù)通常是數(shù)值類型描述狀態(tài)，軌跡數(shù)據(jù)是通過事件表述狀態(tài)，不同場(chǎng)景有不同的表述方式。

?

以上是對(duì)時(shí)序數(shù)據(jù)的一個(gè)抽象的表述，開源的時(shí)序數(shù)據(jù)庫對(duì)時(shí)序數(shù)據(jù)模型有自己的定義，定義了監(jiān)控類時(shí)序數(shù)據(jù)，例如拿OpenTSDB的數(shù)據(jù)模型來舉例：

?

監(jiān)控類時(shí)序數(shù)據(jù)模型定義包含：

• Metric：用于描述監(jiān)控指標(biāo)。

• Tags：用于定位被監(jiān)控的對(duì)象，通過一個(gè)或多個(gè)Tag來描述。

• Timestamp：監(jiān)控值采集的時(shí)間點(diǎn)。

• Value：采集的監(jiān)控值，通常是數(shù)值類型。

?

監(jiān)控類時(shí)序數(shù)據(jù)是時(shí)序數(shù)據(jù)最典型的一類數(shù)據(jù)，有特定的一類特征。監(jiān)控類時(shí)序的特征決定了這類時(shí)序數(shù)據(jù)庫在存儲(chǔ)和計(jì)算上都有特定的方式，相比狀態(tài)類時(shí)序數(shù)據(jù)，在計(jì)算和存儲(chǔ)上有自己特定的優(yōu)化方式。例如聚合計(jì)算會(huì)有特定的幾種數(shù)值聚合函數(shù)，存儲(chǔ)上會(huì)有特殊優(yōu)化的壓縮算法等。在數(shù)據(jù)模型上，監(jiān)控類時(shí)序數(shù)據(jù)通常不需要表述地點(diǎn)即時(shí)空信息，但整體模型上是符合我們對(duì)時(shí)序的一個(gè)統(tǒng)一的抽象表述的。

?

基于監(jiān)控類時(shí)序數(shù)據(jù)模型，按照上面表述的一個(gè)時(shí)序數(shù)據(jù)抽象模型，我們可以定義下時(shí)序數(shù)據(jù)的一個(gè)完整模型：

?

這個(gè)定義包含：

• Name：定義數(shù)據(jù)的類別。

• Tags：描述個(gè)體的元數(shù)據(jù)。

• Location：數(shù)據(jù)的時(shí)空信息。

• Timestamp：數(shù)據(jù)產(chǎn)生的時(shí)間戳。

• Values：數(shù)據(jù)對(duì)應(yīng)的值或狀態(tài)，可提供多個(gè)值或狀態(tài)，非一定是數(shù)值類型。

這個(gè)數(shù)據(jù)模型是一個(gè)更完整的時(shí)序數(shù)據(jù)模型，與OpenTSDB的監(jiān)控類時(shí)序數(shù)據(jù)的模型定義主要有兩個(gè)不同點(diǎn)，一是元數(shù)據(jù)上多了時(shí)空這一維度，二是能表述更豐富的值。

?

時(shí)序數(shù)據(jù)查詢、計(jì)算和分析

時(shí)序數(shù)據(jù)有其特定的查詢和計(jì)算的方式，大致可以分為以下幾類：

時(shí)間線檢索

根據(jù)數(shù)據(jù)模型定義，name+tags+location可以定位個(gè)體，每個(gè)個(gè)體擁有一條時(shí)間線，時(shí)間線上的點(diǎn)就是timestamp和values。時(shí)序數(shù)據(jù)的查詢首先要定位到時(shí)間線，定位是一個(gè)檢索的過程，需要能夠根據(jù)一個(gè)或多個(gè)元數(shù)據(jù)的值的組合來做檢索。也可以根據(jù)元數(shù)據(jù)的關(guān)聯(lián)關(guān)系，來做drill down。

?

時(shí)間范圍查詢

通過檢索定位到時(shí)間線后，會(huì)對(duì)時(shí)間線進(jìn)行查詢。時(shí)間線上很少有對(duì)單個(gè)時(shí)間點(diǎn)的查詢，通常是一段連續(xù)時(shí)間范圍內(nèi)所有點(diǎn)的查詢。而對(duì)于這個(gè)連續(xù)時(shí)間范圍內(nèi)缺失的時(shí)間點(diǎn)，通常會(huì)做插值處理。

?

聚合（Aggregation）

一次查詢可以只針對(duì)單條時(shí)間線，也可以覆蓋多條時(shí)間線。對(duì)于多條時(shí)間線的范圍查詢，通常會(huì)對(duì)返回結(jié)果做聚合。這個(gè)聚合是對(duì)相同時(shí)間點(diǎn)，不同時(shí)間線上值做聚合，通常稱為『后聚合』。

和『后聚合』對(duì)應(yīng)的是『預(yù)聚合』，預(yù)聚合是在時(shí)序數(shù)據(jù)存儲(chǔ)之前提前將多條時(shí)間線聚合為一條時(shí)間線的過程。預(yù)聚合是提前對(duì)數(shù)據(jù)做聚合計(jì)算后存儲(chǔ)，后聚合是查詢存儲(chǔ)數(shù)據(jù)之后做計(jì)算。

?

降精度（Down Sampling）

降精度的計(jì)算邏輯和聚合是類似的，區(qū)別是降精度是針對(duì)的單條時(shí)間線而不是多條時(shí)間線，是對(duì)單條時(shí)間線中一個(gè)時(shí)間范圍內(nèi)的數(shù)據(jù)點(diǎn)做聚合。降精度的目的之一是為了做大時(shí)間范圍數(shù)據(jù)點(diǎn)的展示，另一個(gè)最主要的目的是為了降低存儲(chǔ)成本。

?

分析（Analytic）

分析是為了從時(shí)序數(shù)據(jù)中挖掘更多數(shù)據(jù)價(jià)值出來，有專門的一塊研究領(lǐng)域稱為『時(shí)序分析』。

?

時(shí)序數(shù)據(jù)處理流程

時(shí)序數(shù)據(jù)處理的核心流程如上圖，包含：

• 數(shù)據(jù)模型：對(duì)時(shí)序數(shù)據(jù)的標(biāo)準(zhǔn)定義，采集上來的時(shí)序數(shù)據(jù)必須符合該模型的定義，包含時(shí)序數(shù)據(jù)的所有特征屬性。

• 流計(jì)算：對(duì)時(shí)序數(shù)據(jù)做預(yù)聚合、降精度以及后聚合。

• 數(shù)據(jù)存儲(chǔ)：存儲(chǔ)系統(tǒng)提供高吞吐、海量、低成本存儲(chǔ)，支持?jǐn)?shù)據(jù)冷熱分層，支持高效的范圍查詢。

• 元數(shù)據(jù)檢索：提供元數(shù)據(jù)的存儲(chǔ)和檢索，規(guī)模在千萬級(jí)到億級(jí)的時(shí)間線元數(shù)據(jù)，并且能支持不同方式的檢索（多維過濾和時(shí)空查詢）。

• 數(shù)據(jù)分析：提供對(duì)時(shí)序數(shù)據(jù)的時(shí)序分析計(jì)算能力。

?

我們?cè)賮砜催@幾個(gè)核心過程中，產(chǎn)品選型中可以用到的產(chǎn)品。

?

數(shù)據(jù)存儲(chǔ)

時(shí)序數(shù)據(jù)是典型的非關(guān)系型數(shù)據(jù)，它的特征在于高并發(fā)高吞吐、數(shù)據(jù)體量大以及寫多讀少，查詢模式通常是范圍查詢。針對(duì)這幾個(gè)數(shù)據(jù)特征，是非常適合用NoSQL這類數(shù)據(jù)庫的。幾大流行的開源的時(shí)序數(shù)據(jù)庫，均選擇用NoSQL數(shù)據(jù)庫作為數(shù)據(jù)存儲(chǔ)層，例如基于HBase的OpenTSDB，基于Cassandra的KairosDB等。所以『數(shù)據(jù)存儲(chǔ)』的產(chǎn)品選型，可以選擇HBase或Cassandra這類開源分布式NoSQL數(shù)據(jù)庫，也可以選擇云服務(wù)例如阿里云TableStore。

?

流計(jì)算

流計(jì)算可選用開源產(chǎn)品例如JStrom、Spark Streaming、Flink等，也可以選擇阿里的Blink以及云上產(chǎn)品Stream Compute。

?

元數(shù)據(jù)檢索

時(shí)間線的元數(shù)據(jù)，在量級(jí)上也會(huì)很大，所以首先會(huì)考慮使用分布式數(shù)據(jù)庫。另外在查詢模式上，需要支持檢索，所以數(shù)據(jù)庫需要支持倒排索引和時(shí)空索引，可選擇使用開源的Elasticsearch或Solr。

?

數(shù)據(jù)分析

數(shù)據(jù)分析需要有一個(gè)強(qiáng)大的分布式計(jì)算引擎，可以選擇開源的Spark，也可選擇云上的MaxCompute等，或者一些Serverless SQL引擎例如Presto或云上的Data Lake Analytic等。

?

開源時(shí)序數(shù)據(jù)庫

?

從DB-Engines上的數(shù)據(jù)庫發(fā)展趨勢(shì)可以看到，時(shí)序數(shù)據(jù)庫在這兩年的發(fā)展趨勢(shì)非常迅猛，涌現(xiàn)了一批出色的開源時(shí)序數(shù)據(jù)庫。各大時(shí)序數(shù)據(jù)庫的實(shí)現(xiàn)也各有千秋，從幾個(gè)維度來做一個(gè)綜合對(duì)比：

?

• 數(shù)據(jù)存儲(chǔ)：都是選擇了分布式NoSQL（LSM引擎）存儲(chǔ)，有開源系的分布式數(shù)據(jù)庫例如HBase、Cassandra，也有云服務(wù)系的例如BigTable，也有自研的存儲(chǔ)引擎。

• 聚合：預(yù)聚合基本都只能依賴于外部的流計(jì)算引擎，例如Storm或Spark Streaming。在后聚合層面，查詢后聚合是一個(gè)交互式的過程，所以一般不會(huì)依賴于流計(jì)算引擎，不同時(shí)序數(shù)據(jù)庫提供了單線程的簡(jiǎn)單方式或者并發(fā)的計(jì)算方式。自動(dòng)降精度也是一個(gè)后聚合的過程，不過不是交互式，而是一個(gè)流式的處理，這個(gè)計(jì)算是適合用流計(jì)算引擎的，但都沒有實(shí)現(xiàn)為這么做。

• 元數(shù)據(jù)存儲(chǔ)和檢索：老牌的OpenTSDB沒有專門的元數(shù)據(jù)存儲(chǔ)，不支持對(duì)元數(shù)據(jù)的檢索，元數(shù)據(jù)的獲取和查詢是通過掃描數(shù)據(jù)表的rowkey。KairosDB在Cassandra內(nèi)是專門使用一張表做元數(shù)據(jù)存儲(chǔ)，但是檢索效率很低，需要掃描表。Heroic基于KairosDB做二次開發(fā)，使用Elasticsearch做元數(shù)據(jù)存儲(chǔ)和索引，能支持比較好的元數(shù)據(jù)檢索。InfluxDB和Prometheus則是自己實(shí)現(xiàn)了索引，不過索引實(shí)現(xiàn)也不是一件容易的事，需要承載千萬甚至億級(jí)的時(shí)間線元數(shù)據(jù)。InfluxDB在早期版本實(shí)現(xiàn)了一個(gè)內(nèi)存版元數(shù)據(jù)索引，會(huì)有比較多的限制，例如受限于內(nèi)存大小會(huì)限制時(shí)間線的規(guī)模，以及內(nèi)存索引的構(gòu)建需要掃描所有的時(shí)間線元數(shù)據(jù)，節(jié)點(diǎn)的failover時(shí)間會(huì)較長(zhǎng)。

• 數(shù)據(jù)分析：除了簡(jiǎn)單的查詢后聚合分析能力，大部分TSDB自身都不具備分析能力，除了Elasticsearch，這也是Elasticsearch能插足時(shí)序領(lǐng)域的重要優(yōu)勢(shì)。

?

TableStore時(shí)序數(shù)據(jù)存儲(chǔ)

TableStore作為阿里云自研的分布式NoSQL數(shù)據(jù)庫，在數(shù)據(jù)模型上我們是和Bigtable一樣的Wide Column模型。在存儲(chǔ)模型、數(shù)據(jù)規(guī)模以及寫入和查詢能力上，都能很好的滿足時(shí)序數(shù)據(jù)的場(chǎng)景。在我們之上，也已經(jīng)支持了監(jiān)控類時(shí)序例如云監(jiān)控，以及狀態(tài)類時(shí)序例如阿里健康藥品追蹤以及郵政包裹軌跡等核心業(yè)務(wù)。也有完善的計(jì)算生態(tài)來支撐時(shí)序數(shù)據(jù)的計(jì)算與分析，在未來規(guī)劃中，我們?cè)谠獢?shù)據(jù)檢索、時(shí)序數(shù)據(jù)存儲(chǔ)、計(jì)算與分析以及成本優(yōu)化這幾個(gè)方面，都有針對(duì)時(shí)序場(chǎng)景特定的優(yōu)化。

以上是基于TableStore來構(gòu)建一個(gè)時(shí)序數(shù)據(jù)存儲(chǔ)、計(jì)算和分析的完整架構(gòu)。這是一套Serverless的架構(gòu)，通過組合云產(chǎn)品的方式，能夠做到提供完整的時(shí)序場(chǎng)景所需的所有功能。各個(gè)模塊都是分布式架構(gòu)，提供強(qiáng)大的存儲(chǔ)和計(jì)算能力，且資源可動(dòng)態(tài)擴(kuò)容，各組件也可以替換成其他同類云產(chǎn)品，架構(gòu)上比較靈活，相比開源時(shí)序數(shù)據(jù)庫有很大的優(yōu)勢(shì)。分析下這套架構(gòu)的核心優(yōu)勢(shì)：

?

存儲(chǔ)計(jì)算分離

存儲(chǔ)計(jì)算分離是一套領(lǐng)先的技術(shù)架構(gòu)，其核心優(yōu)勢(shì)在于提供更靈活的計(jì)算和存儲(chǔ)資源配置，成本能更彈性，同時(shí)在負(fù)載均衡和數(shù)據(jù)管理上會(huì)更優(yōu)。在云上環(huán)境，讓用戶真正享受存儲(chǔ)計(jì)算分離帶來的紅利，需要在產(chǎn)品層面提供存儲(chǔ)計(jì)算分離的產(chǎn)品形態(tài)。

TableStore在技術(shù)架構(gòu)和產(chǎn)品形態(tài)上，同時(shí)踐行存儲(chǔ)計(jì)算分離，能夠以比較低的成本自由調(diào)配存儲(chǔ)計(jì)算比。這個(gè)在時(shí)序數(shù)據(jù)場(chǎng)景尤為重要，時(shí)序數(shù)據(jù)場(chǎng)景是一個(gè)計(jì)算相對(duì)比較恒定的場(chǎng)景，但存儲(chǔ)量是線性增長(zhǎng)的。成本優(yōu)化的首要方式是恒定的計(jì)算資源配上可無限擴(kuò)容的存儲(chǔ)，計(jì)算拉動(dòng)存儲(chǔ)，但是無需承擔(dān)額外的計(jì)算成本。

?

數(shù)據(jù)冷熱分層

時(shí)序數(shù)據(jù)有一個(gè)顯著特征是數(shù)據(jù)訪問冷熱分明，最近寫的數(shù)據(jù)會(huì)被更頻繁的訪問。基于這個(gè)特征，熱數(shù)據(jù)采取更高IOPS的存儲(chǔ)介質(zhì)，會(huì)大大的提高整體查詢的效率。TableStore提供高性能和容量型兩種實(shí)例，底下分別對(duì)應(yīng)SSD和SATA兩種存儲(chǔ)介質(zhì)。服務(wù)化的特性，可以支持用戶自由為不同精度的數(shù)據(jù)及不同的查詢分析性能要求，分配使用不同規(guī)格的表。例如對(duì)于高并發(fā)低延遲查詢，分配使用高性能實(shí)例，對(duì)于冷數(shù)據(jù)存儲(chǔ)及低頻查詢，分配使用容量型實(shí)例。對(duì)于交互式的需要較快速度的數(shù)據(jù)分析，可以分配使用高性能實(shí)例。而對(duì)于時(shí)序數(shù)據(jù)分析，離線計(jì)算場(chǎng)景，可以分配使用容量型實(shí)例。

對(duì)于每個(gè)表，可自由定義數(shù)據(jù)的生命周期，例如對(duì)于高精度的表，可配置相對(duì)較短的生命周期。而對(duì)于低精度的表，可配置較長(zhǎng)的生命周期。

存儲(chǔ)量的大頭在冷數(shù)據(jù)，對(duì)于這部分低頻訪問的數(shù)據(jù)，我們會(huì)通過Erasing Coding以及極致壓縮算法進(jìn)一步降低存儲(chǔ)成本。

?

數(shù)據(jù)流動(dòng)閉環(huán)

流計(jì)算是時(shí)序數(shù)據(jù)計(jì)算里最核心的計(jì)算場(chǎng)景，對(duì)時(shí)序數(shù)據(jù)做預(yù)聚合和后聚合。常見的監(jiān)控系統(tǒng)架構(gòu)，采用的是前置流計(jì)算的方案，預(yù)聚合以及對(duì)數(shù)據(jù)的降精度都在前置流計(jì)算內(nèi)做。即數(shù)據(jù)在存儲(chǔ)之前，都是已經(jīng)處理完畢，存儲(chǔ)的僅僅是結(jié)果，不再需要做二次降精度，最多做查詢后聚合。

TableStore與Blink深度結(jié)合，目前已經(jīng)可作為Blink的維表和結(jié)果表，作為Source表已開發(fā)完成待發(fā)布。TableStore可作為Blink的源和端后，整個(gè)數(shù)據(jù)流可形成閉環(huán)，這樣能帶來更靈活的計(jì)算配置。最原始數(shù)據(jù)進(jìn)入Blink會(huì)做一次數(shù)據(jù)清洗和預(yù)聚合，之后將數(shù)據(jù)寫入熱數(shù)據(jù)表。這份數(shù)據(jù)可以自動(dòng)流入到Blink做后聚合，并且支持回溯一定時(shí)間的歷史數(shù)據(jù)，后聚合的結(jié)果可以寫入冷存儲(chǔ)。

TableStore除了對(duì)接Blink，目前也能對(duì)接函數(shù)計(jì)算（Function Compute）做事件編程，在時(shí)序場(chǎng)景可以做實(shí)時(shí)的異常狀態(tài)監(jiān)測(cè)。同時(shí)也可通過Stream API將增量數(shù)據(jù)讀出，做定制化分析。

?

大數(shù)據(jù)分析引擎

TableStore與阿里云自研分布式計(jì)算引擎深度結(jié)合，例如MaxCompute（原ODPS）。MaxCompute可直讀TableStore上的數(shù)據(jù)做分析，免去對(duì)數(shù)據(jù)的ETL過程。

整個(gè)分析過程正在做一些優(yōu)化，例如通過索引去優(yōu)化查詢，底層提供更多的算子做計(jì)算下推等。

?

服務(wù)化能力

一句話總結(jié)，TableStore的服務(wù)化能力特色在于零成本接入、即開即用、全球部署、多語言SDK以及全托管服務(wù)。

?

元數(shù)據(jù)存儲(chǔ)和檢索

元數(shù)據(jù)在時(shí)序數(shù)據(jù)里也是很重要的一塊數(shù)據(jù)，從體量上它相比時(shí)序數(shù)據(jù)會(huì)小很多，但是在查詢復(fù)雜度上，比時(shí)序數(shù)據(jù)會(huì)復(fù)雜很多。

元數(shù)據(jù)從我們給的定義上來說，主要分為Tags和Location，Tags主要用做多維檢索，Location主要做時(shí)空檢索。所以對(duì)底層存儲(chǔ)來說，Tags需要提供高效檢索的話必須要實(shí)現(xiàn)倒排索引，Location則需要實(shí)現(xiàn)時(shí)空索引。一個(gè)服務(wù)級(jí)別的監(jiān)控系統(tǒng)或者軌跡、溯源系統(tǒng)，時(shí)間線的量級(jí)在千萬到億級(jí)別，甚至更高級(jí)別。元數(shù)據(jù)要提供高并發(fā)低延遲的方案，也需要一個(gè)分布式的檢索系統(tǒng)，所以業(yè)界比較好的實(shí)現(xiàn)是用Elasticsearch來存儲(chǔ)和檢索元數(shù)據(jù)。

總結(jié)

TableStore是一款通用的分布式NoSQL數(shù)據(jù)庫，提供多數(shù)據(jù)模型支持，目前已經(jīng)提供的數(shù)據(jù)模型包括Wide Column（類BigTable）以及Timeline（消息數(shù)據(jù)模型）。

業(yè)界同類數(shù)據(jù)庫產(chǎn)品（HBase、Cassandra）的應(yīng)用中，時(shí)序數(shù)據(jù)是一塊很重要的領(lǐng)域。TableStore在時(shí)序數(shù)據(jù)存儲(chǔ)這一塊，正在不停的做探索，在流計(jì)算數(shù)據(jù)閉環(huán)的打造、數(shù)據(jù)分析的優(yōu)化以及元數(shù)據(jù)檢索這幾塊，都在不斷的做改進(jìn)，力求能提供一個(gè)統(tǒng)一的時(shí)序數(shù)據(jù)存儲(chǔ)平臺(tái)。

?

最后，歡迎加入我們的釘釘群（群號(hào)：11789671）進(jìn)行交流。

原文鏈接

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。