時序數(shù)據(jù)庫技術(shù)體系中一個非常重要的技術(shù)點是時序數(shù)據(jù)模型設(shè)計，不同的時序系統(tǒng)有不同的設(shè)計模式，不同的設(shè)計模式對時序數(shù)據(jù)的讀寫性能、數(shù)據(jù)壓縮效率等各個方面都有不同程度的影響。這篇文章筆者將會分別針對OpenTSDB、Druid、InfluxDB以及Beringei這四個時序系統(tǒng)中的時序數(shù)據(jù)模型設(shè)計進行介紹。

在詳細介紹時序數(shù)據(jù)模型之前，還是有必要簡單回顧一下時序數(shù)據(jù)的幾個基本概念，如下圖所示：

上圖是一個典型的時序數(shù)據(jù)示意圖，由圖中可以看出，時序數(shù)據(jù)由兩個維度坐標來表示，橫坐標表示時間軸，隨著時間的不斷流逝，數(shù)據(jù)也會源源不斷地吐出來;和橫坐標不同，縱坐標由兩種元素構(gòu)成，分別是數(shù)據(jù)源和metric，數(shù)據(jù)源由一系列的標簽(tag，也稱為維度)唯一表示，圖中數(shù)據(jù)源是一個廣告數(shù)據(jù)源，這個數(shù)據(jù)源由publisher、advertiser、gender以及country四個維度值唯一表示，metric表示待收集的數(shù)據(jù)源指標。一個數(shù)據(jù)源通常會采集很多指標(metric)，上圖中廣告數(shù)據(jù)源就采集了impressions、clicks以及revenue這三種指標，分別表示廣告瀏覽量、廣告點擊率以及廣告收入。

看到這里，相信大家對時序數(shù)據(jù)已經(jīng)有了一個初步的了解，可以簡單的概括為：一個時序數(shù)據(jù)點(point)由datasource(tags)+metric+timestamp這三部分唯一確定。然而，這只是邏輯上的概念理解，那具體的時序數(shù)據(jù)庫到底是如何將這樣一系列時序數(shù)據(jù)點進行存儲的呢?下文筆者針對OpenTSDB、Druid、InfluxDB以及Beringei四種系統(tǒng)進行介紹。

OpenTSDB(HBase)時序數(shù)據(jù)存儲模型

OpenTSDB基于HBase存儲時序數(shù)據(jù)，在HBase層面設(shè)計RowKey規(guī)則為： metric+timestamp+datasource(tags) 。HBase是一個KV數(shù)據(jù)庫，一個時序數(shù)據(jù)(point)如果以KV的形式表示，那么其中的V必然是point的具體數(shù)值，而K就自然而然是唯一確定point數(shù)值的datasource+metric+timestamp。 這種規(guī)律不僅適用于HBase，還適用于其他KV數(shù)據(jù)庫，比如Kudu。

既然HBase中K是由datasource、metric以及timestamp三者構(gòu)成，現(xiàn)在我們可以簡單認為rowkey就為這三者的組合，那問題來了：這三者的組合順序是怎么樣的呢?

首先來看哪個應該排在首位。因為HBase中一張表的數(shù)據(jù)組織方式是按照rowkey的字典序順序排列的，為了將同一種指標的所有數(shù)據(jù)集中放在一起，HBase將將metric放在了rowkey的最前面。假如將timestamp放在最前面，同一時刻的數(shù)據(jù)必然會寫入同一個數(shù)據(jù)分片，無法起到散列的效果;而如果將datasource(即tags)放在最前面的話，這里有個更大的問題，就是datasource本身由多個標簽組成，如果用戶指定其中部分標簽查找，而且不是前綴標簽的話，在HBase里面將會變成大范圍的掃描過濾查詢，查詢效率非常之低。舉個上面的例子，如果將datasource放在最前面，那rowkey就可以表示為publisher=ultrarimfast.com&advertiser:google.com&gender:Male&country:USA_impressions_20110101000000，此時用戶想查找20110101000000這個時間點所有發(fā)布在USA的所有廣告的瀏覽量，即只根據(jù)country=USA這樣一個維度信息查找指定時間點的某個指標，而且這個維度不是前綴維度，就會掃描大量的記錄進行過濾。

