8月24日阿里云數(shù)據(jù)庫技術(shù)峰會(huì)上，來自阿里數(shù)據(jù)庫事業(yè)部高級(jí)專家鐘宇帶來HiTSDB 時(shí)序數(shù)據(jù)庫方面的演講。本文主要從時(shí)序數(shù)據(jù)開始介紹，包括時(shí)序序列數(shù)據(jù)的特點(diǎn)，接著介紹了時(shí)序數(shù)據(jù)業(yè)務(wù)場(chǎng)景，以及OpenTSDB在HBase上的優(yōu)化，***分享了HiTSDB的優(yōu)化和提高。

時(shí)序數(shù)據(jù)介紹

時(shí)序數(shù)據(jù)就是在時(shí)間上分布的一系列數(shù)值,時(shí)間和數(shù)值是兩個(gè)關(guān)鍵字，時(shí)序數(shù)據(jù)一般指指標(biāo)型數(shù)據(jù)，比如股票價(jià)格、廣告數(shù)據(jù)、氣溫變化、網(wǎng)站的PV/UV、個(gè)人健康數(shù)據(jù)、工業(yè)傳感器數(shù)據(jù)，還有關(guān)于應(yīng)用程序的性能監(jiān)控，像服務(wù)器系統(tǒng)監(jiān)控?cái)?shù)據(jù)，比如cpu和內(nèi)存占用率，此外還有車聯(lián)網(wǎng)。

據(jù)統(tǒng)計(jì)，在大數(shù)據(jù)領(lǐng)域中時(shí)序數(shù)據(jù)會(huì)超過一半。

圖為廣告的監(jiān)測(cè)數(shù)據(jù)，可以看到事例中跟蹤了三個(gè)廣告來源，每個(gè)來源跟蹤了三個(gè)指標(biāo)，包括展示了多少次、點(diǎn)擊了多少次以及產(chǎn)生了多少收入。廣澳來源是用不同的標(biāo)簽來區(qū)分的，比如由誰發(fā)布、廣告商、針對(duì)目標(biāo)用戶的性別和發(fā)布在哪個(gè)國家等。 大家可以清晰的看到每個(gè)指標(biāo)，在不同的時(shí)間點(diǎn)有不同的數(shù)值，這就構(gòu)成了一系列的時(shí)間數(shù)據(jù)。左邊成為數(shù)據(jù)源，中間成為metric，右邊稱為時(shí)間序列，時(shí)間序列在時(shí)間上具有不同的值，

如果對(duì)時(shí)間序列建模會(huì)有兩種方式，一種是單值，一種是多值。單值是把每一個(gè)數(shù)據(jù)源的每一個(gè)指標(biāo)的每一個(gè)值當(dāng)成一行。多值模型是把同一個(gè)數(shù)據(jù)源的不同指標(biāo)放在不同列中，也就是每個(gè)數(shù)據(jù)源在每個(gè)時(shí)間點(diǎn)只會(huì)產(chǎn)生一行數(shù)據(jù)。

多值模型一定能用單值模型來模擬，多值模型在處理某些數(shù)據(jù)時(shí)更方便些，但是單值建模可以模擬所有場(chǎng)景。

時(shí)間序列數(shù)據(jù)的處理和一般數(shù)據(jù)庫處理有所不同，一般數(shù)據(jù)庫基于行，每一個(gè)數(shù)據(jù)點(diǎn)是一行，時(shí)間序列數(shù)據(jù)是按時(shí)間線處理數(shù)據(jù)。每個(gè)時(shí)間線上的數(shù)據(jù)是非常關(guān)聯(lián)的，比如某一個(gè)廣告源收入在不同時(shí)間上就構(gòu)成時(shí)間序列，這些時(shí)間序列中的收入可以畫成一條變化曲線，針對(duì)曲線我們可以做時(shí)間序列變化處理，最常見的是插值和降精度。由于數(shù)據(jù)源采樣的原因，往往會(huì)丟失一些點(diǎn)，我們用插值在中間插上常見的線性插值或者零值補(bǔ)償;如果廣告數(shù)據(jù)不一定需要最細(xì)時(shí)間粒度來看，我們就可以降精度，不同數(shù)據(jù)降精度的方式不一樣。

