Lucene fdt 文件格式详解

本文及后面关于Lucene的文章所采用的lucene 版本为8.1.0.

1. 什么是fdt文件

fdt文件主要作用是保存field信息元始信息, 在lucene中，诸如StringField/TextField(原始text,而不是分词后的term), ByteField等都会将原始field 内容保存在该文件中。 Lucene在通过索引拿到docId时，对于非point类型来说，接着就是从fdt文件中加载docId处的内容以获取doc值。

---

2. fdt文件格式

fdt文件格式

---

3. 测试代码及结果

代码请参考Lucene tim文件格式详解的第三部分

---

4. 范例fdt文件内容

fdt文件.png

---

5. fdt文件内容分析

5.1 文件头

文件头部分主要内容为标识此文件类型为Lucene50StoredFieldsFast, 源码部分在CompressingStoredFieldsWriter的120行，主要内容如下

1. 3fd7 6c17 固定头MAGIC
2. 1c 为Lucene50StoredFieldsFastData长度28, 其中Lucene50StoredFieldsFast中的Fast代表data区采用Fast压缩方式, Data这个代表是data文件，与index文件相对应
3. 28个字节Lucene50StoredFieldsFastData
4. 00 0000 01 4个字节的CompressingStoredFieldsWriter.VERSION_CURRENT
5. 16个字节的segmentId, 这个是随机生成的
6. 00 segment suffix 长度 0

5.2 fdt data 部分

5.2.1 file meta信息

• 8080 01 chunk byte size 最小值 2^14, lucene 会将doc的field value值拆分成若干chunk存储，合理的设置该值能使压缩比与性能达到平衡
• 02 即2, 指的是PackedInts.VERSION_CURRENT

下面开始写field的具体值

5.2.2 Data 数据区

data数据区以chunk为单位组织起来，主要有chunk header和数据两个部分

1. Chunk header
Chunk header主要记录一个chunk的元数据，主要有:

• 00, 即0. docId base, 一般指的是该chunk中第一个doc Id值, 后面在此chunk中存储的docId均以此为base采用delta编码
• 04doc 数量及是否分片, 计算逻辑为 docNum << 1 + slice, docNum = 2, slice = 0, 代表不分片，分片逻辑取决于总的docId 所占空间是否大于等于2个chunk size， 具体逻辑请参考 CompressingStoredFieldsWriter#flush() 方法
• 00 01其中00代表所有的doc的field数量相同, 01代表每个doc的field数量为1, 具体逻辑在以下代码

 //CompressingStoredFieldsWriter
 private static void saveInts(int[] values, int length, DataOutput out) throws IOException {
    assert length > 0;
    //doc 数量为1
    if (length == 1) {
      out.writeVInt(values[0]);
    } else {
      boolean allEqual = true;
      for (int i = 1; i < length; ++i) {
        if (values[i] != values[0]) {
          allEqual = false;
          break;
        }
      }
      //所有的doc的filed num相同，先写一个0, 再写共同的field num
      if (allEqual) {
        out.writeVInt(0);
        out.writeVInt(values[0]);
      } else {
        long max = 0;
        for (int i = 0; i < length; ++i) {
          max |= values[i];
        }
       /*
       采用bit编码， 首先记录需要几个bit表示，然后写每个数值
       假设doc0, doc1, doc2, doc4 的field num 分别为1，2，1，3，则需要2个bit表示，则最终的结果为
       bit size : `0x02`
       bit content: 01, 10, 01, 11 即 `0x67`
       思想如上，更详细内容请参考下面代码
       */
        final int bitsRequired = PackedInts.bitsRequired(max);
        out.writeVInt(bitsRequired);
        final PackedInts.Writer w = PackedInts.getWriterNoHeader(out, PackedInts.Format.PACKED, length, bitsRequired, 1);
        for (int i = 0; i < length; ++i) {
          w.add(values[i]);
        }
        w.finish();
      }
    }
  }

• 0694 b0f2 10 每一个doc中field中值的length, 在样例中，length 分别为了37、11， 需要6个bit表示即06, 后面4个byte为对应的编码，采用Pack编码，有兴趣的同学可以去了解一下

为什么length 是37, 11呢？'lucene test, hello word, nice, nice'长度是35, 'nice haha'长度是9, 加上对应的长度值也应该是36和10，怎么会是37、11呢? 原因: 这个值是meta + data length + data value，meta占一个字节, 详细请参考下一部分

2. data body
body 依次写入每一个doc的每一个field字段内容, 格式请参考fdt格式图

• 00, 即 0 << 1 + 0, 0 << 1 0 代表field numer 为0， 后面的0 代表field的数据类型CompressingStoredFieldsWriter.STRING，详细内容可以参考CompressingStoredFieldsWriter#writeField方法
• 23即35代表第一个doc的第一个field值长度，即'lucene test, hello word, nice, nice'
• 35个字节内容，text/String 类型是直接写，其它类型有不同格式，请参考源码CompressingStoredFieldsWriter#writeField; 上一节提到的length是37指的是35 + 2(00 23)
• 01 chunk 总个数1
• 01 不完整chunk个数1

不完整chunk 指的chunk 中doc个数小于128, 一般在手动触发flush、合并的时候会生成不完整的chunk

5.3 footer区

footer区主要有以下内容

• c0 2893 e8 MAGIC值，为header值的反码
• 00 0000 00 固定4个字节int 值为0
• 0000 0000 ec0a abc0 8个字节的CRC码

---

觉得本文有帮助的话，请关注我的简书，一同进步！