TableStore時序數據存儲 - 架構篇
背景
隨著近幾年物聯網的發展，時序數據迎來了一個不小的爆發。從DB-Engines上近兩年的數據庫類型增長趨勢來看，時序數據庫的增長是非常迅猛的。在去年我花了比較長的時間去了解了一些開源時序數據庫，寫了一個系列的文章（綜述、HBase系、Cassandra系、InfluxDB、Prometheus），感興趣的可以瀏覽。
TableStore作為阿裏雲自研的分布式NoSQL數據庫，在數據模型上我們是多模型設計，包含和BigTable一樣的Wide Column模型以及針對消息數據的Timeline模型。在存儲模型、數據規模以及寫入和查詢能力上，都能比較好的滿足時序數據場景的需求。但我們作為一個通用模型數據庫，時序數據存儲要完全發揮底層數據庫的能力，在表Schema設計以及計算對接上，都要有比較特殊的設計，例如OpenTSDB針對HBase的RowKey設計以及UID編碼等。
本篇文章是架構篇，主要探討時序數據的數據模型定義、核心處理流程以及基於TableStore來構建時序數據存儲的架構。之後還會有方案篇，會提供一個高效的時序數據和元數據存儲的表Schema設計以及索引設計方案。最後還會有計算篇，會提供幾個時序數據流計算和時序分析的方案設計。
什麽是時序數據
時序數據主要劃分為兩類，一類是監控類時序數據，另一類是狀態類時序數據。當前開源的時序數據庫，針對的都是監控類時序數據，針對該場景下數據特征做一些特定的優化。但按照時序數據的特征來看，還有一類是狀態類時序數據。這兩類時序數據分別對應不同的場景，監控類顧名思義對應的是監控場景，而狀態類針對的是其他場景，例如軌跡溯源、異常狀態記錄等。我們最常見的包裹軌跡，就是狀態類時序數據。
但為何把這兩類數據都歸類到時序，因為在數據模型定義、數據采集、數據存儲以及計算上，兩者是完全一致的，可以抽象出用同一個數據庫及同一套技術架構。
時序數據模型
在定義時序數據模型之前，我們先對時序數據做一個抽象的表述。
個體或群體（WHO）：描述產生數據的物體，可以是人、監控指標或者物體。通常描述個體會有多維的屬性，可以通過某一類唯一ID來定位到個體，例如身份ID定位到人，設備ID定位到設備。也可以通過多維屬性來定位到個體，例如通過集群、機器ID、進程名來定位到某個進程。
時間（WHEN）：時間是時序數據最重要的特征，是區別於其他數據的關鍵屬性。
時空（WHERE）：通常是通過經緯度二維坐標定位到地點，在科學計算領域例如氣象，通過經緯度和高度三維坐標來定位。
狀態（WHAT）：用於描述特定個體在某一刻的狀態，監控類時序數據通常是數值類型描述狀態，軌跡數據是通過事件表述狀態，不同場景有不同的表述方式。
以上是對時序數據的一個抽象的表述，開源的時序數據庫對時序數據模型有自己的定義，定義了監控類時序數據，例如拿OpenTSDB的數據模型來舉例：
監控類時序數據模型定義包含：
Metric：用於描述監控指標。
Tags：用於定位被監控的對象，通過一個或多個Tag來描述。
Timestamp：監控值采集的時間點。
Value：采集的監控值，通常是數值類型。
監控類時序數據是時序數據最典型的一類數據，有特定的一類特征。監控類時序的特征決定了這類時序數據庫在存儲和計算上都有特定的方式，相比狀態類時序數據，在計算和存儲上有自己特定的優化方式。例如聚合計算會有特定的幾種數值聚合函數，存儲上會有特殊優化的壓縮算法等。在數據模型上，監控類時序數據通常不需要表述地點即時空信息，但整體模型上是符合我們對時序的一個統一的抽象表述的。
基於監控類時序數據模型，按照上面表述的一個時序數據抽象模型，我們可以定義下時序數據的一個完整模型：
這個定義包含：
Name：定義數據的類別。
Tags：描述個體的元數據。
Location：數據的時空信息。
Timestamp：數據產生的時間戳。
Values：數據對應的值或狀態，可提供多個值或狀態，非一定是數值類型。
這個數據模型是一個更完整的時序數據模型，與OpenTSDB的監控類時序數據的模型定義主要有兩個不同點，一是元數據上多了時空這一維度，二是能表述更豐富的值。
時序數據查詢、計算和分析
時序數據有其特定的查詢和計算的方式，大致可以分為以下幾類：
時間線檢索
根據數據模型定義，name+tags+location可以定位個體，每個個體擁有一條時間線，時間線上的點就是timestamp和values。時序數據的查詢首先要定位到時間線，定位是一個檢索的過程，需要能夠根據一個或多個元數據的值的組合來做檢索。也可以根據元數據的關聯關系，來做drill down。
時間範圍查詢
通過檢索定位到時間線後，會對時間線進行查詢。時間線上很少有對單個時間點的查詢，通常是一段連續時間範圍內所有點的查詢。而對於這個連續時間範圍內缺失的時間點，通常會做插值處理。
聚合（Aggregation）
一次查詢可以只針對單條時間線，也可以覆蓋多條時間線。對於多條時間線的範圍查詢，通常會對返回結果做聚合。這個聚合是對相同時間點，不同時間線上值做聚合，通常稱為『後聚合』。
和『後聚合』對應的是『預聚合』，預聚合是在時序數據存儲之前提前將多條時間線聚合為一條時間線的過程。預聚合是提前對數據做聚合計算後存儲，後聚合是查詢存儲數據之後做計算。
降精度（Down Sampling）
降精度的計算邏輯和聚合是類似的，區別是降精度是針對的單條時間線而不是多條時間線，是對單條時間線中一個時間範圍內的數據點做聚合。降精度的目的之一是為了做大時間範圍數據點的展示，另一個最主要的目的是為了降低存儲成本。
分析（Analytic）
分析是為了從時序數據中挖掘更多數據價值出來，有專門的一塊研究領域稱為『時序分析』。
時序數據處理流程
時序數據處理的核心流程如上圖，包含：
數據模型：對時序數據的標準定義，采集上來的時序數據必須符合該模型的定義，包含時序數據的所有特征屬性。
流計算：對時序數據做預聚合、降精度以及後聚合。
數據存儲：存儲系統提供高吞吐、海量、低成本存儲，支持數據冷熱分層，支持高效的範圍查詢。
元數據檢索：提供元數據的存儲和檢索，規模在千萬級到億級的時間線元數據，並且能支持不同方式的檢索（多維過濾和時空查詢）。
數據分析：提供對時序數據的時序分析計算能力。
我們再來看這幾個核心過程中，產品選型中可以用到的產品。
數據存儲
時序數據是典型的非關系型數據，它的特征在於高並發高吞吐、數據體量大以及寫多讀少，查詢模式通常是範圍查詢。針對這幾個數據特征，是非常適合用NoSQL這類數據庫的。幾大流行的開源的時序數據庫，均選擇用NoSQL數據庫作為數據存儲層，例如基於HBase的OpenTSDB，基於Cassandra的KairosDB等。所以『數據存儲』的產品選型，可以選擇HBase或Cassandra這類開源分布式NoSQL數據庫，也可以選擇雲服務例如阿裏雲TableStore。
流計算
流計算可選用開源產品例如JStrom、Spark Streaming、Flink等，也可以選擇阿裏的Blink以及雲上產品Stream Compute。
元數據檢索
時間線的元數據，在量級上也會很大，所以首先會考慮使用分布式數據庫。另外在查詢模式上，需要支持檢索，所以數據庫需要支持倒排索引和時空索引，可選擇使用開源的Elasticsearch或Solr。
數據分析
數據分析需要有一個強大的分布式計算引擎，可以選擇開源的Spark，也可選擇雲上的MaxCompute等，或者一些Serverless SQL引擎例如Presto或雲上的Data Lake Analytic等。
開源時序數據庫
從DB-Engines上的數據庫發展趨勢可以看到，時序數據庫在這兩年的發展趨勢非常迅猛，湧現了一批出色的開源時序數據庫。各大時序數據庫的實現也各有千秋，從幾個維度來做一個綜合對比：
數據存儲：都是選擇了分布式NoSQL（LSM引擎）存儲，有開源系的分布式數據庫例如HBase、Cassandra，也有雲服務系的例如BigTable，也有自研的存儲引擎。
聚合：預聚合基本都只能依賴於外部的流計算引擎，例如Storm或Spark Streaming。在後聚合層面，查詢後聚合是一個交互式的過程，所以一般不會依賴於流計算引擎，不同時序數據庫提供了單線程的簡單方式或者並發的計算方式。自動降精度也是一個後聚合的過程，不過不是交互式，而是一個流式的處理，這個計算是適合用流計算引擎的，但都沒有實現為這麽做。
元數據存儲和檢索：老牌的OpenTSDB沒有專門的元數據存儲，不支持對元數據的檢索，元數據的獲取和查詢是通過掃描數據表的rowkey。KairosDB在Cassandra內是專門使用一張表做元數據存儲，但是檢索效率很低，需要掃描表。Heroic基於KairosDB做二次開發，使用Elasticsearch做元數據存儲和索引，能支持比較好的元數據檢索。InfluxDB和Prometheus則是自己實現了索引，不過索引實現也不是一件容易的事，需要承載千萬甚至億級的時間線元數據。InfluxDB在早期版本實現了一個內存版元數據索引，會有比較多的限制，例如受限於內存大小會限制時間線的規模，以及內存索引的構建需要掃描所有的時間線元數據，節點的failover時間會較長。
數據分析：除了簡單的查詢後聚合分析能力，大部分TSDB自身都不具備分析能力，除了Elasticsearch，這也是Elasticsearch能插足時序領域的重要優勢。
TableStore時序數據存儲
TableStore作為阿裏雲自研的分布式NoSQL數據庫，在數據模型上我們是和Bigtable一樣的Wide Column模型。在存儲模型、數據規模以及寫入和查詢能力上，都能很好的滿足時序數據的場景。在我們之上，也已經支持了監控類時序例如雲監控，以及狀態類時序例如阿裏健康藥品追蹤以及郵政包裹軌跡等核心業務。也有完善的計算生態來支撐時序數據的計算與分析，在未來規劃中，我們在元數據檢索、時序數據存儲、計算與分析以及成本優化這幾個方面，都有針對時序場景特定的優化。
以上是基於TableStore來構建一個時序數據存儲、計算和分析的完整架構。這是一套Serverless的架構，通過組合雲產品的方式，能夠做到提供完整的時序場景所需的所有功能。各個模塊都是分布式架構，提供強大的存儲和計算能力，且資源可動態擴容，各組件也可以替換成其他同類雲產品，架構上比較靈活，相比開源時序數據庫有很大的優勢。分析下這套架構的核心優勢：
存儲計算分離
存儲計算分離是一套領先的技術架構，其核心優勢在於提供更靈活的計算和存儲資源配置，成本能更彈性，同時在負載均衡和數據管理上會更優。在雲上環境，讓用戶真正享受存儲計算分離帶來的紅利，需要在產品層面提供存儲計算分離的產品形態。
TableStore在技術架構和產品形態上，同時踐行存儲計算分離，能夠以比較低的成本自由調配存儲計算比。這個在時序數據場景尤為重要，時序數據場景是一個計算相對比較恒定的場景，但存儲量是線性增長的。成本優化的首要方式是恒定的計算資源配上可無限擴容的存儲，計算拉動存儲，但是無需承擔額外的計算成本。
數據冷熱分層
時序數據有一個顯著特征是數據訪問冷熱分明，最近寫的數據會被更頻繁的訪問。基於這個特征，熱數據采取更高IOPS的存儲介質，會大大的提高整體查詢的效率。TableStore提供高性能和容量型兩種實例，底下分別對應SSD和SATA兩種存儲介質。服務化的特性，可以支持用戶自由為不同精度的數據及不同的查詢分析性能要求，分配使用不同規格的表。例如對於高並發低延遲查詢，分配使用高性能實例，對於冷數據存儲及低頻查詢，分配使用容量型實例。對於交互式的需要較快速度的數據分析，可以分配使用高性能實例。而對於時序數據分析，離線計算場景，可以分配使用容量型實例。
對於每個表，可自由定義數據的生命周期，例如對於高精度的表，可配置相對較短的生命周期。而對於低精度的表，可配置較長的生命周期。
存儲量的大頭在冷數據，對於這部分低頻訪問的數據，我們會通過Erasing Coding以及極致壓縮算法進一步降低存儲成本。
數據流動閉環
流計算是時序數據計算裏最核心的計算場景，對時序數據做預聚合和後聚合。常見的監控系統架構，采用的是前置流計算的方案，預聚合以及對數據的降精度都在前置流計算內做。即數據在存儲之前，都是已經處理完畢，存儲的僅僅是結果，不再需要做二次降精度，最多做查詢後聚合。
TableStore與Blink深度結合，目前已經可作為Blink的維表和結果表，作為Source表已開發完成待發布。TableStore可作為Blink的源和端後，整個數據流可形成閉環，這樣能帶來更靈活的計算配置。最原始數據進入Blink會做一次數據清洗和預聚合，之後將數據寫入熱數據表。這份數據可以自動流入到Blink做後聚合，並且支持回溯一定時間的歷史數據，後聚合的結果可以寫入冷存儲。
TableStore除了對接Blink，目前也能對接函數計算（Function Compute）做事件編程，在時序場景可以做實時的異常狀態監測。同時也可通過Stream API將增量數據讀出，做定制化分析。
大數據分析引擎
TableStore與阿裏雲自研分布式計算引擎深度結合，例如MaxCompute（原ODPS）。MaxCompute可直讀TableStore上的數據做分析，免去對數據的ETL過程。
整個分析過程正在做一些優化，例如通過索引去優化查詢，底層提供更多的算子做計算下推等。
服務化能力
一句話總結，TableStore的服務化能力特色在於零成本接入、即開即用、全球部署、多語言SDK以及全托管服務。
元數據存儲和檢索
元數據在時序數據裏也是很重要的一塊數據，從體量上它相比時序數據會小很多，但是在查詢復雜度上，比時序數據會復雜很多。
元數據從我們給的定義上來說，主要分為Tags和Location，Tags主要用做多維檢索，Location主要做時空檢索。所以對底層存儲來說，Tags需要提供高效檢索的話必須要實現倒排索引，Location則需要實現時空索引。一個服務級別的監控系統或者軌跡、溯源系統，時間線的量級在千萬到億級別，甚至更高級別。元數據要提供高並發低延遲的方案，也需要一個分布式的檢索系統，所以業界比較好的實現是用Elasticsearch來存儲和檢索元數據。
總結
TableStore是一款通用的分布式NoSQL數據庫，提供多數據模型支持，目前已經提供的數據模型包括Wide Column（類BigTable）以及Timeline（消息數據模型）。
業界同類數據庫產品（HBase、Cassandra）的應用中，時序數據是一塊很重要的領域。TableStore在時序數據存儲這一塊，正在不停的做探索，在流計算數據閉環的打造、數據分析的優化以及元數據檢索這幾塊，都在不斷的做改進，力求能提供一個統一的時序數據存儲平臺。
最後，歡迎加入我們的釘釘群（群號：11789671）進行交流。
原文鏈接請添加鏈接描述
本文為雲棲社區原創內容，未經允許不得轉載。
TableStore時序數據存儲 - 架構篇