Prometheus時序數(shù)據(jù)庫-磁盤中的存儲結(jié)構(gòu)

前言

之前的文章里，筆者詳細描述了監(jiān)控數(shù)據(jù)在Prometheus內(nèi)存中的結(jié)構(gòu)。而其在磁盤中的存儲結(jié)構(gòu)，也是非常有意思的,關(guān)于這部分內(nèi)容，將在本篇文章進行闡述。

磁盤目錄結(jié)構(gòu)

首先我們來看Prometheus運行后，所形成的文件目錄結(jié)構(gòu)

在筆者自己的機器上的具體結(jié)構(gòu)如下:

prometheus-data
    |-01EY0EH5JA3ABCB0PXHAPP999D (block)
    |-01EY0EH5JA3QCQB0PXHAPP999D (block)
        |-chunks
            |-000001
            |-000002
            .....
            |-000021
        |-index
        |-meta.json
        |-tombstones
    |-wal
    |-chunks_head

Block

一個Block就是一個獨立的小型數(shù)據(jù)庫，其保存了一段時間內(nèi)所有查詢所用到的信息。包括標簽/索引/符號表數(shù)據(jù)等等。Block的實質(zhì)就是將一段時間里的內(nèi)存數(shù)據(jù)組織成文件形式保存下來。

最近的Block一般是存儲了2小時的數(shù)據(jù)，而較為久遠的Block則會通過compactor進行合并，一個Block可能存儲了若干小時的信息。值得注意的是，合并操作只是減少了索引的大小(尤其是符號表的合并)，而本身數(shù)據(jù)(chunks)的大小并沒有任何改變。

meta.json

我們可以通過檢查meta.json來得到當前Block的一些元信息。

{
    "ulid":"01EY0EH5JA3QCQB0PXHAPP999D"
    // maxTime-minTime = 7200s => 2 h
    "minTime": 1611664000000
    "maxTime": 1611671200000
    "stats": {
        "numSamples": 1505855631,
        "numSeries": 12063563,
        "numChunks": 12063563
    }
    "compaction":{
        "level" : 1
        "sources: [
            "01EY0EH5JA3QCQB0PXHAPP999D"
        ]
    }
    "version":1
}

其中的元信息非常清楚明了。這個Block記錄了2個小時的數(shù)據(jù)。

讓我們再找一個比較陳舊的Block看下它的meta.json.

    "ulid":"01EXTEH5JA3QCQB0PXHAPP999D",
    // maxTime - maxTime =>162h
    "minTime":1610964800000,
    "maxTime":1611548000000
    ......
    "compaction":{
        "level": 5,
        "sources: [
            31個01EX......
        ]
    },
    "parents: [
        {    
            "ulid": 01EXTEH5JA3QCQB1PXHAPP999D
            ...
        }
        {    
            "ulid": 01EXTEH6JA3QCQB1PXHAPP999D
            ...
        }
                {    
            "ulid": 01EXTEH5JA31CQB1PXHAPP999D
            ...
        }
    ]

從中我們可以看到，該Block是由31個原始Block經(jīng)歷5次壓縮而來。最后一次壓縮的三個Block ulid記錄在parents中。如下圖所示:

Chunks結(jié)構(gòu)

CUT文件切分

所有的Chunk文件在磁盤上都不會大于512M,對應(yīng)的源碼為:

func (w *Writer) WriteChunks(chks ...Meta) error {
    ......
    for i, chk := range chks {
        cutNewBatch := (i != 0) && (batchSize+SegmentHeaderSize > w.segmentSize)
        ......
        if cutNewBatch {
            ......
        }
        ......
    }
}

當寫入磁盤單個文件超過512M的時候，就會自動切分一個新的文件。

一個Chunks文件包含了非常多的內(nèi)存Chunk結(jié)構(gòu),如下圖所示:

圖中也標出了，我們是怎么尋找對應(yīng)Chunk的。通過將文件名(000001，前32位)以及(offset,后32位)編碼到一個int類型的refId中，使得我們可以輕松的通過這個id獲取到對應(yīng)的chunk數(shù)據(jù)。

chunks文件通過mmap去訪問

由于chunks文件大小基本固定(最大512M),所以我們很容易的可以通過mmap去訪問對應(yīng)的數(shù)據(jù)。直接將對應(yīng)文件的讀操作交給操作系統(tǒng)，既省心又省力。對應(yīng)代碼為:

func NewDirReader(dir string, pool chunkenc.Pool) (*Reader, error) {
    ......
    for _, fn := range files {
        f, err := fileutil.OpenMmapFile(fn)
        ......
    }
    ......
    bs = append(bs, realByteSlice(f.Bytes()))
}
通過sgmBytes := s.bs[offset]就直接能獲取對應(yīng)的數(shù)據(jù)

index索引結(jié)構(gòu)

前面介紹完chunk文件，我們就可以開始闡述最復雜的索引結(jié)構(gòu)了。

尋址過程

索引就是為了讓我們快速的找到想要的內(nèi)容，為了便于理解。筆者就通過一次數(shù)據(jù)的尋址來探究Prometheus的磁盤索引結(jié)構(gòu)?？紤]查詢一個

擁有系列三個標簽
({__name__:http_requests}{job:api-server}{instance:0})
且時間為start/end的所有序列數(shù)據(jù)

