本文作為介紹opentsdb原理系列文章的第一篇，主要介紹了時序資料以及opentsdb的一些基礎概念，以及opentsdb中的元資料模型定義。
wiki中關於」時間序列（time series）「的定義：時間序列（time series）是一組按照時間發生先後順序進行排列的資料點序列，通常一組時間序列的時間間隔為一恆定值（如1秒，5分鐘，1小時等）。時間序列資料可被簡稱為時序資料。
實時監控系統所收集的監控指標資料，通常就是時序資料。時序資料具有如下特點：
正是因為這些特點，通常使用專門的時序資料庫來儲存，因為這類資料庫更能理解時序資料((tsdb))的特點，而且在讀寫上做一些針對性的優化。相信在在即將大範圍普及的物聯網(iot)應用場景中，時序資料庫(tsdb)會得到更加廣泛的應用。
opentsdb是其中一種時序資料庫實現，因為基於hbase生態構建而獲得了廣泛的關注。目前，華為雲的cloudtable服務已經推出了opentsdb特性。
如下是源自opentsdb官方資料中的時序資料樣例：
sys.cpu.user host=webserver01 1356998400 50對於上面的任意一行資料，在opentsdb中稱之為乙個時間序列中的乙個data point。以最後一行為例我們說明一下opentsdb中關於data point的每一部分組成定義如下：sys.cpu.user host=webserver01,cpu=0 1356998400 1
sys.cpu.user host=webserver01,cpu=1 1356998400 0
sys.cpu.user host=webserver01,cpu=2 1356998400 2
sys.cpu.user host=webserver01,cpu=3 1356998400 0
sys.cpu.user host=webserver01,cpu=63 1356998400 1
構成資訊
名稱sys.cpu.user
metrics
host
tagkey
webserver01
ta**alue
cputagkey
63ta**alue
1356998400
timestamp
1value
可以看出來，每乙個data point，都關聯乙個metrics名稱，但可能關聯多組資訊。而關於時間序列，事實上就是具有相同的metrics名稱以及相同的組資訊的data points的集合。在儲存這些data points的時候，大家也很容易可以想到，可以將這些metrics名稱以及資訊進行特殊編碼來優化儲存，否則會帶來極大的資料冗餘。opentsdb中為每乙個metrics名稱，tagkey以及ta**alue都定義了乙個唯一的數字型別的標識碼(uid)。
uid的全稱為unique identifier。這些uid資訊被儲存在opentsdb的元資料表中，預設表名為」tsdb-uid」。
opentsdb分配uid時遵循如下規則：
為了從uid索引到metrics（或tagkey、ta**alue），同時也要從metrics（或tagkey、ta**alue）索引到uid，opentsdb同時儲存這兩種對映關係資料。
在元資料表中，把這兩種資料分別儲存到兩個名為」id」與」name」的column family中，column family描述資訊如下所示：
關於metrics名為」cpu.hum」，tagkey值為」host」，ta**alue值分別為」189.120.205.26″、」189.120.205.27″的uid資訊定義如下：
說明：rowkey為」0″的行中，分別儲存了metrics、tagkey和ta**alue的當前uid的最大值。當為新的metrics、tagkey和ta**alue分配了新的uid後，會更新對應的最大值rowkey為」1″的行中，rowkey為uid，qualifier為」name:metrics」的值對應metrics name，qualifier為」name:tagk」的值中存放了tagkey，qualifier為」name:ta**」的值中存放了ta**aluerowkey為」2″的行中，rowkey為uid，qualifier為」name:ta**」的值為ta**alue，不存在metrics與tagkey資訊。rowkey為」189.120.205.26″的行中，qualifer為」id:ta**」的值為uid資訊。表示當」189.120.205.26″為ta**alue時，其uid為1rowkey為」189.120.205.27″的行中，qualifer為」id:ta**」的值為uid資訊。表示當」189.120.205.26″為ta**alue時，其uid為2rowkey為」cpu.hum」的行中，qualifer為」id:metrics」的值為uid資訊。表示當cpu.hum為metrics時，其uid為1rowkey為」host」的行中，qualifer為」id:tagk」的值為uid資訊。表示當host為ta**alue時，其uid為1
由於hbase的儲存資料型別是bytes，所以uid在儲存時會被轉換為3個位元組長度的bytes陣列進行儲存。
對每乙個data point，metrics、timestamp、tagkey和ta**alue都是必要的構成元素。除timestamp外，metrics、tagkey和ta**alue的uid就可組成乙個tsuid，每乙個tsuid關聯乙個時間序列，如下所示：
OpenTSDB原理系列 資料表設計
metrics資料的hbase rowkey中包含主要組成部分為 鹽值 salt metrics名稱 時間戳 tagkey ta alue等部分。上篇文章已經講到，為了統一各個值的長度以及節省空間，對metrics名稱 tagkey和ta alue分配了uid資訊。所以，在hbase rowkey中...
OpenTSDB原理系列 讀取流程
乙個完整的opentsdb http query請求，分別由opentsdb i o thread和asynchbase i o thread完成。opentsdb i o thread執行緒負責處理http query請求，asynchbase i o thread負責處理hbase的響應並傳送h...
分析 OpenTSDB資料的儲存
下面結合例子看看opentsdb儲存的一些核心概念 1 metric 即平時我們所說的監控項。譬如上面的 cpu 使用率。2 tags 就是一些標籤，在 opentsdb 裡面，tags 由 tagk 和 tagv 組成，即 tagk takv。標籤是用來描述metric的，譬如上面為了標記是伺服器...