segment part-3
This commit is contained in:
parent
999018a093
commit
4cf0f3fdf2
|
@ -91,7 +91,7 @@ dimension列是不同的,因为它们支持过滤和聚合操作,所以每
|
|||
|
||||
* `meta.smoosh`
|
||||
|
||||
一个包含其他 `smoosh` 文件内容的元数据文件
|
||||
一个包含其他 `smoosh` 文件内容的元数据(文件名以及偏移量)文件
|
||||
|
||||
* `XXXXX.smoosh`
|
||||
|
||||
|
@ -104,8 +104,67 @@ dimension列是不同的,因为它们支持过滤和聚合操作,所以每
|
|||
在代码库中,段具有内部格式版本。当前的句段格式版本为 `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更改
|
||||
### 替换段
|
||||
### 段之间的不同schemas
|
||||
|
||||
Druid使用数据源、间隔、版本和分区号唯一地标识段。只有在为某个时间粒度创建多个段时,分区号才在段id中可见。例如,如果有小时段,但一小时内的数据量超过单个段的容量,则可以为同一小时创建多个段。这些段将共享相同的数据源、间隔和版本,但具有线性增加的分区号。
|
||||
|
||||
```
|
||||
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。
|
||||
|
||||
```
|
||||
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` 段将从集群中卸载。
|
||||
|
||||
请注意,跨越多个段间隔的更新在每个间隔内都是原子的, 但是在整个更新过程中它们不是原子的。例如,您有如下段:
|
||||
|
||||
```
|
||||
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` 段。
|
||||
|
||||
```
|
||||
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。如果一个字符串列(维度列)存在于一个段中而不是另一个段中,则涉及这两个段的查询仍然有效。对缺少维度的段的查询将表现为该维度只有空值。类似地,如果一个段有一个数值列(指标列),而另一个没有,那么查询缺少指标列的段通常会"做正确的事情", 在缺失的指标上做聚合操作也就是缺失的。
|
Loading…
Reference in New Issue