Prometheus存儲(chǔ)引擎簡(jiǎn)析

背景知識(shí)

時(shí)序特點(diǎn)

時(shí)序數(shù)據(jù)的特點(diǎn)可以用一話概括：垂直寫（最新數(shù)據(jù)），水平查。

對(duì)于云原生場(chǎng)景來(lái)說(shuō)，另一個(gè)特點(diǎn)是數(shù)據(jù)生命周期短，一次容器的擴(kuò)縮容會(huì)導(dǎo)致時(shí)間線膨脹一倍。了解這兩個(gè)特點(diǎn)后，來(lái)看看 Prometheus 是如何存儲(chǔ)數(shù)據(jù)來(lái)迎合上述模式：

├──01BKGV7JC0RY8A6MACW02A2PJD//block的ULID
│├──chunks
││└──000001
│├──tombstones
│├──index
│└──meta.json
├──chunks_head
│└──000001
└──wal
├──000000002
└──checkpoint.00000001
└──00000000

可以看到，數(shù)據(jù)目錄主要有以下幾部分：

block，一個(gè)時(shí)間段內(nèi)（默認(rèn) 2 小時(shí)）的所有數(shù)據(jù)，只讀，用 ULID 命名。每一個(gè) block 內(nèi)主要包括：

chunks 固定大?。ㄗ畲?128M）的 chunks 文件

index 索引文件，主要包含倒排索引的信息

meta.json 元信息，主要包括 block 的 minTime/maxTime，方便查詢時(shí)過(guò)濾

chunks_head，當(dāng)前在寫入的 block 對(duì)應(yīng)的 chunks 文件，只讀，最多 120 個(gè)數(shù)據(jù)點(diǎn)，時(shí)間跨度最大 2 小時(shí)。

wal，Prometheus 采用攢批的方式來(lái)異步刷盤，因此需要 WAL 來(lái)保證數(shù)據(jù)可靠性

通過(guò)上面的目錄結(jié)構(gòu)，不難看出 Prometheus 的設(shè)計(jì)思路：

通過(guò)數(shù)據(jù)按時(shí)間分片的方式來(lái)解決數(shù)據(jù)生命周期短的問(wèn)題

通過(guò)內(nèi)存攢批的方式來(lái)對(duì)應(yīng)只寫最新數(shù)據(jù)的場(chǎng)景

數(shù)據(jù)模式

Prometheus 支持的模式比較簡(jiǎn)單，只支持單值模式，如下：

cpu_usage{core="1",ip="130.25.175.171"}14.041618137750
metriclabelsvaluetimesample

倒排索引

索引是支持多維搜索的主要手段，時(shí)序中的索引結(jié)構(gòu)和搜索引擎的類似，是個(gè)倒排索引，可參考下圖

在一次查詢中，會(huì)對(duì)涉及到的 label 分別求對(duì)應(yīng)的 postings lists（即時(shí)間線集合），然后根據(jù) filter 類型進(jìn)行集合運(yùn)算，最后根據(jù)運(yùn)算結(jié)果得出的時(shí)間線，去查相應(yīng)數(shù)據(jù)即可。

磁盤存儲(chǔ)格式

數(shù)據(jù)格式

┌──────────────────────────────┐
│magic(0x0130BC91)<4?byte>│
├──────────────────────────────┤
│version(1)<1?byte>│
├──────────────────────────────┤
│padding(0)<3?byte>│
├──────────────────────────────┤
│┌──────────────────────────┐│
││Chunk1││
│├──────────────────────────┤│
││...││
│├──────────────────────────┤│
││ChunkN││
│└──────────────────────────┘│
└──────────────────────────────┘


>基于SpringCloudAlibaba+Gateway+Nacos+RocketMQ+Vue&Element實(shí)現(xiàn)的后臺(tái)管理系統(tǒng)+用戶小程序，支持RBAC動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能
>
>*項(xiàng)目地址：
>*視頻教程：

#單個(gè)chunk內(nèi)的結(jié)構(gòu)
┌─────────────────────┬───────────────────────┬───────────────────────┬───────────────────┬───────────────┬──────────────┬────────────────┐
|seriesref<8?byte>|mint<8?byte,?uint64>|maxt<8?byte,?uint64>|encoding<1?byte>|len|data│CRC32<4?byte>│
└─────────────────────┴───────────────────────┴───────────────────────┴────────

