時序數據庫應用場景與設計

• 數據特點

時序數據是基於時間的一系列的數據。在有時間的座標中將這些數據點連成線，往過去看可以做成多緯度報表，揭示其趨勢性、規律性、異常性；往未來看可以做大數據分析，機器學習，實現預測和預警。比如工業上的設備狀態監控，無人駕駛汽車各個設備監控。

時序數據庫就是存放時序數據的數據庫，並且需要支持時序數據的快速寫入、持久化、多緯度的聚合查詢等基本功能。對比傳統數據庫僅僅記錄了數據的當前值，時序數據庫則記錄了所有的歷史數據。同時時序數據的查詢也總是會帶上時間作爲過濾條件

 

• 概念定義

指標	說明
metric	度量，相當於關係型數據庫中的table，用來表示待測定對象
data point	數據點，相當於關係型數據庫中的row，也就是一條一條的記錄
timestamp	時間戳，採集數據的時間
field	度量下的不同字段。比如位置這個度量具有經度和緯度兩個field，風有風速和風向兩個屬性。一般情況下存放的是會隨着時間戳的變化而變化的數據
Tag	標籤，或者附加信息。一般存放的是並不隨着時間戳變化的屬性信息。timestamp加上所有的tags可以認爲是table的primary key

舉個例子：

 

• 應用場景

所有有時序數據產生，並且需要展現其歷史趨勢、週期規律、異常性的，進一步對未來做出預測分析的，都是時序數據庫適合的場景。

在工業物聯網環境監控方向，百度天工的客戶就遇到了這麼一個難題，由於工業上面的要求，需要將工況數據存儲起來。客戶每個廠區具有20000個監測點，500毫秒一個採集週期，一共20個廠區。這樣算起來一年將產生驚人的26萬億個數據點。假設每個點50Byte，數據總量將達1P（如果每臺服務器10T的硬盤，那麼總共需要100多臺服務器）。這些數據不只是要實時生成，寫入存儲；還要支持快速查詢，做可視化的展示，幫助管理者分析決策；並且也能夠用來做大數據分析，發現深層次的問題，幫助企業節能減排，增加效益。最終客戶採用了百度天工的時序數據庫方案，幫助他解決了難題。

在互聯網場景中，也有大量的時序數據產生。百度內部有大量服務使用天工物聯網平臺的時序數據庫。舉個例子，百度內部服務爲了保障用戶的使用體驗，將用戶的每次網絡卡頓、網絡延遲都會記錄到百度天工的時序數據庫。由時序數據庫直接生成報表以供技術產品做分析，儘早的發現、解決問題，保證用戶的使用體驗。

• 需要解決的問題

1. 高併發寫入

如何支持每秒鐘上千萬數據點的寫入

1. 秒級聚合

如何支持在秒級對上億數據的分組聚合運算

1. 成本敏感

如何降低海量數據存儲的成本

 

• 存儲設計

數據的存儲可以分爲兩個問題，單機上存儲和分佈式存儲。

1. 單機存儲

如果只是存儲起來，直接寫成日誌就行。但因爲後續還要快速的查詢，所以需要考慮存儲的結構，合理的進行索引的設計。

傳統數據庫存儲採用的都是Btree（參考鏈接https://www.cnblogs.com/coder2012/p/5309197.html），這是由於其在查詢和順序插入時有利於減少尋道次數的組織形式（順序插入指的是索引key的順序插入，當索引key是順序的時候，能夠充分利用filesystemcache，減少磁盤尋道次數）。我們知道磁盤尋道時間是非常慢的，一般在10ms左右。磁盤的隨機讀寫慢就慢在尋道上面。對於隨機寫入B tree會消耗大量的時間在磁盤尋道上，導致速度很慢。我們知道SSD具有更快的尋道時間，但並沒有從根本上解決這個問題。而在時序數據中，field字段往往是隨機變化的，所以對於90%以上場景都是寫入的時序數據庫，B tree很明顯是不合適的。

業界主流都是採用LSM tree（參考鏈接https://cloud.tencent.com/developer/news/340271）替換B tree，比如Hbase, Cassandra等nosql中。LSM tree操作流程如下：

