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

背景

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

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

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

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

?

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

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

但為何把這兩類數(shù)據(jù)都歸類到時序，因為在數(shù)據(jù)模型定義、數(shù)據(jù)采集、數(shù)據(jù)存儲以及計算上，兩者是完全一致的，可以抽象出用同一個數(shù)據(jù)庫及同一套技術架構。

?

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

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

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

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

• 時空（WHERE）：通常是通過經(jīng)緯度二維坐標定位到地點，在科學計算領域例如氣象，通過經(jīng)緯度和高度三維坐標來定位。

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

?

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

?

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

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

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

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

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

?

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

?

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

?

這個定義包含：

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

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

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

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

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

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

?

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

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

時間線檢索

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

?

時間范圍查詢

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

?

聚合（Aggregation）

一次查詢可以只針對單條時間線，也可以覆蓋多條時間線。對于多條時間線的范圍查詢，通常會對返回結果做聚合。這個聚合是對相同時間點，不同時間線上值做聚合，通常稱為『后聚合』。

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

?

降精度（Down Sampling）

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

?

分析（Analytic）

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

?

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

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

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

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

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

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

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

?

我們再來看這幾個核心過程中，產(chǎn)品選型中可以用到的產(chǎn)品。

?

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

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

?

流計算

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

?

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

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

?

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

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

?

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

?

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

?

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

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

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

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

?

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

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

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

?

存儲計算分離

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

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

?

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

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

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

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

?

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

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

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

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

?

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

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

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

?

服務化能力

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

?

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

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

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

總結

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

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

?

最后，歡迎加入我們的釘釘群（群號：11789671）進行交流。

原文鏈接

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