Druid的數據結構

Druid數據存儲結構可以分為三層： 1. DataSource 2. Chunk 3. Segment

DataSource相當于傳統數據庫的按時間分區的表，Chunk相當于MySQL中的按時間分區的表一個分區，但是Chunk不是一個實體，只是一個虛擬的概念，一個Chunk中可以有多個Segment。 在最終落地的文件結構(可以存在本地文件、HDFS中)中，一個DataSource占用一個目錄，該目錄下包含若干個Segment文件，Segment文件名中包含該Segment所屬的DataSource名、內含數據的時間區間、分區序號，每個Segment都是一個壓縮文件。 Druid的DataSource本身不維護元數據，每一個Segment內部包含了該Segment的所有列信息；一個DataSource下的各Segment的字段可以不同，Druid允許在同一個DataSource下存放不同字段數、字段名的Segment，在做數據入庫的時候不做格式合法性檢查，查詢的時候針對缺失字段提供默認行為(缺失的數值型字段取默認值0，缺失的字符串型字段取默認值null)。

Segment的數據結構

Segment的字段分為三類： 1. TimeStamp 2. Dimension 3. Metric

TimeStamp是固定字段，每個Segment都必須有一個TimeStamp類型字段，字段名可以由用戶指定；Dimension是維度字段，可以是數值型、字符串型；Metric是指標字段，必須是數值型。 Druid的數據是按列存儲的，每一列的所有數據都存儲在一段連續的文件地址內，執行查詢的時候只需要訪問相關的列即可，而且由于列內數據的存儲地址是連續的，所以讀取每一列的數據都很快。 TimeStamp和Metric類型的列的存儲格式都比較簡單，只是單純地把所有數據按照LZ4的格式壓縮存儲而已，而Dimension類型的列的存儲格式比較復雜，包含如下結構： 1. 一個把所有取值(不管Dimension是什么類型，存儲時都被視為是字符串類型)和連續的數字ID一一匹配的字典 2. 該列的所有行的取值對應的數字ID按順序存儲 3. 一個倒排索引字典，key是該列的所有取值，value是一個列表，如果第N行的該列取值為key，則該列表的第N項就是1，否則是0

這些數據結構都是為提高查詢速度而服務的，第一條是基礎，第二條在處理groupBy/topN這類查詢時效率很高，第三條(倒排索引)在處理查詢的AND/OR的聯合篩選時效率很高。 示例如下：

1: Dictionary that encodes column values

{

"Justin Bieber": 0,

"Ke$ha": 1

}

2: Column data

[0,

0,

1,

1]

3: Bitmaps - one for each unique value of the column

value="Justin Bieber": [1,1,0,0]

value="Ke$ha": [0,0,1,1]

總結

以上是生活随笔為你收集整理的druid字段级_Druid的数据结构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。