針對(duì)時(shí)間數(shù)據(jù)，還有一個(gè)最常見的處理——聚合，我們往往看的不僅僅是從一個(gè)數(shù)據(jù)源來的指標(biāo)，如果我們要看北美地區(qū)某一個(gè)廣告源在一段時(shí)間內(nèi)產(chǎn)生的所有收入的總和，我們就需要把跟廣告源標(biāo)簽對(duì)應(yīng)的時(shí)間線全部挑出來，然后將廣告收入時(shí)間點(diǎn)加和在一起，得到一個(gè)新的求和曲線，如圖所示，我們找到了非常多的時(shí)間線，***用某種聚合函數(shù)聚合在一起。每一種業(yè)務(wù)需要的聚合方式也是不一樣的，比如廣告數(shù)據(jù)算加和，或者按廣告源作平均，也有可能找***最小值，或者作統(tǒng)計(jì)性事情，比如99%值都在某個(gè)數(shù)值以上。

時(shí)間序列數(shù)據(jù)的特點(diǎn)

因此，我們得出時(shí)間序列特點(diǎn)包括以下幾方面：

• 持續(xù)產(chǎn)生大量數(shù)據(jù)。不論是廣告監(jiān)控還是傳感器、氣溫，它針對(duì)的情況很多。比如監(jiān)控工業(yè)園區(qū)中燈的耗電量，每盞燈就會(huì)有傳感器實(shí)時(shí)傳輸燈耗電量，如果采樣間隔是一秒鐘，每盞燈每一秒就會(huì)產(chǎn)生一個(gè)數(shù)據(jù)點(diǎn)，幾萬盞燈沒秒就會(huì)有幾萬次寫入，如果涉及樓宇多，就會(huì)產(chǎn)生每秒幾百萬上千萬的寫入。
• 數(shù)據(jù)產(chǎn)生率平穩(wěn)，無明顯的波峰谷。這帶來了優(yōu)化的好處和壞處，好處是不會(huì)產(chǎn)生明顯的峰值，所以在做容量評(píng)估時(shí)會(huì)比較方便;壞處是沒辦法在閑暇時(shí)間做數(shù)據(jù)合并和補(bǔ)償?shù)墓ぷ鳌?/li>
• 近期的數(shù)據(jù)關(guān)注度更高。
• 時(shí)間久遠(yuǎn)的數(shù)據(jù)，極少被訪問，甚至不再需要。所以時(shí)間序列數(shù)據(jù)一般需要數(shù)據(jù)回滾功能。
• 數(shù)據(jù)存在多個(gè)維度的標(biāo)簽。
• 展示或使用時(shí)往往需要對(duì)數(shù)據(jù)做聚合計(jì)算。

當(dāng)傳統(tǒng)數(shù)據(jù)庫遇到時(shí)間序列數(shù)據(jù)

時(shí)間序列數(shù)據(jù)存到傳統(tǒng)數(shù)據(jù)庫中會(huì)遇到一些問題，例如時(shí)間序列數(shù)據(jù)直接保存到關(guān)系數(shù)據(jù)庫中(例如MySQL 的InnoDB引擎)，使用SQL語句進(jìn)行分析。這里就會(huì)遇到以下一些問題：

