逝者如斯夫，不舍晝夜。
?????????????????????????????????????????????????????? —— 孔子

時間如流水，一去不復返。自古不乏對時間流逝的感慨，而現代已經有很多技術記錄流逝的過去。我們可以拍照，可以錄像，當然還可以用時序數據庫！

時序數據庫是專門存放隨著時間推移而不斷變化的數據。近些年，隨著IoT等概念的流行，時序數據庫成為數據庫一個相對獨立的領域逐漸受到重視，廣泛應用于物聯網、監控系統、金融、醫療和零售等多種場景。

過去12個月時序數據庫（Time Series DBMS）熱度不斷增長

那么云上的用戶如何構建一個存儲海量數據的時序數據庫呢？筆者這里推薦使用?云HBase + OpenTSDB?方案。云HBase是使用阿里多年優化過的HBase內核版本，本文不作過多介紹，詳情請看產品主頁。

OpenTSDB簡介

OpenTSDB是一款基于HBase構建的時序數據庫，它的數據存儲完全交給HBase，本身沒有任何數據存儲。所有節點是對等的，所以部署起來其實是非常方便的。因為基于HBase，所以本身就具備了橫向擴展，存儲海量數據的能力。常見的部署模式有2種，一種分離部署，一種混合部署。

獨立部署，即與多個業務共享一個HBase。適合時序業務較小，或者用不滿HBase資源。

?

混合部署，即TSDB進程和RS在一個VM內。適合時序業務較重，需要獨享HBase。

?

上述2種模式，云HBase產品都能提供支持，云HBase購買頁面現已增加時序引擎購買入口。

OpenTSDB數據定義

?

一條時間線由 Metirc + 多個tag 唯一確定，時間線上會有源源不斷的數據點(Data Point)寫入，數據點由時間戳和值組成。OpenTSDB支持秒級(10位整數)，毫秒級別（13位整數）兩種時間精度。

舉個例子，比如我們監控一個手環收集的心跳信息，那么我們可以這樣定義：

Metric: "band.heartbeat" Tags: "id" # 只定義一個tag，就是手環的ID

那么我們通過?band.heartbeat? +?id=1? 就能查詢到編為1的手環收集到的心跳信息。

OpenTSDB數據存儲格式

數據表整體設計

?

這個設計有幾個特點：

• 1.metric和tag映射成UID，不存儲實際字符串，以節約空間。
• 2.每條時間線每小時的數據點歸在一行，每列是一個數據點，這樣每列只需要記錄與這行起始時間偏移，以節省空間。
• 3.每列就是一個KeyValue，如果是毫秒精度，一行最多可以有3600000個KV，這里其實會有些問題，后面會講到。

RowKey格式

?

salt：打散同一metric不同時間線的熱點
metric, tagK, tagV：實際存儲的是字符串對應的UID（在tsdb-uid表中）
timestamp：每小時數據存在一行，記錄的是每小時整點秒級時間戳

metric和tag

它們長度默認是3個字節，即最多只能分配?2^24=16777216?個UID。可以通過這些參數調整：

tsd.storage.uid.width.metric # metric UID長度，默認3 tsd.storage.uid.width.tagk # tagK UID長度，默認3 tsd.storage.uid.width.tagv # tagV UID長度 默認3 # 這3者的UID分配分別是獨立的空間

注意：
集群已經寫過數據后就無法修改，所以最好是一開始就確定好，建議4個字節。因為使用壓縮技術后，RowKey多占的幾個字節可以忽略，下文會提到。

salt

salt這個東西最好根據自己HBase集群規模去配置，它有2個配置：

tsd.storage.salt.width # 默認1，1基本夠了，不用調整 tsd.storage.salt.buckets # 打散到幾個bucket去，默認20

查詢的時候會并發?tsd.storage.salt.buckets? ?個Scanner到HBase上，所以如果這個配置太大，對查詢影響比較大，容易打爆HBase。這里其實是一個權衡，寫入熱點和查詢壓力。默認20其實我個人覺得有點多，配置3～8就差不多了，當然實際效果還和metric設計有關，如果在一個metric里設計了很多時間線，那就得配置很多bucket。在一個metric中設計過多時間線，會影響OpenTSDB的查詢效率，所以不建議這么做。
這個參數也是設置了就不能改的，所以也是要一開始規劃好。

Column格式

?

這是列名（HBase中稱為qualifier）的格式，可以看到毫米級需要多出2個字節。所以如果你的采集間隔不需要精確到毫秒級別，那請一定使用秒級（10位整數）。Value只能存儲整數和浮點，所以有一個bit存儲Float flag。

這里大家一定會有疑問，直接通過qualifier長度是4還是2不就能判斷是秒級精度的數據點，還是毫秒了么？為何還需要MS flag這樣一個標記信息？閱讀下面的“壓縮”部分，就能知道為什么。

OpenTSDB壓縮問題

OpenTSDB有個很常見并且很麻煩的問題，就是整點時候對HBase對流量沖擊。下面2張圖是我們一個測試集群只做寫入對效果：

可以看到會有一個數倍流量的爆發，要持續很久才能消化。這意味著我們需要更高規格去抗這個峰值。首先我們要明白OpenTSDB為啥要做壓縮？在壓縮些什么東西？
前面提到過OpenTSDB一行一小時的特點，那么一行里會有很多KV。表面上看起來好像沒什么問題，但是實際上對比邏輯視圖和物理視圖你會發現一些問題。

很明顯，每個KV都記錄了rowX，那rowX就是一個空間浪費。這個空間不僅影響成本，還影響查詢效率（畢竟數據多了）。壓縮做的事情就是把多個小KV合成1個大KV，減少這部分浪費。所以壓縮的時候會涉及到對HBase的“讀-寫-刪”，這就是整點HBase IO流量的來源。

那么我們有沒有辦法，既做壓縮，同時又消除這部分HBase IO呢？

當然有！我們可以把壓縮的邏輯放到HBase內部去。因為HBase本身就需要對HFile做合并工作，這時候HBase本身就會讀寫數據文件，這部分對HDFS的IO不會少，而我們通過hook在HBase讀出數據后，替換掉要寫入的數據（即壓縮好的數據）。

?

?

實現上面這個功能，當然需要一定內核開發量。好消息是通過云HBase購買頁面購買的時序引擎，已經自帶了上述功能。不管是分離部署模式，還是混合部署模式。
這個功能的好處顯而易見，消除峰值節省成本，提升集群穩定性。這樣我們對一個現有的HBase集群空閑資源需求就不是那么高了，完全可以復用了。下面是使用此功能后，同樣只做寫入的測試集群的流量情況：
?

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

?

總結

以上是生活随笔為你收集整理的解密 云HBase时序引擎OpenTSDB 优化技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。