2017年時(shí)序數(shù)據(jù)庫(kù)忽然火了起來(lái)。開(kāi)年2月Facebook開(kāi)源了beringei時(shí)序數(shù)據(jù)庫(kù)；到了4月基于PostgreSQL打造的時(shí)序數(shù)據(jù)庫(kù)TimeScaleDB也開(kāi)源了，而早在2016年7月，百度云在其天工物聯(lián)網(wǎng)平臺(tái)上發(fā)布了國(guó)內(nèi)***多租戶的分布式時(shí)序數(shù)據(jù)庫(kù)產(chǎn)品TSDB，成為支持其發(fā)展制造，交通，能源，智慧城市等產(chǎn)業(yè)領(lǐng)域的核心產(chǎn)品，同時(shí)也成為百度戰(zhàn)略發(fā)展產(chǎn)業(yè)物聯(lián)網(wǎng)的標(biāo)志性事件。時(shí)序數(shù)據(jù)庫(kù)作為物聯(lián)網(wǎng)方向一個(gè)非常重要的服務(wù)，業(yè)界的頻頻發(fā)聲，正說(shuō)明各家企業(yè)已經(jīng)迫不及待的擁抱物聯(lián)網(wǎng)時(shí)代的到來(lái)。

本文會(huì)從時(shí)序數(shù)據(jù)庫(kù)的基本概念、使用場(chǎng)景、解決的問(wèn)題一一展開(kāi)，***會(huì)從如何解決時(shí)序數(shù)據(jù)存儲(chǔ)這一技術(shù)問(wèn)題入手進(jìn)行深入分析。

1. 背景

百度無(wú)人車(chē)在運(yùn)行時(shí)需要監(jiān)控各種狀態(tài)，包括坐標(biāo)，速度，方向，溫度，濕度等等，并且需要把每時(shí)每刻監(jiān)控的數(shù)據(jù)記錄下來(lái)，用來(lái)做大數(shù)據(jù)分析。每輛車(chē)每天就會(huì)采集將近8T的數(shù)據(jù)。如果只是存儲(chǔ)下來(lái)不查詢也還好(雖然已經(jīng)是不小的成本)，但如果需要快速查詢“今天下午兩點(diǎn)在后廠村路，速度超過(guò)60km/h的無(wú)人車(chē)有哪些”這樣的多緯度分組聚合查詢，那么時(shí)序數(shù)據(jù)庫(kù)會(huì)是一個(gè)很好的選擇。

2. 什么是時(shí)序數(shù)據(jù)庫(kù)

先來(lái)介紹什么是時(shí)序數(shù)據(jù)。時(shí)序數(shù)據(jù)是基于時(shí)間的一系列的數(shù)據(jù)。在有時(shí)間的坐標(biāo)中將這些數(shù)據(jù)點(diǎn)連成線，往過(guò)去看可以做成多緯度報(bào)表，揭示其趨勢(shì)性、規(guī)律性、異常性;往未來(lái)看可以做大數(shù)據(jù)分析，機(jī)器學(xué)習(xí)，實(shí)現(xiàn)預(yù)測(cè)和預(yù)警。

時(shí)序數(shù)據(jù)庫(kù)就是存放時(shí)序數(shù)據(jù)的數(shù)據(jù)庫(kù)，并且需要支持時(shí)序數(shù)據(jù)的快速寫(xiě)入、持久化、多緯度的聚合查詢等基本功能。

對(duì)比傳統(tǒng)數(shù)據(jù)庫(kù)僅僅記錄了數(shù)據(jù)的當(dāng)前值，時(shí)序數(shù)據(jù)庫(kù)則記錄了所有的歷史數(shù)據(jù)。同時(shí)時(shí)序數(shù)據(jù)的查詢也總是會(huì)帶上時(shí)間作為過(guò)濾條件。

時(shí)序數(shù)據(jù)示例

p1-北上廣三地2015年氣溫變化圖