chunk 為數(shù)據(jù)在磁盤中的最小組織單元，需要明確以下兩點(diǎn)：

單個(gè) chunk 的時(shí)間跨度默認(rèn)是 2 小時(shí)，Prometheus 后臺(tái)會(huì)有合并操作，把時(shí)間相鄰的 block 合到一起

series ref 為時(shí)間線的唯一標(biāo)示，由 8 個(gè)字節(jié)組成，前 4 個(gè)表示文件 id，后 4 個(gè)表示在文件內(nèi)的 offset，需配合后文的索引結(jié)構(gòu)來(lái)實(shí)現(xiàn)數(shù)據(jù)的定位

索引格式

┌────────────────────────────┬─────────────────────┐
│magic(0xBAAAD700)<4b>│version(1)<1?byte>│
├────────────────────────────┴─────────────────────┤
│┌──────────────────────────────────────────────┐│
││SymbolTable││
│├──────────────────────────────────────────────┤│
││Series││
│├──────────────────────────────────────────────┤│
││LabelIndex1││
│├──────────────────────────────────────────────┤│
││...││
│├──────────────────────────────────────────────┤│
││LabelIndexN││
│├──────────────────────────────────────────────┤│
││Postings1││
│├──────────────────────────────────────────────┤│
││...││
│├──────────────────────────────────────────────┤│
││PostingsN││
│├──────────────────────────────────────────────┤│
││LabelOffsetTable││
│├──────────────────────────────────────────────┤│
││PostingsOffsetTable││
│├──────────────────────────────────────────────┤│
││TOC││
│└──────────────────────────────────────────────┘│
└──────────────────────────────────────────────────┘

在一個(gè)索引文件中，最主要的是以下幾部分（從下往上）：

TOC 存儲(chǔ)的是其他部分的 offset

Postings Offset Table，用來(lái)存儲(chǔ)倒排索引，Key 為 label name/value 序?qū)?，Value 為 Postings 在文件中的 offset。

Postings N，存儲(chǔ)的是具體的時(shí)間線序列

Series，存儲(chǔ)的是當(dāng)前時(shí)間線，對(duì)應(yīng)的 chunk 文件信息

Label Offset Table 與 Label Index 目前在查詢時(shí)沒有使用到，這里不再講述

每個(gè)部分的具體編碼格式，可參考官方文檔 Index Disk Format，這里重點(diǎn)講述一次查詢是如何找到符合條件的數(shù)據(jù)的：

首先在 Posting Offset Table 中，找到對(duì)應(yīng) label 的 Postings 位置

然后再根據(jù) Postings 中的 series 信息，找到對(duì)應(yīng)的 chunk 位置，即上文中的 series ref。

使用方式

Prometheus 在啟動(dòng)時(shí)，會(huì)去加載數(shù)據(jù)元信息到內(nèi)存中。主要有下面兩部分：

block 的元信息，最主要的是 mint/maxt，用來(lái)確定一次查詢是否需要查看當(dāng)前 block 文件，之后把 chunks 文件以 mmap 方式打開

//openallblocks
bDirs,err:=blockDirs(dir)
for_,bDir:=rangebDirs{
meta,_,err:=readMetaFile(bDir)
//Seeifwealreadyhavetheblockinmemoryoropenitotherwise.
block,open:=getBlock(loaded,meta.ULID)
if!open{
block,err=OpenBlock(l,bDir,chunkPool)
iferr!=nil{
corrupted[meta.ULID]=err
continue
}
}
blocks=append(blocks,block)
}
//openchunkfiles
for_,fn:=rangefiles{
f,err:=fileutil.OpenMmapFile(fn)
iferr!=nil{
returnnil,tsdb_errors.NewMulti(
errors.Wrap(err,"mmapfiles"),
tsdb_errors.CloseAll(cs),
).Err()
}
cs=append(cs,f)
bs=append(bs,realByteSlice(f.Bytes()))
}

block 對(duì)應(yīng)的索引信息，主要是倒排索引。由于單個(gè) label 對(duì)應(yīng)的 Postings 可能會(huì)非常大，Prometheus 不是全量加載，而是每隔 32 個(gè)加載，來(lái)減輕內(nèi)存壓力。并且保證第一個(gè)與最后一個(gè)一定被加載，查詢時(shí)采用類似跳表的方式進(jìn)行 posting 定位。

