摘要：奇技指南現(xiàn)有的開源時序數(shù)據(jù)庫只支持單機運行，在面臨大量數(shù)據(jù)寫入時，會出現(xiàn)查詢慢，機器負載高，單機容量的限制。為了解決這一問題，基礎(chǔ)架構(gòu)團隊在單機的基礎(chǔ)上，開發(fā)了集群版簡述是一個分布式時間序列數(shù)據(jù)庫，用于處理海量數(shù)據(jù)寫入與查詢。

奇技指南
現(xiàn)有的開源時序數(shù)據(jù)庫influxdb只支持單機運行，在面臨大量數(shù)據(jù)寫入時，會出現(xiàn)查詢慢，機器負載高，單機容量的限制。
為了解決這一問題，360基礎(chǔ)架構(gòu)團隊在單機influxdb的基礎(chǔ)上，開發(fā)了集群版——QTSDB

QTSDB是一個分布式時間序列數(shù)據(jù)庫，用于處理海量數(shù)據(jù)寫入與查詢。實現(xiàn)上，是基于開源單機時序數(shù)據(jù)庫influxdb 1.7開發(fā)的分布式版本，除了具有influxdb本身的特性之外，還有容量擴展、副本容錯等集群功能。

主要特點如下：

為時間序列數(shù)據(jù)專門編寫的高性能數(shù)據(jù)存儲, 兼顧寫入性能和磁盤空間占用；

類sql查詢語句, 支持多種統(tǒng)計聚合函數(shù)；

自動清理過期數(shù)據(jù)；

內(nèi)置連續(xù)查詢，自動完成用戶預(yù)設(shè)的聚合操作；

Golang編寫，沒有其它的依賴, 部署運維簡單；

節(jié)點動態(tài)水平擴展，支持海量數(shù)據(jù)存儲；

副本冗余設(shè)計，自動故障轉(zhuǎn)移，支持高可用；

優(yōu)化數(shù)據(jù)寫入，支持高吞吐量；

influxdb架構(gòu)層次最高是database，database下邊根據(jù)數(shù)據(jù)保留時長不同分成了不同的retension policy，形成了database下面的多個存儲容器，因為時序數(shù)據(jù)庫與時間維度關(guān)聯(lián)，所以將相同保留時長的內(nèi)容存放到一起，便于到期刪除。除此之外，在retension policy之下，將retension policy的保留時長繼續(xù)細分，每個時間段的數(shù)據(jù)存儲在一個shard group中，這樣當(dāng)某個分段的shard group到期之后，會將其整個刪掉，避免從存儲引擎內(nèi)部摳出部分數(shù)據(jù)。例如，在database之下的數(shù)據(jù)，可能是30天保留時長，可能是7天保留時長，他們將存放在不同的retension policy之下。假設(shè)將7天的數(shù)據(jù)繼續(xù)按1天進行劃分，就將他們分別存放到7個shard group中，當(dāng)?shù)?天的數(shù)據(jù)生成時，會新建一個shard group寫入，并將第 1天的shard group整個刪除。

到此為止，同一個retension policy下，發(fā)來的當(dāng)下時序數(shù)據(jù)只會落在當(dāng)下的時間段，也就是只有最新的shard group有數(shù)據(jù)寫入，為了提高并發(fā)量，一個shard group又分成了多個shard，這些shard全局唯一，分布于所有物理節(jié)點上，每個shard對應(yīng)一個tsm存儲引擎，負責(zé)存儲數(shù)據(jù)。

在請求訪問數(shù)據(jù)時，通過請求的信息可以鎖定某個database和retension policy，然后根據(jù)請求中的時間段信息，鎖定某個（些）shard group。對于寫入的情況，每條寫入的數(shù)據(jù)都對應(yīng)一個serieskey（這個概念后面會介紹），通過對serieskey進行哈希取模就能鎖定一個shard，進行寫入。而shard是有副本的，在寫入的時候會采用無主多寫的策略同時寫入到每個副本中。查詢時，由于查詢請求中沒有serieskey的信息，所以只能將shard group內(nèi)的shard都查詢一遍，針對一個shard，會在其副本中選擇一個可用的物理節(jié)點進行訪問。