p2-北上廣三地當(dāng)前溫度實(shí)時(shí)展現(xiàn)

下面介紹下時(shí)序數(shù)據(jù)庫(kù)的一些基本概念(不同的時(shí)序數(shù)據(jù)庫(kù)稱呼略有不同)。

metric: 度量，相當(dāng)于關(guān)系型數(shù)據(jù)庫(kù)中的table。

data point: 數(shù)據(jù)點(diǎn)，相當(dāng)于關(guān)系型數(shù)據(jù)庫(kù)中的row。

timestamp：時(shí)間戳，代表數(shù)據(jù)點(diǎn)產(chǎn)生的時(shí)間。

field: 度量下的不同字段。比如位置這個(gè)度量具有經(jīng)度和緯度兩個(gè)field。一般情況下存放的是會(huì)隨著時(shí)間戳的變化而變化的數(shù)據(jù)。

tag: 標(biāo)簽，或者附加信息。一般存放的是并不隨著時(shí)間戳變化的屬性信息。timestamp加上所有的tags可以認(rèn)為是table的primary key。

如下圖，度量為Wind，每一個(gè)數(shù)據(jù)點(diǎn)都具有一個(gè)timestamp，兩個(gè)field：direction和speed，兩個(gè)tag：sensor、city。它的***行和第三行，存放的都是sensor號(hào)碼為95D8-7913的設(shè)備，屬性城市是上海。隨著時(shí)間的變化，風(fēng)向和風(fēng)速都發(fā)生了改變，風(fēng)向從23.4變成23.2;而風(fēng)速?gòu)?.4變成了3.3。

p3-時(shí)序數(shù)據(jù)庫(kù)基本概念圖

3. 時(shí)序數(shù)據(jù)庫(kù)的場(chǎng)景

所有有時(shí)序數(shù)據(jù)產(chǎn)生，并且需要展現(xiàn)其歷史趨勢(shì)、周期規(guī)律、異常性的，進(jìn)一步對(duì)未來(lái)做出預(yù)測(cè)分析的，都是時(shí)序數(shù)據(jù)庫(kù)適合的場(chǎng)景。

在工業(yè)物聯(lián)網(wǎng)環(huán)境監(jiān)控方向，百度天工的客戶就遇到了這么一個(gè)難題，由于工業(yè)上面的要求，需要將工況數(shù)據(jù)存儲(chǔ)起來(lái)?？蛻裘總€(gè)廠區(qū)具有20000個(gè)監(jiān)測(cè)點(diǎn)，500毫秒一個(gè)采集周期，一共20個(gè)廠區(qū)。這樣算起來(lái)一年將產(chǎn)生驚人的26萬(wàn)億個(gè)數(shù)據(jù)點(diǎn)。假設(shè)每個(gè)點(diǎn)50Byte，數(shù)據(jù)總量將達(dá)1P(如果每臺(tái)服務(wù)器10T的硬盤(pán)，那么總共需要100多臺(tái)服務(wù)器)。這些數(shù)據(jù)不只是要實(shí)時(shí)生成，寫(xiě)入存儲(chǔ);還要支持快速查詢，做可視化的展示，幫助管理者分析決策;并且也能夠用來(lái)做大數(shù)據(jù)分析，發(fā)現(xiàn)深層次的問(wèn)題，幫助企業(yè)節(jié)能減排，增加效益。最終客戶采用了百度天工的時(shí)序數(shù)據(jù)庫(kù)方案，幫助他解決了難題。