下面代碼為 DB 啟動(dòng)時(shí)，讀入 postings 的邏輯：

//Forthepostingsoffsettablewekeepeverylabelnamebutonlyeverynth
//labelvalue(plusthefirstandlastone),tosavememory.
ReadOffsetTable(r.b,r.toc.PostingsTable,func(key[]string,_uint64,offint)error{
if_,ok:=r.postings[key[0]];!ok{
//Nextlabelname.
r.postings[key[0]]=[]postingOffset{}
iflastKey!=nil{
//Alwaysincludelastvalueforeachlabelname.
r.postings[lastKey[0]]=append(r.postings[lastKey[0]],postingOffset{value:lastKey[1],off:lastOff})
}
lastKey=nil
valueCount=0
}
ifvalueCount%32==0{
r.postings[key[0]]=append(r.postings[key[0]],postingOffset{value:key[1],off:off})
lastKey=nil
}else{
lastKey=key
lastOff=off
}
valueCount++
}
iflastKey!=nil{
r.postings[lastKey[0]]=append(r.postings[lastKey[0]],postingOffset{value:lastKey[1],off:lastOff})
}

下面代碼為根據(jù) label 查詢 postings 的邏輯，完整可見 index 的 Postings 方法：

e,ok:=r.postings[name]//name為labelkey
if!ok||len(values)==0{//values為當(dāng)前需要查詢的labelvalues
returnEmptyPostings(),nil
}
res:=make([]Postings,0,len(values))
skip:=0
valueIndex:=0
forvalueIndex=value})
ifi==len(e){
//We'repasttheend.
break
}
ifi>0&&e[i].value!=value{//postings中沒有該value，需要用前面一個(gè)來(lái)在文件中搜索
//Needtolookfrompreviousentry.
i--
}
//Don'tCrc32theentirepostingsoffsettable,thisisveryslow
//sohopeanyissueswerecaughtatstartup.
d:=encoding.NewDecbufAt(r.b,int(r.toc.PostingsTable),nil)
d.Skip(e[i].off)
//Iterateontheoffsettable.
varpostingsOffuint64//Theoffsetintothepostingstable.
ford.Err()==nil{
//...skip邏輯省略
v:=d.UvarintBytes()//Labelvalue.
postingsOff=d.Uvarint64()//Offset.
forstring(v)>=value{
ifstring(v)==value{
//Readfromthepostingstable.
d2:=encoding.NewDecbufAt(r.b,int(postingsOff),castagnoliTable)
_,p,err:=r.dec.Postings(d2.Get())
res=append(res,p)
}
valueIndex++
ifvalueIndex==len(values){
break
}
value=values[valueIndex]
}
ifi+1==len(e)||value>=e[i+1].value||valueIndex==len(values){
//Needtogotoalaterpostingsoffsetentry,ifthereisone.
break
}
}
}

內(nèi)存結(jié)構(gòu)

Block 在 Prometheus 實(shí)現(xiàn)中，主要分為兩類：

當(dāng)前正在寫入的，稱為 head。當(dāng)超過(guò) 2 小時(shí)或超過(guò) 120 個(gè)點(diǎn)時(shí)，head 會(huì)將 chunk 寫入到本地磁盤中，并使用 mmap 映射到內(nèi)存中，保存在下文的 mmappedChunk 中。

歷史只讀的，存放在一數(shù)組中

typeDBstruct{
blocks[]*Block
head*Head
//...忽略其他字段
}
//Block內(nèi)的主要字段是IndexReader，其內(nèi)部主要是postings，即倒排索引
//MapofLabelNametoalistofsomeLabelValues'spositionintheoffsettable.
//Thefirstandlastvaluesforeachnamearealwayspresent.
postingsmap[string][]postingOffset
typepostingOffsetstruct{
valuestring//labelvalue
offint//posting在對(duì)于文件中的offset
}

在上文磁盤結(jié)構(gòu)中介紹過(guò)，postingOffset 不是全量加載，而是每隔 32 個(gè)。

Head