那么一個shard group要有多少shard呢，為了達到最大并發(fā)量，又不過分干擾數(shù)據(jù)整體的有序性，在物理節(jié)點數(shù)和副本數(shù)確定后，一個shard group內(nèi)的shard數(shù)量是機器數(shù)除以副本數(shù)，保障了當(dāng)下的數(shù)據(jù)可以均勻?qū)懭氲剿械奈锢砉?jié)點之上，也不至于因為shard過多影響查詢效率。例如，圖上data集群有6個物理節(jié)點，用戶指定雙副本，那么就有3個shard。

整個系統(tǒng)分成三個部分：proxy、meta集群、data集群。proxy負責(zé)接收請求，無狀態(tài)，其前可接lvs支持水平擴展。meta集群保存上面提到的邏輯存儲層次及其與物理節(jié)點的對應(yīng)關(guān)系，通過raft協(xié)議保障元數(shù)據(jù)的強一致，這里meta信息保存在內(nèi)存中，日志和快照會持久化到磁盤。data集群是真正的數(shù)據(jù)存儲節(jié)點，數(shù)據(jù)以shard為單位存儲于其上，每個shard都對應(yīng)一個tsm存儲引擎。

請求到來的時候，經(jīng)過lvs鎖定一臺proxy，proxy先根據(jù)database、retension policy和時間段到meta集群查找meta信息，最終得到一個shard到物理節(jié)點的映射，然后將這個映射關(guān)系轉(zhuǎn)換為物理節(jié)點到shard的映射返回給proxy，最后根據(jù)這個映射關(guān)系，到data集群指定的物理節(jié)點中訪問具體的shard，至于shard之下的數(shù)據(jù)訪問后邊會介紹。

influxdb的查詢提供類似于關(guān)系數(shù)據(jù)庫的查詢方式，展示出來類似一個關(guān)系表：measurement，時序數(shù)據(jù)庫的時間作為一個永恒的列，除此之外的列分成兩類：

1、field

一類是field，他們是時序數(shù)據(jù)最關(guān)鍵的數(shù)據(jù)部分，其值會隨著時間的流動源源不斷的追加，例如兩臺機器之間在每個時間點上的延遲。

2、tag

另一類是tag，他們是一個field值的一些標記，所以都是字符串類型，并且取值范圍很有限。例如某個時間點的延遲field值是2ms，對應(yīng)有兩個標記屬性，從哪臺機器到哪臺機器的延遲，因此可以設(shè)計兩個tag：from、to。

measurement展示出來第一行是key，剩下的可以看成value，這樣tag有tagkey，tagvalue，field有fieldkey和fieldvalue。

當(dāng)收到一行寫入數(shù)據(jù)時，會轉(zhuǎn)化為如下的格式：

measurement+tagkey1+tagvalue1+tagkey2+tagvalue2+fieldkey+fieldvalue+time。

如果一行中存在多個field就會劃分成多條這樣的數(shù)據(jù)存儲。influxdb的存儲引擎可以理解為一個map，從measurement到fieldkey作為存儲key，后邊的fieldvalue和time是存儲value，這些值會源源不斷追加的，在存儲引擎中，這些值會作為一列存儲到一起，因為是隨時間漸變的數(shù)據(jù)，將他們保存到一起可以提升壓縮的效果。另外將存儲key去掉fieldkey之后剩余部分就是上邊提到的serieskey。

上邊提到，訪問請求在集群中如何鎖定shard，這里介紹在一個shard內(nèi)的訪問。

influxdb的查詢類似于sql語法，但是跟sql語句的零散信息無法直接查詢存儲引擎，所以需要一些策略將sql語句轉(zhuǎn)換成存儲key。influxdb通過構(gòu)建倒排索引來將where后的tag信息轉(zhuǎn)換為所有相關(guān)的serieskey的集合，然后將每個serieskey拼接上select后邊的fieldkey就組成了存儲key，這樣就可以按列取出對應(yīng)的數(shù)據(jù)了。

