OpenTSDB原理系列 讀取流程

乙個完整的opentsdb http query請求，分別由opentsdb i/o thread和asynchbase i/o thread完成。opentsdb i/o thread執行緒負責處理http query請求，asynchbase i/o thread負責處理hbase的響應並傳送http響應。

1.opentsdb i/o thread收到http query請求後，會根據opentsdb是否使用了salt進行不同的處理。

引數1：tsd.storage.salt.width

預設值：0

說明：salt的位元組長度。當設定為0時，表示不使用sal。

預設值：20

說明： salt的數量。當「tsd.storage.salt.width」為非0時，才發揮作用。該配置項的值，不能超過salt的位元組長度所能表示的最大數字。例如salt的位元組長度為1時，該配置項的不能配置成大於256。這兩個配置在opentsdb初始化就必須確定，執行過程中不能隨意修改，否則會導致歷史資料讀取錯誤。

當使用了salt，就會生成相應salt數量的hbase scanner。

需要注意的是，scanner的statkey和stopkey中，只包含了。如果需要查詢的metric中包含大量不同的tagname或者ta**alue的話，這個scanner可能需要掃瞄大量的資料，影響opentsdb查詢的效能。

2.為每個scanner設定filter，設定filter可以更精確的過濾hbase的行，減少無效資料行的傳輸和處理，以提高查詢的效能。

如果http query中設定了tag的查詢條件，scanner中就會設定keyregexpfilter；如果同時設定了explicittags 為true，scanner中還會再設定fuzzyrowfilter。

引數3：tsd.query.enable_fuzzy_filter

預設值：true

說明：當查詢請求中包含explicittags欄位的時候，是否在hbase的scan請求中使用fuzzyrowfilter

1. 乙個http query所生成的多個scanner，可能傳送到了多個regionserver上，所以opentsdb可能收到多個regionserver傳送過來的scanner結果。

2. 每個regionserver的scanner結果，都由其繫結的乙個執行緒進行處理。這個執行緒既負責從socket中接收scanner結果，也要負責處理這些scanner結果。因此，它只能逐個處理這些scanner結果。

3. 當處理完乙個scanner結果後，如果這個scanner的所有結果還沒有傳輸完，就繼續非同步呼叫scan方法，以獲得後續的scanner結果。呼叫完後，就繼續處理下乙個scanner結果。

4. 當乙個scanner的所有結果都已經處理完了，而且這個scanner不是所關聯http query請求的最後乙個被處理的scanner，那麼就把處理後的資料暫時快取起來。然後繼續處理下乙個scanner結果；如果是最後乙個scanner，就把這個http query請求的所有scanner結果進行合併，生成乙個http query的response，並傳送回到opentsdb應用。

至此，在opentsdb的應用端，就已經完成了一次完整的http query查詢。

OpenTSDB原理系列 資料表設計

metrics資料的hbase rowkey中包含主要組成部分為 鹽值 salt metrics名稱 時間戳 tagkey ta alue等部分。上篇文章已經講到，為了統一各個值的長度以及節省空間，對metrics名稱 tagkey和ta alue分配了uid資訊。所以，在hbase rowkey中...

OpenTSDB原理系列 元資料模型

本文作為介紹opentsdb原理系列文章的第一篇，主要介紹了時序資料以及opentsdb的一些基礎概念，以及opentsdb中的元資料模型定義。wiki中關於 時間序列 time series 的定義 時間序列 time series 是一組按照時間發生先後順序進行排列的資料點序列，通常一組時間序列...

字元流讀取

一 字元流filereader 1.字元流是什麼 字元流是可以直接讀寫字元的io流 字元流讀取字元,就要先讀取到位元組資料,然後轉為字元.如果要寫出字元,需要把字元轉為位元組再寫出.2.filereader filereader類的read 方法可以按照字元大小讀取 filereader fr ne...