typeHeadstruct{
postings*index.MemPostings//Postingslistsforterms.
//AllseriesaddressablebytheirIDorhash.
series*stripeSeries
//...忽略其他字段
}
typeMemPostingsstruct{
mtxsync.RWMutex
mmap[string]map[string][]uint64//labelkey->labelvalue->postinglists
orderedbool
}

MemPostings 是 Head 中的索引結(jié)構(gòu)，與 Block 的 postingOffset 不同，posting 是全量加載的，畢竟 Head 保存的數(shù)據(jù)較小，對(duì)內(nèi)存壓力也小。

typestripeSeriesstruct{
sizeint
series[]map[uint64]*memSeries
hashes[]seriesHashmap
locks[]stripeLock
seriesLifecycleCallbackSeriesLifecycleCallback
}
typememSeriesstruct{
sync.RWMutex
mmappedChunks[]*mmappedChunk//只讀
headChunk*memChunk//讀寫
......//省略其他字段
}
typemmappedChunkstruct{
//數(shù)據(jù)文件在磁盤上的位置，即上文中的seriesref
refuint64
numSamplesuint16
minTime,maxTimeint64
}

stripeSeries 是比較的核心結(jié)構(gòu)，series 字段的 key 為時(shí)間線，采用自增方式生成；value 為 memSeries，內(nèi)部有存儲(chǔ)具體數(shù)據(jù)的 chunk，采用分段鎖思路來(lái)減少鎖競(jìng)爭(zhēng)。

使用方式

對(duì)于一個(gè)查詢，大概涉及的步驟：

根據(jù) label 查出所涉及到的時(shí)間線，然后根據(jù) filter 類型，進(jìn)行集合運(yùn)算，找出符合要求的時(shí)間線

根據(jù)時(shí)間線信息與時(shí)間范圍信息，去 block 內(nèi)查詢符合條件的數(shù)據(jù)

在第一步主要在 PostingsForMatchers 函數(shù)中完成，主要有下面幾個(gè)優(yōu)化點(diǎn)：

對(duì)于取反的 filter（ != !~ ），轉(zhuǎn)化為等于的形式，這樣因?yàn)榈扔谛问綄?duì)應(yīng)的時(shí)間線往往會(huì)少于取反的效果，最后在合并時(shí)，減去這些取反的時(shí)間線即可?？蓞⒖迹築e smarter in how we look at matchers. #572

不同 label 的時(shí)間線合并時(shí)，利用了時(shí)間線有序的特點(diǎn)，采用類似 mergesort 的方式來(lái)惰性合并，大致過(guò)程如下：

typeintersectPostingsstruct{
arr[]Postings//需要合并的時(shí)間線數(shù)組
curuint64//當(dāng)前的時(shí)間線
}

func(it*intersectPostings)doNext()bool{
Loop:
for{
for_,p:=rangeit.arr{
if!p.Seek(it.cur){
returnfalse
}
ifp.At()>it.cur{
it.cur=p.At()
continueLoop
}
}
returntrue
}
}

func(it*intersectPostings)Next()bool{
for_,p:=rangeit.arr{
if!p.Next(){
returnfalse
}
ifp.At()>it.cur{
it.cur=p.At()
}
}
returnit.doNext()
}

在第一步查出符合條件的 chunk 所在文件以及 offset 信息之后，第二步的取數(shù)據(jù)則相對(duì)簡(jiǎn)單，直接使用 mmap 讀數(shù)據(jù)即可，這間接利用操作系統(tǒng)的 page cache 來(lái)做緩存，自身不需要再去實(shí)現(xiàn) Buffer Pool 之類的數(shù)據(jù)結(jié)構(gòu)。

總結(jié)

通過(guò)上文的分析，大體上把 Prometheus 的存儲(chǔ)結(jié)構(gòu)以及查詢流程分析了一遍，還有些細(xì)節(jié)沒再展開去介紹，比如為了節(jié)約內(nèi)存使用，label 使用了字典壓縮，但這并不妨礙讀者理解其原理。

此外，Prometheus 默認(rèn) 2 小時(shí)一個(gè) Block 對(duì)大時(shí)間范圍查詢不友好，因此其后臺(tái)會(huì)對(duì)定期 chunk 文件進(jìn)行 compaction，合并后的文件大小為 min(31d, retention_time * 0.1) ，相關(guān)細(xì)節(jié)后面有機(jī)會(huì)再單獨(dú)介紹吧。

審核編輯：劉清