確定了metric放在最前面之后，再來看看接下來應該將datasource放在中間呢還是應該將timestamp放在中間?將metric放在前面已經(jīng)可以解決請求均勻分布(散列)的要求，因此HBase將timestamp放在中間，將datasource放在最后。試想，如果將datasource放在中間，也會遇到上文中說到的后綴維度查找的問題。

因此，OpenTSDB中rowkey的設(shè)計為：metric+timestamp+datasource，好了，那HBase就可以只設(shè)置一個columnfamily和一個column。那問題來了，OpenTSDB的這種設(shè)計有什么問題?在了解設(shè)計問題之前需要簡單看看HBase在文件中存儲KV的方式，即一系列時序數(shù)據(jù)在文件、內(nèi)存中的存儲方式，如下圖所示：

上圖是HBase中一個存儲KeyValue(KV)數(shù)據(jù)的數(shù)據(jù)塊結(jié)構(gòu)，一個數(shù)據(jù)塊由多個KeyValue數(shù)據(jù)組成，在我們的事例中KeyValue就是一個時序數(shù)據(jù)點(point)。其中Value結(jié)構(gòu)很簡單，就是一個數(shù)值。而Key就比較復雜了，由rowkey+columnfamily+column+timestamp+keytype組成，其中rowkey等于metric+timestamp+datasource。

• 問題一：存在很多無用的字段。 一個KeyValue中只有rowkey是有用的，其他字段諸如columnfamily、column、timestamp以及keytype從理論上來講都沒有任何實際意義，但在HBase的存儲體系里都必須存在，因而耗費了很大的存儲成本。
• 問題二：數(shù)據(jù)源和采集指標冗余。 KeyValue中rowkey等于metric+timestamp+datasource，試想同一個數(shù)據(jù)源的同一個采集指標，隨著時間的流逝不斷吐出采集數(shù)據(jù)，這些數(shù)據(jù)理論上共用同一個數(shù)據(jù)源(datasource)和采集指標(metric)，但在HBase的這套存儲體系下，共用是無法體現(xiàn)的，因此存在大量的數(shù)據(jù)冗余，主要是數(shù)據(jù)源冗余以及采集指標冗余。
• 問題三：無法有效的壓縮。 HBase提供了塊級別的壓縮算法-snappy、gzip等，這些通用壓縮算法并沒有針對時序數(shù)據(jù)進行設(shè)置，壓縮效率比較低。HBase同樣提供了一些編碼算法，比如FastDiff等等，可以起到一定的壓縮效果，但是效果并不佳。效果不佳的主要原因是HBase沒有數(shù)據(jù)類型的概念，沒有schema的概念，不能針對特定數(shù)據(jù)類型進行特定編碼，只能選擇通用的編碼，效果可想而知。
• 問題四：不能完全保證多維查詢能力。 HBase本身沒有schema，目前沒有實現(xiàn)倒排索引機制，所有查詢必須指定metric、timestamp以及完整的tags或者前綴tags進行查詢，對于后綴維度查詢也勉為其難。

雖說有這樣那樣的問題，但是OpenTSDB還是針對存儲模型做了兩個方面的優(yōu)化：

• 優(yōu)化一：timestamp并不是想象中細粒度到秒級或毫秒級，而是精確到小時級別，然后將小時中每一秒設(shè)置到列上。 這樣一行就會有3600列，每一列表示一小時的一秒。這樣設(shè)置據(jù)說可以有效的取出一小時整的數(shù)據(jù)。
• 優(yōu)化二：所有metrics以及所有標簽信息(tags)都使用了全局編碼將標簽值編碼成更短的bit，減少rowkey的存儲數(shù)據(jù)量。 上文分析HBase這種存儲方式的弊端是說道會存在大量的數(shù)據(jù)源(tags)冗余以及指標(metric)冗余，有冗余是吧，那我就搞個編碼，將string編碼成bit，盡最大努力減少冗余。雖說這樣的全局編碼可以有效降低數(shù)據(jù)的存儲量，但是因為全局編碼字典需要存儲在內(nèi)存中，因此在很多時候(海量標簽值)，字典所需內(nèi)存都會非常之大。

上述兩個優(yōu)化可以參考OpenTSDB這張經(jīng)典的示意圖：

Druid時序數(shù)據(jù)存儲模型設(shè)計