通過對tsm存儲引擎中存儲key內(nèi)serieskey的分析，能夠構(gòu)建出倒排索引，新版本influxdb將倒排索引持久化到每個shard中，與存儲數(shù)據(jù)的tsm存儲引擎對應(yīng)，叫做tsi存儲引擎。倒排索引相當(dāng)于一個三層的map，map的key是measurment，值是一個二層的map，這個二層的map的key是tagkey，對應(yīng)的值是一個一層的map，這個一層map的key是tagval，對應(yīng)的值是一個serieskey的集合，這個集合中的每個serieskey字串都包含了map索引路徑上的measurement、tagkey和tagval。

這樣可以分析查詢sql，用from后的measurement查詢倒排索引三級map獲得一個二級map，然后再分析where之后多個過濾邏輯單元，以tagkey1=tagval1為例，將這兩個信息作為二層map的key，查到最終的值：serieskey的集合，這個集合的每個serieskey字串都包含了measurment、tagkey1和tagval1，他們是滿足當(dāng)下過濾邏輯單元的serieskey。根據(jù)這些邏輯單元的與或邏輯，將其對應(yīng)的serieskey的集合進行交并運算，最終根據(jù)sql的語義過濾出所有的符合其邏輯的serieskey的集合，然后將這些serieskey與select后邊的fieldkey拼接起來，得到最終的存儲·key，就可以讀取數(shù)據(jù)了。

不帶聚合函數(shù)的查詢：如圖，對于一個serieskey，需要拼接眾多的fieldkey，進而取出多個列的數(shù)據(jù)，他們出來后面臨的問題是怎么組合為一行的數(shù)據(jù)，influxdb行列約束比較松散，不能單純按照列內(nèi)偏移確定行。Influxdb把serieskey和time作為判斷列數(shù)據(jù)為一行的依據(jù)，每一個serieskey對應(yīng)的多列就匯集為一個以多行為粒度的數(shù)據(jù)流，多個serieskey對應(yīng)的數(shù)據(jù)流按照一定順序匯集為一個數(shù)據(jù)流，作為最終的結(jié)果集返回到客戶端。

帶聚合函數(shù)的查詢：這種方式與上邊的查詢正好相反，這里是針對聚合函數(shù)參數(shù)field，拼接上眾多的serieskey，當(dāng)然最終目的都是一樣，得到存儲key，多個存儲key可以讀取多個數(shù)據(jù)流，這些數(shù)據(jù)流面臨兩種處理，先將他們按照一定的順序匯集為一個數(shù)據(jù)流，然后按照一定的策略圈定這個數(shù)據(jù)流內(nèi)相鄰的一些數(shù)據(jù)進行聚合計算，進而得到最終聚合后的值。這里的順序和策略來自于sql語句中g(shù)roup by后的聚合方式。

多數(shù)據(jù)流的合并聚合方式，也同樣適用于shard之上的查詢結(jié)果。

對于寫入就比較簡單了，直接更新數(shù)據(jù)存儲引擎和倒排索引就可以了。

對于訪問的整個流程上邊都已經(jīng)提到了，這里整體梳理一下：分成兩個階段，在shard之上的查詢，在shard之下的查詢。

首先訪問請求通過lvs鎖定到某個proxy，proxy到meta集群中查找meta信息，根據(jù)請求信息，鎖定database，retension policy和shard group，進而得到眾多的shard。

對于寫入操作，根據(jù)寫入時的serieskey，鎖定一個shard進行寫入，由于shard存在多副本，需要同時將數(shù)據(jù)寫入到多個副本。對于查詢，無法通過請求信息得到serieskey，因此需要查詢所有的shard，針對每個shard選擇一個可用的副本，進行訪問。

經(jīng)過上邊的處理就獲得shard到物理節(jié)點的映射，然后將其反轉(zhuǎn)為物理節(jié)點到shard的映射，返回給proxy，proxy就可以在data集群的某個節(jié)點訪問對應(yīng)的shard了。

