From 20995e2262357101d2d1e344b9155dea58da6628 Mon Sep 17 00:00:00 2001 From: liujianhuan Date: Sat, 16 May 2020 15:57:49 +0800 Subject: [PATCH] quota to json --- DataIngestion/dataformats.md | 56 +++++++++++++++++------------------ DataIngestion/datamanage.md | 14 ++++----- DataIngestion/ingestion.md | 24 +++++++-------- DataIngestion/kafka.md | 6 ++-- DataIngestion/schemadesign.md | 12 ++++---- Design/Broker.md | 2 +- Design/Coordinator.md | 2 +- Design/Design.md | 4 +-- Design/Historical.md | 2 +- Design/Indexer.md | 2 +- Design/Metadata.md | 6 ++-- Design/MiddleManager.md | 2 +- Design/Overlord.md | 2 +- Design/Peons.md | 2 +- Design/Router.md | 14 ++++----- Design/Segments.md | 12 ++++---- Design/Zookeeper.md | 10 +++---- GettingStarted/chapter-2.md | 8 ++--- GettingStarted/chapter-4.md | 22 +++++++------- Tutorials/chapter-1.md | 10 +++---- Tutorials/chapter-10.md | 42 +++++++++++++------------- Tutorials/chapter-11.md | 8 ++--- Tutorials/chapter-12.md | 8 ++--- Tutorials/chapter-2.md | 14 ++++----- Tutorials/chapter-3.md | 28 +++++++++--------- Tutorials/chapter-4.md | 24 +++++++-------- Tutorials/chapter-5.md | 20 ++++++------- Tutorials/chapter-6.md | 2 +- Tutorials/chapter-7.md | 18 +++++------ Tutorials/chapter-8.md | 14 ++++----- Tutorials/chapter-9.md | 16 +++++----- 31 files changed, 203 insertions(+), 203 deletions(-) diff --git a/DataIngestion/dataformats.md b/DataIngestion/dataformats.md index 2031e86..0046dc7 100644 --- a/DataIngestion/dataformats.md +++ b/DataIngestion/dataformats.md @@ -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" : { diff --git a/DataIngestion/datamanage.md b/DataIngestion/datamanage.md index 310a984..6a30657 100644 --- a/DataIngestion/datamanage.md +++ b/DataIngestion/datamanage.md @@ -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": , @@ -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": , diff --git a/DataIngestion/ingestion.md b/DataIngestion/ingestion.md index f656647..073f5f9 100644 --- a/DataIngestion/ingestion.md +++ b/DataIngestion/ingestion.md @@ -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": "", "inputFormat": { @@ -493,7 +493,7 @@ Druid以两种可能的方式来解释 `dimensionsSpec` : *normal* 和 *schemale #### `tuningConfig` 优化属性在 `tuningConfig` 中指定，`tuningConfig` 位于摄取规范的顶层。有些属性适用于所有摄取方法，但大多数属性特定于每个单独的摄取方法。`tuningConfig` 将所有共享的公共属性设置为默认值的示例如下： -``` +```json "tuningConfig": { "type": "", "maxRowsInMemory": 1000000, diff --git a/DataIngestion/kafka.md b/DataIngestion/kafka.md index 4de7576..3f721b6 100644 --- a/DataIngestion/kafka.md +++ b/DataIngestion/kafka.md @@ -16,12 +16,12 @@ Kafka索引服务支持在Overlord上配置*supervisors*，supervisors通过管 Kafka索引服务需要同时在Overlord和MiddleManagers中加载 `druid-kafka-indexing-service` 扩展。 用于一个数据源的supervisor通过向 `http://:/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 ``` diff --git a/DataIngestion/schemadesign.md b/DataIngestion/schemadesign.md index 3ef8725..9e2c9ed 100644 --- a/DataIngestion/schemadesign.md +++ b/DataIngestion/schemadesign.md @@ -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` 将自动作为维度来被选取 \ No newline at end of file diff --git a/Design/Broker.md b/Design/Broker.md index 8ce4ed1..4046047 100644 --- a/Design/Broker.md +++ b/Design/Broker.md @@ -12,7 +12,7 @@ 在分布式的Druid集群中，Broker是一个查询的路由进程。Broker了解所有已经发布到ZooKeeper的元数据，了解在哪些进程存在哪些段，然后将查询路由到以便它们可以正确命中的进程。Broker还将来自所有单个进程的结果集合并在一起。在启动时，Historical会在Zookeeper中注册它们自身以及它们所服务的段。 ### 运行 -``` +```json org.apache.druid.cli.Main server broker ``` diff --git a/Design/Coordinator.md b/Design/Coordinator.md index acd8490..375f37b 100644 --- a/Design/Coordinator.md +++ b/Design/Coordinator.md @@ -14,7 +14,7 @@ Druid Coordinator定期运行，每次运行之间的时间是一个可配置的 在Historical进程为任何未分配的段提供服务之前，首先按容量对每个层的可用Historical进程进行排序，最小容量的服务器具有最高优先级。未分配的段总是分配给具有最小能力的进程，以保持进程之间的平衡级别。在为Historical进程分配新段时，Coordinator不直接与该进程通信；而是在ZK中的Historical进程加载队列路径下创建有关该新段的一些临时信息。一旦看到此请求，Historical进程将加载段并开始为其提供服务。 ### 运行 -``` +```json org.apache.druid.cli.Main server coordinator ``` ### 规则 diff --git a/Design/Design.md b/Design/Design.md index bc14be9..ae9982e 100644 --- a/Design/Design.md +++ b/Design/Design.md @@ -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 ``` diff --git a/Design/Historical.md b/Design/Historical.md index 79a5b00..e9b66db 100644 --- a/Design/Historical.md +++ b/Design/Historical.md @@ -8,7 +8,7 @@ Historical的API列表，请参见 [Historical API](../Operations/api.md#Historical) ### 运行 -``` +```json org.apache.druid.cli.Main server historical ``` diff --git a/Design/Indexer.md b/Design/Indexer.md index 96d05ba..723b99b 100644 --- a/Design/Indexer.md +++ b/Design/Indexer.md @@ -15,7 +15,7 @@ Apache Druid索引器进程是MiddleManager + Peon任务执行系统的另一种 Indexer进程与[MiddleManager](../Operations/api.md#MiddleManager)共用API ### 运行 -``` +```json org.apache.druid.cli.Main server indexer ``` diff --git a/Design/Metadata.md b/Design/Metadata.md index 725fc9d..6c26618 100644 --- a/Design/Metadata.md +++ b/Design/Metadata.md @@ -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", diff --git a/Design/MiddleManager.md b/Design/MiddleManager.md index 65e65f3..5b13c2e 100644 --- a/Design/MiddleManager.md +++ b/Design/MiddleManager.md @@ -10,6 +10,6 @@ MiddleManager进程是执行提交的任务的工作进程。MiddleManager将任务转发给运行在不同jvm中的Peon。我们为每个任务设置单独的jvm的原因是为了隔离资源和日志。每个Peon一次只能运行一个任务，但是，一个MiddleManager可能有多个Peon。 ### 运行 -``` +```json org.apache.druid.cli.Main server middleManager ``` \ No newline at end of file diff --git a/Design/Overlord.md b/Design/Overlord.md index e0f4c94..7efeeb6 100644 --- a/Design/Overlord.md +++ b/Design/Overlord.md @@ -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 diff --git a/Design/Peons.md b/Design/Peons.md index a0372fb..31696c0 100644 --- a/Design/Peons.md +++ b/Design/Peons.md @@ -11,7 +11,7 @@ Peon在单个JVM中运行单个任务。MiddleManager负责创建运行任务的 ### 运行 Peon应该很少独立于MiddleManager，除非出于开发目的。 -``` +```json org.apache.druid.cli.Main internal peon ``` diff --git a/Design/Router.md b/Design/Router.md index 910df98..37a6571 100644 --- a/Design/Router.md +++ b/Design/Router.md @@ -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 diff --git a/Design/Segments.md b/Design/Segments.md index e6d8d36..868bcdd 100644 --- a/Design/Segments.md +++ b/Design/Segments.md @@ -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 diff --git a/Design/Zookeeper.md b/Design/Zookeeper.md index 7d0de59..48d5b6b 100644 --- a/Design/Zookeeper.md +++ b/Design/Zookeeper.md @@ -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 ``` diff --git a/GettingStarted/chapter-2.md b/GettingStarted/chapter-2.md index c499240..e8e7b6c 100644 --- a/GettingStarted/chapter-2.md +++ b/GettingStarted/chapter-2.md @@ -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", diff --git a/GettingStarted/chapter-4.md b/GettingStarted/chapter-4.md index fece048..7afb0b8 100644 --- a/GettingStarted/chapter-4.md +++ b/GettingStarted/chapter-4.md @@ -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 ``` diff --git a/Tutorials/chapter-1.md b/Tutorials/chapter-1.md index 0b8bc73..2243652 100644 --- a/Tutorials/chapter-1.md +++ b/Tutorials/chapter-1.md @@ -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"} ``` 您可以如上所述从控制台监视此任务的状态 diff --git a/Tutorials/chapter-10.md b/Tutorials/chapter-10.md index 12dea1e..7edd418 100644 --- a/Tutorials/chapter-10.md +++ b/Tutorials/chapter-10.md @@ -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. diff --git a/Tutorials/chapter-11.md b/Tutorials/chapter-11.md index 00a79ff..dd47228 100644 --- a/Tutorials/chapter-11.md +++ b/Tutorials/chapter-11.md @@ -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 │ diff --git a/Tutorials/chapter-12.md b/Tutorials/chapter-12.md index 2b54368..d742f50 100644 --- a/Tutorials/chapter-12.md +++ b/Tutorials/chapter-12.md @@ -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 ``` diff --git a/Tutorials/chapter-2.md b/Tutorials/chapter-2.md index 5f01760..0d85ee8 100644 --- a/Tutorials/chapter-2.md +++ b/Tutorials/chapter-2.md @@ -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"}` diff --git a/Tutorials/chapter-3.md b/Tutorials/chapter-3.md index b6a551a..a5ef1b3 100644 --- a/Tutorials/chapter-3.md +++ b/Tutorials/chapter-3.md @@ -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 # diff --git a/Tutorials/chapter-4.md b/Tutorials/chapter-4.md index 97e4172..d553c18 100644 --- a/Tutorials/chapter-4.md +++ b/Tutorials/chapter-4.md @@ -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" : [ { diff --git a/Tutorials/chapter-5.md b/Tutorials/chapter-5.md index 944118b..8afc1a3 100644 --- a/Tutorials/chapter-5.md +++ b/Tutorials/chapter-5.md @@ -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 │ ├──────────────────────────┼────────┼───────┼─────────┼─────────┼─────────┤ diff --git a/Tutorials/chapter-6.md b/Tutorials/chapter-6.md index 5ad9266..bbe08c5 100644 --- a/Tutorials/chapter-6.md +++ b/Tutorials/chapter-6.md @@ -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 ``` diff --git a/Tutorials/chapter-7.md b/Tutorials/chapter-7.md index 851b926..069c5d4 100644 --- a/Tutorials/chapter-7.md +++ b/Tutorials/chapter-7.md @@ -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 │ diff --git a/Tutorials/chapter-8.md b/Tutorials/chapter-8.md index 37258e1..973da19 100644 --- a/Tutorials/chapter-8.md +++ b/Tutorials/chapter-8.md @@ -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 ``` diff --git a/Tutorials/chapter-9.md b/Tutorials/chapter-9.md index 418fbe5..0bcbcb4 100644 --- a/Tutorials/chapter-9.md +++ b/Tutorials/chapter-9.md @@ -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