1. tag重復(fù)存儲(chǔ)，存儲(chǔ)開銷大，如果將模型變成MySQL的行時(shí)，每個(gè)數(shù)據(jù)點(diǎn)會(huì)產(chǎn)生獨(dú)立的行，也就是標(biāo)簽會(huì)重復(fù)存儲(chǔ)，在一個(gè)時(shí)間序列上每個(gè)數(shù)據(jù)點(diǎn)需要保存到標(biāo)簽重復(fù)存儲(chǔ)一遍，這樣才能用標(biāo)簽把這個(gè)序列上所有的數(shù)據(jù)點(diǎn)找出來。
2. 可以用聯(lián)合索引部分解決多維度的問題，但是進(jìn)一步增加了存儲(chǔ)的開銷。
3. B樹索引在持續(xù)寫入的時(shí)候產(chǎn)生大量隨機(jī)IO，寫性能迅速下降，多聯(lián)合索引加劇了寫入慢的問題，InnoDB是用B+Tree進(jìn)行索引的，為了數(shù)據(jù)查詢快，一般會(huì)根據(jù)標(biāo)簽不同組合建立不同索引，當(dāng)寫入數(shù)據(jù)時(shí)，不同標(biāo)簽寫進(jìn)去的數(shù)據(jù)排序是不一樣的，大部分的標(biāo)簽在寫進(jìn)去時(shí)會(huì)在索引上產(chǎn)生隨機(jī)插入。
4. 數(shù)據(jù)量大導(dǎo)致索引/數(shù)據(jù)很容易超過內(nèi)存容量，查找/聚合性能不高。查詢時(shí)會(huì)導(dǎo)致大量的磁盤IO的開銷。
5. 降精度的SQL子查詢很難被SQL優(yōu)化器優(yōu)化。

OpenTSDB在HBase上的優(yōu)化

OpenTSDB時(shí)間序列數(shù)據(jù)庫架構(gòu)如圖所示，它的存儲(chǔ)基于HBase，HBase具有高性能，可以線性擴(kuò)展。TSD被設(shè)計(jì)為無狀態(tài)節(jié)點(diǎn)，任何一個(gè)節(jié)點(diǎn)可以隨時(shí)替換另一個(gè)節(jié)點(diǎn)進(jìn)行服務(wù)，對(duì)外提供的RPC協(xié)議是HTTP/Json接口，很方便使用。TSD依賴HBase解決一致性，當(dāng)TSD產(chǎn)生寫時(shí)，它一定會(huì)將寫及時(shí)更新到HBase， 而產(chǎn)生讀不***時(shí)候，也會(huì)從HBase中將數(shù)據(jù)讀回來。

OpenTSDB 存儲(chǔ)格式如圖所示，它的存儲(chǔ)上做了很多針對(duì)時(shí)序的考慮和優(yōu)化。

1. 最核心的點(diǎn)是將Tags壓縮，將tags分成兩個(gè)級(jí)別，***個(gè)級(jí)別有一個(gè)表將tags轉(zhuǎn)換成 id，所有的tags id和指標(biāo)的名稱以及時(shí)間一起被組合成row key，row key實(shí)際上是OpenTSDB保存的行鍵，每一行中重復(fù)存儲(chǔ)只有row key，row key 實(shí)際上是每一個(gè)tags都被轉(zhuǎn)換成了整型，row key 相對(duì)來說比較短。
2. 每個(gè)row key對(duì)應(yīng)時(shí)間序列+一個(gè)時(shí)間戳，時(shí)間序列上的數(shù)據(jù)一直存在時(shí)間序列之上，理論上row key 不需要重復(fù)保存，所以一個(gè)小時(shí)的數(shù)據(jù)保存在同一行里，OpenTSDB的存儲(chǔ)格式中每一行有3600個(gè)列，每個(gè)列對(duì)應(yīng)一個(gè)小時(shí)內(nèi)的點(diǎn)，而這一小時(shí)的時(shí)間邊界、指標(biāo)名稱、id一起構(gòu)成了row key。row key重復(fù)存儲(chǔ)的空間就變成了按行設(shè)計(jì)的1/3600，大大地壓縮了row key。
3. Row key的構(gòu)建也經(jīng)過了很好的設(shè)計(jì)，時(shí)間位于metric和tags之間，不需要預(yù)先定義數(shù)據(jù)格式，保證了靈活性;tags掃描時(shí)候，我們經(jīng)常遇到的場(chǎng)景是聚合，需要找到某個(gè)tags的一系列時(shí)間線，OpenTSDB場(chǎng)景中，在tags和搜索條件正好滿足前綴規(guī)則時(shí)可以很好的優(yōu)化，如果共有三個(gè)標(biāo)簽園區(qū)、樓、樓層構(gòu)建row key，如果搜索園區(qū)，掃過的數(shù)據(jù)就是我們要的數(shù)據(jù)，別的園區(qū)數(shù)據(jù)就會(huì)排出掉，HBase常見的問題是產(chǎn)生熱點(diǎn)，OpenTSDB用salt機(jī)制保證熱點(diǎn)。

