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]