Druid--Druid中数据管理

• 基于apache-druid-0.17

schema变化

• DataSource中的schema可以在任何时候进行改动，Druid中支持DataSource中Segment中有不同的schema。

替换Segment

• Druid使用数据源、间隔、版本和分区号唯一地标识Segment。只有在为某个时间粒度创建多个Segment时，分区号才在Segmentid中可见。例如，如果您有每小时的Segment，但是您在一个小时内拥有的数据比单个Segment所能容纳的数据更多，那么您可以为同一小时创建多个Segment。这些Segment将共享相同的数据源、时间间隔和版本，但分区数将线性增加。

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, partitionNum = 0。如果在以后的某个时候，您使用新的模式重新索引数据，那么新创建的段将具有更高的版本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-based or IndexTask-based)保证了每隔一段时间的原子更新。在我们的例子中，在所有的v2版本Segment(2015-01-01 - 2015-01-02)加载到一个Druid集群之前，查询只使用v1版本Segment。一旦所有的v2Segment被加载并可查询，所有的查询都会忽略v1版本Segment并切换到v2版本Segment。不久之后，v1版本Segment将从集群中卸载。
• 注意，跨越多个Segment间隔的更新只是每个间隔内的原子更新。它们在整个更新中不是原子性的。例如，你有如下Segment:

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版本Segment将在构建后立即加载到集群中，并在Segment重叠期间替换v1版本Segment。在v2版本Segment完全加载之前，您的集群可能混合了v1和v2版本Segment。

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版本Segment的混合。

Segment中不同的schema

• 同一数据源的Segment可能有不同的schema。如果一个字符串列(维度)存在于一个Segment中，而不存在于另一个Segment中，则涉及两个Segment的查询仍然有效。对于缺少维度的Segment的查询将表现为该Segment只有null值。类似地，如果一个Segment有一个数字列(度量)，而另一个没有，那么缺少度量的Segment上的查询通常会"do the right thing"。丢失度量的聚合操作就像丢失度量一样。

压缩和重建索引

• 压缩是一种覆盖操作，它读取一组现有的Segment，将它们组合成一个更大但更少的Segment的新集，并使用新的压缩集覆盖原始集，而不改变存储的数据。
• 出于性能方面的考虑，有时将一组Segment压缩成一组更大但更少的Segment是有益的，因为在数据抽取和查询路径中都存在一些每段处理和内存开销。
• 压缩任务合并给定时间间隔的所有Segment。语法如下：

{
    "type": "compact",
    "id": <task_id>,
    "dataSource": <task_datasource>,
    "ioConfig": <IO config>,
    "dimensionsSpec" <custom dimensionsSpec>,
    "metricsSpec" <custom metricsSpec>,
    "segmentGranularity": <segment granularity after compaction>,
    "tuningConfig" <parallel indexing task tuningConfig>,
    "context": <task context>
}

Field	Description	Required
type	Task type. Should be compact	Yes
id	Task id	No
dataSource	DataSource name to be compacted	Yes
ioConfig	ioConfig for compaction task. See Compaction IOConfig for details.	Yes
dimensionsSpec	Custom dimensionsSpec. Compaction task will use this dimensionsSpec if exist instead of generating one. See below for more details.	No
metricsSpec	Custom metricsSpec. Compaction task will use this metricsSpec if specified rather than generating one.	No
segmentGranularity	If this is set, compactionTask will change the segment granularity for the given interval. See segmentGranularity of granularitySpec for more details. See the below table for the behavior.	No
tuningConfig	Parallel indexing task tuningConfig	No
context	Task context	No

• 具体字段连接还需要查看官网文档 Data management
• 压缩Segment的案例如下：

{
  "type" : "compact",
  "dataSource" : "wikipedia",
  "ioConfig" : {
    "type": "compact",
    "inputSpec": {
      "type": "interval",
      "interval": "2017-01-01/2018-01-01"
    }
  }
}

• 这个压缩任务读取区间2017-01-01/2018-01-01的所有Segment，并产生新的Segment。由于Segment粒度为空，所以在压缩之后，原始的Segment粒度将保持不变。要控制每个时间块的结果Segment数量，可以设置maxRowsPerSegment或numShards。请注意，您可以同时运行多个compactionTasks。例如，您可以每月运行12个compactionTasks，而不是全年只运行一个任务。
• 压缩任务在内部生成索引任务规范，用于使用某些固定参数执行压缩工作。例如，它的inputSource总是DruidInputSource，默认情况下，dimensionsSpec和metricsSpec包括输入Segment的所有维度和度量。
• 如果您指定的时间间隔中没有加载任何Segment(或者您指定的时间间隔为空)，那么压缩任务将带着一个失败状态代码退出，而不做任何事情。
• 除非所有输入Segment具有相同的元数据，否则输出Segment可以具有与输入Segment不同的元数据。
• 维度:由于Druid支持Schema改变，即使是同一数据源的一部分，不同Segment的维度也是不同的。如果输入Segment具有不同的维度，则输出Segment基本上包括输入Segment的所有维度。然而，即使输入Segment具有相同的维度集，维度的维度顺序或数据类型也可能不同。例如，某些维度的数据类型可以从字符串更改为基本类型，或者为了更好的局部性而更改维度的顺序。在这种情况下，在数据类型和排序方面，最近Segment的维度优先于旧Segment的维度。这是因为较新的Segment更可能具有新的所需顺序和数据类型。如果希望使用自己的排序和类型，可以在压缩任务规范中指定自定义维度规范。
• rollup:只有在为所有输入Segment设置了rollup时，才会对输出Segment进行rollup。更多细节见Roll-up。您可以使用段元数据查询来检查段是否已卷起。

添加新数据

• Druid可以通过向现有的Segment集添通过append的方式添加新数据。它还可以通过合并（merge）现有的Segment集和新数据，并覆盖原始数据集的方式来添加新数据。
• druid不支持单条记录的主键更新；

更新已存在的数据

• 以下几种方式可以改变druid中已经存在的数据；

采用Lookup

• 如果您有一个需要频繁更新值的维度，请首先尝试使用Looku。一个典型的Lookup用例是当你有一个ID维度存储在一个Druid段中，并且想要将这个ID维度映射到一个类似人名的的字符串值时，这个值可能需要定期更新。

Reingesting数据（清洁数据）

• 如果基于Lookup的技术是满足不了，需要将数据更新到druid中，以获取新的时间块（time chunks）。可以采用batch数据提取的方式进行重写。也可以采用streaming数据提取的方式，前提是需要删除相关时间块的数据。
• 如果采用batch模式，Druid的原子更新机制意味着查询将无缝地从旧数据转换到新数据。
• 我们建议您保留一份原始数据的副本，以备您随时需要检索它。

With Hadoop-based ingestion

• 详见官网

Reindexing with Native Batch Ingestion

• 详见官网

deleting data

• 详见官网