在https://www.iteblog.com/archives/2450.html文章中有實際的案例分析 Rowkey 如何設計的，感興趣的可以點選下面閱讀原文去檢視。

OpenTSDB 是基於 HBase 的可擴充套件、開源時間序列資料庫(Time Series Database)，可以用於儲存監控資料、物聯網感測器、金融K線等帶有時間的資料。它的特點是能夠提供最高毫秒級精度的時間序列資料儲存，能夠長久儲存原始資料並且不失精度。它擁有很強的資料寫入能力，支援大併發的資料寫入，並且擁有可無限水平擴充套件的儲存容量。目前，阿里雲 HBase 產品是直接支援 OpenTSDB 元件的。

OpenTSDB 擁有如此的強大的讀寫和近乎無限的儲存能力源自於基於 HBase 的架構設計，我們甚至可以說 OpenTSDB 就是 HBase 的一個應用。熟悉 HBase 的同學肯定知道，要看 HBase 的表設計的好不好，關鍵是看其 Rowkey 設計的好不好，HBase 的 Rowkey 設計會考慮到實際的查詢場景。所以讀到這裡，大家肯定知道這篇文章是要講什麼內容的。

OpenTSDB 基本概念

在介紹 OpenTSDB 系統如何設計 Rowkey 之前，我們先來了解 OpenTSDB 的一些基本概念。（因為本文側重於介紹 HBase 的 Rowkey 設計，所以關於 OpenTSDB 的其他一些知識本文並不會涉及，如果你對這部分知識感興趣，請自行去網上搜索相關文章。）

我們往 OpenTSDB 裡面寫入一條時序資料，至少包含以下幾個資料：

• 指標名字：這個就是我們監控的指標，比如 sys.cpu.user； 

• 時間戳：監控資料產生的時間； 

• 值：Long 或者 Double 型別的資料，這個是監控指標在某個時間的具體值； 

• 標籤：包括標籤名字（tagk）和標籤值（tagv），比如 tagk1=tagv1，主要用於描述資料屬性，每條時序資料必須包含一組和多組的標籤資料。目前 OpenTSDB 最多支援8組標籤。 

所以如果我們使用終端往 OpenTSDB 寫入時序資料，格式如下：

put <metric> <timestamp> <value> <tagk1=tagv1[ tagk2=tagv2 ...tagkN=tagvN]>
比如
put sys.cpu.user 1541946115 42.5 host=iteblog cpu=0

OpenTSDB 的 Rowkey 設計

上面我們已經簡單瞭解了 OpenTSDB 每條時序資料所包含的要素。基於這些時序資料，OpenTSDB 為我們提供的查詢功能其實很簡單：指定指標名稱和時間範圍，並且給定一個或多個標籤名稱和標籤的值作為過濾條件，以此查詢符合條件的資料。

Rowkey 設計版本一

OpenTSDB 為我們提供的查詢業務場景已經有了，我們可以很快設計出 HBase 的 Rowkey：
metric + timestamp + tagk1 + tagv1 + tagk2 + tagv2 + ... + tagkn + tagvn
注意，實際儲存的時候 + 並不會寫入到磁碟，這裡只是為了說明方便，人為加了這個符號。
比如如果我們往 OpenTSDB 插入下面的資料:

put sys.cpu.user 1541946115 42.5 host=iteblog cpu=0

sys.cpu.user+1541946115+host+iteblog+cpu+0

那如果這個指標有很多監控資料，其儲存在 HBase 的 key-value 如下：

如果想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共帳號：iteblog_hadoop

Rowkey 設計版本二

上面表格記錄著指標名 sys.cpu.user 標籤為 host=iteblog cpu=0 和 標籤為 host=iteblog cpu=1 每隔十秒的監控資料。有些同學可能已經看出來了，如果我們按照這樣的方式去設計 HBase 表的 Rowkey，雖然可以滿足我們的查詢需求，但是這種儲存資料的方式導致 Key 大量的重複儲存，這樣會導致資料的急劇增加，所以 OpenTSDB 並沒有這樣儲存的。在 OpenTSDB 裡面，會對每個指標名、標籤以及標籤值進行編碼，每個指標的編碼都不一樣；同理，每個標籤的編碼也不一樣，但是標籤和指標名稱可以編碼一樣，不同型別之間的編碼互不影響。所以編碼後的資料如下：