在互聯(lián)網(wǎng)場(chǎng)景中，也有大量的時(shí)序數(shù)據(jù)產(chǎn)生。百度內(nèi)部有大量服務(wù)使用天工物聯(lián)網(wǎng)平臺(tái)的時(shí)序數(shù)據(jù)庫(kù)。舉個(gè)例子，百度內(nèi)部服務(wù)為了保障用戶的使用體驗(yàn)，將用戶的每次網(wǎng)絡(luò)卡頓、網(wǎng)絡(luò)延遲都會(huì)記錄到百度天工的時(shí)序數(shù)據(jù)庫(kù)。由時(shí)序數(shù)據(jù)庫(kù)直接生成報(bào)表以供技術(shù)產(chǎn)品做分析，盡早的發(fā)現(xiàn)、解決問(wèn)題，保證用戶的使用體驗(yàn)。

4. 時(shí)序數(shù)據(jù)庫(kù)遇到的挑戰(zhàn)

很多人可能認(rèn)為在傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)上加上時(shí)間戳一列就能作為時(shí)序數(shù)據(jù)庫(kù)。數(shù)據(jù)量少的時(shí)候確實(shí)也沒(méi)問(wèn)題，但少量數(shù)據(jù)是展現(xiàn)的緯度有限，細(xì)節(jié)少，可置信低，更加不能用來(lái)做大數(shù)據(jù)分析。很明顯時(shí)序數(shù)據(jù)庫(kù)是為了解決海量數(shù)據(jù)場(chǎng)景而設(shè)計(jì)的。

可以看到時(shí)序數(shù)據(jù)庫(kù)需要解決以下幾個(gè)問(wèn)題

l 時(shí)序數(shù)據(jù)的寫(xiě)入：如何支持每秒鐘上千萬(wàn)上億數(shù)據(jù)點(diǎn)的寫(xiě)入。

l 時(shí)序數(shù)據(jù)的讀?。河秩绾沃С衷诿爰?jí)對(duì)上億數(shù)據(jù)的分組聚合運(yùn)算。

l 成本敏感：由海量數(shù)據(jù)存儲(chǔ)帶來(lái)的是成本問(wèn)題。如何更低成本的存儲(chǔ)這些數(shù)據(jù)，將成為時(shí)序數(shù)據(jù)庫(kù)需要解決的重中之重。

這些問(wèn)題不是用一篇文章就能含蓋的，同時(shí)每個(gè)問(wèn)題都可以從多個(gè)角度去優(yōu)化解決。在這里只從數(shù)據(jù)存儲(chǔ)這個(gè)角度來(lái)嘗試回答如何解決大數(shù)據(jù)量的寫(xiě)入和讀取。

5. 數(shù)據(jù)的存儲(chǔ)

數(shù)據(jù)的存儲(chǔ)可以分為兩個(gè)問(wèn)題，單機(jī)上存儲(chǔ)和分布式存儲(chǔ)。

單機(jī)存儲(chǔ)

如果只是存儲(chǔ)起來(lái)，直接寫(xiě)成日志就行。但因?yàn)楹罄m(xù)還要快速的查詢，所以需要考慮存儲(chǔ)的結(jié)構(gòu)。

傳統(tǒng)數(shù)據(jù)庫(kù)存儲(chǔ)采用的都是B tree，這是由于其在查詢和順序插入時(shí)有利于減少尋道次數(shù)的組織形式。我們知道磁盤(pán)尋道時(shí)間是非常慢的，一般在10ms左右。磁盤(pán)的隨機(jī)讀寫(xiě)慢就慢在尋道上面。對(duì)于隨機(jī)寫(xiě)入B tree會(huì)消耗大量的時(shí)間在磁盤(pán)尋道上，導(dǎo)致速度很慢。我們知道SSD具有更快的尋道時(shí)間，但并沒(méi)有從根本上解決這個(gè)問(wèn)題。

對(duì)于90%以上場(chǎng)景都是寫(xiě)入的時(shí)序數(shù)據(jù)庫(kù)，B tree很明顯是不合適的。

業(yè)界主流都是采用LSM tree替換B tree，比如Hbase, Cassandra等nosql中。這里我們?cè)敿?xì)介紹一下。

