druid-docs-cn/design/Segments.md

182 lines
10 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!-- toc -->
<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<ins class="adsbygoogle"
style="display:block; text-align:center;"
data-ad-layout="in-article"
data-ad-format="fluid"
data-ad-client="ca-pub-8828078415045620"
data-ad-slot="7586680510"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>
## 段
ApacheDruid将索引存储在按时间分区的*段文件*中。在基本设置中,通常为每个时间间隔创建一个段文件,其中时间间隔可在 `granularitySpec` 的`segmentGranularity` 参数中配置。为了使Druid在繁重的查询负载下运行良好段文件大小必须在建议的300MB-700MB范围内。如果段文件大于此范围请考虑更改时间间隔的粒度或者对数据进行分区并在 `partitionsSpec` 中调整 `targetPartitionSize`此参数的建议起点是500万行。有关更多信息请参阅下面的**分片部分**和[批处理摄取](../DataIngestion/native.md)文档的**分区规范**部分。
### 段文件的核心数据结构
在这里,我们描述段文件的内部结构,它本质上是*列式*的每列的数据在单独的数据结构中。通过分别存储每一列Druid可以通过只扫描查询实际需要的列来减少查询延迟。有三种基本列类型**时间戳列、维度列和指标列**,如下图所示:
![](img/druid-column-types.png)
timestamp和metric列很简单在底层每个列都是用LZ4压缩的整数或浮点值数组。一旦查询知道需要选择哪些行它只需解压缩这些行提取相关行然后使用所需的聚合运算符进行计算。与所有列一样如果不查询一个列则跳过该列的数据。
dimension列是不同的因为它们支持过滤和聚合操作所以每一个维度都需要以下三种数据结构
1. 一个将值通常被当做字符串映射到整数id的字典
2. 一个使用第一步的字典进行编码的列值的列表
3. 对于列中每一个不同的值,标识哪些行包含该值的位图
为什么需要这三种数据结构字典简单地将字符串值映射到整数id以便于在23中可以紧凑的表示。3中的位图也称*倒排索引*可以进行快速过滤操作特别是位图便于快速进行AND和OR操作。 最后,`GroupBy` 和 `TopN` 查询需要2中的值列表。换句话说仅基于过滤器的聚合指标是不需要2中存储的维度值列表的。
要具体了解这些数据结构,请考虑上面示例数据中的"page"列,表示此维度的三个数据结构如下图所示:
```json
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使用特别适合位图的压缩算法如Roaring位图压缩来利用这一点特性。
**多值列**
如果数据源使用多值列,那么段文件中的数据结构看起来有点不同。让我们假设在上面的例子中,第二行同时标记了"Ke$ha"和"Justin Bieber"主题。在这种情况下,这三种数据结构现在看起来如下:
```json
1: Dictionary that encodes column values
{
"Justin Bieber": 0,
"Ke$ha": 1
}
2: Column data
[0,
[0,1], <--Row value of multi-value column can have array of values
1,
1]
3: Bitmaps - one for each unique value
value="Justin Bieber": [1,1,0,0]
value="Ke$ha": [0,1,1,1]
^
|
|
Multi-value column has multiple non-zero entries
```
请注意列数据和Ke$ha位图中第二行的更改。如果一行中的某一列有多个值则其在“列数据”中的条目是一个数组。此外在“列数据”中有n个值的行在位图中将有n个非零值项。
### SQL兼容的空值处理
默认情况下Druid字符串维度列可以使用 `""` 或者 `null` ,数值列和指标列则不能表示为 `null`,而是将 `null` 强制为 `0`。但是Druid还提供了一个与SQL兼容的空值处理模式必须在系统级别通过 `Druid.generic.useDefaultValueForNull` 启用, 当设置为 `false`此设置将允许Druid在接收数据时创建的段中字符串列区分 `""``null` ,数值列区分 `null``0`
在这种模式下,字符串维度列不包含额外的列结构,只是为 `null` 保留额外的字典条目。但是,数值列将与一个附加位图一起存储在段中,该位图标识哪些行是 `null` 值。除了略微增加段大小之外,由于需要检查 `null` 的位图SQL兼容的空值处理在查询时也会导致性能损失此性能开销仅对实际包含`null`列的场景中存在。
### 命名规则
段标识符通常使用数据源时间区间的开始时间ISO 8601格式时间区间的结束时间ISO 8601格式和版本来构造。如果数据被额外的分片后超出了时间范围则段标识符还将包含分区号。
一个示例段标识符可以是:
`数据源名称_开始时间_结束时间_版本号_分区号`
### 段的组成
在底层,一个段由以下几个文件组成:
* `version.bin`
4个字节以整数表示当前段版本。 例如对于v9段版本为0x0、0x0、0x0、0x9
* `meta.smoosh`
一个包含其他 `smoosh` 文件内容的元数据(文件名以及偏移量)文件
* `XXXXX.smoosh`
这些文件中有一些是串联的二进制数据
`smoosh` 文件代表 "smooshed" 在一起的多个文件以减少必须打开用来容纳数据的文件描述符的数量它们是最大为2GB的文件以匹配Java中内存映射的ByteBuffer的限制。`smoosh` 文件为数据中的每个列提供单独的文件,并在 `index.drd` 文件提供有关该段的额外元数据。
还有一个称为 `__time` 的特殊列,它表示该段的时间列。希望随着代码的发展,这种特殊性将越来越少,但就目前而言,它就像我妈妈一直告诉我的那样特殊。
在代码库中,段具有内部格式版本。当前的句段格式版本为 `v9`
### 列的格式
每列存储为两部分:
1. Jackson序列化的列描述符
2. 列二进制文件的其余部分
**列描述符**本质上是一个对象它允许我们使用Jackson的多态反序列化来添加新的有趣的序列化方法并且对代码的影响最小。它由关于列的一些元数据它是什么类型的它是多值的等等和一列序列化/反序列化逻辑组成,这些逻辑可以反序列化二进制文件的其余部分。
### 切分数据以创建段
#### 数据分片
对于同一数据源,同一时间间隔内可能存在多个段。这些段在一段时间内形成一个 `块` 。根据用于切分数据的 `shardSpec` 的类型,只有当一个 `块` 完成时Druid查询才能完成。也就是说如果一个块由3个段组成例如
`sampleData_2011-01-01T02:00:00:00Z_2011-01-01T03:00:00:00Z_v1_0`
`sampleData_2011-01-01T02:00:00:00Z_2011-01-01T03:00:00:00Z_v1_1`
`sampleData_2011-01-01T02:00:00:00Z_2011-01-01T03:00:00:00Z_v1_2`
在完成对间隔 `2011-01-01T02:00:00:00Z_2011-01-01T03:00:00:00Z` 的查询之前必须加载所有3个段。
此规则的例外是使用**线性切片规范**。线性切片规范不会强制"完整性"即使系统中没有加载切片查询也可以完成。例如如果您的实时摄取任务创建了3个使用线性切片规范进行分段的段并且系统中只加载了其中的两个段那么查询将只返回这两个段的结果。
### Schema更改
### 替换段
Druid使用数据源、间隔、版本和分区号唯一地标识段。只有在为某个时间粒度创建多个段时分区号才在段id中可见。例如如果有小时段但一小时内的数据量超过单个段的容量则可以为同一小时创建多个段。这些段将共享相同的数据源、间隔和版本但具有线性增加的分区号。
```json
foo_2015-01-01/2015-01-02_v1_0
foo_2015-01-01/2015-01-02_v1_1
foo_2015-01-01/2015-01-02_v1_2
```
在上述段的实例中,`dataSource = foo`, `interval = 2015-01-01/2015-01-02`, `version = v1`, and `partitionNum = 0`。 如果在以后的某个时间点使用新的schema重新索引数据则新创建的段将具有更高的版本id。
```json
foo_2015-01-01/2015-01-02_v2_0
foo_2015-01-01/2015-01-02_v2_1
foo_2015-01-01/2015-01-02_v2_2
```
Druid批量索引任务基于Hadoop或基于IndexTask保证了间隔内的的原子更新。在我们的例子中`2015-01-01/2015-01-02` 的所有 `v2` 段加载到Druid集群之前查询只使用 `v1` 段。加载完所有 `v2` 段并可查询后,所有查询都将忽略 `v1` 段并切换到 `v2` 段。不久之后,`v1` 段将从集群中卸载。
请注意,跨越多个段间隔的更新在每个间隔内都是原子的, 但是在整个更新过程中它们不是原子的。例如,您有如下段:
```json
foo_2015-01-01/2015-01-02_v1_0
foo_2015-01-02/2015-01-03_v1_1
foo_2015-01-03/2015-01-04_v1_2
```
`v2` 段将在构建后立即加载到集群中,并在段重叠的时间段内替换 `v1` 段。在完全加载 `v2` 段之前,集群可能混合了 `v1``v2` 段。
```json
foo_2015-01-01/2015-01-02_v1_0
foo_2015-01-02/2015-01-03_v2_1
foo_2015-01-03/2015-01-04_v1_2
```
在这种情况下,查询可能会命中 `v1``v2` 段的混合.
### 段之间的不同schemas
同一数据源的Druid段可能有不同的schema。如果一个字符串列维度列存在于一个段中而不是另一个段中则涉及这两个段的查询仍然有效。对缺少维度的段的查询将表现为该维度只有空值。类似地如果一个段有一个数值列指标列而另一个没有那么查询缺少指标列的段通常会"做正确的事情", 在缺失的指标上做聚合操作也就是缺失的。