1. 數據寫入和更新時首先寫入位於內存裏的數據結構。爲了避免數據丟失也會先寫到WAL文件中。
2. 內存裏的數據結構會定時或者達到固定大小會刷到磁盤。這些磁盤上的文件不會被修改。
3. 隨着磁盤上積累的文件越來越多，會定時的進行合併操作，消除冗餘數據，減少文件數量。

LSM tree核心思想就是通過內存寫和後續磁盤的順序寫入獲得更高的寫入性能，避免了隨機寫入。但同時也犧牲了讀取性能

 

1. 分佈式存儲

時序數據庫面向的是海量數據的寫入存儲讀取，單機是無法解決問題的。所以需要採用多機存儲，也就是分佈式存儲。分佈式存儲首先要考慮的是如何將數據分佈到多臺機器上面，也就是 分片（sharding）問題。下面我們就時序數據庫分片問題展開介紹。分片問題由分片方法的選擇和分片的設計組成。時序數據庫的分片方法和其他分佈式系統是相通的。

1. 哈希分片(參考鏈接：https://blog.csdn.net/wang7807564/article/details/80232580)：這種方法實現簡單，均衡性較好，但是集羣不易擴展。
2. 一致性哈希（參考鏈接：https://www.jianshu.com/p/e968c081f563）：這種方案均衡性好，集羣擴展容易，只是實現複雜。代表有Amazon的DynamoDB和開源的Cassandra。
3. 範圍劃分（參考鏈接：https://www.jianshu.com/p/e76f08cdf547）：按照key的範圍進行劃分，比如(0,100],(100,200]劃分成兩塊，通常配合全局有序，複雜度在於合併和分裂。代表有Hbase。

分片設計簡單來說就是以什麼做分片，這是非常有技巧的，會直接影響寫入讀取的性能。結合時序數據庫的特點，根據metric+tags分片是比較好的一種方式，因爲往往會按照一個時間範圍查詢，這樣相同metric和tags的數據會分配到一臺機器上連續存放，順序的磁盤讀取是很快的。再結合上面講到的單機存儲內容，可以做到快速查詢。

       進一步我們考慮時序數據時間範圍很長的情況，需要根據時間範圍再將分成幾段，分別存儲到不同的機器上，這樣對於大範圍時序數據就可以支持併發查詢，優化查詢速度。

       如下圖，第一行和第三行都是同樣的tag（sensor=95D8-7913;city=上海），所以分配到同樣的分片，而第五行雖然也是同樣的tag，但是根據時間範圍再分段，被分到了不同的分片。第二、四、六行屬於同樣的tag（sensor=F3CC-20F3;city=北京）也是一樣的道理。 

 

1. 業界案例

下面我以一批開源時序數據庫作爲說明。

       InfluxDB:

       非常優秀的時序數據庫，但只有單機版是免費開源的，集羣版本是要收費的。從單機版本中可以一窺其存儲方案：在單機上InfluxDB採取類似於LSM tree的存儲結構TSM；而分片的方案InfluxDB先通過<database>+<timestamp>（事實上還要加上retentionPolicy）確定ShardGroup，再通過<metric>+<tags>的hash code確定到具體的Shard。

       這裏timestamp默認情況下是7天對齊，也就是說7天的時序數據會在一個Shard中。

       

p6-Influxdb TSM結構圖（注2）

 

       Kairosdb:

       底層使用Cassandra作爲分佈式存儲引擎，如上文提到單機上採用的是LSM tree。

       Cassandra有兩級索引：partition key和clustering key。其中partition key是其分片ID，使用的是一致性哈希；而clustering key在一個partition key中保證有序。

       Kairosdb利用Cassandra的特性，將 <metric>+<timestamp>+<數據類型>+<tags>作爲partition key，數據點時間在timestamp上的偏移作爲clustering key，其有序性方便做基於時間範圍的查詢。

       partition key中的timestamp是3周對齊的，也就是說21天的時序數據會在一個clustering key下。3周的毫秒數是18億正好小於Cassandra每行列數20億的限制。

 

       OpenTsdb:

       底層使用Hbase作爲其分佈式存儲引擎，採用的也是LSM tree。

       Hbase採用範圍劃分的分片方式。使用row key做分片，保證其全局有序。每個row key下可以有多個column family。每個column family下可以有多個column。

       

       上圖是OpenTsdb的row key組織方式。不同於別的時序數據庫，由於Hbase的row key全局有序，所以增加了可選的salt以達到更好的數據分佈，避免熱點產生。再由與timestamp間的偏移和數據類型組成column qualifier。

       他的timestamp是小時對齊的，也就是說一個row key下最多存儲一個小時的數據。並且需要將構成row key的metric和tags都轉成對應的uid來減少存儲空間，避免Hfile索引太大。下圖是真實的row key示例。

         

 

 

• 查詢設計

用戶對時序數據的查詢場景多種多樣，總的來說時序數據的查詢分爲兩種：原始數據的查詢和時序數據聚合運算的查詢。對於時序數據來說，最主要的難點在於如何解決好海量數據下的聚合查詢問題。爲了解決該問題，數據庫在查詢設計上一般從以下兩方面入手。

1. 分佈式查詢

分佈式聚合查詢通過併發使用多個節點並行查詢和計算來提高性能，減少了分片查詢以及聚合運算的時間，保證了時序數據分析結果秒級返回。 

1. 預處理

數據預處理則是通過空間換時間的思路，將數據根據查詢規則預先計算，查詢時直接返回少量的聚合運算結果來保證更低的查詢延時。 

預處理根據實時性可以分爲二種：批處理和流式處理。批處理的優點是支持對歷史時序數據的處理，實現簡單。但是批處理具有查詢數據量大，非實時的缺點。流式處理的優點是數據實時計算，無需查詢原始數據，但是靈活性欠缺，需要根據應用場景判斷是否適合流式處理。

批處理是使用pull的方式查詢時序原始數據，預先進行聚合運算獲取數據結果寫入時序數據庫，當進行聚合查詢時直接返回預處理後數據結果。時序數據庫定期輪詢規則，根據採樣窗口創建預處理任務，任務根據規則信息形成多個任務隊列。隊列內任務順序執行，隊列間任務併發執行，多任務隊列保證了多租戶對計算資源共享。

流式處理框架同樣能夠支持對數據流做聚合運算，不同於批處理方式，時序數據需要路由到流式處理框架例如Spark，Flink等，當數據時間戳到達採樣窗口時，在內存中實時計算，寫入時序數據庫。

• 關鍵技術

1. 字典編碼

一種通用數據壓縮算法，用《偏移量、長度、下一個字符》的三元組代替一串字符，在編碼中僅僅把字符串看成是一個號碼，而不去管它來表示什麼意義，1977年由兩位以色列教授發明，1985年美國Wekch對該算法進行了改進。

參考鏈接：https://cloud.tencent.com/developer/article/1380632

1. 位圖索引

位圖索引是一種使用位圖的特殊數據庫索引，位置編碼中的每一位表示鍵值對應的數據行的有無。使用場景：主要針對取值範圍較小的列而創建(例如：性別、類別，操作員，部門ID,庫房ID等)，索

引列的取值區間不適合頻繁的更改。相對於B樹索引,佔用的空間非常小,創建和使用非常快。B樹索引更適合於取值範圍較大的列建立索引。

參考鏈接：https://www.cnblogs.com/LBSer/p/3322630.html

1. 列式存儲

列式存儲(Columnar or column-based)是相對於傳統關係型數據庫的行式存儲(Row-basedstorage)來說的。行式存儲意味着同一行數據存放在一起，列式存儲意味着同一列的數據存放在一起。

	行式存儲	列式存儲
優點	數據被保存在一起； INSERT/UPDATE容易；	查詢時只有涉及到的列會被讀取，特別適合大數據場景，減少磁盤IO；任何列都能作爲索引；相同列屬性一致，適合做壓縮，節省存儲空間；
缺點	選擇(Selection)時即使只涉及某幾列，所有數據也都會被讀取；	選擇完成時，被選擇的列要重新組裝； INSERT/UPDATE比較麻煩；

 

存儲過程如下圖：

查詢過程如下，有點像位圖索引的檢索過程：

 

 

 

• 後續

前面部分對時序數據庫場景、設計中的存儲和查詢問題做了分析，後續會針對常用的時序數據庫進行全方位的比較。

參考鏈接：https://blog.csdn.net/huojiao2006/article/details/81203830