LSM tree包括內(nèi)存里的數(shù)據(jù)結(jié)構(gòu)和磁盤(pán)上的文件兩部分。分別對(duì)應(yīng)Hbase里的MemStore和HLog;對(duì)應(yīng)Cassandra里的MemTable和sstable。

LSM tree操作流程如下：

1. 數(shù)據(jù)寫(xiě)入和更新時(shí)首先寫(xiě)入位于內(nèi)存里的數(shù)據(jù)結(jié)構(gòu)。為了避免數(shù)據(jù)丟失也會(huì)先寫(xiě)到WAL文件中。

2. 內(nèi)存里的數(shù)據(jù)結(jié)構(gòu)會(huì)定時(shí)或者達(dá)到固定大小會(huì)刷到磁盤(pán)。這些磁盤(pán)上的文件不會(huì)被修改。

3. 隨著磁盤(pán)上積累的文件越來(lái)越多，會(huì)定時(shí)的進(jìn)行合并操作，消除冗余數(shù)據(jù)，減少文件數(shù)量。

p4-Hbase LSM tree結(jié)構(gòu)介紹(注1)

可以看到LSM tree核心思想就是通過(guò)內(nèi)存寫(xiě)和后續(xù)磁盤(pán)的順序?qū)懭氆@得更高的寫(xiě)入性能，避免了隨機(jī)寫(xiě)入。但同時(shí)也犧牲了讀取性能，因?yàn)橥粋€(gè)key的值可能存在于多個(gè)HFile中。為了獲取更好的讀取性能，可以通過(guò)bloom filter和compaction得到，這里限于篇幅就不詳細(xì)展開(kāi)。

分布式存儲(chǔ)

時(shí)序數(shù)據(jù)庫(kù)面向的是海量數(shù)據(jù)的寫(xiě)入存儲(chǔ)讀取，單機(jī)是無(wú)法解決問(wèn)題的。所以需要采用多機(jī)存儲(chǔ)，也就是分布式存儲(chǔ)。

分布式存儲(chǔ)首先要考慮的是如何將數(shù)據(jù)分布到多臺(tái)機(jī)器上面，也就是 分片(sharding)問(wèn)題。下面我們就時(shí)序數(shù)據(jù)庫(kù)分片問(wèn)題展開(kāi)介紹。分片問(wèn)題由分片方法的選擇和分片的設(shè)計(jì)組成。

分片方法

時(shí)序數(shù)據(jù)庫(kù)的分片方法和其他分布式系統(tǒng)是相通的。

哈希分片：這種方法實(shí)現(xiàn)簡(jiǎn)單，均衡性較好，但是集群不易擴(kuò)展。

一致性哈希：這種方案均衡性好，集群擴(kuò)展容易，只是實(shí)現(xiàn)復(fù)雜。代表有Amazon的DynamoDB和開(kāi)源的Cassandra。

范圍劃分：通常配合全局有序，復(fù)雜度在于合并和分裂。代表有Hbase。

分片設(shè)計(jì)

分片設(shè)計(jì)簡(jiǎn)單來(lái)說(shuō)就是以什么做分片，這是非常有技巧的，會(huì)直接影響寫(xiě)入讀取的性能。

結(jié)合時(shí)序數(shù)據(jù)庫(kù)的特點(diǎn)，根據(jù)metric+tags分片是比較好的一種方式，因?yàn)橥鶗?huì)按照一個(gè)時(shí)間范圍查詢，這樣相同metric和tags的數(shù)據(jù)會(huì)分配到一臺(tái)機(jī)器上連續(xù)存放，順序的磁盤(pán)讀取是很快的。再結(jié)合上面講到的單機(jī)存儲(chǔ)內(nèi)容，可以做到快速查詢。

進(jìn)一步我們考慮時(shí)序數(shù)據(jù)時(shí)間范圍很長(zhǎng)的情況，需要根據(jù)時(shí)間范圍再將分成幾段，分別存儲(chǔ)到不同的機(jī)器上，這樣對(duì)于大范圍時(shí)序數(shù)據(jù)就可以支持并發(fā)查詢，優(yōu)化查詢速度。

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

