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

時(shí)間如流水，一去不復(fù)返。自古不乏對(duì)時(shí)間流逝的感慨，而現(xiàn)代已經(jīng)有很多技術(shù)記錄流逝的過(guò)去。我們可以拍照，可以錄像，當(dāng)然還可以用時(shí)序數(shù)據(jù)庫(kù)！

時(shí)序數(shù)據(jù)庫(kù)是專(zhuān)門(mén)存放隨著時(shí)間推移而不斷變化的數(shù)據(jù)。近些年，隨著IoT等概念的流行，時(shí)序數(shù)據(jù)庫(kù)成為數(shù)據(jù)庫(kù)一個(gè)相對(duì)獨(dú)立的領(lǐng)域逐漸受到重視，廣泛應(yīng)用于物聯(lián)網(wǎng)、監(jiān)控系統(tǒng)、金融、醫(yī)療和零售等多種場(chǎng)景。

過(guò)去12個(gè)月時(shí)序數(shù)據(jù)庫(kù)（Time Series DBMS）熱度不斷增長(zhǎng)

那么云上的用戶如何構(gòu)建一個(gè)存儲(chǔ)海量數(shù)據(jù)的時(shí)序數(shù)據(jù)庫(kù)呢？筆者這里推薦使用?云HBase + OpenTSDB?方案。云HBase是使用阿里多年優(yōu)化過(guò)的HBase內(nèi)核版本，本文不作過(guò)多介紹，詳情請(qǐng)看產(chǎn)品主頁(yè)。

OpenTSDB簡(jiǎn)介

OpenTSDB是一款基于HBase構(gòu)建的時(shí)序數(shù)據(jù)庫(kù)，它的數(shù)據(jù)存儲(chǔ)完全交給HBase，本身沒(méi)有任何數(shù)據(jù)存儲(chǔ)。所有節(jié)點(diǎn)是對(duì)等的，所以部署起來(lái)其實(shí)是非常方便的。因?yàn)榛贖Base，所以本身就具備了橫向擴(kuò)展，存儲(chǔ)海量數(shù)據(jù)的能力。常見(jiàn)的部署模式有2種，一種分離部署，一種混合部署。

獨(dú)立部署，即與多個(gè)業(yè)務(wù)共享一個(gè)HBase。適合時(shí)序業(yè)務(wù)較小，或者用不滿HBase資源。

?

混合部署，即TSDB進(jìn)程和RS在一個(gè)VM內(nèi)。適合時(shí)序業(yè)務(wù)較重，需要獨(dú)享HBase。

?

上述2種模式，云HBase產(chǎn)品都能提供支持，云HBase購(gòu)買(mǎi)頁(yè)面現(xiàn)已增加時(shí)序引擎購(gòu)買(mǎi)入口。

OpenTSDB數(shù)據(jù)定義

?

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

舉個(gè)例子，比如我們監(jiān)控一個(gè)手環(huán)收集的心跳信息，那么我們可以這樣定義：

Metric: "band.heartbeat" Tags: "id" # 只定義一個(gè)tag，就是手環(huán)的ID

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

OpenTSDB數(shù)據(jù)存儲(chǔ)格式

數(shù)據(jù)表整體設(shè)計(jì)

?

這個(gè)設(shè)計(jì)有幾個(gè)特點(diǎn)：

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

RowKey格式

?

salt：打散同一metric不同時(shí)間線的熱點(diǎn)
metric, tagK, tagV：實(shí)際存儲(chǔ)的是字符串對(duì)應(yīng)的UID（在tsdb-uid表中）
timestamp：每小時(shí)數(shù)據(jù)存在一行，記錄的是每小時(shí)整點(diǎn)秒級(jí)時(shí)間戳

metric和tag

它們長(zhǎng)度默認(rèn)是3個(gè)字節(jié)，即最多只能分配?2^24=16777216?個(gè)UID。可以通過(guò)這些參數(shù)調(diào)整：

tsd.storage.uid.width.metric # metric UID長(zhǎng)度，默認(rèn)3 tsd.storage.uid.width.tagk # tagK UID長(zhǎng)度，默認(rèn)3 tsd.storage.uid.width.tagv # tagV UID長(zhǎng)度 默認(rèn)3 # 這3者的UID分配分別是獨(dú)立的空間

注意：
集群已經(jīng)寫(xiě)過(guò)數(shù)據(jù)后就無(wú)法修改，所以最好是一開(kāi)始就確定好，建議4個(gè)字節(jié)。因?yàn)槭褂脡嚎s技術(shù)后，RowKey多占的幾個(gè)字節(jié)可以忽略，下文會(huì)提到。

salt

salt這個(gè)東西最好根據(jù)自己HBase集群規(guī)模去配置，它有2個(gè)配置：

