quota to json
This commit is contained in:
liujianhuan
parent
be46e364ef
commit
20995e2262
|
|
@ -9,7 +9,7 @@ Apache Druid可以接收JSON、CSV或TSV等分隔格式或任何自定义格式
|
|||
下面的示例显示了在Druid中原生支持的数据格式：
|
||||
|
||||
*JSON*
|
||||
```
|
||||
```json
|
||||
{"timestamp": "2013-08-31T01:02:33Z", "page": "Gypsy Danger", "language" : "en", "user" : "nuclear", "unpatrolled" : "true", "newPage" : "true", "robot": "false", "anonymous": "false", "namespace":"article", "continent":"North America", "country":"United States", "region":"Bay Area", "city":"San Francisco", "added": 57, "deleted": 200, "delta": -143}
|
||||
{"timestamp": "2013-08-31T03:32:45Z", "page": "Striker Eureka", "language" : "en", "user" : "speed", "unpatrolled" : "false", "newPage" : "true", "robot": "true", "anonymous": "false", "namespace":"wikipedia", "continent":"Australia", "country":"Australia", "region":"Cantebury", "city":"Syndey", "added": 459, "deleted": 129, "delta": 330}
|
||||
{"timestamp": "2013-08-31T07:11:21Z", "page": "Cherno Alpha", "language" : "ru", "user" : "masterYi", "unpatrolled" : "false", "newPage" : "true", "robot": "true", "anonymous": "false", "namespace":"article", "continent":"Asia", "country":"Russia", "region":"Oblast", "city":"Moscow", "added": 123, "deleted": 12, "delta": 111}
|
||||
|
|
@ -18,7 +18,7 @@ Apache Druid可以接收JSON、CSV或TSV等分隔格式或任何自定义格式
|
|||
```
|
||||
|
||||
*CSV*
|
||||
```
|
||||
```json
|
||||
2013-08-31T01:02:33Z,"Gypsy Danger","en","nuclear","true","true","false","false","article","North America","United States","Bay Area","San Francisco",57,200,-143
|
||||
2013-08-31T03:32:45Z,"Striker Eureka","en","speed","false","true","true","false","wikipedia","Australia","Australia","Cantebury","Syndey",459,129,330
|
||||
2013-08-31T07:11:21Z,"Cherno Alpha","ru","masterYi","false","true","true","false","article","Asia","Russia","Oblast","Moscow",123,12,111
|
||||
|
|
@ -27,7 +27,7 @@ Apache Druid可以接收JSON、CSV或TSV等分隔格式或任何自定义格式
|
|||
```
|
||||
|
||||
*TSV(Delimited)*
|
||||
```
|
||||
```json
|
||||
2013-08-31T01:02:33Z "Gypsy Danger" "en" "nuclear" "true" "true" "false" "false" "article" "North America" "United States" "Bay Area" "San Francisco" 57 200 -143
|
||||
2013-08-31T03:32:45Z "Striker Eureka" "en" "speed" "false" "true" "true" "false" "wikipedia" "Australia" "Australia" "Cantebury" "Syndey" 459 129 330
|
||||
2013-08-31T07:11:21Z "Cherno Alpha" "ru" "masterYi" "false" "true" "true" "false" "article" "Asia" "Russia" "Oblast" "Moscow" 123 12 111
|
||||
|
|
@ -54,7 +54,7 @@ Druid支持自定义数据格式，可以使用 `Regex` 解析器或 `JavaScript
|
|||
|
||||
**JSON**
|
||||
一个加载JSON格式数据的 `inputFormat` 示例：
|
||||
```
|
||||
```json
|
||||
"ioConfig": {
|
||||
"inputFormat": {
|
||||
"type": "json"
|
||||
|
|
@ -73,7 +73,7 @@ JSON `inputFormat` 有以下组件：
|
|||
|
||||
#### CSV
|
||||
一个加载CSV格式数据的 `inputFormat` 示例：
|
||||
```
|
||||
```json
|
||||
"ioConfig": {
|
||||
"inputFormat": {
|
||||
"type": "csv",
|
||||
|
|
@ -94,7 +94,7 @@ CSV `inputFormat` 有以下组件：
|
|||
| skipHeaderRows | 整型数值 | 该项如果设置，任务将略过 `skipHeaderRows`配置的行数 | 否（默认为0） |
|
||||
|
||||
#### TSV(Delimited)
|
||||
```
|
||||
```json
|
||||
"ioConfig": {
|
||||
"inputFormat": {
|
||||
"type": "tsv",
|
||||
|
|
@ -126,7 +126,7 @@ TSV `inputFormat` 有以下组件：
|
|||
> 如果您正在考虑从早于0.15.0的版本升级到0.15.0或更高版本，请仔细阅读 [从contrib扩展的迁移](../Development/orc-extensions.md#从contrib扩展迁移)。
|
||||
|
||||
一个加载ORC格式数据的 `inputFormat` 示例：
|
||||
```
|
||||
```json
|
||||
"ioConfig": {
|
||||
"inputFormat": {
|
||||
"type": "orc",
|
||||
|
|
@ -160,7 +160,7 @@ ORC `inputFormat` 有以下组件：
|
|||
> 使用Parquet输入格式之前，首先需要包含 [druid-parquet-extensions](../Development/parquet-extensions.md)
|
||||
|
||||
一个加载Parquet格式数据的 `inputFormat` 示例：
|
||||
```
|
||||
```json
|
||||
"ioConfig": {
|
||||
"inputFormat": {
|
||||
"type": "parquet",
|
||||
|
|
@ -191,7 +191,7 @@ Parquet `inputFormat` 有以下组件：
|
|||
#### FlattenSpec
|
||||
|
||||
`flattenSpec` 位于 `inputFormat` -> `flattenSpec` 中，负责将潜在的嵌套输入数据（如JSON、Avro等）和Druid的平面数据模型之间架起桥梁。 `flattenSpec` 示例如下：
|
||||
```
|
||||
```json
|
||||
"flattenSpec": {
|
||||
"useFieldDiscovery": true,
|
||||
"fields": [
|
||||
|
|
@ -291,7 +291,7 @@ Parquet `inputFormat` 有以下组件：
|
|||
Avro parseSpec可以包含使用"root"或"path"字段类型的 [flattenSpec](#flattenspec)，这些字段类型可用于读取嵌套的Avro记录。Avro当前不支持“jq”字段类型。
|
||||
|
||||
例如，使用带有自定义读取器schema文件的Avro Hadoop解析器：
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type" : "index_hadoop",
|
||||
"spec" : {
|
||||
|
|
@ -351,7 +351,7 @@ Avro parseSpec可以包含使用"root"或"path"字段类型的 [flattenSpec](#fl
|
|||
|
||||
像大多数Hadoop作业，最佳结果是在 `tuningConfig` 中的 `jobProperties` 中添加 `"mapreduce.job.user.classpath.first": "true"` 或者 `"mapreduce.job.classloader": "true"`。 注意，如果使用了 `"mapreduce.job.classloader": "true"`, 需要设置 `mapreduce.job.classloader.system.classes` 包含 `-org.apache.hadoop.hive.` 来让Hadoop从应用jars包中加载 `org.apache.hadoop.hive` 而非从系统jar中，例如：
|
||||
|
||||
```
|
||||
```json
|
||||
...
|
||||
"mapreduce.job.classloader": "true",
|
||||
"mapreduce.job.classloader.system.classes" : "java., javax.accessibility., javax.activation., javax.activity., javax.annotation., javax.annotation.processing., javax.crypto., javax.imageio., javax.jws., javax.lang.model., -javax.management.j2ee., javax.management., javax.naming., javax.net., javax.print., javax.rmi., javax.script., -javax.security.auth.message., javax.security.auth., javax.security.cert., javax.security.sasl., javax.sound., javax.sql., javax.swing., javax.tools., javax.transaction., -javax.xml.registry., -javax.xml.rpc., javax.xml., org.w3c.dom., org.xml.sax., org.apache.commons.logging., org.apache.log4j., -org.apache.hadoop.hbase., -org.apache.hadoop.hive., org.apache.hadoop., core-default.xml, hdfs-default.xml, mapred-default.xml, yarn-default.xml",
|
||||
|
|
@ -363,7 +363,7 @@ Avro parseSpec可以包含使用"root"或"path"字段类型的 [flattenSpec](#fl
|
|||
**示例**
|
||||
|
||||
**`orc` parser, `orc` parseSpec, 自动字段发现, 展平表达式**
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type": "index_hadoop",
|
||||
"spec": {
|
||||
|
|
@ -413,7 +413,7 @@ Avro parseSpec可以包含使用"root"或"path"字段类型的 [flattenSpec](#fl
|
|||
|
||||
**`orc` parser, `orc` parseSpec, 不具有 `flattenSpec` 或者 `dimensionSpec`的字段发现**
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type": "index_hadoop",
|
||||
"spec": {
|
||||
|
|
@ -447,7 +447,7 @@ Avro parseSpec可以包含使用"root"或"path"字段类型的 [flattenSpec](#fl
|
|||
```
|
||||
**`orc` parser, `orc` parseSpec, 非自动发现**
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type": "index_hadoop",
|
||||
"spec": {
|
||||
|
|
@ -507,7 +507,7 @@ Avro parseSpec可以包含使用"root"或"path"字段类型的 [flattenSpec](#fl
|
|||
|
||||
**`orc` parser, `timeAndDims` parseSpec**
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type": "index_hadoop",
|
||||
"spec": {
|
||||
|
|
@ -577,7 +577,7 @@ Parquet Hadoop 解析器支持自动字段发现，如果提供了一个带有 `
|
|||
**示例**
|
||||
|
||||
`parquet` parser, `parquet` parseSpec
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type": "index_hadoop",
|
||||
"spec": {
|
||||
|
|
@ -630,7 +630,7 @@ Parquet Hadoop 解析器支持自动字段发现，如果提供了一个带有 `
|
|||
}
|
||||
```
|
||||
`parquet` parser, `timeAndDims` parseSpec
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type": "index_hadoop",
|
||||
"spec": {
|
||||
|
|
@ -695,7 +695,7 @@ Parquet Avro Hadoop 解析器支持自动字段发现，如果提供了一个带
|
|||
当时间维度是一个 [date类型的列](https://github.com/apache/parquet-format/blob/master/LogicalTypes.md), 则无需指定一个格式。 当格式为UTF8的String， 则要么指定为 `auto`，或者显式的指定一个 [时间格式](http://www.joda.org/joda-time/apidocs/org/joda/time/format/DateTimeFormat.html)。
|
||||
|
||||
**示例**
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type": "index_hadoop",
|
||||
"spec": {
|
||||
|
|
@ -764,7 +764,7 @@ Parquet Avro Hadoop 解析器支持自动字段发现，如果提供了一个带
|
|||
Avro parseSpec包含一个使用"root"或者"path"类型的 [`flattenSpec`](ingestion.md#flattenspec.md), 以便可以用来读取嵌套的avro数据。 "jq"类型在Avro中目前还不支持。
|
||||
|
||||
以下示例展示了一个具有**schema repo**avro解码器的 `Avro stream parser`:
|
||||
```
|
||||
```json
|
||||
"parser" : {
|
||||
"type" : "avro_stream",
|
||||
"avroBytesDecoder" : {
|
||||
|
|
@ -797,7 +797,7 @@ Avro parseSpec包含一个使用"root"或者"path"类型的 [`flattenSpec`](inge
|
|||
> "schema_inline"解码器使用固定schema读取Avro记录，不支持schema迁移。如果将来可能需要迁移schema，请考虑其他解码器之一，所有解码器都使用一个消息头，该消息头允许解析器识别正确的Avro schema以读取记录。
|
||||
|
||||
如果可以使用同一schema读取所有输入事件，则可以使用此解码器。在这种情况下，在输入任务JSON本身中指定schema，如下所述:
|
||||
```
|
||||
```json
|
||||
...
|
||||
"avroBytesDecoder": {
|
||||
"type": "schema_inline",
|
||||
|
|
@ -817,7 +817,7 @@ Avro parseSpec包含一个使用"root"或者"path"类型的 [`flattenSpec`](inge
|
|||
**基于Avro Bytes Decoder的 `multiple inline schemas`**
|
||||
|
||||
如果不同的输入事件可以有不同的读取schema，请使用此解码器。在这种情况下，在输入任务JSON本身中指定schema，如下所述:
|
||||
```
|
||||
```json
|
||||
...
|
||||
"avroBytesDecoder": {
|
||||
"type": "multiple_schemas_inline",
|
||||
|
|
@ -885,7 +885,7 @@ Avro Bytes Decorder首先提取输入消息的 `subject` 和 `id`， 然后使
|
|||
| url | String | 指定架构注册表的url | 是 |
|
||||
| capacity | 整型数字 | 指定缓存的最大值（默认为 Integer.MAX_VALUE）| 否 |
|
||||
|
||||
```
|
||||
```json
|
||||
...
|
||||
"avroBytesDecoder" : {
|
||||
"type" : "schema_registry",
|
||||
|
|
@ -909,7 +909,7 @@ Avro Bytes Decorder首先提取输入消息的 `subject` 和 `id`， 然后使
|
|||
| parseSpec | JSON对象 | 指定数据的时间戳和维度。格式必须为JSON。有关更多配置选项，请参阅 [JSON ParseSpec](#json)。请注意，不再支持timeAndDims parseSpec | 是 |
|
||||
|
||||
样例规范：
|
||||
```
|
||||
```json
|
||||
"parser": {
|
||||
"type": "protobuf",
|
||||
"descriptor": "file:///tmp/metrics.desc",
|
||||
|
|
@ -961,7 +961,7 @@ Avro Bytes Decorder首先提取输入消息的 `subject` 和 `id`， 然后使
|
|||
| flattenSpec | JSON对象 | 指定嵌套的JSON数据的展平配置，详情可见 [flattenSpec](#flattenspec) | 否 |
|
||||
|
||||
示例规范：
|
||||
```
|
||||
```json
|
||||
"parseSpec": {
|
||||
"format" : "json",
|
||||
"timestampSpec" : {
|
||||
|
|
@ -999,7 +999,7 @@ Avro Bytes Decorder首先提取输入消息的 `subject` 和 `id`， 然后使
|
|||
| columns | JSON数组 | 指定数据的列 | 是 |
|
||||
|
||||
示例规范：
|
||||
```
|
||||
```json
|
||||
"parseSpec": {
|
||||
"format" : "csv",
|
||||
"timestampSpec" : {
|
||||
|
|
@ -1038,7 +1038,7 @@ Avro Bytes Decorder首先提取输入消息的 `subject` 和 `id`， 然后使
|
|||
| columns | JSON数组 | 指定数据的列 | 是 |
|
||||
|
||||
示例规范：
|
||||
```
|
||||
```json
|
||||
"parseSpec": {
|
||||
"format" : "tsv",
|
||||
"timestampSpec" : {
|
||||
|
|
@ -1072,7 +1072,7 @@ Avro Bytes Decorder首先提取输入消息的 `subject` 和 `id`， 然后使
|
|||
JSON数据也可以包含多值维度。维度的多个值必须在接收的数据中格式化为 `JSON数组`，不需要额外的 `parseSpec` 配置。
|
||||
|
||||
#### 正则解析规范
|
||||
```
|
||||
```json
|
||||
"parseSpec":{
|
||||
"format" : "regex",
|
||||
"timestampSpec" : {
|
||||
|
|
@ -1089,7 +1089,7 @@ JSON数据也可以包含多值维度。维度的多个值必须在接收的数
|
|||
`columns` 字段必须以相同的顺序与regex匹配组的列匹配。如果未提供列，则默认列名称（“column_1”、“column2”、…”列“）将被分配, 确保列名包含所有维度
|
||||
|
||||
#### JavaScript解析规范
|
||||
```
|
||||
```json
|
||||
"parseSpec":{
|
||||
"format" : "javascript",
|
||||
"timestampSpec" : {
|
||||
|
|
|
|||
|
|
@ -5,13 +5,13 @@
|
|||
数据源的schema可以随时更改，Apache Druid支持不同段之间的有不同的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`，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
|
||||
|
|
@ -19,13 +19,13 @@ 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
|
||||
|
|
@ -39,7 +39,7 @@ foo_2015-01-03/2015-01-04_v1_2
|
|||
出于性能原因，有时将一组段压缩为一组较大但较少的段是有益的，因为在接收和查询路径中都存在一些段处理和内存开销。
|
||||
|
||||
压缩任务合并给定时间间隔内的所有段。语法为：
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type": "compact",
|
||||
"id": <task_id>,
|
||||
|
|
@ -66,7 +66,7 @@ foo_2015-01-03/2015-01-04_v1_2
|
|||
| `context` | [任务的上下文](taskrefer.md#上下文参数) | 否 |
|
||||
|
||||
一个压缩合并任务的示例如下：
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type" : "compact",
|
||||
"dataSource" : "wikipedia",
|
||||
|
|
@ -170,7 +170,7 @@ Druid支持永久的将标记为"unused"状态（详情可见架构设计中的
|
|||
### 杀死任务
|
||||
|
||||
**杀死任务**删除段的所有信息并将其从深层存储中删除。在Druid的段表中，要杀死的段必须是未使用的（used==0）。可用语法为：
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type": "kill",
|
||||
"id": <task_id>,
|
||||
|
|
|
|||
|
|
@ -92,7 +92,7 @@ Rollup由 `granularitySpec` 中的 `rollup` 配置项控制。 默认情况下
|
|||
|
||||
#### 最大化rollup比率
|
||||
通过比较Druid中的行数和接收的事件数，可以测量数据源的汇总率。这个数字越高，从汇总中获得的好处就越多。一种方法是使用[Druid SQL](../Querying/druidsql.md)查询，比如：
|
||||
```
|
||||
```json
|
||||
SELECT SUM("cnt") / COUNT(*) * 1.0 FROM datasource
|
||||
```
|
||||
|
||||
|
|
@ -163,7 +163,7 @@ Druid数据源总是按时间划分为*时间块*，每个时间块包含一个
|
|||
* [`tuningConfig`](#tuningconfig), 该部分控制着每一种[摄入方法](#摄入方式)的不同的特定调整参数
|
||||
|
||||
一个 `index_parallel` 类型任务的示例摄入规范如下：
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type": "index_parallel",
|
||||
"spec": {
|
||||
|
|
@ -230,7 +230,7 @@ Druid数据源总是按时间划分为*时间块*，每个时间块包含一个
|
|||
* [`数据源名称`](#datasource), [`主时间戳列`](#timestampspec), [`维度`](#dimensionspec), [`指标`](#metricsspec) 和 [`转换与过滤`](#transformspec)
|
||||
|
||||
一个 `dataSchema` 如下：
|
||||
```
|
||||
```json
|
||||
"dataSchema": {
|
||||
"dataSource": "wikipedia",
|
||||
"timestampSpec": {
|
||||
|
|
@ -261,12 +261,12 @@ Druid数据源总是按时间划分为*时间块*，每个时间块包含一个
|
|||
|
||||
##### `dataSource`
|
||||
`dataSource` 位于 `dataSchema` -> `dataSource` 中，简单的标识了数据将被写入的数据源的名称，示例如下：
|
||||
```
|
||||
```json
|
||||
"dataSource": "my-first-datasource"
|
||||
```
|
||||
##### `timestampSpec`
|
||||
`timestampSpec` 位于 `dataSchema` -> `timestampSpec` 中，用来配置 [主时间戳](#timestampspec), 示例如下：
|
||||
```
|
||||
```json
|
||||
"timestampSpec": {
|
||||
"column": "timestamp",
|
||||
"format": "auto"
|
||||
|
|
@ -315,7 +315,7 @@ Druid数据源总是按时间划分为*时间块*，每个时间块包含一个
|
|||
|
||||
##### `dimensionSpec`
|
||||
`dimensionsSpec` 位于 `dataSchema` -> `dimensionsSpec`, 用来配置维度。示例如下：
|
||||
```
|
||||
```json
|
||||
"dimensionsSpec" : {
|
||||
"dimensions": [
|
||||
"page",
|
||||
|
|
@ -370,7 +370,7 @@ Druid以两种可能的方式来解释 `dimensionsSpec` : *normal* 和 *schemale
|
|||
`metricsSpec` 位于 `dataSchema` -> `metricsSpec` 中，是一个在摄入阶段要应用的 [聚合器](../Querying/Aggregations.md) 列表。 在启用了 [rollup](#rollup) 时是很有用的，因为它将配置如何在摄入阶段进行聚合。
|
||||
|
||||
一个 `metricsSpec` 实例如下：
|
||||
```
|
||||
```json
|
||||
"metricsSpec": [
|
||||
{ "type": "count", "name": "count" },
|
||||
{ "type": "doubleSum", "name": "bytes_added_sum", "fieldName": "bytes_added" },
|
||||
|
|
@ -391,7 +391,7 @@ Druid以两种可能的方式来解释 `dimensionsSpec` : *normal* 和 *schemale
|
|||
除了 `rollup`, 这些操作都是基于 [主时间戳列](#主时间戳列)
|
||||
|
||||
一个 `granularitySpec` 实例如下：
|
||||
```
|
||||
```json
|
||||
"granularitySpec": {
|
||||
"segmentGranularity": "day",
|
||||
"queryGranularity": "none",
|
||||
|
|
@ -414,7 +414,7 @@ Druid以两种可能的方式来解释 `dimensionsSpec` : *normal* 和 *schemale
|
|||
|
||||
##### `transformSpec`
|
||||
`transformSpec` 位于 `dataSchema` -> `transformSpec`，用来摄取时转换和过滤输入数据。 一个 `transformSpec` 实例如下：
|
||||
```
|
||||
```json
|
||||
"transformSpec": {
|
||||
"transforms": [
|
||||
{ "type": "expression", "name": "countryUpper", "expression": "upper(country)" }
|
||||
|
|
@ -448,7 +448,7 @@ Druid以两种可能的方式来解释 `dimensionsSpec` : *normal* 和 *schemale
|
|||
|
||||
一个 `parser` 实例如下：
|
||||
|
||||
```
|
||||
```json
|
||||
"parser": {
|
||||
"type": "string",
|
||||
"parseSpec": {
|
||||
|
|
@ -479,7 +479,7 @@ Druid以两种可能的方式来解释 `dimensionsSpec` : *normal* 和 *schemale
|
|||
#### `ioConfig`
|
||||
|
||||
`ioConfig` 影响从源系统（如Apache Kafka、Amazon S3、挂载的文件系统或任何其他受支持的源系统）读取数据的方式。`inputFormat` 属性适用于除Hadoop摄取之外的[所有摄取方法](#摄入方式)。Hadoop摄取仍然使用过时的 `dataSchema` 中的 [parser]。`ioConfig` 的其余部分特定于每个单独的摄取方法。读取JSON数据的 `ioConfig` 示例如下：
|
||||
```
|
||||
```json
|
||||
"ioConfig": {
|
||||
"type": "<ingestion-method-specific type code>",
|
||||
"inputFormat": {
|
||||
|
|
@ -493,7 +493,7 @@ Druid以两种可能的方式来解释 `dimensionsSpec` : *normal* 和 *schemale
|
|||
#### `tuningConfig`
|
||||
|
||||
优化属性在 `tuningConfig` 中指定，`tuningConfig` 位于摄取规范的顶层。有些属性适用于所有摄取方法，但大多数属性特定于每个单独的摄取方法。`tuningConfig` 将所有共享的公共属性设置为默认值的示例如下：
|
||||
```
|
||||
```json
|
||||
"tuningConfig": {
|
||||
"type": "<ingestion-method-specific type code>",
|
||||
"maxRowsInMemory": 1000000,
|
||||
|
|
|
|||
|
|
@ -16,12 +16,12 @@ Kafka索引服务支持在Overlord上配置*supervisors*，supervisors通过管
|
|||
|
||||
Kafka索引服务需要同时在Overlord和MiddleManagers中加载 `druid-kafka-indexing-service` 扩展。 用于一个数据源的supervisor通过向 `http://<OVERLORD_IP>:<OVERLORD_PORT>/druid/indexer/v1/supervisor` 发送一个HTTP POST请求来启动，例如：
|
||||
|
||||
```
|
||||
```json
|
||||
curl -X POST -H 'Content-Type: application/json' -d @supervisor-spec.json http://localhost:8090/druid/indexer/v1/supervisor
|
||||
```
|
||||
|
||||
一个示例supervisor规范如下：
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type": "kafka",
|
||||
"dataSchema": {
|
||||
|
|
@ -264,7 +264,7 @@ Kafka索引任务运行在MiddleManager上，因此，其受限于MiddleManager
|
|||
|
||||
读取任务的数量由 `replicas` 和 `taskCount` 控制。 一般， 一共有 `replicas * taskCount` 个读取任务， 存在一个例外是当 taskCount > {numKafkaPartitions}, 在这种情况时 {numKafkaPartitions}个任务将被使用。 当 `taskDuration` 结束时，这些任务将被转换为发布状态并创建 `replicas * taskCount` 个新的读取任务。 因此，为了使得读取任务和发布任务可以并发的运行， 最小的容量应该是：
|
||||
|
||||
```
|
||||
```json
|
||||
workerCapacity = 2 * replicas * taskCount
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -97,12 +97,12 @@ Druid schema必须始终包含一个主时间戳, 主时间戳用于对数据进
|
|||
#### 嵌套维度
|
||||
|
||||
在编写本文时，Druid不支持嵌套维度。嵌套维度需要展平，例如，如果您有以下数据：
|
||||
```
|
||||
```json
|
||||
{"foo":{"bar": 3}}
|
||||
```
|
||||
|
||||
然后在编制索引之前，应将其转换为：
|
||||
```
|
||||
```json
|
||||
{"foo_bar": 3}
|
||||
```
|
||||
|
||||
|
|
@ -115,7 +115,7 @@ Druid能够将JSON、Avro或Parquet输入数据展平化。请阅读 [展平规
|
|||
在这种情况下，可以使用*摄取时*的计数聚合器来计算事件数。但是，需要注意的是，在查询此Metrics时，应该使用 `longSum` 聚合器。查询时的 `count` 聚合器将返回时间间隔的Druid行数，该行数可用于确定rollup比率。
|
||||
|
||||
为了举例说明，如果摄取规范包含：
|
||||
```
|
||||
```json
|
||||
...
|
||||
"metricsSpec" : [
|
||||
{
|
||||
|
|
@ -126,7 +126,7 @@ Druid能够将JSON、Avro或Parquet输入数据展平化。请阅读 [展平规
|
|||
```
|
||||
|
||||
您应该使用查询:
|
||||
```
|
||||
```json
|
||||
...
|
||||
"aggregations": [
|
||||
{ "type": "longSum", "name": "numIngestedEvents", "fieldName": "count" },
|
||||
|
|
@ -144,11 +144,11 @@ Druid能够将JSON、Avro或Parquet输入数据展平化。请阅读 [展平规
|
|||
一个具有唯一ID的工作流能够对特定ID进行过滤，同时仍然能够对ID列进行快速的唯一计数。如果不使用无schema维度，则通过将Metric的 `name` 设置为与维度不同的值来支持此场景。如果使用无schema维度，这里的最佳实践是将同一列包含两次，一次作为维度，一次作为 `hyperUnique` Metric。这可能涉及到ETL时的一些工作。
|
||||
|
||||
例如，对于无schema维度，请重复同一列：
|
||||
```
|
||||
```json
|
||||
{"device_id_dim":123, "device_id_met":123}
|
||||
```
|
||||
同时在 `metricsSpec` 中包含：
|
||||
```
|
||||
```json
|
||||
{ "type" : "hyperUnique", "name" : "devices", "fieldName" : "device_id_met" }
|
||||
```
|
||||
`device_id_dim` 将自动作为维度来被选取
|
||||
|
|
@ -12,7 +12,7 @@
|
|||
在分布式的Druid集群中，Broker是一个查询的路由进程。Broker了解所有已经发布到ZooKeeper的元数据，了解在哪些进程存在哪些段，然后将查询路由到以便它们可以正确命中的进程。Broker还将来自所有单个进程的结果集合并在一起。在启动时，Historical会在Zookeeper中注册它们自身以及它们所服务的段。
|
||||
|
||||
### 运行
|
||||
```
|
||||
```json
|
||||
org.apache.druid.cli.Main server broker
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Druid Coordinator定期运行，每次运行之间的时间是一个可配置的
|
|||
在Historical进程为任何未分配的段提供服务之前，首先按容量对每个层的可用Historical进程进行排序，最小容量的服务器具有最高优先级。未分配的段总是分配给具有最小能力的进程，以保持进程之间的平衡级别。在为Historical进程分配新段时，Coordinator不直接与该进程通信；而是在ZK中的Historical进程加载队列路径下创建有关该新段的一些临时信息。一旦看到此请求，Historical进程将加载段并开始为其提供服务。
|
||||
|
||||
### 运行
|
||||
```
|
||||
```json
|
||||
org.apache.druid.cli.Main server coordinator
|
||||
```
|
||||
### 规则
|
||||
|
|
|
|||
|
|
@ -94,12 +94,12 @@ Druid数据被存储在"datasources"中，类似于传统RDBMS中的表。每一
|
|||
|
||||
例如这个一个段标识符，数据源为 `clarity-cloud0`, 时间块为 `2018-05-21T16:00:00.000Z/2018-05-21T17:00:00.000Z`, 版本为 `2018-05-21T15:56:09.909Z` 以及分区编号为 `1`:
|
||||
|
||||
```
|
||||
```json
|
||||
clarity-cloud0_2018-05-21T16:00:00.000Z_2018-05-21T17:00:00.000Z_2018-05-21T15:56:09.909Z_1
|
||||
```
|
||||
分区号为0的段（块中的第一个分区）忽略分区号，如下例所示，该段与上一个时间块位于同一时间块中，但分区号为0而不是1：
|
||||
|
||||
```
|
||||
```json
|
||||
clarity-cloud0_2018-05-21T16:00:00.000Z_2018-05-21T17:00:00.000Z_2018-05-21T15:56:09.909Z
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
Historical的API列表，请参见 [Historical API](../Operations/api.md#Historical)
|
||||
|
||||
### 运行
|
||||
```
|
||||
```json
|
||||
org.apache.druid.cli.Main server historical
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Apache Druid索引器进程是MiddleManager + Peon任务执行系统的另一种
|
|||
Indexer进程与[MiddleManager](../Operations/api.md#MiddleManager)共用API
|
||||
|
||||
### 运行
|
||||
```
|
||||
```json
|
||||
org.apache.druid.cli.Main server indexer
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Derby是Druid的默认元数据存储，但是它不适合生产环境。[MySQL]
|
|||
|
||||
将以下内容添加到您的Druid配置中：
|
||||
|
||||
```
|
||||
```json
|
||||
druid.metadata.storage.type=derby
|
||||
druid.metadata.storage.connector.connectURI=jdbc:derby://localhost:1527//opt/var/druid_state/derby;create=true
|
||||
```
|
||||
|
|
@ -32,7 +32,7 @@ druid.metadata.storage.connector.connectURI=jdbc:derby://localhost:1527//opt/var
|
|||
|
||||
支持的属性示例：
|
||||
|
||||
```
|
||||
```json
|
||||
druid.metadata.storage.connector.dbcp.maxConnLifetimeMillis=1200000
|
||||
druid.metadata.storage.connector.dbcp.defaultQueryTimeout=30000
|
||||
```
|
||||
|
|
@ -50,7 +50,7 @@ druid.metadata.storage.connector.dbcp.defaultQueryTimeout=30000
|
|||
|
||||
`payload` 列存储一个JSON blob，该blob包含该段的所有元数据（存储在该payload中的某些数据与表中的某些列是冗余的，这是有意的）, 信息如下：
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"dataSource":"wikipedia",
|
||||
"interval":"2012-05-23T00:00:00.000Z/2012-05-24T00:00:00.000Z",
|
||||
|
|
|
|||
|
|
@ -10,6 +10,6 @@
|
|||
MiddleManager进程是执行提交的任务的工作进程。MiddleManager将任务转发给运行在不同jvm中的Peon。我们为每个任务设置单独的jvm的原因是为了隔离资源和日志。每个Peon一次只能运行一个任务，但是，一个MiddleManager可能有多个Peon。
|
||||
|
||||
### 运行
|
||||
```
|
||||
```json
|
||||
org.apache.druid.cli.Main server middleManager
|
||||
```
|
||||
|
|
@ -17,7 +17,7 @@ Druid Overlord公开了一个web GUI，用于管理任务和worker。有关详
|
|||
如果一个MiddleManager的任务失败超过阈值，Overlord会将这些MiddleManager列入黑名单。不超过20%的MiddleManager可以被列入黑名单，被列入黑名单的MiddleManager将定期被列入白名单。
|
||||
|
||||
以下变量可用于设置阈值和黑名单超时：
|
||||
```
|
||||
```json
|
||||
druid.indexer.runner.maxRetriesBeforeBlacklist
|
||||
druid.indexer.runner.workerBlackListBackoffTime
|
||||
druid.indexer.runner.workerBlackListCleanupPeriod
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Peon在单个JVM中运行单个任务。MiddleManager负责创建运行任务的
|
|||
### 运行
|
||||
Peon应该很少独立于MiddleManager，除非出于开发目的。
|
||||
|
||||
```
|
||||
```json
|
||||
org.apache.druid.cli.Main internal peon <task_file> <status_file>
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Apache Druid Router用于将查询路由到不同的Broker。默认情况下，B
|
|||
|
||||
### 运行
|
||||
|
||||
```
|
||||
```json
|
||||
org.apache.druid.cli.Main server router
|
||||
```
|
||||
|
||||
|
|
@ -32,7 +32,7 @@ Router可以配置为将转发请求到活跃的Coordinator和Overlord。 该功
|
|||
|
||||
要启用此功能，请在Router的 `runtime.properties` 中设置以下内容：
|
||||
|
||||
```
|
||||
```json
|
||||
druid.router.managementProxy.enabled=true
|
||||
```
|
||||
|
||||
|
|
@ -55,7 +55,7 @@ druid.router.managementProxy.enabled=true
|
|||
Router有一个可配置的策略列表，用于选择将查询路由到哪个Broker。策略的顺序很重要，因为一旦策略条件匹配，就会选择一个Broker。
|
||||
|
||||
**timeBoundary**
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type":"timeBoundary"
|
||||
}
|
||||
|
|
@ -64,7 +64,7 @@ Router有一个可配置的策略列表，用于选择将查询路由到哪个Br
|
|||
包含这个策略的话意味着所有的 **timeRange** 查询将全部路由到高优先级的Broker
|
||||
|
||||
**priority**
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type":"priority",
|
||||
"minPriority":0,
|
||||
|
|
@ -78,7 +78,7 @@ Router有一个可配置的策略列表，用于选择将查询路由到哪个Br
|
|||
允许使用JavaScript函数定义任意路由规则。将配置和要执行的查询传递给函数，并返回它应该路由到的层（tier），或者对于默认层返回null。
|
||||
|
||||
示例：将包含三个以上聚合器的查询发送到最低优先级Broker的函数：
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type" : "javascript",
|
||||
"function" : "function (config, query) { if (query.getAggregatorSpecs && query.getAggregatorSpecs().size() >= 3) { var size = config.getTierToBrokerMap().values().size(); if (size > 0) { return config.getTierToBrokerMap().values().toArray()[size-1] } else { return config.getDefaultBrokerServiceName() } } else { return null } }"
|
||||
|
|
@ -122,7 +122,7 @@ druid.router.avatica.balancer.type=consistentHash
|
|||
|
||||
JVM设置：
|
||||
|
||||
```
|
||||
```json
|
||||
-server
|
||||
-Xmx13g
|
||||
-Xms13g
|
||||
|
|
@ -144,7 +144,7 @@ JVM设置：
|
|||
```
|
||||
|
||||
Runtime.properties:
|
||||
```
|
||||
```json
|
||||
druid.host=#{IP_ADDR}:8080
|
||||
druid.plaintextPort=8080
|
||||
druid.service=druid/router
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ dimension列是不同的，因为它们支持过滤和聚合操作，所以每
|
|||
|
||||
要具体了解这些数据结构，请考虑上面示例数据中的"page"列,表示此维度的三个数据结构如下图所示：
|
||||
|
||||
```
|
||||
```json
|
||||
1: Dictionary that encodes column values
|
||||
{
|
||||
"Justin Bieber": 0,
|
||||
|
|
@ -44,7 +44,7 @@ dimension列是不同的，因为它们支持过滤和聚合操作，所以每
|
|||
|
||||
如果数据源使用多值列，那么段文件中的数据结构看起来有点不同。让我们假设在上面的例子中，第二行同时标记了"Ke$ha"和"Justin Bieber"主题。在这种情况下，这三种数据结构现在看起来如下：
|
||||
|
||||
```
|
||||
```json
|
||||
1: Dictionary that encodes column values
|
||||
{
|
||||
"Justin Bieber": 0,
|
||||
|
|
@ -131,7 +131,7 @@ dimension列是不同的，因为它们支持过滤和聚合操作，所以每
|
|||
|
||||
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
|
||||
|
|
@ -139,7 +139,7 @@ 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
|
||||
|
|
@ -149,7 +149,7 @@ Druid批量索引任务（基于Hadoop或基于IndexTask）保证了间隔内的
|
|||
|
||||
请注意，跨越多个段间隔的更新在每个间隔内都是原子的, 但是在整个更新过程中它们不是原子的。例如，您有如下段：
|
||||
|
||||
```
|
||||
```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
|
||||
|
|
@ -157,7 +157,7 @@ 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
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Apache Druid使用[Apache ZooKeeper](http://zookeeper.apache.org/) 来管理整
|
|||
### Coordinator Leader选举
|
||||
|
||||
我们使用 **Curator LeadershipLatch** 进行Leader选举：
|
||||
```
|
||||
```json
|
||||
${druid.zk.paths.coordinatorPath}/_COORDINATOR
|
||||
```
|
||||
|
||||
|
|
@ -21,17 +21,17 @@ ${druid.zk.paths.coordinatorPath}/_COORDINATOR
|
|||
`announcementsPath` 和 `servedSegmentsPath` 这两个参数用于这个功能。
|
||||
|
||||
所有的 [Historical](Historical.md) 进程都将它们自身发布到 `announcementsPath`, 具体来说它们将在以下路径创建一个临时的ZNODE：
|
||||
```
|
||||
```json
|
||||
${druid.zk.paths.announcementsPath}/${druid.host}
|
||||
```
|
||||
|
||||
这意味着Historical节点可用。它们也将随后创建一个ZNODE:
|
||||
```
|
||||
```json
|
||||
${druid.zk.paths.servedSegmentsPath}/${druid.host}
|
||||
```
|
||||
|
||||
当它们加载段时，它们将在以下路径附着的一个临时的ZNODE：
|
||||
```
|
||||
```json
|
||||
${druid.zk.paths.servedSegmentsPath}/${druid.host}/_segment_identifier_
|
||||
```
|
||||
|
||||
|
|
@ -42,7 +42,7 @@ ${druid.zk.paths.servedSegmentsPath}/${druid.host}/_segment_identifier_
|
|||
|
||||
当 [Coordiantor](Coordinator.md) 决定一个 [Historical](Historical.md) 进程应该加载或删除一个段时，它会将一个临时znode写到:
|
||||
|
||||
```
|
||||
```json
|
||||
${druid.zk.paths.loadQueuePath}/_host_of_historical_process/_segment_identifier
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Druid安装包提供了几个[单服务器配置](./chapter-3.md)的示例，以
|
|||
|
||||
在终端中运行以下命令来提取Druid
|
||||
|
||||
```
|
||||
```json
|
||||
tar -xzf apache-druid-0.17.0-bin.tar.gz
|
||||
cd apache-druid-0.17.0
|
||||
```
|
||||
|
|
@ -49,12 +49,12 @@ cd apache-druid-0.17.0
|
|||
|
||||
在`apache-druid-0.17.0`安装包的根目录下执行命令：
|
||||
|
||||
```
|
||||
```json
|
||||
./bin/start-micro-quickstart
|
||||
```
|
||||
然后将在本地计算机上启动Zookeeper和Druid服务实例，例如：
|
||||
|
||||
```
|
||||
```json
|
||||
$ ./bin/start-micro-quickstart
|
||||
[Fri May 3 11:40:50 2019] Running command[zk], logging to[/apache-druid-0.17.0/var/sv/zk.log]: bin/run-zk conf
|
||||
[Fri May 3 11:40:50 2019] Running command[coordinator-overlord], logging to[/apache-druid-0.17.0/var/sv/coordinator-overlord.log]: bin/run-druid coordinator-overlord conf/druid/single-server/micro-quickstart
|
||||
|
|
@ -103,7 +103,7 @@ $ ./bin/start-micro-quickstart
|
|||
* regionName
|
||||
* user
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"timestamp":"2015-09-12T20:03:45.018Z",
|
||||
"channel":"#en.wikipedia",
|
||||
|
|
|
|||
|
|
@ -173,7 +173,7 @@ Druid依赖于分布式文件系统或大对象（blob）存储来存储数据
|
|||
|
||||
上述操作之后，您将看到以下的变化：
|
||||
|
||||
```
|
||||
```json
|
||||
druid.extensions.loadList=["druid-s3-extensions"]
|
||||
|
||||
#druid.storage.type=local
|
||||
|
|
@ -204,7 +204,7 @@ druid.indexer.logs.s3Prefix=druid/indexing-logs
|
|||
|
||||
上述操作之后，您将看到以下的变化：
|
||||
|
||||
```
|
||||
```json
|
||||
druid.extensions.loadList=["druid-hdfs-storage"]
|
||||
|
||||
#druid.storage.type=local
|
||||
|
|
@ -261,7 +261,7 @@ druid.indexer.logs.directory=/druid/indexing-logs
|
|||
|
||||
Historical（单服务器）
|
||||
|
||||
```
|
||||
```json
|
||||
druid.processing.buffer.sizeBytes=500000000
|
||||
druid.processing.numMergeBuffers=8
|
||||
druid.processing.numThreads=31
|
||||
|
|
@ -269,7 +269,7 @@ druid.processing.numThreads=31
|
|||
|
||||
MiddleManager（单服务器）
|
||||
|
||||
```
|
||||
```json
|
||||
druid.worker.capacity=8
|
||||
druid.indexer.fork.property.druid.processing.numMergeBuffers=2
|
||||
druid.indexer.fork.property.druid.processing.buffer.sizeBytes=100000000
|
||||
|
|
@ -295,7 +295,7 @@ MiddleManager:
|
|||
|
||||
新的Historical(2 Data服务器)
|
||||
|
||||
```
|
||||
```json
|
||||
druid.processing.buffer.sizeBytes=500000000
|
||||
druid.processing.numMergeBuffers=8
|
||||
druid.processing.numThreads=31
|
||||
|
|
@ -303,7 +303,7 @@ MiddleManager:
|
|||
|
||||
新的MiddleManager（2 Data服务器）
|
||||
|
||||
```
|
||||
```json
|
||||
druid.worker.capacity=4
|
||||
druid.indexer.fork.property.druid.processing.numMergeBuffers=2
|
||||
druid.indexer.fork.property.druid.processing.buffer.sizeBytes=100000000
|
||||
|
|
@ -356,21 +356,21 @@ druid.indexer.fork.property.druid.processing.numThreads=1
|
|||
|
||||
如果您一直在本地计算机上编辑配置，则可以使用rsync复制它们：
|
||||
|
||||
```
|
||||
```json
|
||||
rsync -az apache-druid-0.17.0/ MASTER_SERVER:apache-druid-0.17.0/
|
||||
```
|
||||
|
||||
#### 不带Zookeeper启动
|
||||
|
||||
在发行版根目录中，运行以下命令以启动Master服务：
|
||||
```
|
||||
```json
|
||||
bin/start-cluster-master-no-zk-server
|
||||
```
|
||||
|
||||
#### 带Zookeeper启动
|
||||
|
||||
如果计划在Master服务器上运行ZK，请首先更新`conf/zoo.cfg`以标识您计划如何运行ZK，然后，您可以使用以下命令与ZK一起启动Master服务进程：
|
||||
```
|
||||
```json
|
||||
bin/start-cluster-master-with-zk-server
|
||||
```
|
||||
|
||||
|
|
@ -382,7 +382,7 @@ bin/start-cluster-master-with-zk-server
|
|||
将Druid发行版和您编辑的配置文件复制到您的Data服务器。
|
||||
|
||||
在发行版根目录中，运行以下命令以启动Data服务：
|
||||
```
|
||||
```json
|
||||
bin/start-cluster-data-server
|
||||
```
|
||||
|
||||
|
|
@ -396,7 +396,7 @@ bin/start-cluster-data-server
|
|||
|
||||
在发行版根目录中，运行以下命令以启动Query服务：
|
||||
|
||||
```
|
||||
```json
|
||||
bin/start-cluster-query-server
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ Druid的体系结构需要一个主时间列（内部存储为名为__time的列
|
|||
|
||||
Druid的安装包中在 `quickstart/tutorial/wikipedia-index.json` 文件中包含了一个本地批摄入任务规范的示例。 为了方便我们在这里展示出来，该规范已经配置好读取 `quickstart/tutorial/wikiticker-2015-09-12-sampled.json.gz` 输入文件。
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type" : "index_parallel",
|
||||
"spec" : {
|
||||
|
|
@ -168,12 +168,12 @@ Druid的安装包中在 `quickstart/tutorial/wikipedia-index.json` 文件中包
|
|||
|
||||
在Druid根目录运行以下命令：
|
||||
|
||||
```
|
||||
```json
|
||||
bin/post-index-task --file quickstart/tutorial/wikipedia-index.json --url http://localhost:8081
|
||||
```
|
||||
可以看到以下的输出：
|
||||
|
||||
```
|
||||
```json
|
||||
Beginning indexing data for wikipedia
|
||||
Task started: index_wikipedia_2018-07-27T06:37:44.323Z
|
||||
Task log: http://localhost:8081/druid/indexer/v1/task/index_wikipedia_2018-07-27T06:37:44.323Z/log
|
||||
|
|
@ -192,11 +192,11 @@ wikipedia loading complete! You may now query your data
|
|||
|
||||
要提交任务，可以在一个新的终端中通过以下方式提交任务到Druid：
|
||||
|
||||
```
|
||||
```json
|
||||
curl -X 'POST' -H 'Content-Type:application/json' -d @quickstart/tutorial/wikipedia-index.json http://localhost:8081/druid/indexer/v1/task
|
||||
```
|
||||
当任务提交成功后会打印出来任务的ID
|
||||
```
|
||||
```json
|
||||
{"task":"index_wikipedia_2018-06-09T21:30:32.802Z"}
|
||||
```
|
||||
您可以如上所述从控制台监视此任务的状态
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@
|
|||
* `bytes`: 传输的字节数
|
||||
* `cost`: 发送流量的成本
|
||||
|
||||
```
|
||||
```json
|
||||
{"ts":"2018-01-01T01:01:35Z","srcIP":"1.1.1.1", "dstIP":"2.2.2.2", "srcPort":2000, "dstPort":3000, "protocol": 6, "packets":10, "bytes":1000, "cost": 1.4}
|
||||
{"ts":"2018-01-01T01:01:51Z","srcIP":"1.1.1.1", "dstIP":"2.2.2.2", "srcPort":2000, "dstPort":3000, "protocol": 6, "packets":20, "bytes":2000, "cost": 3.1}
|
||||
{"ts":"2018-01-01T01:01:59Z","srcIP":"1.1.1.1", "dstIP":"2.2.2.2", "srcPort":2000, "dstPort":3000, "protocol": 6, "packets":30, "bytes":3000, "cost": 0.4}
|
||||
|
|
@ -46,7 +46,7 @@ Druid摄取规范中最核心的元素是 `dataSchema`。 `dataSchema` 定义了
|
|||
|
||||
在 `quickstart/` 中创建一个名为 `insertion-tutorial-index.json` 的新文件，其中包含以下内容：
|
||||
|
||||
```
|
||||
```json
|
||||
"dataSchema" : {}
|
||||
```
|
||||
|
||||
|
|
@ -55,7 +55,7 @@ Druid摄取规范中最核心的元素是 `dataSchema`。 `dataSchema` 定义了
|
|||
#### 数据源名称
|
||||
|
||||
数据源的名称通过 `dataSource` 字段来在 `dataSchema` 中被指定：
|
||||
```
|
||||
```json
|
||||
"dataSchema" : {
|
||||
"dataSource" : "ingestion-tutorial",
|
||||
}
|
||||
|
|
@ -68,7 +68,7 @@ Druid摄取规范中最核心的元素是 `dataSchema`。 `dataSchema` 定义了
|
|||
`dataSchema` 需要知道如何从输入数据中提取主时间戳字段。
|
||||
|
||||
输入数据中的timestamp列名为"ts"，包含ISO 8601时间戳，因此让我们将包含该信息的 `timestampSpec` 添加到 `dataSchema`：
|
||||
```
|
||||
```json
|
||||
"dataSchema" : {
|
||||
"dataSource" : "ingestion-tutorial",
|
||||
"timestampSpec" : {
|
||||
|
|
@ -95,7 +95,7 @@ Druid支持以下列类型：String、Long、Float和Double。我们将在下面
|
|||
|
||||
对于本教程，让我们启用rollup。这是用 `dataSchema` 上`granularitySpec` 指定的。
|
||||
|
||||
```
|
||||
```json
|
||||
"dataSchema" : {
|
||||
"dataSource" : "ingestion-tutorial",
|
||||
"timestampSpec" : {
|
||||
|
|
@ -122,7 +122,7 @@ Druid支持以下列类型：String、Long、Float和Double。我们将在下面
|
|||
|
||||
在 `dataSchema` 中使用 `dimensionSpec` 指定维度。
|
||||
|
||||
```
|
||||
```json
|
||||
"dataSchema" : {
|
||||
"dataSource" : "ingestion-tutorial",
|
||||
"timestampSpec" : {
|
||||
|
|
@ -163,7 +163,7 @@ Druid支持以下列类型：String、Long、Float和Double。我们将在下面
|
|||
|
||||
在 `dataSchema` 中使用 `metricsSpec` 来指定metrics
|
||||
|
||||
```
|
||||
```json
|
||||
"dataSchema" : {
|
||||
"dataSource" : "ingestion-tutorial",
|
||||
"timestampSpec" : {
|
||||
|
|
@ -201,7 +201,7 @@ Druid支持以下列类型：String、Long、Float和Double。我们将在下面
|
|||
#### No Rollup
|
||||
|
||||
如果我们没使用rollup，所有的列都将在 `dimensionsSpec` 中指定：
|
||||
```
|
||||
```json
|
||||
"dimensionsSpec" : {
|
||||
"dimensions": [
|
||||
"srcIP",
|
||||
|
|
@ -228,7 +228,7 @@ Druid支持以下列类型：String、Long、Float和Double。我们将在下面
|
|||
**段粒度**
|
||||
|
||||
段粒度由 `granularitySpec` 中的 `SegmentGranularity` 属性配置。对于本教程，我们将创建小时段：
|
||||
```
|
||||
```json
|
||||
"dataSchema" : {
|
||||
"dataSource" : "ingestion-tutorial",
|
||||
"timestampSpec" : {
|
||||
|
|
@ -261,7 +261,7 @@ Druid支持以下列类型：String、Long、Float和Double。我们将在下面
|
|||
|
||||
**查询粒度**
|
||||
查询粒度由 `granularitySpec` 中的 `queryGranularity` 属性配置。对于本教程，我们使用分钟粒度：
|
||||
```
|
||||
```json
|
||||
"dataSchema" : {
|
||||
"dataSource" : "ingestion-tutorial",
|
||||
"timestampSpec" : {
|
||||
|
|
@ -292,11 +292,11 @@ Druid支持以下列类型：String、Long、Float和Double。我们将在下面
|
|||
}
|
||||
```
|
||||
要查看查询粒度的影响，让我们从原始输入数据中查看这一行
|
||||
```
|
||||
```json
|
||||
{"ts":"2018-01-01T01:03:29Z","srcIP":"1.1.1.1", "dstIP":"2.2.2.2", "srcPort":5000, "dstPort":7000, "protocol": 6, "packets":60, "bytes":6000, "cost": 4.3}
|
||||
```
|
||||
当这一行以分钟查询粒度摄取时，Druid会将该行的时间戳设置为分钟桶：
|
||||
```
|
||||
```json
|
||||
{"ts":"2018-01-01T01:03:00Z","srcIP":"1.1.1.1", "dstIP":"2.2.2.2", "srcPort":5000, "dstPort":7000, "protocol": 6, "packets":60, "bytes":6000, "cost": 4.3}
|
||||
```
|
||||
|
||||
|
|
@ -305,7 +305,7 @@ Druid支持以下列类型：String、Long、Float和Double。我们将在下面
|
|||
对于批处理任务，需要定义时间间隔。时间戳超出时间间隔的输入行将不会被接收。
|
||||
|
||||
时间间隔指定在 `granularitySpec` 配置项中：
|
||||
```
|
||||
```json
|
||||
"dataSchema" : {
|
||||
"dataSource" : "ingestion-tutorial",
|
||||
"timestampSpec" : {
|
||||
|
|
@ -342,7 +342,7 @@ Druid支持以下列类型：String、Long、Float和Double。我们将在下面
|
|||
我们现在已经完成了 `dataSchema` 的定义。剩下的步骤是将我们创建的数据模式放入一个摄取任务规范中，并指定输入源。
|
||||
|
||||
`dataSchema` 在所有任务类型之间共享，但每个任务类型都有自己的规范格式。对于本教程，我们将使用本机批处理摄取任务：
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type" : "index_parallel",
|
||||
"spec" : {
|
||||
|
|
@ -382,7 +382,7 @@ Druid支持以下列类型：String、Long、Float和Double。我们将在下面
|
|||
|
||||
现在让我们定义输入源，它在 `ioConfig` 对象中指定。每个任务类型都有自己的 `ioConfig` 类型。要读取输入数据，我们需要指定一个`inputSource`。我们前面保存的示例网络流数据需要从本地文件中读取，该文件配置如下：
|
||||
|
||||
```
|
||||
```json
|
||||
"ioConfig" : {
|
||||
"type" : "index_parallel",
|
||||
"inputSource" : {
|
||||
|
|
@ -395,7 +395,7 @@ Druid支持以下列类型：String、Long、Float和Double。我们将在下面
|
|||
|
||||
#### 定义数据格式
|
||||
因为我们的输入数据为JSON字符串，我们使用json的 `inputFormat`:
|
||||
```
|
||||
```json
|
||||
"ioConfig" : {
|
||||
"type" : "index_parallel",
|
||||
"inputSource" : {
|
||||
|
|
@ -408,7 +408,7 @@ Druid支持以下列类型：String、Long、Float和Double。我们将在下面
|
|||
}
|
||||
}
|
||||
```
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type" : "index_parallel",
|
||||
"spec" : {
|
||||
|
|
@ -460,7 +460,7 @@ Druid支持以下列类型：String、Long、Float和Double。我们将在下面
|
|||
每一个摄入任务都有一个 `tuningConfig` 部分，该部分允许用户可以调整不同的摄入参数
|
||||
|
||||
例如，我们添加一个 `tuningConfig`，它为本地批处理摄取任务设置目标段大小：
|
||||
```
|
||||
```json
|
||||
"tuningConfig" : {
|
||||
"type" : "index_parallel",
|
||||
"maxRowsPerSegment" : 5000000
|
||||
|
|
@ -470,7 +470,7 @@ Druid支持以下列类型：String、Long、Float和Double。我们将在下面
|
|||
|
||||
### 最终形成的规范
|
||||
我们已经定义了摄取规范，现在应该如下所示：
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type" : "index_parallel",
|
||||
"spec" : {
|
||||
|
|
@ -524,7 +524,7 @@ Druid支持以下列类型：String、Long、Float和Double。我们将在下面
|
|||
|
||||
### 提交任务和查询数据
|
||||
在根目录运行以下命令：
|
||||
```
|
||||
```json
|
||||
bin/post-index-task --file quickstart/ingestion-tutorial-index.json --url http://localhost:8081
|
||||
```
|
||||
|
||||
|
|
@ -532,7 +532,7 @@ bin/post-index-task --file quickstart/ingestion-tutorial-index.json --url http:/
|
|||
|
||||
运行 `bin/dsql` 中运行 `select * from "ingestion-tutorial"` 查询我们摄入什么样的数据
|
||||
|
||||
```
|
||||
```json
|
||||
$ bin/dsql
|
||||
Welcome to dsql, the command-line client for Druid SQL.
|
||||
Type "\h" for help.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
|
||||
我们在 `quickstart/tutorial/transform-data.json` 中包括了样例数据，为了方便我们展示一下：
|
||||
|
||||
```
|
||||
```json
|
||||
{"timestamp":"2018-01-01T07:01:35Z","animal":"octopus", "location":1, "number":100}
|
||||
{"timestamp":"2018-01-01T05:01:35Z","animal":"mongoose", "location":2,"number":200}
|
||||
{"timestamp":"2018-01-01T06:01:35Z","animal":"snake", "location":3, "number":300}
|
||||
|
|
@ -21,7 +21,7 @@
|
|||
|
||||
### 使用转换规范加载数据
|
||||
我们将使用以下规范摄取示例数据，该规范演示了转换规范的使用：
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type" : "index_parallel",
|
||||
"spec" : {
|
||||
|
|
@ -104,14 +104,14 @@
|
|||
这个过滤器选择前3行，它将排除输入数据中的最后一个"lion"行。请注意，过滤器是在转换之后应用的。
|
||||
|
||||
现在提交位于 `quickstart/tutorial/transform-index.json` 的任务：
|
||||
```
|
||||
```json
|
||||
bin/post-index-task --file quickstart/tutorial/transform-index.json --url http://localhost:8081
|
||||
```
|
||||
|
||||
### 查询已转换的数据
|
||||
|
||||
运行 `bin/dsql` 提交 `select * from "transform-tutorial"` 查询来看摄入的数据：
|
||||
```
|
||||
```json
|
||||
dsql> select * from "transform-tutorial";
|
||||
┌──────────────────────────┬────────────────┬───────┬──────────┬────────┬───────────────┐
|
||||
│ __time │ animal │ count │ location │ number │ triple-number │
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Druid创建了必要的子文件夹，以便在这个新创建的文件夹下存
|
|||
在 `conf/druid/common/common.runtime.properties` 中编辑`common.runtime.properties` 以包含HDFS属性,用于该位置的文件夹与上面示例中使用的文件夹相同
|
||||
|
||||
#### common.runtime.properties
|
||||
```
|
||||
```json
|
||||
# Deep storage
|
||||
#
|
||||
# For HDFS:
|
||||
|
|
@ -41,7 +41,7 @@ druid.indexer.logs.directory=/druid/indexing-logs
|
|||
|
||||
同时，需要在 `conf/druid/_common/common/common.runtime.properties` 中增加hdfs-storage核心扩展：
|
||||
|
||||
```
|
||||
```json
|
||||
#
|
||||
# Extensions
|
||||
#
|
||||
|
|
@ -65,12 +65,12 @@ druid.extensions.loadList=["mysql-metadata-storage", "druid-hdfs-storage", "drui
|
|||
|
||||
编辑 `conf/druid/_common/common.runtime.properties` 增加下列属性：
|
||||
|
||||
```
|
||||
```json
|
||||
druid.hadoop.security.kerberos.principal
|
||||
druid.hadoop.security.kerberos.keytab
|
||||
```
|
||||
例如：
|
||||
```
|
||||
```json
|
||||
druid.hadoop.security.kerberos.principal=hdfs-test@EXAMPLE.IO
|
||||
druid.hadoop.security.kerberos.keytab=/etc/security/keytabs/hdfs.headless.keytab
|
||||
```
|
||||
|
|
|
|||
|
|
@ -11,20 +11,20 @@
|
|||
|
||||
[Apache Kafka](http://kafka.apache.org/)是一种高吞吐量消息总线，可与Druid很好地配合使用。在本教程中，我们将使用Kafka2.1.0。要下载Kafka，请在终端中执行以下命令：
|
||||
|
||||
```
|
||||
```json
|
||||
curl -O https://archive.apache.org/dist/kafka/2.1.0/kafka_2.12-2.1.0.tgz
|
||||
tar -xzf kafka_2.12-2.1.0.tgz
|
||||
cd kafka_2.12-2.1.0
|
||||
```
|
||||
通过在终端中运行以下命令来启动一个Kafka Broker：
|
||||
|
||||
```
|
||||
```json
|
||||
./bin/kafka-server-start.sh config/server.properties
|
||||
```
|
||||
|
||||
执行以下命令来创建一个我们用来发送数据的Kafka主题，称为"*wikipedia*":
|
||||
|
||||
```
|
||||
```json
|
||||
./bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic wikipedia
|
||||
```
|
||||
|
||||
|
|
@ -33,13 +33,13 @@ cd kafka_2.12-2.1.0
|
|||
让我们为该主题启动一个生产者并发送一些数据
|
||||
|
||||
在Druid目录下，运行下边的命令：
|
||||
```
|
||||
```json
|
||||
cd quickstart/tutorial
|
||||
gunzip -c wikiticker-2015-09-12-sampled.json.gz > wikiticker-2015-09-12-sampled.json
|
||||
```
|
||||
|
||||
在Kafka目录下，运行以下命令，{PATH_TO_DRUID}替换为Druid目录的路径：
|
||||
```
|
||||
```json
|
||||
export KAFKA_OPTS="-Dfile.encoding=UTF-8"
|
||||
./bin/kafka-console-producer.sh --broker-list localhost:9092 --topic wikipedia < {PATH_TO_DRUID}/quickstart/tutorial/wikiticker-2015-09-12-sampled.json
|
||||
```
|
||||
|
|
@ -131,7 +131,7 @@ Druid的体系结构需要一个主时间列（内部存储为名为__time的列
|
|||
|
||||
粘贴以下规范后点击 `Submit`
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type": "kafka",
|
||||
"spec" : {
|
||||
|
|
@ -198,7 +198,7 @@ Druid的体系结构需要一个主时间列（内部存储为名为__time的列
|
|||
|
||||
为了直接启动服务，我们可以在Druid的根目录下运行以下命令来提交一个supervisor规范到Druid Overlord中
|
||||
|
||||
```
|
||||
```json
|
||||
curl -XPOST -H'Content-Type: application/json' -d @quickstart/tutorial/wikipedia-kafka-supervisor.json http://localhost:8081/druid/indexer/v1/supervisor
|
||||
```
|
||||
如果supervisor被成功创建后，将会返回一个supervisor的ID，在本例中看到的是 `{"id":"wikipedia"}`
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Docker安装完成后，请继续执行本教程中的后续步骤
|
|||
|
||||
从apache-druid-0.17.0软件包根目录中，运行以下命令以构建名为"druid-hadoop-demo"的Docker镜像，其版本标签为"2.8.5"：
|
||||
|
||||
```
|
||||
```json
|
||||
cd quickstart/tutorial/hadoop/docker
|
||||
docker build -t druid-hadoop-demo:2.8.5 .
|
||||
```
|
||||
|
|
@ -32,7 +32,7 @@ docker build -t druid-hadoop-demo:2.8.5 .
|
|||
|
||||
我们在 `/tmp` 下创建一些文件夹，稍后我们在启动Hadoop容器时会使用到它们：
|
||||
|
||||
```
|
||||
```json
|
||||
mkdir -p /tmp/shared
|
||||
mkdir -p /tmp/shared/hadoop_xml
|
||||
```
|
||||
|
|
@ -40,19 +40,19 @@ mkdir -p /tmp/shared/hadoop_xml
|
|||
#### 配置 /etc/hosts
|
||||
|
||||
在主机的 `/etc/hosts` 中增加以下入口：
|
||||
```
|
||||
```json
|
||||
127.0.0.1 druid-hadoop-demo
|
||||
```
|
||||
#### 启动Hadoop容器
|
||||
在 `/tmp/shared` 文件夹被创建和 `/etc/hosts` 入口被添加后，运行以下命令来启动Hadoop容器：
|
||||
|
||||
```
|
||||
```json
|
||||
docker run -it -h druid-hadoop-demo --name druid-hadoop-demo -p 2049:2049 -p 2122:2122 -p 8020:8020 -p 8021:8021 -p 8030:8030 -p 8031:8031 -p 8032:8032 -p 8033:8033 -p 8040:8040 -p 8042:8042 -p 8088:8088 -p 8443:8443 -p 9000:9000 -p 10020:10020 -p 19888:19888 -p 34455:34455 -p 49707:49707 -p 50010:50010 -p 50020:50020 -p 50030:50030 -p 50060:50060 -p 50070:50070 -p 50075:50075 -p 50090:50090 -p 51111:51111 -v /tmp/shared:/shared druid-hadoop-demo:2.8.5 /etc/bootstrap.sh -bash
|
||||
```
|
||||
|
||||
容器启动后，您的终端将连接到容器内运行的bash shell：
|
||||
|
||||
```
|
||||
```json
|
||||
Starting sshd: [ OK ]
|
||||
18/07/26 17:27:15 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
|
||||
Starting namenodes on [druid-hadoop-demo]
|
||||
|
|
@ -72,7 +72,7 @@ bash-4.1#
|
|||
##### 进入Hadoop容器shell
|
||||
|
||||
运行下边命令打开Hadoop容器的另一个shell：
|
||||
```
|
||||
```json
|
||||
docker exec -it druid-hadoop-demo bash
|
||||
```
|
||||
|
||||
|
|
@ -80,7 +80,7 @@ docker exec -it druid-hadoop-demo bash
|
|||
|
||||
从apache-druid-0.17.0安装包的根目录拷贝 `quickstart/tutorial/wikiticker-2015-09-12-sampled.json.gz` 样例数据到共享文件夹
|
||||
|
||||
```
|
||||
```json
|
||||
cp quickstart/tutorial/wikiticker-2015-09-12-sampled.json.gz /tmp/shared/wikiticker-2015-09-12-sampled.json.gz
|
||||
```
|
||||
|
||||
|
|
@ -88,7 +88,7 @@ cp quickstart/tutorial/wikiticker-2015-09-12-sampled.json.gz /tmp/shared/wikitic
|
|||
|
||||
在Hadoop容器shell中，运行以下命令来设置本次教程需要的HDFS目录，同时拷贝输入数据到HDFS上：
|
||||
|
||||
```
|
||||
```json
|
||||
cd /usr/local/hadoop/bin
|
||||
./hdfs dfs -mkdir /druid
|
||||
./hdfs dfs -mkdir /druid/segments
|
||||
|
|
@ -109,13 +109,13 @@ cd /usr/local/hadoop/bin
|
|||
#### 拷贝Hadoop配置到Druid classpath
|
||||
|
||||
从Hadoop容器shell中，运行以下命令将Hadoop.xml配置文件拷贝到共享文件夹中：
|
||||
```
|
||||
```json
|
||||
cp /usr/local/hadoop/etc/hadoop/*.xml /shared/hadoop_xml
|
||||
```
|
||||
|
||||
在宿主机上运行下边命令，其中{PATH_TO_DRUID}替换为Druid软件包的路径：
|
||||
|
||||
```
|
||||
```json
|
||||
mkdir -p {PATH_TO_DRUID}/conf/druid/single-server/micro-quickstart/_common/hadoop-xml
|
||||
cp /tmp/shared/hadoop_xml/*.xml {PATH_TO_DRUID}/conf/druid/single-server/micro-quickstart/_common/hadoop-xml/
|
||||
```
|
||||
|
|
@ -124,7 +124,7 @@ cp /tmp/shared/hadoop_xml/*.xml {PATH_TO_DRUID}/conf/druid/single-server/micro-q
|
|||
在常用的文本编辑器中，打开 `conf/druid/single-server/micro-quickstart/_common/common.runtime.properties` 文件做如下修改：
|
||||
|
||||
**禁用本地深度存储，启用HDFS深度存储**
|
||||
```
|
||||
```json
|
||||
#
|
||||
# Deep storage
|
||||
#
|
||||
|
|
@ -138,7 +138,7 @@ druid.storage.type=hdfs
|
|||
druid.storage.storageDirectory=/druid/segments
|
||||
```
|
||||
**禁用本地日志存储，启动HDFS日志存储**
|
||||
```
|
||||
```json
|
||||
#
|
||||
# Indexing service logs
|
||||
#
|
||||
|
|
@ -164,7 +164,7 @@ Hadoop.xml文件拷贝到Druid集群、段和日志存储配置更新为HDFS后
|
|||
要将数据加载到Druid中，可以提交指向该文件的*摄取任务*。我们已经包含了一个任务，该任务会加载存档中包含 `wikiticker-2015-09-12-sampled.json.gz`文件。
|
||||
|
||||
通过以下命令进行提交 `wikipedia-index-hadoop.json` 任务：
|
||||
```
|
||||
```json
|
||||
bin/post-index-task --file quickstart/tutorial/wikipedia-index-hadoop.json --url http://localhost:8081
|
||||
```
|
||||
|
||||
|
|
@ -184,7 +184,7 @@ bin/post-index-task --file quickstart/tutorial/wikipedia-index-hadoop.json --url
|
|||
这是必需的，因为其他摄取教程将写入相同的"wikipedia"数据源，并且以后的教程希望集群使用本地深度存储。
|
||||
|
||||
恢复配置示例：
|
||||
```
|
||||
```json
|
||||
#
|
||||
# Deep storage
|
||||
#
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Druid支持SQL查询。
|
|||
|
||||
该查询检索了2015年9月12日被编辑最多的10个维基百科页面
|
||||
|
||||
```
|
||||
```json
|
||||
SELECT page, COUNT(*) AS Edits
|
||||
FROM wikipedia
|
||||
WHERE TIMESTAMP '2015-09-12 00:00:00' <= "__time" AND "__time" < TIMESTAMP '2015-09-13 00:00:00'
|
||||
|
|
@ -52,14 +52,14 @@ LIMIT 10
|
|||
为方便起见，Druid软件包中包括了一个SQL命令行客户端，位于Druid根目录中的 `bin/dsql`
|
||||
|
||||
运行 `bin/dsql`, 可以看到如下：
|
||||
```
|
||||
```json
|
||||
Welcome to dsql, the command-line client for Druid SQL.
|
||||
Type "\h" for help.
|
||||
dsql>
|
||||
```
|
||||
将SQl粘贴到 `dsql` 中提交查询：
|
||||
|
||||
```
|
||||
```json
|
||||
dsql> SELECT page, COUNT(*) AS Edits FROM wikipedia WHERE "__time" BETWEEN TIMESTAMP '2015-09-12 00:00:00' AND TIMESTAMP '2015-09-13 00:00:00' GROUP BY page ORDER BY Edits DESC LIMIT 10;
|
||||
┌──────────────────────────────────────────────────────────┬───────┐
|
||||
│ page │ Edits │
|
||||
|
|
@ -84,12 +84,12 @@ SQL查询作为JSON通过HTTP提交
|
|||
|
||||
教程包括一个示例文件, 该文件`quickstart/tutorial/wikipedia-top-pages-sql.json`包含上面显示的SQL查询, 我们将该查询提交给Druid Broker。
|
||||
|
||||
```
|
||||
```json
|
||||
curl -X 'POST' -H 'Content-Type:application/json' -d @quickstart/tutorial/wikipedia-top-pages-sql.json http://localhost:8888/druid/v2/sql
|
||||
```
|
||||
结果返回如下：
|
||||
|
||||
```
|
||||
```json
|
||||
[
|
||||
{
|
||||
"page": "Wikipedia:Vandalismusmeldung",
|
||||
|
|
@ -140,7 +140,7 @@ curl -X 'POST' -H 'Content-Type:application/json' -d @quickstart/tutorial/wikipe
|
|||
|
||||
**时间查询**
|
||||
|
||||
```
|
||||
```json
|
||||
SELECT FLOOR(__time to HOUR) AS HourTime, SUM(deleted) AS LinesDeleted
|
||||
FROM wikipedia WHERE "__time" BETWEEN TIMESTAMP '2015-09-12 00:00:00' AND TIMESTAMP '2015-09-13 00:00:00'
|
||||
GROUP BY 1
|
||||
|
|
@ -150,7 +150,7 @@ GROUP BY 1
|
|||
|
||||
**聚合查询**
|
||||
|
||||
```
|
||||
```json
|
||||
SELECT channel, page, SUM(added)
|
||||
FROM wikipedia WHERE "__time" BETWEEN TIMESTAMP '2015-09-12 00:00:00' AND TIMESTAMP '2015-09-13 00:00:00'
|
||||
GROUP BY channel, page
|
||||
|
|
@ -161,7 +161,7 @@ ORDER BY SUM(added) DESC
|
|||
|
||||
**查询原始数据**
|
||||
|
||||
```
|
||||
```json
|
||||
SELECT user, page
|
||||
FROM wikipedia WHERE "__time" BETWEEN TIMESTAMP '2015-09-12 02:00:00' AND TIMESTAMP '2015-09-12 03:00:00'
|
||||
LIMIT 5
|
||||
|
|
@ -181,7 +181,7 @@ Druid SQL能够解释给定查询的查询计划, 在控制台中，可以通过
|
|||
|
||||
`EXPLAIN PLAN FOR SELECT page, COUNT(*) AS Edits FROM wikipedia WHERE "__time" BETWEEN TIMESTAMP '2015-09-12 00:00:00' AND TIMESTAMP '2015-09-13 00:00:00' GROUP BY page ORDER BY Edits DESC LIMIT 10;`
|
||||
|
||||
```
|
||||
```json
|
||||
dsql> EXPLAIN PLAN FOR SELECT page, COUNT(*) AS Edits FROM wikipedia WHERE "__time" BETWEEN TIMESTAMP '2015-09-12 00:00:00' AND TIMESTAMP '2015-09-13 00:00:00' GROUP BY page ORDER BY Edits DESC LIMIT 10;
|
||||
┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ PLAN │
|
||||
|
|
@ -201,7 +201,7 @@ Druid的原生查询格式以JSON表示。
|
|||
|
||||
这是一个查询，可检索2015-09-12上具有最多页面编辑量的10个wikipedia页面。
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"queryType" : "topN",
|
||||
"dataSource" : "wikipedia",
|
||||
|
|
@ -228,13 +228,13 @@ Druid的原生查询格式以JSON表示。
|
|||
|
||||
提交该查询到Druid：
|
||||
|
||||
```
|
||||
```json
|
||||
curl -X 'POST' -H 'Content-Type:application/json' -d @quickstart/tutorial/wikipedia-top-pages.json http://localhost:8888/druid/v2?pretty
|
||||
```
|
||||
|
||||
您可以看到如下的查询结果：
|
||||
|
||||
```
|
||||
```json
|
||||
[ {
|
||||
"timestamp" : "2015-09-12T00:46:58.771Z",
|
||||
"result" : [ {
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Apache Druid可以通过roll-up在数据摄取阶段对原始数据进行汇总
|
|||
|
||||
对于本教程，我们将使用一个网络流事件数据的小样本，表示在特定时间内从源到目标IP地址的流量的数据包和字节计数。
|
||||
|
||||
```
|
||||
```json
|
||||
{"timestamp":"2018-01-01T01:01:35Z","srcIP":"1.1.1.1", "dstIP":"2.2.2.2","packets":20,"bytes":9024}
|
||||
{"timestamp":"2018-01-01T01:01:51Z","srcIP":"1.1.1.1", "dstIP":"2.2.2.2","packets":255,"bytes":21133}
|
||||
{"timestamp":"2018-01-01T01:01:59Z","srcIP":"1.1.1.1", "dstIP":"2.2.2.2","packets":11,"bytes":5780}
|
||||
|
|
@ -29,7 +29,7 @@ Apache Druid可以通过roll-up在数据摄取阶段对原始数据进行汇总
|
|||
|
||||
我们将使用 `quickstart/tutorial/rollup-index.json` 的摄入数据规范来摄取数据
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type" : "index_parallel",
|
||||
"spec" : {
|
||||
|
|
@ -89,7 +89,7 @@ Apache Druid可以通过roll-up在数据摄取阶段对原始数据进行汇总
|
|||
|
||||
在Druid的根目录下运行以下命令：
|
||||
|
||||
```
|
||||
```json
|
||||
bin/post-index-task --file quickstart/tutorial/rollup-index.json --url http://localhost:8081
|
||||
```
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ bin/post-index-task --file quickstart/tutorial/rollup-index.json --url http://lo
|
|||
|
||||
现在运行 `bin/dsql` 然后执行查询 `select * from "rollup-tutorial";` 来查看已经被摄入的数据。
|
||||
|
||||
```
|
||||
```json
|
||||
$ bin/dsql
|
||||
Welcome to dsql, the command-line client for Druid SQL.
|
||||
Type "\h" for help.
|
||||
|
|
@ -120,14 +120,14 @@ dsql>
|
|||
|
||||
我们来看发生在 `2018-01-01T01:01` 的三条原始数据：
|
||||
|
||||
```
|
||||
```json
|
||||
{"timestamp":"2018-01-01T01:01:35Z","srcIP":"1.1.1.1", "dstIP":"2.2.2.2","packets":20,"bytes":9024}
|
||||
{"timestamp":"2018-01-01T01:01:51Z","srcIP":"1.1.1.1", "dstIP":"2.2.2.2","packets":255,"bytes":21133}
|
||||
{"timestamp":"2018-01-01T01:01:59Z","srcIP":"1.1.1.1", "dstIP":"2.2.2.2","packets":11,"bytes":5780}
|
||||
```
|
||||
这三条数据已经被roll up为以下一行数据：
|
||||
|
||||
```
|
||||
```json
|
||||
┌──────────────────────────┬────────┬───────┬─────────┬─────────┬─────────┐
|
||||
│ __time │ bytes │ count │ dstIP │ packets │ srcIP │
|
||||
├──────────────────────────┼────────┼───────┼─────────┼─────────┼─────────┤
|
||||
|
|
@ -140,11 +140,11 @@ dsql>
|
|||
在进行分组之前，原始输入数据的时间戳按分钟进行标记/布局，这是由于摄取规范中的 `"queryGranularity"："minute"` 设置造成的。
|
||||
同样，`2018-01-01T01:02` 期间发生的这两起事件也已经汇总。
|
||||
|
||||
```
|
||||
```json
|
||||
{"timestamp":"2018-01-01T01:02:14Z","srcIP":"1.1.1.1", "dstIP":"2.2.2.2","packets":38,"bytes":6289}
|
||||
{"timestamp":"2018-01-01T01:02:29Z","srcIP":"1.1.1.1", "dstIP":"2.2.2.2","packets":377,"bytes":359971}
|
||||
```
|
||||
```
|
||||
```json
|
||||
┌──────────────────────────┬────────┬───────┬─────────┬─────────┬─────────┐
|
||||
│ __time │ bytes │ count │ dstIP │ packets │ srcIP │
|
||||
├──────────────────────────┼────────┼───────┼─────────┼─────────┼─────────┤
|
||||
|
|
@ -154,10 +154,10 @@ dsql>
|
|||
|
||||
对于记录1.1.1.1和2.2.2.2之间流量的最后一个事件没有发生汇总，因为这是 `2018-01-01T01:03` 期间发生的唯一事件
|
||||
|
||||
```
|
||||
```json
|
||||
{"timestamp":"2018-01-01T01:03:29Z","srcIP":"1.1.1.1", "dstIP":"2.2.2.2","packets":49,"bytes":10204}
|
||||
```
|
||||
```
|
||||
```json
|
||||
┌──────────────────────────┬────────┬───────┬─────────┬─────────┬─────────┐
|
||||
│ __time │ bytes │ count │ dstIP │ packets │ srcIP │
|
||||
├──────────────────────────┼────────┼───────┼─────────┼─────────┼─────────┤
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@
|
|||
|
||||
数据摄取规范位于 `quickstart/tutorial/retention-index.json`, 提交这个规范，将创建一个名称为 `retention-tutorial` 的数据源
|
||||
|
||||
```
|
||||
```json
|
||||
bin/post-index-task --file quickstart/tutorial/retention-index.json --url http://localhost:8081
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -15,12 +15,12 @@
|
|||
本节教程使用的任务摄取规范位于 `quickstart/tutorial/updates-init-index.json`, 本规范从 `quickstart/tutorial/updates-data.json` 输入文件创建一个名称为 `updates-tutorial` 的数据源
|
||||
|
||||
提交任务：
|
||||
```
|
||||
```json
|
||||
bin/post-index-task --file quickstart/tutorial/updates-init-index.json --url http://localhost:8081
|
||||
```
|
||||
|
||||
我们有三个包含"动物"维度和"数字"指标的初始行：
|
||||
```
|
||||
```json
|
||||
dsql> select * from "updates-tutorial";
|
||||
┌──────────────────────────┬──────────┬───────┬────────┐
|
||||
│ __time │ animal │ count │ number │
|
||||
|
|
@ -40,13 +40,13 @@ Retrieved 3 rows in 1.42s.
|
|||
注意，此任务从 `quickstart/tutorial/updates-data2.json` 读取输入，`appendToExisting` 设置为false（表示这是一个覆盖）
|
||||
|
||||
提交任务：
|
||||
```
|
||||
```json
|
||||
bin/post-index-task --file quickstart/tutorial/updates-overwrite-index.json --url http://localhost:8081
|
||||
```
|
||||
|
||||
当Druid从这个覆盖任务加载完新的段时，"tiger"行现在有了值"lion"，"aardvark"行有了不同的编号，"giraffe"行已经被替换。更改可能需要几分钟才能生效：
|
||||
|
||||
```
|
||||
```json
|
||||
dsql> select * from "updates-tutorial";
|
||||
┌──────────────────────────┬──────────┬───────┬────────┐
|
||||
│ __time │ animal │ count │ number │
|
||||
|
|
@ -65,12 +65,12 @@ Retrieved 3 rows in 0.02s.
|
|||
`quickstart/tutorial/updates-append-index.json` 任务规范配置为从现有的 `updates-tutorial` 数据源和 `quickstart/tutorial/updates-data3.json` 文件读取数据，该任务将组合来自两个输入源的数据，然后用新的组合数据覆盖原始数据。
|
||||
|
||||
提交任务：
|
||||
```
|
||||
```json
|
||||
bin/post-index-task --file quickstart/tutorial/updates-append-index.json --url http://localhost:8081
|
||||
```
|
||||
|
||||
当Druid完成从这个覆盖任务加载新段时，新行将被添加到数据源中。请注意，“Lion”行发生了roll up：
|
||||
```
|
||||
```json
|
||||
dsql> select * from "updates-tutorial";
|
||||
┌──────────────────────────┬──────────┬───────┬────────┐
|
||||
│ __time │ animal │ count │ number │
|
||||
|
|
@ -92,13 +92,13 @@ Retrieved 6 rows in 0.02s.
|
|||
`quickstart/tutorial/updates-append-index2.json` 任务规范从 `quickstart/tutorial/updates-data4.json` 文件读取数据，然后追加到 `updates-tutorial` 数据源。注意到在规范中 `appendToExisting` 设置为 `true`
|
||||
|
||||
提交任务：
|
||||
```
|
||||
```json
|
||||
bin/post-index-task --file quickstart/tutorial/updates-append-index2.json --url http://localhost:8081
|
||||
```
|
||||
|
||||
加载新数据后，我们可以看到"octopus"后面额外的两行。请注意，编号为222的新"bear"行尚未与现有的bear-111行合并，因为新数据保存在单独的段中。
|
||||
|
||||
```
|
||||
```json
|
||||
dsql> select * from "updates-tutorial";
|
||||
┌──────────────────────────┬──────────┬───────┬────────┐
|
||||
│ __time │ animal │ count │ number │
|
||||
|
|
@ -117,7 +117,7 @@ Retrieved 8 rows in 0.02s.
|
|||
|
||||
当我们执行一个GroupBy查询而非 `Select *`, 我们看到"beer"行将在查询时聚合在一起：
|
||||
|
||||
```
|
||||
```json
|
||||
dsql> select __time, animal, SUM("count"), SUM("number") from "updates-tutorial" group by __time, animal;
|
||||
┌──────────────────────────┬──────────┬────────┬────────┐
|
||||
│ __time │ animal │ EXPR$2 │ EXPR$3 │
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
|
||||
数据摄取规范位于 `quickstart/tutorial/compaction-init-index.json` ,提交这个任务规范将创建一个名称为 `compaction-tutorial` 的数据源：
|
||||
|
||||
```
|
||||
```json
|
||||
bin/post-index-task --file quickstart/tutorial/compaction-init-index.json --url http://localhost:8081
|
||||
```
|
||||
|
||||
|
|
@ -35,7 +35,7 @@ bin/post-index-task --file quickstart/tutorial/compaction-init-index.json --url
|
|||
|
||||
对该数据源执行一个 `COUNT(*)` 查询可以看到39244行数据：
|
||||
|
||||
```
|
||||
```json
|
||||
dsql> select count(*) from "compaction-tutorial";
|
||||
┌────────┐
|
||||
│ EXPR$0 │
|
||||
|
|
@ -51,7 +51,7 @@ Retrieved 1 row in 1.38s.
|
|||
|
||||
在 `quickstart/tutorial/compaction-keep-granularity.json` 文件中我们包含了一个本教程数据源的合并任务规范。
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type": "compact",
|
||||
"dataSource": "compaction-tutorial",
|
||||
|
|
@ -71,7 +71,7 @@ Retrieved 1 row in 1.38s.
|
|||
在本教程示例中，每小时只创建一个合并段，因为每小时的行数少于5000000 `maxRowsPerSegment`（请注意，行总数为39244）。
|
||||
|
||||
现在提交这个任务：
|
||||
```
|
||||
```json
|
||||
bin/post-index-task --file quickstart/tutorial/compaction-keep-granularity.json --url http://localhost:8081
|
||||
```
|
||||
|
||||
|
|
@ -87,7 +87,7 @@ bin/post-index-task --file quickstart/tutorial/compaction-keep-granularity.json
|
|||
新的合并段比原来的段有一个更新的版本，所以即使两组段都显示在Druid控制台中，查询也只能从新的合并段中读取。
|
||||
|
||||
我们再次在 `compaction-tutorial` 数据源执行 `COUNT(*)` 查询可以看到，行数仍然是39244:
|
||||
```
|
||||
```json
|
||||
dsql> select count(*) from "compaction-tutorial";
|
||||
┌────────┐
|
||||
│ EXPR$0 │
|
||||
|
|
@ -108,7 +108,7 @@ Coordinator运行至少15分钟后，"Segments"视图应显示有24个分段，
|
|||
|
||||
我们在 `quickstart/tutorial/compaction-day-granularity.json` 文件中包含了一个可以创建 `DAY` 粒度的合并任务摄取规范：
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"type": "compact",
|
||||
"dataSource": "compaction-tutorial",
|
||||
|
|
@ -126,7 +126,7 @@ Coordinator运行至少15分钟后，"Segments"视图应显示有24个分段，
|
|||
请注意这个合并任务规范中 `segmentGranularity` 配置项设置为了 `DAY`
|
||||
|
||||
现在提交这个任务：
|
||||
```
|
||||
```json
|
||||
bin/post-index-task --file quickstart/tutorial/compaction-day-granularity.json --url http://localhost:8081
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
这份规范位于 `quickstart/tutorial/deletion-index.json`, 它将创建一个名称为 `deletion-tutorial` 的数据源
|
||||
|
||||
现在加载这份初始数据：
|
||||
```
|
||||
```json
|
||||
bin/post-index-task --file quickstart/tutorial/deletion-index.json --url http://localhost:8081
|
||||
```
|
||||
当加载完成后，在浏览器中访问[http://localhost:8888/unified-console.html#datasources](http://localhost:8888/unified-console.html#datasources)
|
||||
|
|
@ -29,7 +29,7 @@ bin/post-index-task --file quickstart/tutorial/deletion-index.json --url http://
|
|||
|
||||
让我们在指定的时间间隔内禁用段。这会将间隔中的所有段标记为"未使用"，但不会将它们从深层存储中移除。让我们禁用间隔 `2015-09-12T18:00:00.000Z/2015-09-12T20:00:00.000Z`中的段，即在18到20小时之间
|
||||
|
||||
```
|
||||
```json
|
||||
curl -X 'POST' -H 'Content-Type:application/json' -d '{ "interval" : "2015-09-12T18:00:00.000Z/2015-09-12T20:00:00.000Z" }' http://localhost:8081/druid/coordinator/v1/datasources/deletion-tutorial/markUnused
|
||||
```
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ curl -X 'POST' -H 'Content-Type:application/json' -d '{ "interval" : "2015-09-12
|
|||
|
||||
请注意，第18小时和第19小时的数据段仍在深层存储中:
|
||||
|
||||
```
|
||||
```json
|
||||
$ ls -l1 var/druid/segments/deletion-tutorial/
|
||||
2015-09-12T00:00:00.000Z_2015-09-12T01:00:00.000Z
|
||||
2015-09-12T01:00:00.000Z_2015-09-12T02:00:00.000Z
|
||||
|
|
@ -76,7 +76,7 @@ $ ls -l1 var/druid/segments/deletion-tutorial/
|
|||
信息框的顶部显示完整的段ID，例如 `deletion-tutorial_2015-09-12T14:00:00.000Z_2015-09-12T15:00:00.000Z_2019-02-28T01:11:51.606Z`，第14小时的段。
|
||||
|
||||
让我们向Coordinator发送一个POST请求来禁用13点和14点的段
|
||||
```
|
||||
```json
|
||||
{
|
||||
"segmentIds":
|
||||
[
|
||||
|
|
@ -88,7 +88,7 @@ $ ls -l1 var/druid/segments/deletion-tutorial/
|
|||
|
||||
json文件位于 `curl -X 'POST' -H 'Content-Type:application/json' -d @quickstart/tutorial/deletion-disable-segments.json http://localhost:8081/druid/coordinator/v1/datasources/deletion-tutorial/markUnused` , 如下向Coordinator提交一个POST请求：
|
||||
|
||||
```
|
||||
```json
|
||||
curl -X 'POST' -H 'Content-Type:application/json' -d @quickstart/tutorial/deletion-disable-segments.json http://localhost:8081/druid/coordinator/v1/datasources/deletion-tutorial/markUnused
|
||||
```
|
||||
|
||||
|
|
@ -97,7 +97,7 @@ curl -X 'POST' -H 'Content-Type:application/json' -d @quickstart/tutorial/deleti
|
|||
|
||||
注意到这时13时和14时的段仍然在深度存储中：
|
||||
|
||||
```
|
||||
```json
|
||||
$ ls -l1 var/druid/segments/deletion-tutorial/
|
||||
2015-09-12T00:00:00.000Z_2015-09-12T01:00:00.000Z
|
||||
2015-09-12T01:00:00.000Z_2015-09-12T02:00:00.000Z
|
||||
|
|
@ -130,12 +130,12 @@ $ ls -l1 var/druid/segments/deletion-tutorial/
|
|||
现在我们已经禁用了一些段，我们可以提交一个Kill任务，它将从元数据和深层存储中删除禁用的段。
|
||||
|
||||
在 `quickstart/tutorial/deletion-kill.json` 提供了一个Kill任务的规范，通过以下的命令将任务提交到Overlord：
|
||||
```
|
||||
```json
|
||||
curl -X 'POST' -H 'Content-Type:application/json' -d @quickstart/tutorial/deletion-kill.json http://localhost:8081/druid/indexer/v1/task
|
||||
```
|
||||
任务执行完成后，可以看到已经禁用的段已经被从深度存储中移除了：
|
||||
|
||||
```
|
||||
```json
|
||||
$ ls -l1 var/druid/segments/deletion-tutorial/
|
||||
2015-09-12T12:00:00.000Z_2015-09-12T13:00:00.000Z
|
||||
2015-09-12T15:00:00.000Z_2015-09-12T16:00:00.000Z
|
||||
|
|
|
|||
Loading…
Reference in New Issue