p5-時(shí)序數(shù)據(jù)分片說(shuō)明

6. 真實(shí)案例

下面我以一批開(kāi)源時(shí)序數(shù)據(jù)庫(kù)作為說(shuō)明。

InfluxDB:

非常優(yōu)秀的時(shí)序數(shù)據(jù)庫(kù)，但只有單機(jī)版是免費(fèi)開(kāi)源的，集群版本是要收費(fèi)的。從單機(jī)版本中可以一窺其存儲(chǔ)方案：在單機(jī)上InfluxDB采取類(lèi)似于LSM tree的存儲(chǔ)結(jié)構(gòu)TSM;而分片的方案InfluxDB先通過(guò)+(事實(shí)上還要加上retentionPolicy)確定ShardGroup，再通過(guò)+的hash code確定到具體的Shard。

這里timestamp默認(rèn)情況下是7天對(duì)齊，也就是說(shuō)7天的時(shí)序數(shù)據(jù)會(huì)在一個(gè)Shard中。

p6-Influxdb TSM結(jié)構(gòu)圖(注2)

Kairosdb:

底層使用Cassandra作為分布式存儲(chǔ)引擎，如上文提到單機(jī)上采用的是LSM tree。

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

Kairosdb利用Cassandra的特性，將++<數(shù)據(jù)類(lèi)型>+作為partition key，數(shù)據(jù)點(diǎn)時(shí)間在timestamp上的偏移作為clustering key，其有序性方便做基于時(shí)間范圍的查詢。

partition key中的timestamp是3周對(duì)齊的，也就是說(shuō)21天的時(shí)序數(shù)據(jù)會(huì)在一個(gè)clustering key下。3周的毫秒數(shù)是18億正好小于Cassandra每行列數(shù)20億的限制。

OpenTsdb:

底層使用Hbase作為其分布式存儲(chǔ)引擎，采用的也是LSM tree。

Hbase采用范圍劃分的分片方式。使用row key做分片，保證其全局有序。每個(gè)row key下可以有多個(gè)column family。每個(gè)column family下可以有多個(gè)column。

上圖是OpenTsdb的row key組織方式。不同于別的時(shí)序數(shù)據(jù)庫(kù)，由于Hbase的row key全局有序，所以增加了可選的salt以達(dá)到更好的數(shù)據(jù)分布，避免熱點(diǎn)產(chǎn)生。再由與timestamp間的偏移和數(shù)據(jù)類(lèi)型組成column qualifier。

他的timestamp是小時(shí)對(duì)齊的，也就是說(shuō)一個(gè)row key下最多存儲(chǔ)一個(gè)小時(shí)的數(shù)據(jù)。并且需要將構(gòu)成row key的metric和tags都轉(zhuǎn)成對(duì)應(yīng)的uid來(lái)減少存儲(chǔ)空間，避免Hfile索引太大。下圖是真實(shí)的row key示例。

p7-open tsdb的row key示例(注3)

7. 結(jié)束語(yǔ)

可以看到各分布式時(shí)序數(shù)據(jù)庫(kù)雖然存儲(chǔ)方案都略有不同，但本質(zhì)上是一致的，由于時(shí)序數(shù)據(jù)寫(xiě)多讀少的場(chǎng)景，在單機(jī)上采用更加適合大吞吐量寫(xiě)入的單機(jī)存儲(chǔ)結(jié)構(gòu)，而在分布式方案上根據(jù)時(shí)序數(shù)據(jù)的特點(diǎn)來(lái)精心設(shè)計(jì)，目標(biāo)就是設(shè)計(jì)的分片方案能方便時(shí)序數(shù)據(jù)的寫(xiě)入和讀取，同時(shí)使數(shù)據(jù)分布更加均勻，盡量避免熱點(diǎn)的產(chǎn)生。