和HBase和Kudu這類KV數(shù)據(jù)庫不同，Druid是另一種玩法。Druid是一個不折不扣的列式存儲系統(tǒng)，沒有HBase的主鍵。上述時序數(shù)據(jù)在Druid中表示是下面這個樣子的：

Druid是一個列式數(shù)據(jù)庫，所以每一列都會獨立存儲，比如Timestamp列會存儲在一起形成一個文件，publish列會存儲在一起形成一個文件，以此類推。細心的童鞋就會說了，這樣存儲，依然會有數(shù)據(jù)源(tags)大量冗余的問題。針對冗余這個問題，Druid和HBase的處理方式一樣，都是采用編碼字典對標簽值進行編碼，將string類型的標簽值編碼成int值。但和HBase不一樣的是，Druid編碼是局部編碼，Druid和HBase都采用LSM結(jié)構(gòu)，數(shù)據(jù)先寫入內(nèi)存再flush到數(shù)據(jù)文件，Druid編碼是文件級別的，局部編碼可以有效減小對內(nèi)存的巨大壓力。除此之外，Druid的這種列式存儲模式還有如下好處：

數(shù)據(jù)存儲壓縮率高。每列獨立存儲，可以針對每列進行壓縮，而且可以為每列設(shè)置對應的壓縮策略，比如時間列、int、fload、double、string都可以分別進行壓縮，壓縮效果更好。

支持多維查找。Druid為datasource的每個列分別設(shè)置了Bitmap索引，利用Bitmap索引可以有效實現(xiàn)多維查找，比如用戶想查找20110101T00:00:00這個時間點所有發(fā)布在USA的所有廣告的瀏覽量，可以根據(jù)country=USA在Bitmap索引中找到要找的行號，再根據(jù)行號定位待查的metrics。

然而，這樣的存儲模型也有一些問題：

1. 數(shù)據(jù)依然存在冗余。 和OpenTSDB一樣，tags存在大量的冗余。
2. 指定數(shù)據(jù)源的范圍查找并沒有OpenTSDB高效。 這是因為Druid會將數(shù)據(jù)源拆開成多個標簽，每個標簽都走Bitmap索引，再最后使用與操作找到滿足條件的行號，這個過程需要一定的開銷。而OpenTSDB中直接可以根據(jù)數(shù)據(jù)源拼成rowkey，查找走B+樹索引，效率必然會更高。

InfluxDB時序數(shù)據(jù)存儲模型設(shè)計

相比OpenTSDB以及Druid，可能很多童鞋對InfluxDB并不特別熟悉，然而在時序數(shù)據(jù)庫排行榜單上InfluxDB卻是遙遙領(lǐng)先。InfluxDB是一款專業(yè)的時序數(shù)據(jù)庫，只存儲時序數(shù)據(jù)，因此在數(shù)據(jù)模型的存儲上可以針對時序數(shù)據(jù)做非常多的優(yōu)化工作。

為了保證寫入的高效，InfluxDB也采用LSM結(jié)構(gòu)，數(shù)據(jù)先寫入內(nèi)存，當內(nèi)存容量達到一定閾值之后flush到文件。InfluxDB在時序數(shù)據(jù)模型設(shè)計方面提出了一個非常重要的概念：seriesKey，seriesKey實際上就是datasource(tags)+metric，時序數(shù)據(jù)寫入內(nèi)存之后按照seriesKey進行組織：

內(nèi)存中實際上就是一個Map：>，Map中一個SeriesKey對應一個List，List中存儲時間線數(shù)據(jù)。數(shù)據(jù)進來之后根據(jù)datasource(tags)+metric拼成SeriesKey，再將Timestamp|Value組合值寫入時間線數(shù)據(jù)List中。內(nèi)存中的數(shù)據(jù)flush的文件后，同樣會將同一個SeriesKey中的時間線數(shù)據(jù)寫入同一個Block塊內(nèi)，即一個Block塊內(nèi)的數(shù)據(jù)都屬于同一個數(shù)據(jù)源下的一個metric。

這種設(shè)計我們認為是將時間序列數(shù)據(jù)按照時間線挑了出來。先來看看這樣設(shè)計的好處：