OpenTSDB的缺點(diǎn)

OpenTSDB也有很多缺點(diǎn)，具體如下：

• 時(shí)間序列的Meta Data以緩存的方式在所有的TSD節(jié)點(diǎn)中存在，時(shí)間序列太多的時(shí)候內(nèi)存壓力很大
• 以RowScan的方式做多維度查詢，當(dāng)查詢條件不滿足RowKey的前綴時(shí)，會(huì)掃過很多無用的RowKey
• 在固定的Column中保存一小時(shí)內(nèi)的時(shí)間點(diǎn)，Qualifier存在額外的開銷
• 單點(diǎn)聚合，容易出現(xiàn)聚合性能瓶頸(cpu&memory)
• 通用壓縮算法，壓縮率依然不理想(每個(gè)數(shù)據(jù)點(diǎn)大約消耗20字節(jié)，包括了RowKey的開銷)
• HiTSDB的優(yōu)化和提高

倒排索引

參考搜索引擎的倒排索引實(shí)現(xiàn)，每個(gè)時(shí)間序列作為一個(gè)文檔，通過tags的倒排索引到時(shí)間序列ID，把timestamp + 時(shí)間序列ID作為RowKey，取代由timestamp + metric ID + tag IDs拼接成的RowKey。

使用倒排索引的解決的問題和對(duì)比如下：

• 倒排索引在集群中的分片和一致性問題，解決辦法：BinLog寫入到HDFS，每個(gè)分片一個(gè)BinLog文件
• 分片策略的問題：按metric，按特定的tag，還是按metric+tags?
• 倒排索引加速了多維度的任意條件查詢
• 倒排索引可以方便的實(shí)現(xiàn)metric和tagkey/tag value的輸入提示
• RowScan vs mget
• 從HBase讀取數(shù)據(jù)是瓶頸，包括網(wǎng)絡(luò)吞吐率和磁盤IO

高壓縮比算法

我們一般認(rèn)為最近的數(shù)據(jù)是最熱的，我們希望最近的數(shù)據(jù)能夠完全的被內(nèi)存緩存，但是時(shí)序數(shù)據(jù)量比較大，因此我們需要采用高壓縮比算法：平均每個(gè)時(shí)間點(diǎn)壓縮到1.37字節(jié)。timestamp采用delta-delta壓縮，value采用二進(jìn)制xor壓縮。

高壓縮比使得最近一段時(shí)間(若干小時(shí))的數(shù)據(jù)可以完全緩存在內(nèi)存里，查詢的時(shí)候避免了HBase的mget操作。解壓縮速度很快，而且降精度可以在解壓的過程中同時(shí)處理，減少內(nèi)存的開銷。

預(yù)降精度功能

我們做了預(yù)降精度，HiTSDB會(huì)在寫入之前根據(jù)很多預(yù)測(cè)好的降精度級(jí)別將數(shù)據(jù)計(jì)算好，預(yù)降精度在邏輯上會(huì)有一些問題，包括以下幾個(gè)方面：

• 數(shù)據(jù)老化 vs 預(yù)降精度
• 預(yù)降精度的級(jí)別和額外空間開銷
• 預(yù)降精度和實(shí)時(shí)降精度結(jié)合
• 平均值帶來的問題
• 精確計(jì)算 vs 概略計(jì)算，在預(yù)降精度數(shù)據(jù)上統(tǒng)計(jì)P99
• 時(shí)間窗口和數(shù)據(jù)修改