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

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

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

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

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

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

多值模型一定能用單值模型來模擬，多值模型在處理某些數(shù)據(jù)時更方便些，但是單值建?？梢阅M所有場景。

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

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

時間序列數(shù)據(jù)的特點

因此，我們得出時間序列特點包括以下幾方面：

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

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

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

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

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

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

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

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

OpenTSDB的缺點

OpenTSDB也有很多缺點，具體如下：

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

倒排索引

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

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

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

高壓縮比算法

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

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

預(yù)降精度功能

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

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