• 好處一：同一數(shù)據(jù)源的tags不再冗余存儲。一個Block內(nèi)的數(shù)據(jù)都共用一個SeriesKey，只需要將這個SeriesKey寫入這個Block的Trailer部分就可以。 大大降低了時序數(shù)據(jù)的存儲量。
• 好處二：時間序列和value可以在同一個Block內(nèi)分開獨立存儲，獨立存儲就可以對時間列以及數(shù)值列分別進行壓縮。InfluxDB對時間列的存儲借鑒了Beringei的壓縮方式，使用delta-delta壓縮方式極大的提高了壓縮效率。而對Value的壓縮可以針對不同的數(shù)據(jù)類型采用相同的壓縮效率。
• 好處三：對于給定數(shù)據(jù)源以及時間范圍的數(shù)據(jù)查找，可以非常高效的進行查找。這一點和OpenTSDB一樣。

細心的同學可能會問了，將datasource(tags)和metric拼成SeriesKey，不是也不能實現(xiàn)多維查找。確實是這樣，不過InfluxDB內(nèi)部實現(xiàn)了倒排索引機制，即實現(xiàn)了tag到SeriesKey的映射關(guān)系，如果用戶想根據(jù)某個tag查找的話，首先根據(jù)tag在倒排索引中找到對應的SeriesKey，再根據(jù)SeriesKey定位具體的時間線數(shù)據(jù)。 InfluxDB的這種存儲引擎稱為TSM，全稱為Timestamp-Structure Merge Tree，基本原理類似于LSM。后期筆者將會對InfluxDB的數(shù)據(jù)寫入、文件格式、倒排索引以及數(shù)據(jù)讀取進行專題介紹。

Beringei時序數(shù)據(jù)存儲模型設(shè)計

Beringei是今年Facebook開源的一個時序數(shù)據(jù)庫系統(tǒng)。InfluxDB時序數(shù)據(jù)模型設(shè)計很好地將時間序列按照數(shù)據(jù)源以及metric挑選了出來，解決了維度列值冗余存儲，時間列不能有效壓縮的問題。但InfluxDB沒有很好的解決寫入緩存壓縮的問題：InfluxDB在寫入內(nèi)存的時候并沒有壓縮，而是在數(shù)據(jù)寫入文件的時候進行對應壓縮。我們知道時序數(shù)據(jù)最大的特點之一是最近寫入的數(shù)據(jù)最熱，將最近寫入的數(shù)據(jù)全部放在內(nèi)存可以極大提升讀取效率。Beringei很好的解決了這個問題，流式壓縮意味著數(shù)據(jù)寫入內(nèi)存之后就進行壓縮，這樣會使得內(nèi)存中可以緩存更多的時序數(shù)據(jù)，這樣對于最近數(shù)據(jù)的查詢會有很大的幫助。

Beringei的時序數(shù)據(jù)模型設(shè)計與InfluxDB基本一致，也是提出類似于SeriesKey的概念，將時間線挑了出來。但和InfluxDB有兩個比較大的區(qū)別：

1. 文件組織形式不同。Beringei的文件存儲形式按照時間窗口組織，比如最近5分鐘的數(shù)據(jù)全部寫入同一個文件，這個文件分為很多block，每個block中的所有時序數(shù)據(jù)共用一個SeriesKey。Beringei文件沒有索引，InfluxDB有索引。
2. Beringei目前沒有倒排索引機制，因此對于多維查詢并不高效。

后續(xù)筆者也會針對Beringei的數(shù)據(jù)寫入、流式壓縮、文件格式等進行介紹。在筆者看來，如果將Beringei和InfluxDB有效結(jié)合起來，就能夠?qū)r序數(shù)據(jù)高效存儲在內(nèi)存，另外數(shù)據(jù)按照維度進行組織，可以非常高效的提高數(shù)據(jù)在文件的存儲效率以及查詢效率，最后結(jié)合InfluxDB的倒排索引功能可以有效提高多維查詢能力。

本文是時序數(shù)據(jù)庫技術(shù)體系的第一篇文章，筆者主要結(jié)合OpenTSDB、Druid、InfluxDB以及Beringei這四種時序數(shù)據(jù)庫分別對時序數(shù)據(jù)這種數(shù)據(jù)形式的存儲模型進行了介紹。每種數(shù)據(jù)庫都有自己的一套存儲方式，而每種存儲方式都有各自的一些優(yōu)勢以及缺陷，正是這些優(yōu)劣式直接決定了相應時序數(shù)據(jù)庫的壓縮性能、讀寫性能。