本文根據演講視頻以及PPT整理而成。
本文將主要圍繞以下四個方面進行分享：
- OpenTSDB的介紹
- OpenTSDB的常見問題
- OpenTSDB的壓縮優化
- 雲OpenTSDB的使用模式
本文首先會對OpenTSDB簡單介紹，以及使用OpenTSDB時所遇到的常見問題，之後則會重點介紹相對於社區版的OpenTSDB所做的相應改進，最後介紹雲OpenTSDB的幾種使用模式。
在這裡還是要推薦下我自己建的大數據學習交流群740041381，群裡都是學大數據開發的，如果你正在學習大數據 ，小編歡迎你加入,大家都是軟件開發黨，不定期分享乾貨（只有大數據軟件開發相關的），包括我自己整理的一份最新的大數據進階資料和高級開發教程，歡迎進階中和進想深入大數據的小夥伴加入。
一、OpenTSDB的介紹
OpenTSDB是一款基於HBase構建的時序數據庫，時序數據具有以下特點：
（1）數據為數值類型，常用於監控。
（2）數據通常按照時間順序抵達。
（3）數據基本不會被更新。
（4）寫入較多，讀入較少。目前用戶在阿里雲上部署時序數據庫所選擇的架構通常為對SLB進行掛載後，對一定數量的OpenTSDB進行部署，最後底層與HBase相關聯。
OpenTSDB對時序數據具有如下定義，首先在數據存儲過程中會創建Metric，可以理解為一個監控的group，並用Tags對數據進行進一步的標識，Metric+Tags的組合代表一個具體的時間線，每一條時間線上會存儲多個數據點，其中數據點是一個包含時間和值的二元組，每一條時間線會不斷的產生相關數據並進行寫入。對於時間精度，OpenTSDB支持秒級和毫秒級的時間精度，在寫入的數據中如果數據點的時間戳為10位，則時間精度為秒，如果寫入的時間戳為13位，則時間精度為毫秒。接下來簡單介紹一下OpenTSDB的存儲結構，以寫metric=host.cpu, timestamp=1552643656, tags={region:HangZhou,host:30,43,111,255}, value=100為例，這條數據到達HBase存儲層後經過了如下轉換，其中存儲數據metric=host.cpu時，將其映射成唯一UID進行存儲。為了減少存儲空間，每條時間線每一小時存儲一行。因此對於timestamp=1552643656，會將數據轉換成小時的起始整秒，同樣，對於tags的信息，也會映射成唯一UID進行存儲。至此整個RowKey部分便存儲完成，對於Column部分，將會記錄和這個小時起始時間的偏移量，以及value的值。
下面對RowKey和Column的數據格式進行更為詳細的介紹，實際上，為了避免同一個Metric擁有很多條時間線導致的寫入熱點問題，在Metric前面會有加鹽的一位數據salt，來打散同一Metric下不同時間線的熱點。同時Metric和Tag的默認長度為3個字節，即最多隻能分配16777216個UID，為了防止UID超量的問題，可以通過修改相應的參數（tsd.storage.uid.width.metric, tsd.storage.uid.width.tagk, tsd.storage.uid.width.tagv）來進行調整，但需要注意的是，一旦集群已經寫入數據後參數便無法再次進行修改。對於Column部分的數據格式來說，秒級和毫秒級的數據格式是有差異的，毫秒級的數據需要更多的空間來進行存儲，
二、OpenTSDB的常見問題
接下來介紹OpenTSDB的常見問題，在上文提到，為了避免同一個Metric擁有很多條時間線導致的寫入熱點問題，會通過對數據加鹽一位來將熱點打散，但打散後會將Metric分到多個buckets中，此時在進行查詢時，有多少個buckets便會併發多少個查詢請求到HBase中，此時便有了寫入熱點與併發查詢的權衡問題，過多的併發度很容易將HBase打爆，因此需要考慮實際的HBase的業務規模來進行參數的設置。同樣需要注意的一點，該項設置寫入數據後，也無法進行修改。
第二個問題是Tags的笛卡兒積影響查詢效率，假設一個監控機器CPU情況的mertric=host.cpu有三個tag，分別是機房區域region，主機名host，cpu單核編號core。這三個tag的數量分別為10，100，8。那麼該mertric會包含101008=8000條時間線，假使現在需要查詢某一條時間線上的數據，也需要訪問8000條時間線上的數據才能得到所需要的結果，其根本原因在於tag是沒有索引的，目前常見的解決辦法主要有兩種，一種是將tag提至RowKey前，來進行索引的建立，另一種是在RowKey中拼接tag的部分信息來減少笛卡兒積。OpenTSDB還有一些其他的查詢問題，比如數據不是流式處理，數據點要全部放入到TSDB內存後才會開始進行聚合處理，容易OOM；一個大的查詢只會分配給一臺TSDB上進行處理，不能分佈式處理；即使只查詢15分鐘的數據，也需要遍歷一小時的數據等。
第三個問題便是OpenTSDB的壓縮問題，即整點壓縮對HBase產生流量衝擊。為了節省存儲空間，OpenTSDB會將離散的KV合成為一個大的KV，來減少重複字段，所以在整點時間便會有讀取-壓縮-重寫-刪除一系列的操作產生，這些操作會對HBase發起大量的IO請求，導致長時間的數倍流量波峰，很容易將HBase打爆。因此需要更高的機器規模來抵抗波峰。
三、OpenTSDB的壓縮優化
事實上，如果能夠消除流量波峰，可以極大的降低運營成本，提高系統的穩定性。傳統數據壓縮的步驟是先從HBase中讀取上一個小時寫入的所有數據，然後在OpenTSDB中壓縮這些讀出的數據，並將壓縮好的數據寫入HBase中，最後將舊的數據從HBase中刪除，可以看出壓縮數據中存在了大量的OpenTSDB對於HBase的IO請求。為了解決這一問題，需要對OpenTSDB的壓縮進行優化，具體的實現思路是將OpenTSDB的壓縮過程下沉到底層HBase中，因為HBaes自身壓縮數據時便會對數據進行讀寫，在此時對數據進行處理，複用HBase壓縮過程的流量，在合併HFile的時候將KV按照OpenTSDB的數據格式進行合併，便可以避免OpenTSDB對HBase發起大量的IO請求，從而避免了流量波峰。
四、雲OpenTSDB的使用模式
最後介紹一下雲OpenTSDB的幾種使用模式，一種是獨享模式，即完全獨立部署的時序數據庫，適合時序業務較重，需要分離部署的情況。
另一種是共享模式，可以複用已經購買的雲HBase，適合時序業務較小，或者使用HBase雲資源較小的情況，可以在一定程度上節約成本。
閱讀更多 微笑數據工程師 的文章