我們先從選擇Block開始,遍歷所有Block的meta.json，找到具體的Block

前文說了，通過Labels找數(shù)據(jù)是通過倒排索引。我們的倒排索引是保存在index文件里面的。那么怎么在這個單一文件里找到倒排索引的位置呢？這就引入了TOC(Table Of Content)

TOC(Table Of Content)

由于index文件一旦形成之后就不再會改變，所以Prometheus也依舊使用mmap來進行操作。采用mmap讀取TOC非常容易:

func NewTOCFromByteSlice(bs ByteSlice) (*TOC, error) {
    ......
    // indexTOCLen = 6*8+4 = 52
    b := bs.Range(bs.Len()-indexTOCLen, bs.Len())
    ......
    return &TOC{
        Symbols:           d.Be64(),
        Series:            d.Be64(),
        LabelIndices:      d.Be64(),
        LabelIndicesTable: d.Be64(),
        Postings:          d.Be64(),
        PostingsTable:     d.Be64(),
    }, nil
}

Posting offset table 以及 Posting倒排索引

首先我們訪問的是Posting offset table。由于倒排索引按照不同的LabelPair(key/value)會有非常多的條目。所以Posing offset table就是決定到底訪問哪一條Posting索引。offset就是指的這一Posting條目在文件中的偏移。

Series

我們通過三條Postings倒排索引索引取交集得出

{series1,Series2,Series3,Series4}
∩
{series1,Series2,Series3}
∩
{Series2,Series3}
=
{Series2,Series3}

也就是要讀取Series2和Serie3中的數(shù)據(jù)，而Posting中的Ref(Series2)和Ref(Series3)即為這兩Series在index文件中的偏移。

Series以Delta的形式記錄了chunkId以及該chunk包含的時間范圍。這樣就可以很容易過濾出我們需要的chunk,然后再按照chunk文件的訪問，即可找到最終的原始數(shù)據(jù)。

SymbolTable

值得注意的是，為了盡量減少我們文件的大小，對于Label的Name和Value這些有限的數(shù)據(jù)，我們會按照字母序存在符號表中。由于是有序的，所以我們可以直接將符號表認為是一個
[]string切片。然后通過切片的下標去獲取對應(yīng)的sting?？紤]如下符號表:

讀取index文件時候，會將SymbolTable全部加載到內(nèi)存中，并組織成symbols []string這樣的切片形式，這樣一個Series中的所有標簽值即可通過切片下標訪問得到。

Label Index以及Label Table

事實上，前面的介紹已經(jīng)將一個普通數(shù)據(jù)尋址的過程全部講完了。但是index文件中還包含label索引以及l(fā)abel Table，這兩個是用來記錄一個Label下面所有可能的值而存在的。
這樣，在正則的時候就可以非常容易的找到我們需要哪些LabelPair。詳情可以見前篇。

事實上，真正的Label Index比圖中要復雜一點。它設(shè)計成一條LabelIndex可以表示(多個標簽組合)的所有數(shù)據(jù)。不過在Prometheus代碼中只會采用存儲一個標簽對應(yīng)所有值的形式。

完整的index文件結(jié)構(gòu)

這里直接給出完整的index文件結(jié)構(gòu)，摘自Prometheus中index.md文檔。

┌────────────────────────────┬─────────────────────┐
│ magic(0xBAAAD700) <4b>     │ version(1) <1 byte> │
├────────────────────────────┴─────────────────────┤
│ ┌──────────────────────────────────────────────┐ │
│ │                 Symbol Table                 │ │
│ ├──────────────────────────────────────────────┤ │
│ │                    Series                    │ │
│ ├──────────────────────────────────────────────┤ │
│ │                 Label Index 1                │ │
│ ├──────────────────────────────────────────────┤ │
│ │                      ...                     │ │
│ ├──────────────────────────────────────────────┤ │
│ │                 Label Index N                │ │
│ ├──────────────────────────────────────────────┤ │
│ │                   Postings 1                 │ │
│ ├──────────────────────────────────────────────┤ │
│ │                      ...                     │ │
│ ├──────────────────────────────────────────────┤ │
│ │                   Postings N                 │ │
│ ├──────────────────────────────────────────────┤ │
│ │               Label Index Table              │ │
│ ├──────────────────────────────────────────────┤ │
│ │                 Postings Table               │ │
│ ├──────────────────────────────────────────────┤ │
│ │                      TOC                     │ │
│ └──────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────┘

tombstones

由于Prometheus Block的數(shù)據(jù)一般在寫完后就不會變動。如果要刪除部分數(shù)據(jù)，就只能記錄一下刪除數(shù)據(jù)的范圍，由下一次compactor組成新block的時候刪除。而記錄這些信息的文件即是tomstones。

Prometheus入門書籍推薦

總結(jié)

Prometheus作為時序數(shù)據(jù)庫，設(shè)計了各種文件結(jié)構(gòu)來保存海量的監(jiān)控數(shù)據(jù)，同時還兼顧了性能。只有徹底了解其存儲結(jié)構(gòu)，才能更好的指導我們應(yīng)用它！

歡迎大家關(guān)注我公眾號，里面有各種干貨，還有大禮包相送哦!