GitHub
commit
e3883982e1
|
|
@ -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) 位于这个地址。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,60 +0,0 @@
|
|||
<!-- toc -->
|
||||
|
||||
<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
|
||||
<ins class="adsbygoogle"
|
||||
style="display:block; text-align:center;"
|
||||
data-ad-layout="in-article"
|
||||
data-ad-format="fluid"
|
||||
data-ad-client="ca-pub-8828078415045620"
|
||||
data-ad-slot="7586680510"></ins>
|
||||
<script>
|
||||
(adsbygoogle = window.adsbygoogle || []).push({});
|
||||
</script>
|
||||
|
||||
### Druid是什么
|
||||
|
||||
Apache Druid是一个实时分析型数据库，旨在对大型数据集进行快速的查询分析（"[OLAP](https://en.wikipedia.org/wiki/Online_analytical_processing)"查询)。Druid最常被当做数据库来用以支持实时摄取、高性能查询和高稳定运行的应用场景，同时，Druid也通常被用来助力分析型应用的图形化界面，或者当做需要快速聚合的高并发后端API，Druid最适合应用于面向事件类型的数据。
|
||||
|
||||
Druid通常应用于以下场景：
|
||||
|
||||
* 点击流分析（Web端和移动端）
|
||||
* 网络监测分析（网络性能监控）
|
||||
* 服务指标存储
|
||||
* 供应链分析（制造类指标）
|
||||
* 应用性能指标分析
|
||||
* 数字广告分析
|
||||
* 商务智能 / OLAP
|
||||
|
||||
Druid的核心架构吸收和结合了[数据仓库](https://en.wikipedia.org/wiki/Data_warehouse)、[时序数据库](https://en.wikipedia.org/wiki/Time_series_database)以及[检索系统](https://en.wikipedia.org/wiki/Search_engine_(computing))的优势，其主要特征如下：
|
||||
|
||||
1. **列式存储**，Druid使用列式存储，这意味着在一个特定的数据查询中它只需要查询特定的列，这样极地提高了部分列查询场景的性能。另外，每一列数据都针对特定数据类型做了优化存储，从而支持快速的扫描和聚合。
|
||||
2. **可扩展的分布式系统**，Druid通常部署在数十到数百台服务器的集群中，并且可以提供每秒数百万条记录的接收速率，数万亿条记录的保留存储以及亚秒级到几秒的查询延迟。
|
||||
3. **大规模并行处理**，Druid可以在整个集群中并行处理查询。
|
||||
4. **实时或批量摄取**，Druid可以实时（已经被摄取的数据可立即用于查询）或批量摄取数据。
|
||||
5. **自修复、自平衡、易于操作**，作为集群运维操作人员，要伸缩集群只需添加或删除服务，集群就会在后台自动重新平衡自身，而不会造成任何停机。如果任何一台Druid服务器发生故障，系统将自动绕过损坏。 Druid设计为7*24全天候运行，无需出于任何原因而导致计划内停机，包括配置更改和软件更新。
|
||||
6. **不会丢失数据的云原生容错架构**，一旦Druid摄取了数据，副本就安全地存储在[深度存储介质](Design/../chapter-1.md)（通常是云存储，HDFS或共享文件系统）中。即使某个Druid服务发生故障，也可以从深度存储中恢复您的数据。对于仅影响少数Druid服务的有限故障，副本可确保在系统恢复时仍然可以进行查询。
|
||||
7. **用于快速过滤的索引**，Druid使用[CONCISE](https://arxiv.org/pdf/1004.0403.pdf)或[Roaring](https://roaringbitmap.org/)压缩的位图索引来创建索引，以支持快速过滤和跨多列搜索。
|
||||
8. **基于时间的分区**，Druid首先按时间对数据进行分区，另外同时可以根据其他字段进行分区。这意味着基于时间的查询将仅访问与查询时间范围匹配的分区，这将大大提高基于时间的数据的性能。
|
||||
9. **近似算法**，Druid应用了近似count-distinct，近似排序以及近似直方图和分位数计算的算法。这些算法占用有限的内存使用量，通常比精确计算要快得多。对于精度要求比速度更重要的场景，Druid还提供了精确count-distinct和精确排序。
|
||||
10. **摄取时自动汇总聚合**，Druid支持在数据摄取阶段可选地进行数据汇总，这种汇总会部分预先聚合您的数据，并可以节省大量成本并提高性能。
|
||||
|
||||
### 什么场景下应该使用Druid
|
||||
|
||||
许多公司都已经将Druid应用于多种不同的应用场景，详情可查看[Powered by Apache Druid](https://druid.apache.org/druid-powered)页面。
|
||||
|
||||
如果您的使用场景符合以下的几个特征，那么Druid是一个非常不错的选择：
|
||||
|
||||
* 数据插入频率比较高，但较少更新数据
|
||||
* 大多数查询场景为聚合查询和分组查询（GroupBy），同时还有一定得检索与扫描查询
|
||||
* 将数据查询延迟目标定位100毫秒到几秒钟之间
|
||||
* 数据具有时间属性（Druid针对时间做了优化和设计）
|
||||
* 在多表场景下，每次查询仅命中一个大的分布式表，查询又可能命中多个较小的lookup表
|
||||
* 场景中包含高基维度数据列（例如URL，用户ID等），并且需要对其进行快速计数和排序
|
||||
* 需要从Kafka、HDFS、对象存储（如Amazon S3）中加载数据
|
||||
|
||||
如果您的使用场景符合以下特征，那么使用Druid可能是一个不好的选择：
|
||||
|
||||
* 根据主键对现有数据进行低延迟更新操作。Druid支持流式插入，但不支持流式更新（更新操作是通过后台批处理作业完成）
|
||||
* 延迟不重要的离线数据系统
|
||||
* 场景中包括大连接（将一个大事实表连接到另一个大事实表），并且可以接受花费很长时间来完成这些查询
|
||||
|
||||
|
|
@ -1,163 +0,0 @@
|
|||
<!-- toc -->
|
||||
<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
|
||||
<ins class="adsbygoogle"
|
||||
style="display:block; text-align:center;"
|
||||
data-ad-layout="in-article"
|
||||
data-ad-format="fluid"
|
||||
data-ad-client="ca-pub-8828078415045620"
|
||||
data-ad-slot="7586680510"></ins>
|
||||
<script>
|
||||
(adsbygoogle = window.adsbygoogle || []).push({});
|
||||
</script>
|
||||
|
||||
### 快速开始
|
||||
|
||||
在本快速入门教程中，我们将下载Druid并将其安装在一台服务器上，完成初始安装后，向集群中加载数据。
|
||||
|
||||
在开始快速入门之前，阅读[Druid概述](./chapter-1.md)和[数据摄取概述](../DataIngestion/index.md)会很有帮助，因为当前教程会引用这些页面上讨论的概念。
|
||||
|
||||
#### 预备条件
|
||||
##### 软件
|
||||
* **Java 8(8u92+)**
|
||||
* Linux, Mac OS X, 或者其他类UNIX系统（Windows不支持）
|
||||
|
||||
> [!WARNING]
|
||||
> Druid服务运行依赖Java 8，可以使用环境变量`DRUID_JAVA_HOME`或`JAVA_HOME`指定在何处查找Java,有关更多详细信息，请运行`verify-java`脚本。
|
||||
|
||||
##### 硬件
|
||||
|
||||
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进程完全启动需要花费几秒钟。 如果在启动服务后立即打开控制台，则可能会看到一些可以安全忽略的错误。
|
||||
|
||||
#### 加载数据
|
||||
##### 教程使用的数据集
|
||||
|
||||
对于以下数据加载教程，我们提供了一个示例数据文件，其中包含2015年9月12日发生的Wikipedia页面编辑事件。
|
||||
|
||||
该样本数据位于Druid包根目录的`quickstart/tutorial/wikiticker-2015-09-12-sampled.json.gz`中,页面编辑事件作为JSON对象存储在文本文件中。
|
||||
|
||||
示例数据包含以下几列，示例事件如下所示：
|
||||
|
||||
* added
|
||||
* channel
|
||||
* cityName
|
||||
* comment
|
||||
* countryIsoCode
|
||||
* countryName
|
||||
* deleted
|
||||
* delta
|
||||
* isAnonymous
|
||||
* isMinor
|
||||
* isNew
|
||||
* isRobot
|
||||
* isUnpatrolled
|
||||
* metroCode
|
||||
* namespace
|
||||
* page
|
||||
* regionIsoCode
|
||||
* regionName
|
||||
* user
|
||||
|
||||
```json
|
||||
{
|
||||
"timestamp":"2015-09-12T20:03:45.018Z",
|
||||
"channel":"#en.wikipedia",
|
||||
"namespace":"Main",
|
||||
"page":"Spider-Man's powers and equipment",
|
||||
"user":"foobar",
|
||||
"comment":"/* Artificial web-shooters */",
|
||||
"cityName":"New York",
|
||||
"regionName":"New York",
|
||||
"regionIsoCode":"NY",
|
||||
"countryName":"United States",
|
||||
"countryIsoCode":"US",
|
||||
"isAnonymous":false,
|
||||
"isNew":false,
|
||||
"isMinor":false,
|
||||
"isRobot":false,
|
||||
"isUnpatrolled":false,
|
||||
"added":99,
|
||||
"delta":99,
|
||||
"deleted":0,
|
||||
}
|
||||
```
|
||||
|
||||
##### 数据加载
|
||||
|
||||
以下教程演示了将数据加载到Druid的各种方法，包括批处理和流处理用例。 所有教程均假定您使用的是上面提到的`micro-quickstart`单机配置。
|
||||
|
||||
* [加载本地文件](../Tutorials/chapter-1.md) - 本教程演示了如何使用Druid的本地批处理摄取来执行批文件加载
|
||||
* [从Kafka加载流数据](../Tutorials/chapter-2.md) - 本教程演示了如何从Kafka主题加载流数据
|
||||
* [从Hadoop加载数据](../Tutorials/chapter-3.md) - 本教程演示了如何使用远程Hadoop集群执行批处理文件加载
|
||||
* [编写一个自己的数据摄取规范](../Tutorials/chapter-10.md) - 本教程演示了如何编写新的数据摄取规范并使用它来加载数据
|
||||
|
||||
##### 重置集群状态
|
||||
|
||||
如果要在清理服务后重新启动，请删除`var`目录，然后再次运行`bin/start-micro-quickstart`脚本。
|
||||
|
||||
一旦每个服务都启动，您就可以加载数据了。
|
||||
|
||||
##### 重置Kafka
|
||||
|
||||
如果您完成了[教程：从Kafka加载流数据](../Tutorials/chapter-2.md)并希望重置集群状态，则还应该清除所有Kafka状态。
|
||||
|
||||
在停止ZooKeeper和Druid服务之前，使用`CTRL-C`关闭`Kafka Broker`，然后删除`/tmp/kafka-logs`中的Kafka日志目录：
|
||||
|
||||
```
|
||||
rm -rf /tmp/kafka-logs
|
||||
```
|
||||
|
|
@ -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上的连接池。
|
||||
|
||||
### 加载数据
|
||||
|
||||
|
|
|
|||
|
|
@ -5,9 +5,11 @@
|
|||
|
||||
---
|
||||
|
||||
[中文社区](https://www.ossez.com/tag/druid) |
|
||||
[中文文档](https://druid.ossez.com/) |
|
||||
[官方网站](https://druid.apache.org/) |
|
||||
[官方社区（英文）](https://www.druidforum.org/) |
|
||||
[官方文档（英文）](https://druid.apache.org/docs/latest/design/) |
|
||||
[官方网站](https://druid.apache.org/) |
|
||||
[开发者邮件地址](https://lists.apache.org/list.html?dev@druid.apache.org) |
|
||||
[用户邮件地址](https://groups.google.com/forum/#!forum/druid-user) |
|
||||
[Slack](https://s.apache.org/slack-invite) |
|
||||
|
|
|
|||
|
|
@ -14,7 +14,6 @@
|
|||
* [官方原版英文文档](https://druid.apache.org/docs/latest/design/)
|
||||
|
||||
* [新手入门]()
|
||||
* [Druid介绍](GettingStarted/chapter-1.md)
|
||||
* [快速开始](GettingStarted/chapter-2.md)
|
||||
* [Docker](tutorials/docker.md)
|
||||
* [单服务器部署](GettingStarted/chapter-3.md)
|
||||
|
|
@ -43,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)
|
||||
|
|
@ -104,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上的连接池。
|
||||
|
||||
### 加载数据
|
||||
|
||||
|
|
|
|||
|
|
@ -1,89 +1,73 @@
|
|||
---
|
||||
id: index
|
||||
title: "Quickstart"
|
||||
---
|
||||
# 快速开始
|
||||
|
||||
<!--
|
||||
~ Licensed to the Apache Software Foundation (ASF) under one
|
||||
~ or more contributor license agreements. See the NOTICE file
|
||||
~ distributed with this work for additional information
|
||||
~ regarding copyright ownership. The ASF licenses this file
|
||||
~ to you under the Apache License, Version 2.0 (the
|
||||
~ "License"); you may not use this file except in compliance
|
||||
~ with the License. You may obtain a copy of the License at
|
||||
~
|
||||
~ http://www.apache.org/licenses/LICENSE-2.0
|
||||
~
|
||||
~ Unless required by applicable law or agreed to in writing,
|
||||
~ software distributed under the License is distributed on an
|
||||
~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
~ KIND, either express or implied. See the License for the
|
||||
~ specific language governing permissions and limitations
|
||||
~ under the License.
|
||||
-->
|
||||
在本快速开始的内容部分，将向你介绍有关如何开始使用 Apache Druid 和一些相关的基本特性。
|
||||
当你按照给出的步骤完成操作后，你将能够安装并且运行 Druid 和使用自带的批量数据摄取（ingestion）特性向安装成功的 Druid 实例中导入数据。
|
||||
|
||||
在开始我们下面的步骤之前，请先阅读 [Druid 概述](../design/index.md) 和 [数据摄取（ingestion）概述](../ingestion/index.md) 中的内容。
|
||||
因为下面使用的步骤将会参照在前面 2 个 页面中提到过的一些概念和定义。
|
||||
|
||||
## 安装要求
|
||||
|
||||
你可以按照后续的步骤在一个相对机器性能比较小的计算机上进行安装。例如我们说的笔记本电脑（4 CPU 和 16 GB 的内存）。
|
||||
|
||||
针对不同的机器性能和安装条件，Druid 有一系列的安装配置属性。例如, `micro-quickstart` 配置属性对需要进行 Druid 评估时候的计算机性能进行了配置。
|
||||
如果你希望对 Druid 的计算性能进行评估或者对计算能力进行调整的话，你可能需要更大和更好性能的计算机并且配置属性（profile）。
|
||||
|
||||
Druid 配置属性包括有从 _Nano-Quickstart_ 配置 （1 CPU, 4GB RAM） 到 _X-Large_ 配置（64 CPU, 512GB RAM）。
|
||||
|
||||
有关更多的配置信息，请参考 [独立服务器部署](../operations/single-server.md) 页面中的内容
|
||||
另外，如果你希望对 Druid 进行集群部署的话，请参考 [集群服务器部署](./cluster.md) 页面中的内容来了解更多有关 Druid 集群部署中的配置。
|
||||
|
||||
针对运行 Druid 的计算机，你需要完成下面的软件配置：
|
||||
|
||||
* Linux， Mac OS X， 或者其他基于 Unix 的操作系统（**不能部署在 Windows 上**）
|
||||
* Java 8, Update 92 或者后续版本 (8u92+)
|
||||
|
||||
> Druid 官方只支持 Java 8 only。对其他主要的 Java 版本进行支持目前还主要是实验性的。
|
||||
|
||||
> Druid 通过计算机中的环境变量 `JAVA_HOME` 或者 `DRUID_JAVA_HOME` 来找到安装的 Java 版本。如果你的计算机中安装有多个版本的 Java，那么你可以通过
|
||||
> 设置环境变量 `DRUID_JAVA_HOME` 来让你安装的 Druid 实例找到相应的 Java 版本。
|
||||
> 可以运行 Druid 程序中的 `bin/verify-java` 脚本来查看当前运行的 Java 版本。
|
||||
|
||||
在将 Druid 安装到生产环境的时候，你需要注意 Druid 实例运行的用户账号是什么。因为 Druid 控制台用户的权限和当前 Druid 实例运行的用户权限是相同的。
|
||||
例如，如果你使用 Druid 的控制台对文件进行浏览的话，那么操作系统通只显示这个用户能够访问到的文件，或者说有权限进行查看的文件进行显示。
|
||||
一般来说，我们是不希望 Druid 以 root 用户的权限来运行的。因此针对 Druid 的安装环境，可以考虑针对 Druid 实例，在操作系统中创建一个只供 Druid 运行的用户。
|
||||
|
||||
|
||||
This quickstart gets you started with Apache Druid and introduces you to some of its basic features.
|
||||
Following these steps, you will install Druid and load sample
|
||||
data using its native batch ingestion feature.
|
||||
## 第 1 步：安装 Druid
|
||||
|
||||
Before starting, you may want to read the [general Druid overview](../design/index.md) and
|
||||
[ingestion overview](../ingestion/index.md), as the tutorials refer to concepts discussed on those pages.
|
||||
|
||||
## Requirements
|
||||
|
||||
You can follow these steps on a relatively small machine, such as a laptop with around 4 CPU and 16 GB of RAM.
|
||||
|
||||
Druid comes with several startup configuration profiles for a range of machine sizes.
|
||||
The `micro-quickstart`configuration profile shown here is suitable for evaluating Druid. If you want to
|
||||
try out Druid's performance or scaling capabilities, you'll need a larger machine and configuration profile.
|
||||
|
||||
The configuration profiles included with Druid range from the even smaller _Nano-Quickstart_ configuration (1 CPU, 4GB RAM)
|
||||
to the _X-Large_ configuration (64 CPU, 512GB RAM). For more information, see
|
||||
[Single server deployment](../operations/single-server.md). Alternatively, see [Clustered deployment](./cluster.md) for
|
||||
information on deploying Druid services across clustered machines.
|
||||
|
||||
The software requirements for the installation machine are:
|
||||
|
||||
* Linux, Mac OS X, or other Unix-like OS (Windows is not supported)
|
||||
* Java 8, Update 92 or later (8u92+)
|
||||
|
||||
> Druid officially supports Java 8 only. Support for later major versions of Java is currently in experimental status.
|
||||
|
||||
> Druid relies on the environment variables `JAVA_HOME` or `DRUID_JAVA_HOME` to find Java on the machine. You can set
|
||||
`DRUID_JAVA_HOME` if there is more than one instance of Java. To verify Java requirements for your environment, run the
|
||||
`bin/verify-java` script.
|
||||
|
||||
Before installing a production Druid instance, be sure to consider the user account on the operating system under
|
||||
which Druid will run. This is important because any Druid console user will have, effectively, the same permissions as
|
||||
that user. So, for example, the file browser UI will show console users the files that the underlying user can
|
||||
access. In general, avoid running Druid as root user. Consider creating a dedicated user account for running Druid.
|
||||
|
||||
## Step 1. Install 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` 文件，以及一些子目录，在这些子目录中保存有可执行文件，配置文件，示例数据和其他的内容。
|
||||
|
||||
## Step 2: Start up Druid services
|
||||
在安装包中可能有下面的文件和用途供参考：
|
||||
|
||||
Start up Druid services using the `micro-quickstart` single-machine configuration.
|
||||
* `LICENSE`和`NOTICE` - 文件
|
||||
* `bin/*` - 启动或停止的脚本
|
||||
* `conf/*` - 用于单节点部署和集群部署的示例配置
|
||||
* `extensions/*` - Druid 核心扩展
|
||||
* `hadoop-dependencies/*` - Druid Hadoop 依赖
|
||||
* `lib/*` - Druid 核心库和依赖
|
||||
* `quickstart/*` - 配置文件，样例数据，以及快速入门教材的其他文件
|
||||
|
||||
From the apache-druid-{{DRUIDVERSION}} package root, run the following command:
|
||||
## 第 2 步：启动 Druid 服务
|
||||
|
||||
针对一台计算机，你可以使用 `micro-quickstart` 配置来启动所有 Druid 的服务。
|
||||
|
||||
在 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
|
||||
|
|
@ -95,26 +79,32 @@ $ ./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 的进程。
|
||||
|
||||
|
||||
## Step 3. Open the Druid console
|
||||
## 第 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 服务器都完全启动之前尝试访问控制台的话，那么很有可能会得到浏览器的房屋错误提示信息，请等待一些时间再尝试访问。
|
||||
|
||||
|
||||
## Step 4. Load data
|
||||
## 第 4 步：导入数据
|
||||
|
||||
|
||||
Ingestion specs define the schema of the data Druid reads and stores. You can write ingestion specs by hand or using the _data loader_,
|
||||
|
|
@ -224,7 +214,7 @@ in the Druid root directory represents Wikipedia page edits for a given day.
|
|||
A successful task means that one or more segments have been built and are now picked up by our data servers.
|
||||
|
||||
|
||||
## Step 5. Query the data
|
||||
## 第 5 步：查询数据
|
||||
|
||||
You can now see the data as a datasource in the console and try out a query, as follows:
|
||||
|
||||
|
|
@ -248,7 +238,7 @@ Congratulations! You've gone from downloading Druid to querying data in just one
|
|||
section for what to do next.
|
||||
|
||||
|
||||
## Next steps
|
||||
## 下一步
|
||||
|
||||
After finishing the quickstart, check out the [query tutorial](../tutorials/tutorial-query.md) to further explore
|
||||
Query features in the Druid console.
|
||||
|
|
@ -266,3 +256,81 @@ since in them you will create the same wikipedia datasource.
|
|||
|
||||
|
||||
|
||||
|
||||
#### 加载数据
|
||||
##### 教程使用的数据集
|
||||
|
||||
对于以下数据加载教程，我们提供了一个示例数据文件，其中包含2015年9月12日发生的Wikipedia页面编辑事件。
|
||||
|
||||
该样本数据位于Druid包根目录的`quickstart/tutorial/wikiticker-2015-09-12-sampled.json.gz`中,页面编辑事件作为JSON对象存储在文本文件中。
|
||||
|
||||
示例数据包含以下几列，示例事件如下所示：
|
||||
|
||||
* added
|
||||
* channel
|
||||
* cityName
|
||||
* comment
|
||||
* countryIsoCode
|
||||
* countryName
|
||||
* deleted
|
||||
* delta
|
||||
* isAnonymous
|
||||
* isMinor
|
||||
* isNew
|
||||
* isRobot
|
||||
* isUnpatrolled
|
||||
* metroCode
|
||||
* namespace
|
||||
* page
|
||||
* regionIsoCode
|
||||
* regionName
|
||||
* user
|
||||
|
||||
```json
|
||||
{
|
||||
"timestamp":"2015-09-12T20:03:45.018Z",
|
||||
"channel":"#en.wikipedia",
|
||||
"namespace":"Main",
|
||||
"page":"Spider-Man's powers and equipment",
|
||||
"user":"foobar",
|
||||
"comment":"/* Artificial web-shooters */",
|
||||
"cityName":"New York",
|
||||
"regionName":"New York",
|
||||
"regionIsoCode":"NY",
|
||||
"countryName":"United States",
|
||||
"countryIsoCode":"US",
|
||||
"isAnonymous":false,
|
||||
"isNew":false,
|
||||
"isMinor":false,
|
||||
"isRobot":false,
|
||||
"isUnpatrolled":false,
|
||||
"added":99,
|
||||
"delta":99,
|
||||
"deleted":0,
|
||||
}
|
||||
```
|
||||
|
||||
##### 数据加载
|
||||
|
||||
以下教程演示了将数据加载到Druid的各种方法，包括批处理和流处理用例。 所有教程均假定您使用的是上面提到的`micro-quickstart`单机配置。
|
||||
|
||||
* [加载本地文件](../Tutorials/chapter-1.md) - 本教程演示了如何使用Druid的本地批处理摄取来执行批文件加载
|
||||
* [从Kafka加载流数据](../Tutorials/chapter-2.md) - 本教程演示了如何从Kafka主题加载流数据
|
||||
* [从Hadoop加载数据](../Tutorials/chapter-3.md) - 本教程演示了如何使用远程Hadoop集群执行批处理文件加载
|
||||
* [编写一个自己的数据摄取规范](../Tutorials/chapter-10.md) - 本教程演示了如何编写新的数据摄取规范并使用它来加载数据
|
||||
|
||||
##### 重置集群状态
|
||||
|
||||
如果要在清理服务后重新启动，请删除`var`目录，然后再次运行`bin/start-micro-quickstart`脚本。
|
||||
|
||||
一旦每个服务都启动，您就可以加载数据了。
|
||||
|
||||
##### 重置 Kafka
|
||||
|
||||
如果您完成了[教程：从Kafka加载流数据](../Tutorials/chapter-2.md)并希望重置集群状态，则还应该清除所有Kafka状态。
|
||||
|
||||
在停止ZooKeeper和Druid服务之前，使用`CTRL-C`关闭`Kafka Broker`，然后删除`/tmp/kafka-logs`中的Kafka日志目录：
|
||||
|
||||
```
|
||||
rm -rf /tmp/kafka-logs
|
||||
```
|
||||
|
|
|
|||
Loading…
Reference in New Issue