在shard之下的寫入訪問，需要拆解insert語句，組合為存儲鍵值對存入tsm存儲引擎，然后根據(jù)組合的serieskey更新倒排索引。

在shard之下的查詢訪問，分析sql語句，查詢倒排索引，獲取其相關(guān)的serieskey集合，將其拼接field，形成最終的存儲key，進行數(shù)據(jù)訪問。然后將眾多數(shù)據(jù)在data節(jié)點上進行shard之上的合并聚合，在proxy上進行data之上的合并聚合。

最終proxy將訪問結(jié)果返回給客戶端。

上邊提到influxdb針對shard提供副本容錯，當(dāng)寫入數(shù)據(jù)發(fā)送到proxy，proxy將數(shù)據(jù)以無主多寫的形式發(fā)送到所有的shard副本。meta集群以心跳的形式監(jiān)控data節(jié)點是否在線，在讀取的時候，針對同一shard會在在線的data節(jié)點中隨機選擇一個讀取節(jié)點進行讀取。

在寫入時如果一個data節(jié)點不可用，則會寫入到proxy的一個臨時文件中，等網(wǎng)絡(luò)恢復(fù)正常會將這些暫存的數(shù)據(jù)發(fā)送到指定節(jié)點。

data集群擴容

當(dāng)有全新節(jié)點加入data集群，目前還不支持自動將現(xiàn)有數(shù)據(jù)進行遷移，不過也做了些努力，為了使當(dāng)下寫入數(shù)據(jù)盡快應(yīng)用到新的節(jié)點，在新加入節(jié)點的時候，會將當(dāng)下時間作為當(dāng)下shard group的結(jié)尾時間，然后按照全新的data節(jié)點數(shù)量新建一個shard group，這樣當(dāng)下數(shù)據(jù)量馬上就能均分到各個data節(jié)點，而每個shard group相關(guān)的meta信息都存儲在meta集群里，因此不會對之前數(shù)據(jù)的讀取造成干擾。

data節(jié)點短暫不可用

如果data節(jié)點處于短期不可用狀態(tài)，包括短暫的網(wǎng)絡(luò)故障后自恢復(fù)，或者硬件故障后運維人員干預(yù)，最終data節(jié)點還存有掉線前的數(shù)據(jù)，那么就可以以原來的身份加入到data集群。對于寫入來說，不可用期間proxy會臨時存放此data節(jié)點的數(shù)據(jù)，在data加入集群時會將這部分數(shù)據(jù)再次發(fā)送到data節(jié)點，保障數(shù)據(jù)最終一致。

data節(jié)點長期不可用

如果data節(jié)點由于一些原因，不能或者不需要以原來的身份加入到集群，需要運維人員手動將原來不可用的data節(jié)點下線，那么這臺機器可用時，可以以全新的data身份加入到集群中，這等同于集群的擴容。

QTSDB集群實現(xiàn)為：寫入時根據(jù)serieskey將數(shù)據(jù)寫到指定shard，而讀取時無法預(yù)知serieskey，因此需要查詢每個shard。將整個讀取過程切分為兩個階段：在data節(jié)點上進行存儲引擎的讀取以及節(jié)點內(nèi)部多shard的合并聚合，在proxy節(jié)點將多個data節(jié)點的數(shù)據(jù)匯總，進行后期的合并聚合，形成最終的結(jié)果集返回到客戶端。

QTSDB現(xiàn)有的集群功能還有不完善的地方，會在之后的使用中不斷完善。

本文為360技術(shù)原創(chuàng)文章，轉(zhuǎn)載請務(wù)必注明出處及文末二維碼，謝謝~

關(guān)于360技術(shù)
360技術(shù)是360技術(shù)團隊打造的技術(shù)分享公眾號，每天推送技術(shù)干貨內(nèi)容
更多技術(shù)信息歡迎關(guān)注“360技術(shù)”微信公眾號