sys.cpu.user  => \x00\x00\x01
host => \x00\x00\x01
iteblog => \x00\x00\x01
cpu => \x00\x00\x02
0 => \x00\x00\x02
1 => \x00\x00\x03

在上面，OpenTSDB 預設使用三個位元組來編碼指標名稱，三個位元組編碼標籤名稱以及標籤值。經過這樣的編碼之後，OpenTSDB 的 Rowkey 就變成了下面的形式：

sys.cpu.user+1541946115+host+iteblog+cpu+0
變成
\x00\x00\x01+1541946115+\x00\x00\x01+\x00\x00\x01+\x00\x00\x02+\x00\x00\x02

所以上表的資料就變成下面的了：

如果想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共帳號：iteblog_hadoop

這樣我們可以節省一些儲存空間（不要看這張表好像比上面的表要長了，這裡其實是用十六進位制表示的，每個\x00佔用一個位元組，整個指標名稱預設只佔用三個位元組，如果用字串表示是不止三個位元組的）。

Rowkey 設計版本三

但是細心的同學肯定發現了，上表中同一個指標每隔十秒傳送一條監控資料，但是每條監控資料就只是當前指標的監控值，如上表的42.5、39.1、41.4、40.0。而每次傳送的資料都在 HBase 裡面儲存一行，這樣會導致重複儲存大量相同的指標名、標籤名、標籤值等資料。我們仔細觀察可以發現，Rowkey 組成中同一個指標的監控資料除了的時間不一樣，其他都是一樣的！基於這個特點，OpenTSDB 對 Rowkey 進行了進一步的優化，思想為：將 Rowkey 中時間戳由原來的秒級別或毫秒級別統一轉換成小時級別的，多餘的秒資料或者毫秒資料作為 HBase 的列名稱。可能大家沒有理解這句話的含義，下面我們來具體介紹這個實現。

1541946115 時間戳轉換成時間為 2018-11-11 22:21:55，其對應的整點小時為 2018-11-11 22:00:00，這個轉換成時間戳是 1541944800。1541946115 相對於 1541944800 多餘出來的秒數為 1315，在 HBase 裡面，1315 就作為當前指標對應值的列名。經過這樣的優化之後，同一小時的監控資料都放在一行的不同列裡面，所以上面的表格就變成下面的了：

如果想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共帳號：iteblog_hadoop

注意：

• 第三張表中為了展示方便，我將 000001+1541944800+000001+000001+000002+000003 簡寫為 001+1541944800+001+001+002+003；

• 上面幾張表中的 Rowkey 部分我這裡都是使用時間戳的形式顯示的，只是為了檢視方便，在實際儲存中時間戳其實是以二進位制形式儲存的，比如 1541944800 的十六進位制表示為 5BE835E0；所以上面表格中 Rowkey 為 001+1541944800+001+001+002+003 在 HBase 實際儲存為（十六進位制表示） 0000015BE835E0000001000001000002000003；

• 第三張表中的列名稱在實際儲存中除了包含相對於 Rowkey 的秒數或者毫秒數，其實還包含了當前列值的資料型別，資料長度等標識。

如果說用一張圖表示上面的過程，可以如下所示。

如果想及時瞭解Spark、Hadoop或者Hbase相關的文章，歡迎關注微信公共帳號：iteblog_hadoop

在https://www.iteblog.com/archives/2450.html文章中有實際的案例分析 Rowkey 如何設計的，感興趣的可以點選下面閱讀原文去檢視。

HBase技術交流釘釘大群【強烈推薦！】 群內每週進行群直播技術分享及問答

加入方式1：
1）點選link申請加入 https://dwz.cn/Fvqv066s

加入方式2：
釘釘掃碼加入：

歡迎關注本公眾號：iteblog_hadoop:

回覆 spark_summit_201806 下載 Spark Summit North America 201806 全部PPT

回復 spark_summit_eu_2018 下載 Spark+AI Summit europe 2018 全部PPT

0、回覆 電子書獲取 本站所有可下載的電子書