Update the document for Guide
This commit is contained in:
parent
97881b3d17
commit
016738042c
|
|
@ -173,9 +173,9 @@ Druid支持永久的将标记为"unused"状态（详情可见架构设计中的
|
|||
1. 段必须首先标记为"未使用"。当用户通过Coordinator API手动禁用段时，就会发生这种情况
|
||||
2. 在段被标记为"未使用"之后，一个Kill任务将从Druid的元数据存储和深层存储中删除任何“未使用”的段
|
||||
|
||||
对于数据保留规则的文档，可以详细看 [数据保留](../Operations/retainingOrDropData.md)
|
||||
对于数据保留规则的文档，可以详细看 [数据保留](../operations/retainingOrDropData.md)
|
||||
|
||||
对于通过Coordinator API来禁用段的文档，可以详细看 [Coordinator数据源API](../Operations/api.md#coordinator)
|
||||
对于通过Coordinator API来禁用段的文档，可以详细看 [Coordinator数据源API](../operations/api.md#coordinator)
|
||||
|
||||
在本文档中已经包含了一个删除删除的教程，请看 [数据删除教程](../tutorials/chapter-9.md)
|
||||
|
||||
|
|
@ -199,4 +199,4 @@ Druid还支持将Historical进程分成不同的层，并且可以将保留规
|
|||
|
||||
这些特性对于性能/成本管理非常有用；一个常见的场景是将Historical进程分为"热(hot)"层和"冷(cold)"层。
|
||||
|
||||
有关详细信息，请参阅 [加载规则](../Operations/retainingOrDropData.md)。
|
||||
有关详细信息，请参阅 [加载规则](../operations/retainingOrDropData.md)。
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Druid可以摄取JSON、CSV、TSV和其他分隔数据。Druid支持一维值或
|
|||
|
||||
### 并非所有的事件都被摄取了
|
||||
|
||||
Druid会拒绝时间窗口之外的事件， 确认事件是否被拒绝了的最佳方式是查看 [Druid摄取指标](../Operations/metrics.md)
|
||||
Druid会拒绝时间窗口之外的事件， 确认事件是否被拒绝了的最佳方式是查看 [Druid摄取指标](../operations/metrics.md)
|
||||
|
||||
如果摄取的事件数似乎正确，请确保查询的格式正确。如果在摄取规范中包含 `count` 聚合器，则需要使用 `longSum` 聚合器查询此聚合的结果。使用count聚合器发出查询将计算Druid行的数量，包括 [rollup](ingestion.md#rollup)。
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@
|
|||
|
||||
Apache Druid当前支持通过一个Hadoop摄取任务来支持基于Apache Hadoop的批量索引任务， 这些任务被提交到 [Druid Overlord](../design/Overlord.md)的一个运行实例上。详情可以查看 [基于Hadoop的摄取vs基于本地批摄取的对比](ingestion.md#批量摄取) 来了解基于Hadoop的摄取、本地简单批摄取、本地并行摄取三者的比较。
|
||||
|
||||
运行一个基于Hadoop的批量摄取任务，首先需要编写一个如下的摄取规范， 然后提交到Overlord的 [`druid/indexer/v1/task`](../Operations/api.md#overlord) 接口，或者使用Druid软件包中自带的 `bin/post-index-task` 脚本。
|
||||
运行一个基于Hadoop的批量摄取任务，首先需要编写一个如下的摄取规范， 然后提交到Overlord的 [`druid/indexer/v1/task`](../operations/api.md#overlord) 接口，或者使用Druid软件包中自带的 `bin/post-index-task` 脚本。
|
||||
|
||||
### 教程
|
||||
|
||||
|
|
@ -318,7 +318,7 @@ s3n://billy-bucket/the/data/is/here/y=2012/m=06/d=01/H=23
|
|||
```
|
||||
Hadoop的 [MapReduce文档](https://hadoop.apache.org/docs/stable/hadoop-mapreduce-client/hadoop-mapreduce-client-core/mapred-default.xml) 列出来了所有可能的配置参数。
|
||||
|
||||
在一些Hadoop分布式环境中，可能需要设置 `mapreduce.job.classpath` 或者 `mapreduce.job.user.classpath.first` 来避免类加载相关的问题。 更多详细信息可以参见 [使用不同Hadoop版本的文档](../Operations/other-hadoop.md)
|
||||
在一些Hadoop分布式环境中，可能需要设置 `mapreduce.job.classpath` 或者 `mapreduce.job.user.classpath.first` 来避免类加载相关的问题。 更多详细信息可以参见 [使用不同Hadoop版本的文档](../operations/other-hadoop.md)
|
||||
|
||||
#### `partitionsSpec`
|
||||
|
||||
|
|
@ -376,7 +376,7 @@ Hadoop的 [MapReduce文档](https://hadoop.apache.org/docs/stable/hadoop-mapredu
|
|||
|
||||
如果已经有了一个远程的Hadoop集群，确保在Druid的 `_common` 配置目录中包含 `*.xml` 文件。
|
||||
|
||||
如果Hadoop与Druid的版本存在依赖等问题，请查看 [这些文档](../Operations/other-hadoop.md)
|
||||
如果Hadoop与Druid的版本存在依赖等问题，请查看 [这些文档](../operations/other-hadoop.md)
|
||||
|
||||
### Elastic MapReduce
|
||||
|
||||
|
|
@ -420,7 +420,7 @@ classification=yarn-site,properties=[mapreduce.reduce.memory.mb=6144,mapreduce.r
|
|||
|
||||
Druid在许多Hadoop发行版中都是开箱即用的。
|
||||
|
||||
如果Druid与您当前使用的Hadoop版本发生依赖冲突时，您可以尝试在 [Druid用户组](https://groups.google.com/forum/#!forum/druid-user) 中搜索解决方案， 或者阅读 [Druid不同版本Hadoop文档](../Operations/other-hadoop.md)
|
||||
如果Druid与您当前使用的Hadoop版本发生依赖冲突时，您可以尝试在 [Druid用户组](https://groups.google.com/forum/#!forum/druid-user) 中搜索解决方案， 或者阅读 [Druid不同版本Hadoop文档](../operations/other-hadoop.md)
|
||||
|
||||
### 命令行版本
|
||||
|
||||
|
|
|
|||
|
|
@ -230,7 +230,7 @@ Druid数据源总是按时间划分为*时间块*，每个时间块包含一个
|
|||
|
||||
该部分中支持的特定选项依赖于选择的[摄入方法](#摄入方式)。 更多的示例，可以参考每一种[摄入方法](#摄入方式)的文档。
|
||||
|
||||
您还可以不用编写一个摄入规范，可视化的加载数据，该功能位于 [Druid控制台](../Operations/manageui.md) 的 "Load Data" 视图中。 Druid可视化数据加载器目前支持 [Kafka](kafka.md), [Kinesis](kinesis.md) 和 [本地批](native.md) 模式。
|
||||
您还可以不用编写一个摄入规范，可视化的加载数据，该功能位于 [Druid控制台](../operations/manageui.md) 的 "Load Data" 视图中。 Druid可视化数据加载器目前支持 [Kafka](kafka.md), [Kinesis](kinesis.md) 和 [本地批](native.md) 模式。
|
||||
|
||||
#### `dataSchema`
|
||||
> [!WARNING]
|
||||
|
|
|
|||
|
|
@ -121,7 +121,7 @@ curl -X POST -H 'Content-Type: application/json' -d @supervisor-spec.json http:/
|
|||
| `indexSpecForIntermediatePersists` | | 定义要在索引时用于中间持久化临时段的段存储格式选项。这可用于禁用中间段上的维度/度量压缩，以减少最终合并所需的内存。但是，在中间段上禁用压缩可能会增加页缓存的使用，而在它们被合并到发布的最终段之前使用它们，有关可能的值，请参阅IndexSpec。 | 否（默认与 `indexSpec` 相同） |
|
||||
| `reportParseExceptions` | Boolean | *已废弃*。如果为true，则在解析期间遇到的异常即停止摄取；如果为false，则将跳过不可解析的行和字段。将 `reportParseExceptions` 设置为 `true` 将覆盖`maxParseExceptions` 和 `maxSavedParseExceptions` 的现有配置，将`maxParseExceptions` 设置为 `0` 并将 `maxSavedParseExceptions` 限制为不超过1。 | 否（默认为false）|
|
||||
| `handoffConditionTimeout` | Long | 段切换（持久化）可以等待的毫秒数（超时时间）。 该值要被设置为大于0的数，设置为0意味着将会一直等待不超时 | 否（默认为0）|
|
||||
| `resetOffsetAutomatically` | Boolean | 控制当Druid需要读取Kafka中不可用的消息时的行为，比如当发生了 `OffsetOutOfRangeException` 异常时。 <br> 如果为false，则异常将抛出，这将导致任务失败并停止接收。如果发生这种情况，则需要手动干预来纠正这种情况；可能使用 [重置 Supervisor API](../Operations/api.md#Supervisor)。此模式对于生产非常有用，因为它将使您意识到摄取的问题。 <br> 如果为true，Druid将根据 `useEarliestOffset` 属性的值（`true` 为 `earliest`，`false` 为 `latest`）自动重置为Kafka中可用的较早或最新偏移量。请注意，这可能导致数据在您不知情的情况下*被丢弃*（如果`useEarliestOffset` 为 `false`）或 *重复*（如果 `useEarliestOffset` 为 `true`）。消息将被记录下来，以标识已发生重置，但摄取将继续。这种模式对于非生产环境非常有用，因为它将使Druid尝试自动从问题中恢复，即使这些问题会导致数据被安静删除或重复。 <br> 该特性与Kafka的 `auto.offset.reset` 消费者属性很相似 | 否（默认为false）|
|
||||
| `resetOffsetAutomatically` | Boolean | 控制当Druid需要读取Kafka中不可用的消息时的行为，比如当发生了 `OffsetOutOfRangeException` 异常时。 <br> 如果为false，则异常将抛出，这将导致任务失败并停止接收。如果发生这种情况，则需要手动干预来纠正这种情况；可能使用 [重置 Supervisor API](../operations/api.md#Supervisor)。此模式对于生产非常有用，因为它将使您意识到摄取的问题。 <br> 如果为true，Druid将根据 `useEarliestOffset` 属性的值（`true` 为 `earliest`，`false` 为 `latest`）自动重置为Kafka中可用的较早或最新偏移量。请注意，这可能导致数据在您不知情的情况下*被丢弃*（如果`useEarliestOffset` 为 `false`）或 *重复*（如果 `useEarliestOffset` 为 `true`）。消息将被记录下来，以标识已发生重置，但摄取将继续。这种模式对于非生产环境非常有用，因为它将使Druid尝试自动从问题中恢复，即使这些问题会导致数据被安静删除或重复。 <br> 该特性与Kafka的 `auto.offset.reset` 消费者属性很相似 | 否（默认为false）|
|
||||
| `workerThreads` | Integer | supervisor用于异步操作的线程数。| 否（默认为: min(10, taskCount)） |
|
||||
| `chatThreads` | Integer | 与索引任务的会话线程数 | 否（默认为：min(10, taskCount * replicas)）|
|
||||
| `chatRetries` | Integer | 在任务没有响应之前，将重试对索引任务的HTTP请求的次数 | 否（默认为8）|
|
||||
|
|
@ -170,7 +170,7 @@ curl -X POST -H 'Content-Type: application/json' -d @supervisor-spec.json http:/
|
|||
|-|-|-|-|
|
||||
| `topic` | String | 要读取数据的Kafka主题。这必须是一个特定的主题，因为不支持主题模式 | 是 |
|
||||
| `inputFormat` | Object | [`inputFormat`](dataformats.md#inputformat) 指定如何解析输入数据。 看 [下边部分](#指定输入数据格式) 查看指定输入格式的详细信息。 | 是 |
|
||||
| `consumerProperties` | Map<String, Object> | 传给Kafka消费者的一组属性map。必须得包含 `bootstrap.servers` 的属性，其值为Kafka Broker列表，格式为: `<BROKER_1>:<PORT_1>,<BROKER_2>:<PORT_2>,...`。 对于SSL连接，`keystore`, `truststore` 和 `key` 密码可以被以一个字符串密码或者 [密码Provider](../Operations/passwordproviders.md) 来提供 | 是 |
|
||||
| `consumerProperties` | Map<String, Object> | 传给Kafka消费者的一组属性map。必须得包含 `bootstrap.servers` 的属性，其值为Kafka Broker列表，格式为: `<BROKER_1>:<PORT_1>,<BROKER_2>:<PORT_2>,...`。 对于SSL连接，`keystore`, `truststore` 和 `key` 密码可以被以一个字符串密码或者 [密码Provider](../operations/passwordproviders.md) 来提供 | 是 |
|
||||
| `pollTimeout` | Long | Kafka消费者拉取消息记录的超时等待时间，毫秒单位 | 否（默认为100）|
|
||||
| `replicas` | Integer | 副本的数量，1意味着一个单一任务（无副本）。副本任务将始终分配给不同的worker，以提供针对流程故障的恢复能力。| 否（默认为1）|
|
||||
| `taskCount` | Integer | *一个副本集* 中*读取*任务的最大数量。 这意味着读取任务的最大的数量将是 `taskCount * replicas`, 任务总数（*读取 + 发布*）是大于这个数字的。 详情可以看下边的 [容量规划](#容量规划)。 如果 `taskCount > {numKafkaPartitions}`, 读取任务的数量会小于 `taskCount` | 否（默认为1）|
|
||||
|
|
@ -190,7 +190,7 @@ Kafka索引服务同时支持通过 [`inputFormat`](dataformats.md#inputformat)
|
|||
|
||||
### 操作
|
||||
|
||||
本节描述了一些supervisor API如何在Kafka索引服务中具体工作。对于所有的supervisor API，请查看 [Supervisor APIs](../Operations/api.md#Supervisor)
|
||||
本节描述了一些supervisor API如何在Kafka索引服务中具体工作。对于所有的supervisor API，请查看 [Supervisor APIs](../operations/api.md#Supervisor)
|
||||
|
||||
#### 获取supervisor的状态报告
|
||||
|
||||
|
|
@ -298,5 +298,5 @@ schema和配置更改是通过最初用于创建supervisor的 `POST /druid/index
|
|||
|
||||
每个Kafka索引任务将从分配给它的Kafka分区中消费的事件放在每个段粒度间隔的单个段中，直到达到 `maxRowsPerSegment`、`maxTotalRows` 或 `intermediateHandoffPeriod` 限制，此时将为进一步的事件创建此段粒度的新分区。Kafka索引任务还执行增量移交，这意味着任务创建的所有段在任务持续时间结束之前都不会被延迟。一旦达到 `maxRowsPerSegment`、`maxTotalRows` 或 `intermediateHandoffPeriod` 限制，任务在该时间点持有的所有段都将被传递，并且将为进一步的事件创建新的段集。这意味着任务可以运行更长的时间，而不必在MiddleManager进程的本地累积旧段，因此鼓励这样做。
|
||||
|
||||
Kafka索引服务可能仍然会产生一些小片段。假设任务持续时间为4小时，段粒度设置为1小时，supervisor在9:10启动，然后在13:10的4小时后，将启动新的任务集，并且间隔13:00-14:00的事件可以跨以前的和新的任务集拆分。如果您发现这成为一个问题，那么可以调度重新索引任务，以便将段合并到理想大小的新段中（每个段大约500-700 MB）。有关如何优化段大小的详细信息，请参见 ["段大小优化"](../Operations/segmentSizeOpt.md)。还有一些工作正在进行，以支持碎片段的自动段压缩，以及不需要Hadoop的压缩(参见[此处](https://github.com/apache/druid/pull/5102))。
|
||||
Kafka索引服务可能仍然会产生一些小片段。假设任务持续时间为4小时，段粒度设置为1小时，supervisor在9:10启动，然后在13:10的4小时后，将启动新的任务集，并且间隔13:00-14:00的事件可以跨以前的和新的任务集拆分。如果您发现这成为一个问题，那么可以调度重新索引任务，以便将段合并到理想大小的新段中（每个段大约500-700 MB）。有关如何优化段大小的详细信息，请参见 ["段大小优化"](../operations/segmentSizeOpt.md)。还有一些工作正在进行，以支持碎片段的自动段压缩，以及不需要Hadoop的压缩(参见[此处](https://github.com/apache/druid/pull/5102))。
|
||||
|
||||
|
|
|
|||
|
|
@ -731,8 +731,8 @@ S3对象：
|
|||
|
||||
| 属性 | 描述 | 默认 | 是否必须 |
|
||||
|-|-|-|-|
|
||||
| `accessKeyId` | S3输入源访问密钥的 [Password Provider](../Operations/passwordproviders.md) 或纯文本字符串 | None | 如果 `secretAccessKey` 被提供的话，则为必须 |
|
||||
| `secretAccessKey` | S3输入源访问密钥的 [Password Provider](../Operations/passwordproviders.md) 或纯文本字符串 | None | 如果 `accessKeyId` 被提供的话，则为必须 |
|
||||
| `accessKeyId` | S3输入源访问密钥的 [Password Provider](../operations/passwordproviders.md) 或纯文本字符串 | None | 如果 `secretAccessKey` 被提供的话，则为必须 |
|
||||
| `secretAccessKey` | S3输入源访问密钥的 [Password Provider](../operations/passwordproviders.md) 或纯文本字符串 | None | 如果 `accessKeyId` 被提供的话，则为必须 |
|
||||
|
||||
**注意**： *如果 `accessKeyId` 和 `secretAccessKey` 未被指定的话， 则将使用默认的 [S3认证](../development/S3-compatible.md#S3认证方式)*
|
||||
|
||||
|
|
|
|||
|
|
@ -15,13 +15,13 @@
|
|||
|
||||
任务在Druid中完成所有与 [摄取](ingestion.md) 相关的工作。
|
||||
|
||||
对于批量摄取，通常使用 [任务api](../Operations/api.md#Overlord) 直接将任务提交给Druid。对于流式接收，任务通常被提交给supervisor。
|
||||
对于批量摄取，通常使用 [任务api](../operations/api.md#Overlord) 直接将任务提交给Druid。对于流式接收，任务通常被提交给supervisor。
|
||||
|
||||
### 任务API
|
||||
|
||||
任务API主要在两个地方是可用的：
|
||||
|
||||
* [Overlord](../design/Overlord.md) 进程提供HTTP API接口来进行提交任务、取消任务、检查任务状态、查看任务日志与报告等。 查看 [任务API文档](../Operations/api.md) 可以看到完整列表
|
||||
* [Overlord](../design/Overlord.md) 进程提供HTTP API接口来进行提交任务、取消任务、检查任务状态、查看任务日志与报告等。 查看 [任务API文档](../operations/api.md) 可以看到完整列表
|
||||
* Druid SQL包括了一个 [`sys.tasks`](../querying/druidsql.md#系统Schema) ，保存了当前任务运行的信息。 此表是只读的，并且可以通过Overlord API查询完整信息的有限制的子集。
|
||||
|
||||
### 任务报告
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ Druid `docker-compose.yml` 示例使用单个环境文件来指定完整的Drui
|
|||
|
||||
运行 `docker-compose up` 启动附加shell的集群，或运行 `docker-compose up -d` 在后台运行集群。如果直接使用示例文件，这个命令应该从Druid安装目录中的 `distribution/docker/` 运行。
|
||||
|
||||
启动集群后，可以导航到 [http://localhost:8888](http://localhost/) 。服务于 [Druid控制台](../Operations/druid-console.md) 的 [Druid路由进程](../Design/Router.md) 位于这个地址。
|
||||
启动集群后，可以导航到 [http://localhost:8888](http://localhost/) 。服务于 [Druid控制台](../operations/druid-console.md) 的 [Druid路由进程](../Design/Router.md) 位于这个地址。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ Druid Broker服务接收查询请求，并将其转发到集群中的其他部
|
|||
|
||||
如果您的使用场景具有复杂的扩展要求，则还可以选择不将Druid服务混合部署（例如，独立的Historical Server）。
|
||||
|
||||
[基本集群调整指南](../Operations/basicClusterTuning.md)中的信息可以帮助您进行决策，并可以调整配置大小。
|
||||
[基本集群调整指南](../operations/basicClusterTuning.md)中的信息可以帮助您进行决策，并可以调整配置大小。
|
||||
|
||||
#### 从单服务器环境迁移部署
|
||||
|
||||
|
|
@ -107,7 +107,7 @@ Query服务的硬件选择主要考虑可用的CPU、Broker服务的堆内和堆
|
|||
|
||||
对于CPU，可以选择接近于单服务器环境核数1/4的硬件。
|
||||
|
||||
[基本集群调优指南](../Operations/basicClusterTuning.md)包含有关如何计算Broker和Router服务内存使用量的信息。
|
||||
[基本集群调优指南](../operations/basicClusterTuning.md)包含有关如何计算Broker和Router服务内存使用量的信息。
|
||||
|
||||
### 选择操作系统
|
||||
|
||||
|
|
@ -152,7 +152,7 @@ cd apache-druid-0.17.0
|
|||
### 配置元数据存储和深度存储
|
||||
#### 从单服务器环境迁移部署
|
||||
|
||||
如果您已经有一个单服务器部署，并且希望在整个迁移过程中保留数据，请在更新元数据/深层存储配置之前，按照[元数据迁移](../Operations/metadataMigration.md)和[深层存储迁移](../Operations/DeepstorageMigration.md)中的说明进行操作。
|
||||
如果您已经有一个单服务器部署，并且希望在整个迁移过程中保留数据，请在更新元数据/深层存储配置之前，按照[元数据迁移](../operations/metadataMigration.md)和[深层存储迁移](../operations/DeepstorageMigration.md)中的说明进行操作。
|
||||
|
||||
这些指南针对使用Derby元数据存储和本地深度存储的单服务器部署。 如果您已经在单服务器集群中使用了非Derby元数据存储，则可以在新集群中可以继续使用当前的元数据存储。
|
||||
|
||||
|
|
@ -334,7 +334,7 @@ druid.indexer.fork.property.druid.processing.numThreads=1
|
|||
|
||||
`conf/druid/cluster`下的配置已经为此硬件确定了，一般情况下您无需做进一步的修改。
|
||||
|
||||
如果您选择了其他硬件，则[基本的集群调整指南](../Operations/basicClusterTuning.md)可以帮助您调整配置大小。
|
||||
如果您选择了其他硬件，则[基本的集群调整指南](../operations/basicClusterTuning.md)可以帮助您调整配置大小。
|
||||
|
||||
### 开启端口(如果使用了防火墙)
|
||||
|
||||
|
|
@ -410,7 +410,7 @@ bin/start-cluster-data-server
|
|||
bin/start-cluster-query-server
|
||||
```
|
||||
|
||||
您可以根据查询负载添加更多查询服务器。 如果增加了查询服务器的数量，请确保按照[基本集群调优指南](../Operations/basicClusterTuning.md)中的说明调整Historical和Task上的连接池。
|
||||
您可以根据查询负载添加更多查询服务器。 如果增加了查询服务器的数量，请确保按照[基本集群调优指南](../operations/basicClusterTuning.md)中的说明调整Historical和Task上的连接池。
|
||||
|
||||
### 加载数据
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@
|
|||
* [Historical](design/Historical.md)
|
||||
* [MiddleManager](design/MiddleManager.md)
|
||||
* [Broker](design/Broker.md)
|
||||
* [Router](design/Router.md)
|
||||
* [Router](design/router.md)
|
||||
* [Indexer](design/Indexer.md)
|
||||
* [Peon](design/Peons.md)
|
||||
* [深度存储](design/Deepstorage.md)
|
||||
|
|
@ -103,7 +103,7 @@
|
|||
* [配置列表](Configuration/configuration.md)
|
||||
|
||||
* [操作指南]()
|
||||
* [操作指南](Operations/index.md)
|
||||
* [操作指南](operations/index.md)
|
||||
|
||||
* [开发指南]()
|
||||
* [开发指南](development/index.md)
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
对于Apache Druid Broker的配置，请参见 [Broker配置](../Configuration/configuration.md#Broker)
|
||||
|
||||
### HTTP
|
||||
对于Broker的API的列表，请参见 [Broker API](../Operations/api.md#Broker)
|
||||
对于Broker的API的列表，请参见 [Broker API](../operations/api.md#Broker)
|
||||
|
||||
### 综述
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
对于Apache Druid的Coordinator进程配置，详见 [Coordinator配置](../Configuration/configuration.md#Coordinator)
|
||||
|
||||
### HTTP
|
||||
对于Coordinator的API接口，详见 [Coordinator API](../Operations/api.md#Coordinator)
|
||||
对于Coordinator的API接口，详见 [Coordinator API](../operations/api.md#Coordinator)
|
||||
|
||||
### 综述
|
||||
Druid Coordinator程序主要负责段管理和分发。更具体地说，Druid Coordinator进程与Historical进程通信，根据配置加载或删除段。Druid Coordinator负责加载新段、删除过时段、管理段复制和平衡段负载。
|
||||
|
|
@ -30,7 +30,7 @@ Druid Coordinator定期运行，每次运行之间的时间是一个可配置的
|
|||
org.apache.druid.cli.Main server coordinator
|
||||
```
|
||||
### 规则
|
||||
可以根据一组规则自动从集群中加载和删除段。有关规则的详细信息，请参阅[规则配置](../Operations/retainingOrDropData.md)。
|
||||
可以根据一组规则自动从集群中加载和删除段。有关规则的详细信息，请参阅[规则配置](../operations/retainingOrDropData.md)。
|
||||
|
||||
### 清理段
|
||||
每次运行时，Druid Coordinator都会将数据库中可用段的列表与集群中的当前段进行比较,不在数据库中但仍在集群中服务的段将被标记并附加到删除列表中,被遮蔽的段（它们的版本太旧，它们的数据被更新的段替换）也会被丢弃。
|
||||
|
|
@ -43,9 +43,9 @@ org.apache.druid.cli.Main server coordinator
|
|||
|
||||
### 合并段
|
||||
|
||||
每次运行时，Druid Coordinator都通过合并小段或拆分大片段来压缩段。当您的段没有进行段大小（可能会导致查询性能下降）优化时，该操作非常有用。有关详细信息，请参见[段大小优化](../Operations/segmentSizeOpt.md)。
|
||||
每次运行时，Druid Coordinator都通过合并小段或拆分大片段来压缩段。当您的段没有进行段大小（可能会导致查询性能下降）优化时，该操作非常有用。有关详细信息，请参见[段大小优化](../operations/segmentSizeOpt.md)。
|
||||
|
||||
Coordinator首先根据[段搜索策略](#段搜索策略)查找要压缩的段。找到某些段后，它会发出[压缩任务](../DataIngestion/taskrefer.md#compact)来压缩这些段。运行压缩任务的最大数目为 `min(sum of worker capacity * slotRatio, maxSlots)`。请注意，即使 `min(sum of worker capacity * slotRatio, maxSlots)` = 0，如果为数据源启用了压缩，则始终会提交至少一个压缩任务。请参阅[压缩配置API](../Operations/api.md#Coordinator)和[压缩配置](../Configuration/configuration.md#Coordinator)以启用压缩。
|
||||
Coordinator首先根据[段搜索策略](#段搜索策略)查找要压缩的段。找到某些段后，它会发出[压缩任务](../DataIngestion/taskrefer.md#compact)来压缩这些段。运行压缩任务的最大数目为 `min(sum of worker capacity * slotRatio, maxSlots)`。请注意，即使 `min(sum of worker capacity * slotRatio, maxSlots)` = 0，如果为数据源启用了压缩，则始终会提交至少一个压缩任务。请参阅[压缩配置API](../operations/api.md#Coordinator)和[压缩配置](../Configuration/configuration.md#Coordinator)以启用压缩。
|
||||
|
||||
压缩任务可能由于以下原因而失败:
|
||||
|
||||
|
|
@ -83,7 +83,7 @@ Coordinator首先根据[段搜索策略](#段搜索策略)查找要压缩的段
|
|||
|
||||
### Coordinator控制台
|
||||
|
||||
Druid Coordinator公开了一个web GUI，用于显示集群信息和规则配置。有关详细信息，请参阅[Coordinator控制台](../Operations/manageui.md)。
|
||||
Druid Coordinator公开了一个web GUI，用于显示集群信息和规则配置。有关详细信息，请参阅[Coordinator控制台](../operations/manageui.md)。
|
||||
|
||||
### FAQ
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Druid有若干不同类型的进程，简单描述如下：
|
|||
* [Coordinator](Coordinator.md) 进程管理集群中数据的可用性
|
||||
* [Overlord](Overlord.md) 进程控制数据摄取负载的分配
|
||||
* [Broker](Broker.md) 进程处理来自外部客户端的查询请求
|
||||
* [Router](Router.md) 进程是一个可选进程，可以将请求路由到Brokers、Coordinators和Overlords
|
||||
* [Router](router.md) 进程是一个可选进程，可以将请求路由到Brokers、Coordinators和Overlords
|
||||
* [Historical](Historical.md) 进程存储可查询的数据
|
||||
* [MiddleManager](MiddleManager.md) 进程负责摄取数据
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
对于Apache Druid Historical的配置，请参见 [Historical配置](../Configuration/configuration.md#Historical)
|
||||
|
||||
### HTTP
|
||||
Historical的API列表，请参见 [Historical API](../Operations/api.md#Historical)
|
||||
Historical的API列表，请参见 [Historical API](../operations/api.md#Historical)
|
||||
|
||||
### 运行
|
||||
```json
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Apache Druid索引器进程是MiddleManager + Peon任务执行系统的另一种
|
|||
对于Apache Druid Indexer进程的配置，请参见 [Indexer配置](../Configuration/configuration.md#Indexer)
|
||||
|
||||
### HTTP
|
||||
Indexer进程与[MiddleManager](../Operations/api.md#MiddleManager)共用API
|
||||
Indexer进程与[MiddleManager](../operations/api.md#MiddleManager)共用API
|
||||
|
||||
### 运行
|
||||
```json
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
对于Apache Druid MiddleManager配置，可以参见[索引服务配置](../Configuration/configuration.md#MiddleManager)
|
||||
|
||||
### HTTP
|
||||
对于MiddleManager的API接口，详见 [MiddleManager API](../Operations/api.md#MiddleManager)
|
||||
对于MiddleManager的API接口，详见 [MiddleManager API](../operations/api.md#MiddleManager)
|
||||
|
||||
### 综述
|
||||
MiddleManager进程是执行提交的任务的工作进程。MiddleManager将任务转发给运行在不同jvm中的Peon。我们为每个任务设置单独的jvm的原因是为了隔离资源和日志。每个Peon一次只能运行一个任务，但是，一个MiddleManager可能有多个Peon。
|
||||
|
|
|
|||
|
|
@ -16,13 +16,13 @@
|
|||
对于Apache Druid的Overlord进程配置，详见 [Overlord配置](../Configuration/configuration.md#Overlord)
|
||||
|
||||
### HTTP
|
||||
对于Overlord的API接口，详见 [Overlord API](../Operations/api.md#Overlord)
|
||||
对于Overlord的API接口，详见 [Overlord API](../operations/api.md#Overlord)
|
||||
|
||||
### 综述
|
||||
Overlord进程负责接收任务、协调任务分配、创建任务锁并将状态返回给调用方。Overlord可以配置为本地模式运行或者远程模式运行（默认为本地）。在本地模式下，Overlord还负责创建执行任务的Peon， 在本地模式下运行Overlord时，还必须提供所有MiddleManager和Peon配置。本地模式通常用于简单的工作流。在远程模式下，Overlord和MiddleManager在不同的进程中运行，您可以在不同的服务器上运行每一个进程。如果要将索引服务用作所有Druid索引的单个端点，建议使用此模式。
|
||||
|
||||
### Overlord控制台
|
||||
Druid Overlord公开了一个web GUI，用于管理任务和worker。有关详细信息，请参阅[Overlord控制台](../Operations/manageui.md)。
|
||||
Druid Overlord公开了一个web GUI，用于管理任务和worker。有关详细信息，请参阅[Overlord控制台](../operations/manageui.md)。
|
||||
|
||||
### worker黑名单
|
||||
如果一个MiddleManager的任务失败超过阈值，Overlord会将这些MiddleManager列入黑名单。不超过20%的MiddleManager可以被列入黑名单，被列入黑名单的MiddleManager将定期被列入白名单。
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
对于Apache Druid Peon配置，可以参见 [Peon查询配置](../Configuration/configuration.md) 和 [额外的Peon配置](../Configuration/configuration.md)
|
||||
|
||||
### HTTP
|
||||
对于Peon的API接口，详见 [Peon API](../Operations/api.md#Peon)
|
||||
对于Peon的API接口，详见 [Peon API](../operations/api.md#Peon)
|
||||
|
||||
Peon在单个JVM中运行单个任务。MiddleManager负责创建运行任务的Peon。Peon应该很少（如果为了测试目的）自己运行。
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Druid有以下几种进程类型：
|
|||
* [Historical](./Historical.md)
|
||||
* [MiddleManager](./MiddleManager.md) 和 [Peons](./Peons.md)
|
||||
* [Indexer(可选)](./Indexer.md)
|
||||
* [Router(可选)](./Router.md)
|
||||
* [Router(可选)](router.md)
|
||||
|
||||
### 服务类型
|
||||
|
||||
|
|
@ -62,7 +62,7 @@ Query服务提供用户和客户端应用程序交互，将查询路由到Data
|
|||
|
||||
Router进程是*可选*的进程，相当于是为Druid Broker、Overlord和Coordinator提供一个统一的API网关。Router是可选的，因为也可以直接与Druid的Broker、Overlord和Coordinator。
|
||||
|
||||
Router还运行着[Druid控制台](../Operations/manageui.md)，一个用于数据源、段、任务、数据进程（Historical和MiddleManager）和Coordinator动态配置的管理UI。用户还可以在控制台中运行SQL和本地Druid查询。
|
||||
Router还运行着[Druid控制台](../operations/manageui.md)，一个用于数据源、段、任务、数据进程（Historical和MiddleManager）和Coordinator动态配置的管理UI。用户还可以在控制台中运行SQL和本地Druid查询。
|
||||
|
||||
#### Data服务
|
||||
|
||||
|
|
|
|||
|
|
@ -16,11 +16,11 @@
|
|||
> [!WARNING]
|
||||
> Router是一个可选的和实验性的特性，因为它在Druid集群架构中的推荐位置仍在不断发展。然而，它已经在生产中经过了测试，并且承载了强大的Druid控制台，所以您应该放心地部署它。
|
||||
|
||||
Apache Druid Router用于将查询路由到不同的Broker。默认情况下，Broker根据 [规则](../Operations/retainingOrDropData.md) 设置路由查询。例如，如果将最近1个月的数据加载到一个 `热集群` 中，则可以将最近一个月内的查询路由到一组专用的Broker,超出此范围的查询将路由到另一组Broker。该设置的主要功能是为了提供查询隔离，以便对较重要数据的查询不会受到对较不重要数据的查询的影响。
|
||||
Apache Druid Router用于将查询路由到不同的Broker。默认情况下，Broker根据 [规则](../operations/retainingOrDropData.md) 设置路由查询。例如，如果将最近1个月的数据加载到一个 `热集群` 中，则可以将最近一个月内的查询路由到一组专用的Broker,超出此范围的查询将路由到另一组Broker。该设置的主要功能是为了提供查询隔离，以便对较重要数据的查询不会受到对较不重要数据的查询的影响。
|
||||
|
||||
出于查询路由的目的，如果您有一个TB数据规模的Druid集群，您应该只使用Router进程。
|
||||
|
||||
除了查询路由，Router还运行 [Druid控制台](../Operations/manageui.md), 一个用于数据源、段、任务、数据进程（Historical和MiddleManager）和Coordinator动态配置的管理UI。用户还可以在控制台中运行SQL和本地Druid查询。
|
||||
除了查询路由，Router还运行 [Druid控制台](../operations/manageui.md), 一个用于数据源、段、任务、数据进程（Historical和MiddleManager）和Coordinator动态配置的管理UI。用户还可以在控制台中运行SQL和本地Druid查询。
|
||||
|
||||
### 配置
|
||||
|
||||
|
|
@ -28,7 +28,7 @@ Apache Druid Router用于将查询路由到不同的Broker。默认情况下，B
|
|||
|
||||
### HTTP
|
||||
|
||||
对于Router的API列表，请参见 [Router API](../Operations/api.md#Router)
|
||||
对于Router的API列表，请参见 [Router API](../operations/api.md#Router)
|
||||
|
||||
### 运行
|
||||
|
||||
|
|
@ -647,7 +647,7 @@ try (Connection connection = DriverManager.getConnection(url, connectionProperti
|
|||
|
||||
**连接粘性**
|
||||
|
||||
Druid的JDBC服务不在Broker之间共享连接状态。这意味着，如果您使用JDBC并且有多个Druid Broker，您应该连接到一个特定的Broker，或者使用启用了粘性会话的负载平衡器。Druid Router进程在平衡JDBC请求时提供连接粘性，即使使用普通的非粘性负载平衡器，也可以用来实现必要的粘性。请参阅 [Router文档](../design/Router.md) 以了解更多详细信息
|
||||
Druid的JDBC服务不在Broker之间共享连接状态。这意味着，如果您使用JDBC并且有多个Druid Broker，您应该连接到一个特定的Broker，或者使用启用了粘性会话的负载平衡器。Druid Router进程在平衡JDBC请求时提供连接粘性，即使使用普通的非粘性负载平衡器，也可以用来实现必要的粘性。请参阅 [Router文档](../design/router.md) 以了解更多详细信息
|
||||
|
||||
注意：非JDBC的 [HTTP POST](#http-post) 是无状态的，不需要粘性
|
||||
|
||||
|
|
|
|||
|
|
@ -235,7 +235,7 @@ GroupBy查询可以使用两种不同的策略执行。默认策略由Broker上
|
|||
|
||||
如果`maxOnDiskStorage`大于0，则超出内存限制的查询将开始使用磁盘进行聚合。在这种情况下，当堆内字典或堆外哈希表填满时，部分聚合的记录将被排序并刷新到磁盘。然后，两个内存中的结构都将被清除，以便进一步聚合。然后继续超过`maxOnDiskStorage`的查询将失败，并出现"Resource limit exceeded"错误，指示它们的磁盘空间不足。
|
||||
|
||||
对于groupBy v2，集群操作符应该确保堆外哈希表和堆内合并字典不会超过最大可能并发查询负载的可用内存（由`druid.processing.numMergeBuffers`控制)。有关直接内存使用（按Druid进程类型组织）的更多详细信息，请参阅[基本集群调优指南](../Operations/basicClusterTuning.md)。
|
||||
对于groupBy v2，集群操作符应该确保堆外哈希表和堆内合并字典不会超过最大可能并发查询负载的可用内存（由`druid.processing.numMergeBuffers`控制)。有关直接内存使用（按Druid进程类型组织）的更多详细信息，请参阅[基本集群调优指南](../operations/basicClusterTuning.md)。
|
||||
|
||||
Broker对基础的groupBy查询不需要合并缓冲区。包含子查询的查询（使用`query`数据源）需要一个合并缓冲区（如果有一个子查询），如果有多个嵌套子查询层，则需要两个合并缓冲区。包含[`subtotals`](#关于subtotalSpec)的查询需要一个合并缓冲区。它们可以相互堆叠：一个包含多层嵌套子查询的groupBy查询，也使用小计，将需要三个合并缓冲区。
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ Druid中的数据源等价于关系型数据库中的表。 对于多租户场
|
|||
|
||||
### 定制数据的分布
|
||||
|
||||
Druid还通过提供可配置的数据分发方式来支持多租户。Druid的Historical进程可以配置成多个[层次(tier)](../Operations/role-configuration.md)，并且可以设置 [规则(rule)](../Operations/role-configuration.md) 来决定哪些部分进入哪些层。其中一个场景是最近的数据比旧的数据更容易被访问，分层使较新的数据段能够托管在功能更强大的硬件上，以获得更好的性能。最近的段的第二个副本可以复制到更便宜的硬件上（另一层），旧的段也可以存储在这个层上。
|
||||
Druid还通过提供可配置的数据分发方式来支持多租户。Druid的Historical进程可以配置成多个[层次(tier)](../operations/role-configuration.md)，并且可以设置 [规则(rule)](../operations/role-configuration.md) 来决定哪些部分进入哪些层。其中一个场景是最近的数据比旧的数据更容易被访问，分层使较新的数据段能够托管在功能更强大的硬件上，以获得更好的性能。最近的段的第二个副本可以复制到更便宜的硬件上（另一层），旧的段也可以存储在这个层上。
|
||||
|
||||
### 支持高查询并发
|
||||
|
||||
|
|
@ -52,4 +52,4 @@ Druid在内部将扫描段的请求存储在优先队列中。如果一个给定
|
|||
|
||||
Druid查询可以选择在[查询上下文](query-context.md)中设置`priority`标志。已知速度较慢的查询（下载或报告样式的查询）可以取消优先级，交互程度更高的查询可以具有更高的优先级。
|
||||
|
||||
Broker进程也可以专用于给定的层。例如，一组Broker进程可以专用于快速交互查询，另一组Broker进程可以专用于较慢的报告查询。Druid还提供了一个[Router](../design/Router.md)进程，可以根据各种查询参数（datasource、interval等）将查询路由到不同的Broker。
|
||||
Broker进程也可以专用于给定的层。例如，一组Broker进程可以专用于快速交互查询，另一组Broker进程可以专用于较慢的报告查询。Druid还提供了一个[Router](../design/router.md)进程，可以根据各种查询参数（datasource、interval等）将查询路由到不同的Broker。
|
||||
|
|
|
|||
|
|
@ -96,4 +96,4 @@ bin/post-index-task --file quickstart/tutorial/retention-index.json --url http:/
|
|||
相反，如果希望根据数据的生命周期保留数据（例如，保留从过去3个月到现在3个月的数据），则应定义一个周期性加载规则(Period Load Rule)。
|
||||
|
||||
### 进一步阅读
|
||||
[加载规则](../Operations/retainingOrDropData.md)
|
||||
[加载规则](../operations/retainingOrDropData.md)
|
||||
|
|
@ -15,7 +15,7 @@
|
|||
|
||||
本教程演示如何将现有段合并为较少但更大的段
|
||||
|
||||
因为每一个段都有一些内存和处理开销，所以有时减少段的总数是有益的。有关详细信息，请查阅[段大小优化](../Operations/segmentSizeOpt.md)。
|
||||
因为每一个段都有一些内存和处理开销，所以有时减少段的总数是有益的。有关详细信息，请查阅[段大小优化](../operations/segmentSizeOpt.md)。
|
||||
|
||||
本教程我们假设您已经按照[单服务器部署](../GettingStarted/chapter-3.md)中描述下载了Druid，并运行在本地机器上。
|
||||
|
||||
|
|
@ -149,4 +149,4 @@ Coordinator将旧的输入段标记为未使用需要一段时间，因此您可
|
|||
### 进一步阅读
|
||||
[任务文档](../DataIngestion/taskrefer.md)
|
||||
|
||||
[段优化](../Operations/segmentSizeOpt.md)
|
||||
[段优化](../operations/segmentSizeOpt.md)
|
||||
|
|
@ -41,7 +41,7 @@ Druid `docker-compose.yml` 示例使用单个环境文件来指定完整的Drui
|
|||
|
||||
运行 `docker-compose up` 启动附加shell的集群，或运行 `docker-compose up -d` 在后台运行集群。如果直接使用示例文件，这个命令应该从Druid安装目录中的 `distribution/docker/` 运行。
|
||||
|
||||
启动集群后，可以导航到 [http://localhost:8888](http://localhost/) 。服务于 [Druid控制台](../Operations/druid-console.md) 的 [Druid路由进程](../design/Router.md) 位于这个地址。
|
||||
启动集群后，可以导航到 [http://localhost:8888](http://localhost/) 。服务于 [Druid控制台](../operations/druid-console.md) 的 [Druid路由进程](../design/router.md) 位于这个地址。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ Druid Broker服务接收查询请求，并将其转发到集群中的其他部
|
|||
|
||||
如果您的使用场景具有复杂的扩展要求，则还可以选择不将Druid服务混合部署（例如，独立的Historical Server）。
|
||||
|
||||
[基本集群调整指南](../../Operations/basicClusterTuning.md)中的信息可以帮助您进行决策，并可以调整配置大小。
|
||||
[基本集群调整指南](../../operations/basicClusterTuning.md)中的信息可以帮助您进行决策，并可以调整配置大小。
|
||||
|
||||
#### 从单服务器环境迁移部署
|
||||
|
||||
|
|
@ -107,7 +107,7 @@ Query服务的硬件选择主要考虑可用的CPU、Broker服务的堆内和堆
|
|||
|
||||
对于CPU，可以选择接近于单服务器环境核数1/4的硬件。
|
||||
|
||||
[基本集群调优指南](../../Operations/basicClusterTuning.md)包含有关如何计算Broker和Router服务内存使用量的信息。
|
||||
[基本集群调优指南](../../operations/basicClusterTuning.md)包含有关如何计算Broker和Router服务内存使用量的信息。
|
||||
|
||||
### 选择操作系统
|
||||
|
||||
|
|
@ -152,7 +152,7 @@ cd apache-druid-0.17.0
|
|||
### 配置元数据存储和深度存储
|
||||
#### 从单服务器环境迁移部署
|
||||
|
||||
如果您已经有一个单服务器部署，并且希望在整个迁移过程中保留数据，请在更新元数据/深层存储配置之前，按照[元数据迁移](../../Operations/metadataMigration.md)和[深层存储迁移](../../Operations/DeepstorageMigration.md)中的说明进行操作。
|
||||
如果您已经有一个单服务器部署，并且希望在整个迁移过程中保留数据，请在更新元数据/深层存储配置之前，按照[元数据迁移](../../operations/metadataMigration.md)和[深层存储迁移](../../operations/DeepstorageMigration.md)中的说明进行操作。
|
||||
|
||||
这些指南针对使用Derby元数据存储和本地深度存储的单服务器部署。 如果您已经在单服务器集群中使用了非Derby元数据存储，则可以在新集群中可以继续使用当前的元数据存储。
|
||||
|
||||
|
|
@ -334,7 +334,7 @@ druid.indexer.fork.property.druid.processing.numThreads=1
|
|||
|
||||
`conf/druid/cluster`下的配置已经为此硬件确定了，一般情况下您无需做进一步的修改。
|
||||
|
||||
如果您选择了其他硬件，则[基本的集群调整指南](../../Operations/basicClusterTuning.md)可以帮助您调整配置大小。
|
||||
如果您选择了其他硬件，则[基本的集群调整指南](../../operations/basicClusterTuning.md)可以帮助您调整配置大小。
|
||||
|
||||
### 开启端口(如果使用了防火墙)
|
||||
|
||||
|
|
@ -410,7 +410,7 @@ bin/start-cluster-data-server
|
|||
bin/start-cluster-query-server
|
||||
```
|
||||
|
||||
您可以根据查询负载添加更多查询服务器。 如果增加了查询服务器的数量，请确保按照[基本集群调优指南](../../Operations/basicClusterTuning.md)中的说明调整Historical和Task上的连接池。
|
||||
您可以根据查询负载添加更多查询服务器。 如果增加了查询服务器的数量，请确保按照[基本集群调优指南](../../operations/basicClusterTuning.md)中的说明调整Historical和Task上的连接池。
|
||||
|
||||
### 加载数据
|
||||
|
||||
|
|
|
|||
|
|
@ -36,29 +36,38 @@ Druid 配置属性包括有从 _Nano-Quickstart_ 配置 （1 CPU, 4GB RAM） 到
|
|||
|
||||
## 第 1 步：安装 Druid
|
||||
|
||||
After confirming the [requirements](#requirements), follow these steps:
|
||||
|
||||
1. Download
|
||||
the [{{DRUIDVERSION}} release](https://www.apache.org/dyn/closer.cgi?path=/druid/{{DRUIDVERSION}}/apache-druid-{{DRUIDVERSION}}-bin.tar.gz).
|
||||
2. In your terminal, extract Druid and change directories to the distribution directory:
|
||||
当你确定你的系统已经满足 [安装要求](#安装要求) 的所有内容后，请按照下面的步骤：
|
||||
|
||||
1. 下载
|
||||
下载地址为： [{{DRUIDVERSION}} 发布（release）](https://www.apache.org/dyn/closer.cgi?path=/druid/{{DRUIDVERSION}}/apache-druid-{{DRUIDVERSION}}-bin.tar.gz).
|
||||
2. 在你的控制台中，将下载的压缩包进行解压到当前目录，并且进入到解压的目录，或者你将目录移动到你希望部署的的目录中：
|
||||
```bash
|
||||
tar -xzf apache-druid-{{DRUIDVERSION}}-bin.tar.gz
|
||||
cd apache-druid-{{DRUIDVERSION}}
|
||||
```
|
||||
In the directory, you'll find `LICENSE` and `NOTICE` files and subdirectories for executable files, configuration files, sample data and more.
|
||||
在解压后的目录中，你会看到 `LICENSE` 和 `NOTICE` 文件，以及一些子目录，在这些子目录中保存有可执行文件，配置文件，示例数据和其他的内容。
|
||||
|
||||
在安装包中可能有下面的文件和用途供参考：
|
||||
|
||||
* `LICENSE`和`NOTICE` - 文件
|
||||
* `bin/*` - 启动或停止的脚本
|
||||
* `conf/*` - 用于单节点部署和集群部署的示例配置
|
||||
* `extensions/*` - Druid 核心扩展
|
||||
* `hadoop-dependencies/*` - Druid Hadoop 依赖
|
||||
* `lib/*` - Druid 核心库和依赖
|
||||
* `quickstart/*` - 配置文件，样例数据，以及快速入门教材的其他文件
|
||||
|
||||
## 第 2 步：启动 Druid 服务
|
||||
|
||||
Start up Druid services using the `micro-quickstart` single-machine configuration.
|
||||
针对一台计算机，你可以使用 `micro-quickstart` 配置来启动所有 Druid 的服务。
|
||||
|
||||
From the apache-druid-{{DRUIDVERSION}} package root, run the following command:
|
||||
在 apache-druid-{{DRUIDVERSION}} 包的根目录下，运行下面的命令：
|
||||
|
||||
```bash
|
||||
./bin/start-micro-quickstart
|
||||
```
|
||||
|
||||
This brings up instances of ZooKeeper and the Druid services:
|
||||
上面的命令将会启动 ZooKeeper 和 Druid 服务：
|
||||
|
||||
```bash
|
||||
$ ./bin/start-micro-quickstart
|
||||
|
|
@ -70,23 +79,29 @@ $ ./bin/start-micro-quickstart
|
|||
[Fri May 3 11:40:50 2019] Running command[middleManager], logging to[/apache-druid-{{DRUIDVERSION}}/var/sv/middleManager.log]: bin/run-druid middleManager conf/druid/single-server/micro-quickstart
|
||||
```
|
||||
|
||||
All persistent state, such as the cluster metadata store and segments for the services, are kept in the `var` directory under
|
||||
the Druid root directory, apache-druid-{{DRUIDVERSION}}. Each service writes to a log file under `var/sv`, as noted in the startup script output above.
|
||||
如上面输出的内容表示的，集群元数据存储（cluster metadata store） 和服务段（segments for the service）都会保存在 Druid 根目录下面的 `var` 目录中。
|
||||
这个 Druid 的根目录就是 apache-druid-{{DRUIDVERSION}}，换句话说就是你最开始解压并且既然怒的目录。
|
||||
|
||||
At any time, you can revert Druid to its original, post-installation state by deleting the entire `var` directory. You may
|
||||
want to do this, for example, between Druid tutorials or after experimentation, to start with a fresh instance.
|
||||
所有的服务将会把日志写入到 `var/sv` 目录中，同时也会将脚本的控制台输出按照上面的格式进行输出。
|
||||
|
||||
To stop Druid at any time, use CTRL-C in the terminal. This exits the `bin/start-micro-quickstart` script and
|
||||
terminates all Druid processes.
|
||||
在任何时候，如果你删除 `var` 目录的话，那你按照的 Druid 实例将会返回到原始初始化后的状态。
|
||||
|
||||
例如，如果你在完成了一个 Druid 的展示或者数据处理后希望开始一个全新完整的实例，那么你可以直接删除 `var` 目录就可以了。
|
||||
|
||||
如果你希望推出当前 Druid 的实例的话，在终端中使用快捷键 CTRL-C 来退出当前运行的模式。这个命令将会退出 `bin/start-micro-quickstart` 脚本，并且终止所有 Druid 的进程。
|
||||
|
||||
|
||||
## 第 3 步：访问 Druid 控制台
|
||||
|
||||
After the Druid services finish startup, open the [Druid console](../operations/druid-console.md) at [http://localhost:8888](http://localhost:8888).
|
||||
当 Druid 的进程完全启动后，打开 [Druid 控制台（console）](../operations/druid-console.md) 。访问的地址为： [http://localhost:8888](http://localhost:8888) 默认的使用端口为 8888。
|
||||
|
||||
|
||||
|
||||
It may take a few seconds for all Druid services to finish starting, including the [Druid router](../design/router.md), which serves the console. If you attempt to open the Druid console before startup is complete, you may see errors in the browser. Wait a few moments and try again.
|
||||
整个过程可能还需要耗费几秒钟的时间等待所有的 Druid 服务启动，包括 [Druid router](../design/router.md) 这个服务。
|
||||
|
||||
在 Druid 中 router 服务是提供控制台访问的的服务。
|
||||
|
||||
如果在所有 Druid 服务器都完全启动之前尝试访问控制台的话，那么很有可能会得到浏览器的房屋错误提示信息，请等待一些时间再尝试访问。
|
||||
|
||||
|
||||
## 第 4 步：导入数据
|
||||
|
|
@ -240,65 +255,7 @@ running the `bin/start-micro-quickstart` script again. You will likely want to d
|
|||
since in them you will create the same wikipedia datasource.
|
||||
|
||||
|
||||
##### 硬件
|
||||
|
||||
Druid安装包提供了几个[单服务器配置](./chapter-3.md)的示例，以及使用这些配置启动Druid进程的脚本。
|
||||
|
||||
如果您正在使用便携式等小型计算机上运行服务，则配置为4CPU/16GB RAM环境的`micro-quickstart`配置是一个不错的选择。
|
||||
|
||||
如果您打算在本教程之外使用单机部署进行进一步试验评估，则建议使用比`micro-quickstart`更大的配置。
|
||||
|
||||
#### 入门开始
|
||||
|
||||
[下载](https://www.apache.org/dyn/closer.cgi?path=/druid/0.17.0/apache-druid-0.17.0-bin.tar.gz)Druid最新0.17.0release安装包
|
||||
|
||||
在终端中运行以下命令来提取Druid
|
||||
|
||||
```json
|
||||
tar -xzf apache-druid-0.17.0-bin.tar.gz
|
||||
cd apache-druid-0.17.0
|
||||
```
|
||||
|
||||
在安装包中有以下文件：
|
||||
|
||||
* `LICENSE`和`NOTICE`文件
|
||||
* `bin/*` - 启停等脚本
|
||||
* `conf/*` - 用于单节点部署和集群部署的示例配置
|
||||
* `extensions/*` - Druid核心扩展
|
||||
* `hadoop-dependencies/*` - Druid Hadoop依赖
|
||||
* `lib/*` - Druid核心库和依赖
|
||||
* `quickstart/*` - 配置文件，样例数据，以及快速入门教材的其他文件
|
||||
|
||||
#### 启动服务
|
||||
|
||||
以下命令假定您使用的是`micro-quickstart`单机配置，如果使用的是其他配置，在`bin`目录下有每一种配置对应的脚本，如`bin/start-single-server-small`
|
||||
|
||||
在`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
|
||||
[Fri May 3 11:40:50 2019] Running command[broker], logging to[/apache-druid-0.17.0/var/sv/broker.log]: bin/run-druid broker conf/druid/single-server/micro-quickstart
|
||||
[Fri May 3 11:40:50 2019] Running command[router], logging to[/apache-druid-0.17.0/var/sv/router.log]: bin/run-druid router conf/druid/single-server/micro-quickstart
|
||||
[Fri May 3 11:40:50 2019] Running command[historical], logging to[/apache-druid-0.17.0/var/sv/historical.log]: bin/run-druid historical conf/druid/single-server/micro-quickstart
|
||||
[Fri May 3 11:40:50 2019] Running command[middleManager], logging to[/apache-druid-0.17.0/var/sv/middleManager.log]: bin/run-druid middleManager conf/druid/single-server/micro-quickstart
|
||||
```
|
||||
|
||||
所有的状态（例如集群元数据存储和服务的segment文件）将保留在`apache-druid-0.17.0`软件包根目录下的`var`目录中, 服务的日志位于 `var/sv`。
|
||||
|
||||
稍后，如果您想停止服务，请按`CTRL-C`退出`bin/start-micro-quickstart`脚本，该脚本将终止Druid进程。
|
||||
|
||||
集群启动后，可以访问[http://localhost:8888](http://localhost:8888)来Druid控制台，控制台由Druid Router进程启动。
|
||||
|
||||
|
||||
|
||||
所有Druid进程完全启动需要花费几秒钟。 如果在启动服务后立即打开控制台，则可能会看到一些可以安全忽略的错误。
|
||||
|
||||
#### 加载数据
|
||||
##### 教程使用的数据集
|
||||
|
|
@ -368,7 +325,7 @@ $ ./bin/start-micro-quickstart
|
|||
|
||||
一旦每个服务都启动，您就可以加载数据了。
|
||||
|
||||
##### 重置Kafka
|
||||
##### 重置 Kafka
|
||||
|
||||
如果您完成了[教程：从Kafka加载流数据](../Tutorials/chapter-2.md)并希望重置集群状态，则还应该清除所有Kafka状态。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue