Doris存储文件格式优化

图1. doris segment文件格式

文件包括：

文件开始是8个字节的magic code，用于识别文件格式和版本
Data Region：用于存储各个列的数据信息，这里的数据是按需分page加载的
Index Region: doris中将各个列的index数据统一存储在Index Region，这里的数据会按照列粒度进行加载，所以跟列的数据信息分开存储
Footer信息
- FileFooterPB:定义文件的元数据信息
- 4个字节的footer pb内容的checksum
- 8个字节的MAGIC CODE，之所以在末位存储，是方便不同的场景进行文件类型的识别

文件中的数据按照page的方式进行组织，page是编码和压缩的基本单位。现在的page类型包括以下几种:

DataPage分为两种：nullable和non-nullable的data page。

nullable的data page内容包括：

non-nullable data page结构如下：

value count
- 表示page中的行数
first row id
- page中第一行的行号
bitmap length
- 表示接下来bitmap的字节数
null bitmap
- 表示null信息的bitmap
data
- 存储经过encoding和compress之后的数据
- 需要在数据的头部信息中写入：is_compressed
- 各种不同编码的data需要在头部信息写入一些字段信息，以实现数据的解析
  - TODO：添加各种encoding的header信息
checksum
- 存储page粒度的校验和，包括page的header和之后的实际数据

针对每个bloom filter列,会在page的粒度相应的生成一个bloom filter的page，保存在bloom filter pages区域

针对每个列，都会按照page粒度，建立行号的稀疏索引。内容为这个page的起始行的行号到这个block的指针（包括offset和length）

我们会每隔N行（可配置）生成一个short key的稀疏索引，索引的内容为：short key->行号(ordinal)

该格式设计支持后续扩展其他的索引信息，比如bitmap索引，spatial索引等等，只需要将需要的数据写到现有的列数据后面，并且添加对应的元数据字段到FileFooterPB中

FileFooterPB的定义为：

大体的写入流程如下：

写入magic
根据schema信息，生成对应的ColumnWriter，每个ColumnWriter按照不同的类型，获取对应的encoding信息（可配置），根据encoding，生成对应的encoder
调用encoder->add(value)进行数据写入，每个K行，生成一个short key index entry，并且，如果当前的page满足一定条件（大小超过1M或者行数为K），就生成一个新的page，缓存在内存中。
生成FileFooterPB信息，写入文件中。

short key的索引如何生成？
- 现在还是按照每隔多少行生成一个short key的稀疏索引，保持每隔1024行生成一个short的稀疏索引,具体的内容是：short key -> ordinal
ordinal索引里面应该存什么？
- 存储page的第一个ordinal到page pointer的映射信息
不同encoding类型的page里存什么？
- 词典压缩
- plain
- rle
- bshuf

读取文件的magic，判断文件类型和版本
读取FileFooterPB，进行checksum校验
按照需要的列，读取short key索引和对应列的数据ordinal索引信息
使用start key和end key，通过short key索引定位到要读取的行号，然后通过ordinal索引确定需要读取的row ranges, 同时需要通过统计信息、bitmap索引等过滤需要读取的row ranges
然后按照row ranges通过ordinal索引读取行的数据