ElasticSearch核心引擎Apache Lucene（三）：数值与空间数据索引

文章目录

- [一、背景：倒排索引处理数字的尴尬](#一、背景：倒排索引处理数字的尴尬)
- - [1.1 传统的"数字即字符串"方案](#1.1 传统的“数字即字符串”方案)
  - [1.2 BKD 的登场](#1.2 BKD 的登场)
- [二、核心原理：什么是 BKD Tree？](#二、核心原理：什么是 BKD Tree？)
- - [1. 几何空间视图：如何"切蛋糕"？](#1. 几何空间视图：如何“切蛋糕”？)
  - [2. 逻辑树视图：程序是怎么存的？](#2. 逻辑树视图：程序是怎么存的？)
  - [3. 物理存储视图：磁盘上长什么样？](#3. 物理存储视图：磁盘上长什么样？)
- [三、为什么 BKD 查询这么快？](#三、为什么 BKD 查询这么快？)
- - [3.1 三种状态判断](#3.1 三种状态判断)
  - [3.2 查询流程图](#3.2 查询流程图)
- [四、磁盘文件剖析 (.dim & .dii)](#四、磁盘文件剖析 (.dim & .dii))
- [五、实际应用场景与调优](#五、实际应用场景与调优)
- - [5.1 数值字段的选择](#5.1 数值字段的选择)
  - [5.2 地理位置 (Geo Point)](#5.2 地理位置 (Geo Point))
  - [5.3 性能调优 (Force Merge)](#5.3 性能调优 (Force Merge))
- 总结

摘要：在 ElasticSearch 5.0 之前，数字和地理位置的索引效率一直是痛点。随着 Lucene 6.0 引入了基于 BKD-Tree（Block K-Dimensional Tree）的全新多维点索引机制，ES 在范围查询（Range Query）、最近邻搜索（KNN）以及多维过滤性能上实现了质的飞跃。本文将深入内核，揭示 BKD Tree 如何优雅地统一处理数值、日期和地理空间数据。

一、背景：倒排索引处理数字的尴尬

在深入 BKD Tree 之前，我们需要理解为什么倒排索引（Inverted Index）不适合处理数字。

1.1 传统的"数字即字符串"方案

在 ES 早期（2.x时代），数字被当成字符串处理。为了支持范围查询（如 price: [10 TO 100]），Lucene 必须使用 Trie Range 结构（类似于 TrieIntField）。

它将数字转换成多个精度的 Term（例如 100 可能被索引为 1, 10, 100）。
缺点：索引膨胀严重，查询时需要产生大量的 Term 查找，IO 开销巨大。

1.2 BKD 的登场

Lucene 6.0 引入了 PointValues 接口，底层实现为 BKD Tree 。它不仅仅是为了优化数字，而是为了解决 多维数据（Multi-dimensional Data） 的索引问题。

数值 (Integer/Long/Float)：被视为 1 维的点。
日期 (Date)：被视为 1 维的点（毫秒数）。
地理位置 (GeoPoint)：被视为 2 维的点（经度, 纬度）。
IP 地址：被视为 IPv4 (1维) 或 IPv6 (16维) 的点。

二、核心原理：什么是 BKD Tree？

BKD Tree 是 K-D-B-tree 的变体，结合了 k-d tree （空间二分）和 B+ tree（块状存储、磁盘友好）的优点。

BKD-Tree 之所以难理解，是因为它同时涉及逻辑结构（树）和几何结构（空间划分）。光看文字很难想象它是如何"切分"数据的。

为了能够更加直观理解，我将把 BKD-Tree 拆解为三个视图：逻辑树视图 、几何空间视图 （最核心）和物理存储视图。

以一个 2维数据（地理位置：经度 X，纬度 Y） 为例。假设我们在地图上有 8 个点（文档）。BKD-Tree 的构建过程，实际上就是不断"切蛋糕"的过程。

1. 几何空间视图：如何"切蛋糕"？

这是理解 BKD 最关键的视角。BKD 并不是像倒排索引那样列出所有点，而是把整个地图切割成一个个矩形块（Block）。

规则：

交替选择维度进行切分（先切 X 轴，再切 Y 轴，再切 X 轴...）。
每次切分选中位数，保证左右两边数据量平衡。
切到 Block 内的点数量少于阈值（比如 2 个点）就停止。

空间切分演示图：

假设整个空间是 [0, 100] x [0, 100] 的正方形。

第 1 刀 (Root) : 按照 X轴中位数（比如 50）切分。左边是 X < 50，右边是 X >= 50。
第 2 刀 (Layer 1) : 在左右两个半区内，分别按照 Y轴切分。
- 左半区：Y 切分点 60。
- 右半区：Y 切分点 30。

左半区 (X < 50) Block A (Y >= 60) Block B (Y < 60) 右半区 (X >= 50) Block C (Y >= 30) Block D (Y < 30)

👆 也就是：

Block A: 左上角区域 (X<50, Y>=60) -> 包含点 P1, P2

Block B: 左下角区域 (X<50, Y<60) -> 包含点 P3, P4

Block C: 右上角区域 (X>=50, Y>=30) -> 包含点 P5, P6

Block D: 右下角区域 (X>=50, Y<30) -> 包含点 P7, P8

2. 逻辑树视图：程序是怎么存的？

在计算机内存中，上面的"切蛋糕"过程被表示为一棵完全二叉树。

每个非叶子节点 （中间节点）存储切分的维度和数值，以及该节点覆盖的最大/最小范围（Min/Max Packing）。
X < 50
X >= 50
Y >= 60
Y < 60
Y >= 30
Y < 30
ROOT节点

Split Dim: X

Split Val: 50

Range: [0,0] to [100,100]
节点 L

Split Dim: Y

Split Val: 60

Range: [0,0] to [49,100]
节点 R

Split Dim: Y

Split Val: 30

Range: [50,0] to [100,100]
🍃 Leaf Block A

Docs: [1, 5]

Range: [0,60] to [49,100]
🍃 Leaf Block B

Docs: [2, 8]

Range: [0,0] to [49,59]
🍃 Leaf Block C

Docs: [3, 9]

Range: [50,30] to [100,100]
🍃 Leaf Block D

Docs: [4, 7]

Range: [50,0] to [100,29]

🔍 关键点解析：

Min/Max Range : 每个节点都知道自己这棵子树所覆盖的确切矩形范围。
快速剪枝 : 如果我查询 X > 80，在 Root 节点一看，左子树的最大 X 是 49，直接整棵左子树全部跳过。这就是 BKD 快的原因。

3. 物理存储视图：磁盘上长什么样？

Lucene 为了极致性能，将这棵树分成了两个文件存储：.dii (索引) 和 .dim (数据)。

Packed Index (内存/堆外)：只存树的骨架（上面的圆圈节点）。为了省内存，它是一个紧凑的数组，而不是对象链表。
Leaf Blocks (磁盘)：只存叶子（上面的绿色方块）。包含真实的坐标数值和 DocID。

💿 磁盘 (Leaf Blocks .dim)
💾 内存 (Packed Index .dii)
Offset: 1024
Offset: 2048
Offset: 3072
Offset: 4096
Node 1: Split X=50
Node 2: Split Y=60
Node 3: Split Y=30
这部分极小

常驻内存

快速定位偏移量
文件头部
Data Block A

DocIds: 1,5

Coords: Compressed...
Data Block B

DocIds: 2,8

Coords: Compressed...
Data Block C...
Data Block D...

三、为什么 BKD 查询这么快？

当执行查询（例如：age > 18 或 geo_distance）时，Lucene 使用 IntersectVisitor 模式。

3.1 三种状态判断

对于树中的每一个节点（代表一个空间矩形范围），查询器会判断它与查询条件（Range Query）的关系

：

CELL_CROSSES_QUERY (相交) ：当前节点范围与查询范围部分重叠。
- 动作：继续递归进入子节点。
CELL_INSIDE_QUERY (全含) ：当前节点范围完全包含 在查询范围内。
- 动作：直接收割！该节点下的所有文档 ID 直接加入结果集，无需遍历子节点，效率极高。
CELL_OUTSIDE_QUERY (无关) ：当前节点范围与查询范围完全不相交。
- 动作：直接放弃该分支。

3.2 查询流程图

完全在范围内
完全在范围外
部分重叠
Yes
No
查询开始: range query
访问 BKD 节点
批量添加 Block 内所有 DocID
跳过该分支
是叶子节点?
遍历 Block 内每个点进行过滤
递归访问子节点
End

四、磁盘文件剖析 (.dim & .dii)

在 Lucene 的 Segment 目录中，你会看到如下文件：

.dii (Dimensional Index) :
存储 BKD Tree 的Packed Index（索引部分）。这部分非常紧凑，通常会被加载到堆外内存（Off-heap）中，以便快速导航。
.dim (Dimensional Points) :
存储 BKD Tree 的Leaf Blocks（数据部分）。这里存储了实际的经过压缩的数值和文档 ID（DocID）。

压缩黑科技：

Lucene 在存储叶子节点时使用了 DocID 差值存储 和 公共前缀压缩。如果一个 Block 内的所有数值高位相同（例如都是 2023 年的时间戳），这部分会被剥离出来只存储一次。

五、实际应用场景与调优

理解了 BKD Tree，我们就能明白 ES 中某些行为的原因：

5.1 数值字段的选择

Keyword vs Integer : 如果你的数字只是用来精确匹配（如订单号、状态码），使用 keyword 类型（倒排索引）可能更快。
Range Query : 如果你需要 range 查询（如价格、时间），必须使用 integer/long/date，利用 BKD Tree 的优势。

5.2 地理位置 (Geo Point)

在 BKD 出现之前，Geo 查询依赖 Geohash （将二维转为一维字符串）。

现在，ES 默认使用 geo_point 存储为 2D BKD Point。

优势：不需要预先定义精度（Geohash 长度），查询精度极高，且索引文件更小。

5.3 性能调优 (Force Merge)

BKD Tree 存在于每个 Segment 中。如果 Segment 数量太多，查询时需要遍历每棵树。

操作：执行 POST /my_index/_forcemerge?max_num_segments=1。
效果：将多棵小 BKD Tree 合并为一棵大树，极大提升 Range 查询性能（因为全局有序，排除无关 Block 的效率更高）。

总结

ElasticSearch 之所以能从单纯的"搜索引擎"进化为"分析引擎"，BKD Tree 功不可没。

统一性：它用一套逻辑（多维点划分）统一解决了数值、日期、地理位置的索引问题。
高性能 ：通过 Block 存储 减少磁盘 IO，通过 Inside 判定 实现批量收割文档。
空间小：相比旧的 Trie Range 和 Geohash，磁盘占用大幅降低。

掌握 BKD Tree 原理，是理解现代 ElasticSearch 性能优化的关键钥匙。