tsd.storage.salt.width # 默認(rèn)1，1基本夠了，不用調(diào)整 tsd.storage.salt.buckets # 打散到幾個(gè)bucket去，默認(rèn)20

查詢的時(shí)候會(huì)并發(fā)?tsd.storage.salt.buckets? ?個(gè)Scanner到HBase上，所以如果這個(gè)配置太大，對(duì)查詢影響比較大，容易打爆HBase。這里其實(shí)是一個(gè)權(quán)衡，寫(xiě)入熱點(diǎn)和查詢壓力。默認(rèn)20其實(shí)我個(gè)人覺(jué)得有點(diǎn)多，配置3～8就差不多了，當(dāng)然實(shí)際效果還和metric設(shè)計(jì)有關(guān)，如果在一個(gè)metric里設(shè)計(jì)了很多時(shí)間線，那就得配置很多bucket。在一個(gè)metric中設(shè)計(jì)過(guò)多時(shí)間線，會(huì)影響OpenTSDB的查詢效率，所以不建議這么做。
這個(gè)參數(shù)也是設(shè)置了就不能改的，所以也是要一開(kāi)始規(guī)劃好。

Column格式

?

這是列名（HBase中稱(chēng)為qualifier）的格式，可以看到毫米級(jí)需要多出2個(gè)字節(jié)。所以如果你的采集間隔不需要精確到毫秒級(jí)別，那請(qǐng)一定使用秒級(jí)（10位整數(shù)）。Value只能存儲(chǔ)整數(shù)和浮點(diǎn)，所以有一個(gè)bit存儲(chǔ)Float flag。

這里大家一定會(huì)有疑問(wèn)，直接通過(guò)qualifier長(zhǎng)度是4還是2不就能判斷是秒級(jí)精度的數(shù)據(jù)點(diǎn)，還是毫秒了么？為何還需要MS flag這樣一個(gè)標(biāo)記信息？閱讀下面的“壓縮”部分，就能知道為什么。

OpenTSDB壓縮問(wèn)題

OpenTSDB有個(gè)很常見(jiàn)并且很麻煩的問(wèn)題，就是整點(diǎn)時(shí)候?qū)Base對(duì)流量沖擊。下面2張圖是我們一個(gè)測(cè)試集群只做寫(xiě)入對(duì)效果：

可以看到會(huì)有一個(gè)數(shù)倍流量的爆發(fā)，要持續(xù)很久才能消化。這意味著我們需要更高規(guī)格去抗這個(gè)峰值。首先我們要明白OpenTSDB為啥要做壓縮？在壓縮些什么東西？
前面提到過(guò)OpenTSDB一行一小時(shí)的特點(diǎn)，那么一行里會(huì)有很多KV。表面上看起來(lái)好像沒(méi)什么問(wèn)題，但是實(shí)際上對(duì)比邏輯視圖和物理視圖你會(huì)發(fā)現(xiàn)一些問(wèn)題。

很明顯，每個(gè)KV都記錄了rowX，那rowX就是一個(gè)空間浪費(fèi)。這個(gè)空間不僅影響成本，還影響查詢效率（畢竟數(shù)據(jù)多了）。壓縮做的事情就是把多個(gè)小KV合成1個(gè)大KV，減少這部分浪費(fèi)。所以壓縮的時(shí)候會(huì)涉及到對(duì)HBase的“讀-寫(xiě)-刪”，這就是整點(diǎn)HBase IO流量的來(lái)源。

那么我們有沒(méi)有辦法，既做壓縮，同時(shí)又消除這部分HBase IO呢？

當(dāng)然有！我們可以把壓縮的邏輯放到HBase內(nèi)部去。因?yàn)镠Base本身就需要對(duì)HFile做合并工作，這時(shí)候HBase本身就會(huì)讀寫(xiě)數(shù)據(jù)文件，這部分對(duì)HDFS的IO不會(huì)少，而我們通過(guò)hook在HBase讀出數(shù)據(jù)后，替換掉要寫(xiě)入的數(shù)據(jù)（即壓縮好的數(shù)據(jù)）。

?

?

實(shí)現(xiàn)上面這個(gè)功能，當(dāng)然需要一定內(nèi)核開(kāi)發(fā)量。好消息是通過(guò)云HBase購(gòu)買(mǎi)頁(yè)面購(gòu)買(mǎi)的時(shí)序引擎，已經(jīng)自帶了上述功能。不管是分離部署模式，還是混合部署模式。
這個(gè)功能的好處顯而易見(jiàn)，消除峰值節(jié)省成本，提升集群穩(wěn)定性。這樣我們對(duì)一個(gè)現(xiàn)有的HBase集群空閑資源需求就不是那么高了，完全可以復(fù)用了。下面是使用此功能后，同樣只做寫(xiě)入的測(cè)試集群的流量情況：
?

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

?

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。