Merge pull request #23 from cwiki-us-docs/feature/getting_started

调整目录结构
This commit is contained in:
YuCheng Hu 2021-07-27 13:03:42 -04:00 committed by GitHub
commit c19959e1e9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
20 changed files with 829 additions and 504 deletions

View File

@ -34,8 +34,8 @@
* [架构设计]() * [架构设计]()
* [整体设计](design/Design.md) * [整体设计](design/Design.md)
* [段设计](design/Segments.md) * [段设计](design/segments.md)
* [进程与服务](design/Processes.md) * [进程与服务](design/processes.md)
* [Coordinator](design/Coordinator.md) * [Coordinator](design/Coordinator.md)
* [Overlord](design/Overlord.md) * [Overlord](design/Overlord.md)
* [Historical](design/Historical.md) * [Historical](design/Historical.md)

View File

@ -6,11 +6,30 @@
- [Druid 介绍](design/index.md) - [Druid 介绍](design/index.md)
- [快速开始](tutorials/index.md) - [快速开始](tutorials/index.md)
- [Docker 容器](tutorials/docker.md) - [Docker 容器](tutorials/docker.md)
- [独立服务器方式部署](operations/single-server.md)
- [集群方式部署](tutorials/cluster.md)
- 教程Tutorials
- [原生文件载入数据](tutorials/tutorial-batch.md)
- [从 Apache Kafka 载入数据](tutorials/tutorial-kafka.md)
- [从 Apache Hadoop 载入数据](tutorials/tutorial-batch-hadoop.md)
- [查询数据](tutorials/tutorial-query.md)
- [回滚](tutorials/tutorial-rollup.md)
- [配置数据保存时间](tutorials/tutorial-retention.md)
- [更新已经存在的数据](tutorials/tutorial-update-data.md)
- [压缩段](tutorials/tutorial-compaction.md)
- [删除数据](tutorials/tutorial-delete-data.md)
- [写入数据导入属性](tutorials/tutorial-ingestion-spec.md)
- [转换导入数据](tutorials/tutorial-transform-spec.md)
- [Kerberized HDFS 深度存储](tutorials/tutorial-kerberos-hadoop.md)
- 设计Design - 设计Design
- [JWT](jwt/README.md) - [设计](design/architecture.md)
- [MessagePack](message-pack/index.md) - [Segments](design/segments.md)
- [Protocol Buffers](protocol-buffers/index.md) - [进程和服务](design/processes.md)
- [深度存储](dependencies/deep-storage.md)
- [元数据存储](dependencies/metadata-storage.md)
- [ZooKeeper](dependencies/zookeeper.md)
- 摄取Ingestion - 摄取Ingestion
- [面试问题和经验](interview/index.md) - [面试问题和经验](interview/index.md)

53
dependencies/deep-storage.md vendored Normal file
View File

@ -0,0 +1,53 @@
---
id: deep-storage
title: "Deep storage"
---
<!--
~ 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.
-->
Deep storage is where segments are stored. It is a storage mechanism that Apache Druid does not provide. This deep storage infrastructure defines the level of durability of your data, as long as Druid processes can see this storage infrastructure and get at the segments stored on it, you will not lose data no matter how many Druid nodes you lose. If segments disappear from this storage layer, then you will lose whatever data those segments represented.
## Local Mount
A local mount can be used for storage of segments as well. This allows you to use just your local file system or anything else that can be mount locally like NFS, Ceph, etc. This is the default deep storage implementation.
In order to use a local mount for deep storage, you need to set the following configuration in your common configs.
|Property|Possible Values|Description|Default|
|--------|---------------|-----------|-------|
|`druid.storage.type`|local||Must be set.|
|`druid.storage.storageDirectory`||Directory for storing segments.|Must be set.|
Note that you should generally set `druid.storage.storageDirectory` to something different from `druid.segmentCache.locations` and `druid.segmentCache.infoDir`.
If you are using the Hadoop indexer in local mode, then just give it a local file as your output directory and it will work.
## S3-compatible
See [druid-s3-extensions extension documentation](../development/extensions-core/s3.md).
## HDFS
See [druid-hdfs-storage extension documentation](../development/extensions-core/hdfs.md).
## Additional Deep Stores
For additional deep stores, please see our [extensions list](../development/extensions.md).

138
dependencies/metadata-storage.md vendored Normal file
View File

@ -0,0 +1,138 @@
---
id: metadata-storage
title: "Metadata storage"
---
<!--
~ 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.
-->
The Metadata Storage is an external dependency of Apache Druid. Druid uses it to store
various metadata about the system, but not to store the actual data. There are
a number of tables used for various purposes described below.
Derby is the default metadata store for Druid, however, it is not suitable for production.
[MySQL](../development/extensions-core/mysql.md) and [PostgreSQL](../development/extensions-core/postgresql.md) are more production suitable metadata stores.
> The Metadata Storage stores the entire metadata which is essential for a Druid cluster to work.
> For production clusters, consider using MySQL or PostgreSQL instead of Derby.
> Also, it's highly recommended to set up a high availability environment
> because there is no way to restore if you lose any metadata.
## Using Derby
Add the following to your Druid configuration.
```properties
druid.metadata.storage.type=derby
druid.metadata.storage.connector.connectURI=jdbc:derby://localhost:1527//opt/var/druid_state/derby;create=true
```
## MySQL
See [mysql-metadata-storage extension documentation](../development/extensions-core/mysql.md).
## PostgreSQL
See [postgresql-metadata-storage](../development/extensions-core/postgresql.md).
## Adding custom dbcp properties
NOTE: These properties are not settable through the `druid.metadata.storage.connector.dbcp properties`: `username`, `password`, `connectURI`, `validationQuery`, `testOnBorrow`. These must be set through `druid.metadata.storage.connector` properties.
Example supported properties:
```properties
druid.metadata.storage.connector.dbcp.maxConnLifetimeMillis=1200000
druid.metadata.storage.connector.dbcp.defaultQueryTimeout=30000
```
See [BasicDataSource Configuration](https://commons.apache.org/proper/commons-dbcp/configuration) for full list.
## Metadata storage tables
### Segments table
This is dictated by the `druid.metadata.storage.tables.segments` property.
This table stores metadata about the segments that should be available in the system. (This set of segments is called
"used segments" elsewhere in the documentation and throughout the project.) The table is polled by the
[Coordinator](../design/coordinator.md) to determine the set of segments that should be available for querying in the
system. The table has two main functional columns, the other columns are for indexing purposes.
Value 1 in the `used` column means that the segment should be "used" by the cluster (i.e., it should be loaded and
available for requests). Value 0 means that the segment should not be loaded into the cluster. We do this as a means of
unloading segments from the cluster without actually removing their metadata (which allows for simpler rolling back if
that is ever an issue).
The `payload` column stores a JSON blob that has all of the metadata for the segment (some of the data stored in this payload is redundant with some of the columns in the table, that is intentional). This looks something like
```json
{
"dataSource":"wikipedia",
"interval":"2012-05-23T00:00:00.000Z/2012-05-24T00:00:00.000Z",
"version":"2012-05-24T00:10:00.046Z",
"loadSpec":{
"type":"s3_zip",
"bucket":"bucket_for_segment",
"key":"path/to/segment/on/s3"
},
"dimensions":"comma-delimited-list-of-dimension-names",
"metrics":"comma-delimited-list-of-metric-names",
"shardSpec":{"type":"none"},
"binaryVersion":9,
"size":size_of_segment,
"identifier":"wikipedia_2012-05-23T00:00:00.000Z_2012-05-24T00:00:00.000Z_2012-05-23T00:10:00.046Z"
}
```
Note that the format of this blob can and will change from time-to-time.
### Rule table
The rule table is used to store the various rules about where segments should
land. These rules are used by the [Coordinator](../design/coordinator.md)
when making segment (re-)allocation decisions about the cluster.
### Config table
The config table is used to store runtime configuration objects. We do not have
many of these yet and we are not sure if we will keep this mechanism going
forward, but it is the beginnings of a method of changing some configuration
parameters across the cluster at runtime.
### Task-related tables
There are also a number of tables created and used by the [Overlord](../design/overlord.md) and [MiddleManager](../design/middlemanager.md) when managing tasks.
### Audit table
The Audit table is used to store the audit history for configuration changes
e.g rule changes done by [Coordinator](../design/coordinator.md) and other
config changes.
## Accessed by
The Metadata Storage is accessed only by:
1. Indexing Service Processes (if any)
2. Realtime Processes (if any)
3. Coordinator Processes
Thus you need to give permissions (e.g., in AWS Security Groups) only for these machines to access the Metadata storage.

86
dependencies/zookeeper.md vendored Normal file
View File

@ -0,0 +1,86 @@
---
id: zookeeper
title: "ZooKeeper"
---
<!--
~ 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 uses [Apache ZooKeeper](http://zookeeper.apache.org/) (ZK) for management of current cluster state.
## Minimum ZooKeeper versions
Apache Druid supports ZooKeeper versions 3.5.x and above.
> Note: Starting with Apache Druid 0.22.0, support for ZooKeeper 3.4.x has been removed
## ZooKeeper Operations
The operations that happen over ZK are
1. [Coordinator](../design/coordinator.md) leader election
2. Segment "publishing" protocol from [Historical](../design/historical.md)
3. Segment load/drop protocol between [Coordinator](../design/coordinator.md) and [Historical](../design/historical.md)
4. [Overlord](../design/overlord.md) leader election
5. [Overlord](../design/overlord.md) and [MiddleManager](../design/middlemanager.md) task management
## Coordinator Leader Election
We use the Curator LeadershipLatch recipe to do leader election at path
```
${druid.zk.paths.coordinatorPath}/_COORDINATOR
```
## Segment "publishing" protocol from Historical and Realtime
The `announcementsPath` and `servedSegmentsPath` are used for this.
All [Historical](../design/historical.md) processes publish themselves on the `announcementsPath`, specifically, they will create an ephemeral znode at
```
${druid.zk.paths.announcementsPath}/${druid.host}
```
Which signifies that they exist. They will also subsequently create a permanent znode at
```
${druid.zk.paths.servedSegmentsPath}/${druid.host}
```
And as they load up segments, they will attach ephemeral znodes that look like
```
${druid.zk.paths.servedSegmentsPath}/${druid.host}/_segment_identifier_
```
Processes like the [Coordinator](../design/coordinator.md) and [Broker](../design/broker.md) can then watch these paths to see which processes are currently serving which segments.
## Segment load/drop protocol between Coordinator and Historical
The `loadQueuePath` is used for this.
When the [Coordinator](../design/coordinator.md) decides that a [Historical](../design/historical.md) process should load or drop a segment, it writes an ephemeral znode to
```
${druid.zk.paths.loadQueuePath}/_host_of_historical_process/_segment_identifier
```
This znode will contain a payload that indicates to the Historical process what it should do with the given segment. When the Historical process is done with the work, it will delete the znode in order to signify to the Coordinator that it is complete.

View File

@ -29,7 +29,7 @@ org.apache.druid.cli.Main server broker
### 转发查询 ### 转发查询
大多数Druid查询都包含一个interval对象该对象指示请求数据的时间跨度。同样Druid[段](./Segments.md)被划分为包含一定时间间隔的数据并且段分布在集群中。假设有一个具有7个段的简单数据源其中每个段包含一周中给定一天的数据对数据源发出的任何查询如果超过一天的数据都将命中多个段这些段可能分布在多个进程中因此查询可能会命中多个进程。 大多数Druid查询都包含一个interval对象该对象指示请求数据的时间跨度。同样Druid[段](segments.md)被划分为包含一定时间间隔的数据并且段分布在集群中。假设有一个具有7个段的简单数据源其中每个段包含一周中给定一天的数据对数据源发出的任何查询如果超过一天的数据都将命中多个段这些段可能分布在多个进程中因此查询可能会命中多个进程。
为了确定将查询转发到哪个进程Broker首先从Zookeeper中的信息构建一个全局视图。Zookeeper中维护有关 [Historical](./Historical.md) 和流式摄取 [Peon](./Peons.md) 过程及其所服务的段的信息。对于Zookeeper中的每个数据源Broker都会构建一个段的时间线以及为它们提供服务的进程。当接收到针对特定数据源和间隔的查询时Broker将对与查询数据源关联的查询间隔时间线执行查找并检索包含所查询数据的进程。然后Broker将查询向下转发到所选进程。 为了确定将查询转发到哪个进程Broker首先从Zookeeper中的信息构建一个全局视图。Zookeeper中维护有关 [Historical](./Historical.md) 和流式摄取 [Peon](./Peons.md) 过程及其所服务的段的信息。对于Zookeeper中的每个数据源Broker都会构建一个段的时间线以及为它们提供服务的进程。当接收到针对特定数据源和间隔的查询时Broker将对与查询数据源关联的查询间隔时间线执行查找并检索包含所查询数据的进程。然后Broker将查询向下转发到所选进程。

View File

@ -19,7 +19,7 @@ Druid进程可以按照您喜欢的方式部署但是为了便于部署
* **Query**: 运行Broker和可选的Router进程处理来自外部客户端的请求 * **Query**: 运行Broker和可选的Router进程处理来自外部客户端的请求
* **Data**: 运行Historical和MiddleManager进程执行摄取负载和存储所有可查询的数据 * **Data**: 运行Historical和MiddleManager进程执行摄取负载和存储所有可查询的数据
关于进程和服务组织的更多信息,可以查看[Druid进程与服务](Processes.md) 关于进程和服务组织的更多信息,可以查看[Druid进程与服务](processes.md)
<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script> <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
@ -77,7 +77,7 @@ Druid数据被存储在"datasources"中类似于传统RDBMS中的表。每一
周期性地段被提交和发布此时它们将被写入到深度存储且变得不可更改同时从MiddleManager移动到Historical进程。有关段的信息也写入到元数据存储中这个信息是一个自描述的信息包括段的schema、大小以及在深度存储中的位置Coordinator可以根据这些信息来知道集群上应该有哪些数据是可用的 周期性地段被提交和发布此时它们将被写入到深度存储且变得不可更改同时从MiddleManager移动到Historical进程。有关段的信息也写入到元数据存储中这个信息是一个自描述的信息包括段的schema、大小以及在深度存储中的位置Coordinator可以根据这些信息来知道集群上应该有哪些数据是可用的
有关段文件格式的信息,请参见[段文件](Segments.md) 有关段文件格式的信息,请参见[段文件](segments.md)
有关数据在Druid的建模请参见[schema设计](../DataIngestion/schemadesign.md) 有关数据在Druid的建模请参见[schema设计](../DataIngestion/schemadesign.md)

View File

@ -29,7 +29,7 @@ org.apache.druid.cli.Main server historical
[Coordinator](./Coordinator.md) 负责通过在与Historical关联的加载队列路径下创建一个短暂的Zookeeper条目来将新的段分配给Historical。有关Coordinator如何将段分配给Historical的更多信息请参阅 [Coordinator](./Coordinator.md)。 [Coordinator](./Coordinator.md) 负责通过在与Historical关联的加载队列路径下创建一个短暂的Zookeeper条目来将新的段分配给Historical。有关Coordinator如何将段分配给Historical的更多信息请参阅 [Coordinator](./Coordinator.md)。
当Historical在其加载队列路径中注意到新的加载队列条目时它将首先检查本地磁盘目录缓存以获取有关段的信息。如果缓存中不存在有关段的信息Historical将从Zookeeper下载有关新段的元数据此元数据包括段在深层存储中的位置以及如何解压缩和处理段的规范。有关段的元数据和一般的Druid段的更多信息请参见 [](./Segments.md)。一旦一个Historical完成了对一个段的处理这个段就会在Zookeeper中与该进程相关联的服务段路径下被宣布同时该段可供查询。 当Historical在其加载队列路径中注意到新的加载队列条目时它将首先检查本地磁盘目录缓存以获取有关段的信息。如果缓存中不存在有关段的信息Historical将从Zookeeper下载有关新段的元数据此元数据包括段在深层存储中的位置以及如何解压缩和处理段的规范。有关段的元数据和一般的Druid段的更多信息请参见 [](segments.md)。一旦一个Historical完成了对一个段的处理这个段就会在Zookeeper中与该进程相关联的服务段路径下被宣布同时该段可供查询。
### 从缓存加载和服务段 ### 从缓存加载和服务段

110
operations/single-server.md Normal file
View File

@ -0,0 +1,110 @@
Druid includes a set of reference configurations and launch scripts for single-machine deployments:
- `nano-quickstart`
- `micro-quickstart`
- `small`
- `medium`
- `large`
- `xlarge`
The `micro-quickstart` is sized for small machines like laptops and is intended for quick evaluation use-cases.
The `nano-quickstart` is an even smaller configuration, targeting a machine with 1 CPU and 4GiB memory. It is meant for limited evaluations in resource constrained environments, such as small Docker containers.
The other configurations are intended for general use single-machine deployments. They are sized for hardware roughly based on Amazon's i3 series of EC2 instances.
The startup scripts for these example configurations run a single ZK instance along with the Druid services. You can choose to deploy ZK separately as well.
The example configurations run the Druid Coordinator and Overlord together in a single process using the optional configuration `druid.coordinator.asOverlord.enabled=true`, described in the [Coordinator configuration documentation](../configuration/index.md#coordinator-operation).
While example configurations are provided for very large single machines, at higher scales we recommend running Druid in a [clustered deployment](../tutorials/cluster.md), for fault-tolerance and reduced resource contention.
## Single server reference configurations
### Nano-Quickstart: 1 CPU, 4GiB RAM
- Launch command: `bin/start-nano-quickstart`
- Configuration directory: `conf/druid/single-server/nano-quickstart`
### Micro-Quickstart: 4 CPU, 16GiB RAM
- Launch command: `bin/start-micro-quickstart`
- Configuration directory: `conf/druid/single-server/micro-quickstart`
### Small: 8 CPU, 64GiB RAM (~i3.2xlarge)
- Launch command: `bin/start-small`
- Configuration directory: `conf/druid/single-server/small`
### Medium: 16 CPU, 128GiB RAM (~i3.4xlarge)
- Launch command: `bin/start-medium`
- Configuration directory: `conf/druid/single-server/medium`
### Large: 32 CPU, 256GiB RAM (~i3.8xlarge)
- Launch command: `bin/start-large`
- Configuration directory: `conf/druid/single-server/large`
### X-Large: 64 CPU, 512GiB RAM (~i3.16xlarge)
- Launch command: `bin/start-xlarge`
- Configuration directory: `conf/druid/single-server/xlarge`
### 单服务器部署
Druid包括一组参考配置和用于单机部署的启动脚本
* `nano-quickstart`
* `micro-quickstart`
* `small`
* `medium`
* `large`
* `large`
* `xlarge`
`micro-quickstart`适合于笔记本电脑等小型机器,旨在用于快速评估测试使用场景。
`nano-quickstart`是一种甚至更小的配置目标是具有1个CPU和4GB内存的计算机。它旨在在资源受限的环境例如小型Docker容器中进行有限的评估测试。
其他配置旨在用于一般用途的单机部署,它们的大小适合大致基于亚马逊i3系列EC2实例的硬件。
这些示例配置的启动脚本与Druid服务一起运行单个ZK实例,您也可以选择单独部署ZK。
通过[Coordinator配置文档](../../Configuration/configuration.md#Coordinator)中描述的可选配置`druid.coordinator.asOverlord.enabled = true`可以在单个进程中同时运行Druid Coordinator和Overlord。
虽然为大型单台计算机提供了示例配置但在更高规模下我们建议在集群部署中运行Druid以实现容错和减少资源争用。
#### 单服务器参考配置
##### Nano-Quickstart: 1 CPU, 4GB 内存
* 启动命令: `bin/start-nano-quickstart`
* 配置目录: `conf/druid/single-server/nano-quickstart`
##### Micro-Quickstart: 4 CPU, 16GB 内存
* 启动命令: `bin/start-micro-quickstart`
* 配置目录: `conf/druid/single-server/micro-quickstart`
##### Small: 8 CPU, 64GB 内存 (~i3.2xlarge)
* 启动命令: `bin/start-small`
* 配置目录: `conf/druid/single-server/small`
##### Medium: 16 CPU, 128GB 内存 (~i3.4xlarge)
* 启动命令: `bin/start-medium`
* 配置目录: `conf/druid/single-server/medium`
##### Large: 32 CPU, 256GB 内存 (~i3.8xlarge)
* 启动命令: `bin/start-large`
* 配置目录: `conf/druid/single-server/large`
##### X-Large: 64 CPU, 512GB 内存 (~i3.16xlarge)
* 启动命令: `bin/start-xlarge`
* 配置目录: `conf/druid/single-server/xlarge`

View File

@ -60,7 +60,7 @@
该项功能仅仅对多值维度是比较有用的。如果你在Apache Druid中有一个值为 ["v1","v2","v3"] 的行,当发送一个带有对维度值为"v1"进行[查询过滤](filters.md)的GroupBy/TopN查询, 在响应中,将会得到包含"v1","v2","v3"的三行数据。这个行为在大多数场景是不适合的。 该项功能仅仅对多值维度是比较有用的。如果你在Apache Druid中有一个值为 ["v1","v2","v3"] 的行,当发送一个带有对维度值为"v1"进行[查询过滤](filters.md)的GroupBy/TopN查询, 在响应中,将会得到包含"v1","v2","v3"的三行数据。这个行为在大多数场景是不适合的。
之所以会发生这种情况,是因为"查询过滤器"是在位图上内部使用的,并且只用于匹配要包含在查询结果处理中的行。对于多值维度,"查询过滤器"的行为类似于包含检查,它将匹配维度值为["v1"、"v2"、"v3"]的行。有关更多详细信息,请参阅[段](../design/Segments.md)中"多值列"一节, 然后groupBy/topN处理管道"分解"所有多值维度得到3行"v1"、"v2"和"v3"。 之所以会发生这种情况,是因为"查询过滤器"是在位图上内部使用的,并且只用于匹配要包含在查询结果处理中的行。对于多值维度,"查询过滤器"的行为类似于包含检查,它将匹配维度值为["v1"、"v2"、"v3"]的行。有关更多详细信息,请参阅[段](../design/segments.md)中"多值列"一节, 然后groupBy/topN处理管道"分解"所有多值维度得到3行"v1"、"v2"和"v3"。
除了有效地选择要处理的行的"查询过滤器"之外还可以使用带过滤的DimensionSpec来筛选多值维度值中的特定值。这些维度规范采用代理维度规范和筛选条件。从"分解"行中,查询结果中只返回与给定筛选条件匹配的行。 除了有效地选择要处理的行的"查询过滤器"之外还可以使用带过滤的DimensionSpec来筛选多值维度值中的特定值。这些维度规范采用代理维度规范和筛选条件。从"分解"行中,查询结果中只返回与给定筛选条件匹配的行。

View File

@ -131,7 +131,7 @@ Druid的原生类型系统允许字符串可能有多个值。这些 [多值维
在默认模式(`true`)下Druid将NULL和空字符串互换处理而不是根据SQL标准。在这种模式下Druid SQL只部分支持NULL。例如表达式 `col IS NULL``col = ''` 等效,如果 `col` 包含空字符串则两者的计算结果都为true。类似地如果`col1`是空字符串,则表达式 `COALESCE(col1col2)` 将返回 `col2`。当 `COUNT(*)` 聚合器计算所有行时,`COUNT(expr)` 聚合器将计算expr既不为空也不为空字符串的行数。此模式中的数值列不可为空任何空值或缺少的值都将被视为零。 在默认模式(`true`)下Druid将NULL和空字符串互换处理而不是根据SQL标准。在这种模式下Druid SQL只部分支持NULL。例如表达式 `col IS NULL``col = ''` 等效,如果 `col` 包含空字符串则两者的计算结果都为true。类似地如果`col1`是空字符串,则表达式 `COALESCE(col1col2)` 将返回 `col2`。当 `COUNT(*)` 聚合器计算所有行时,`COUNT(expr)` 聚合器将计算expr既不为空也不为空字符串的行数。此模式中的数值列不可为空任何空值或缺少的值都将被视为零。
在SQL兼容模式(`false`)中NULL的处理更接近SQL标准该属性同时影响存储和查询因此为了获得最佳行为应该在接收时和查询时同时设置该属性。处理空值的能力会带来一些开销有关更多详细信息请参阅 [段文档](../design/Segments.md#SQL兼容的空值处理)。 在SQL兼容模式(`false`)中NULL的处理更接近SQL标准该属性同时影响存储和查询因此为了获得最佳行为应该在接收时和查询时同时设置该属性。处理空值的能力会带来一些开销有关更多详细信息请参阅 [段文档](../design/segments.md#SQL兼容的空值处理)。
### 聚合函数 ### 聚合函数

View File

@ -3,7 +3,7 @@
Apache Druid支持多值字符串维度。当输入字段中包括一个数组值而非单一值例如JSON数组或者包括多个 `listDelimiter` 分割的TSV字段时即可生成多值维度。 Apache Druid支持多值字符串维度。当输入字段中包括一个数组值而非单一值例如JSON数组或者包括多个 `listDelimiter` 分割的TSV字段时即可生成多值维度。
本文档描述了对一个维度进行聚合时多值维度上的GroupBy查询行为TopN很类似。对于多值维度的内部详细信息可以查看 [Segments](../design/Segments.md) 文档的多值列部分。本文档中的示例都为 [原生Druid查询](makeNativeQueries.md)格式对于多值维度在SQL中的使用情况请查阅 [Druid SQL 文档](druidsql.md) 本文档描述了对一个维度进行聚合时多值维度上的GroupBy查询行为TopN很类似。对于多值维度的内部详细信息可以查看 [Segments](../design/segments.md) 文档的多值列部分。本文档中的示例都为 [原生Druid查询](makeNativeQueries.md)格式对于多值维度在SQL中的使用情况请查阅 [Druid SQL 文档](druidsql.md)
<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script> <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<ins class="adsbygoogle" <ins class="adsbygoogle"

View File

@ -46,7 +46,7 @@ Druid还通过提供可配置的数据分发方式来支持多租户。Druid的H
### 支持高查询并发 ### 支持高查询并发
Druid的基本计算单位是[段](../design/Segments.md)。进程并行地扫描段,给定进程可以根据`druid.processing.numThreads`的配置并发扫描。为了并行处理更多的数据并提高性能可以向集群中添加更多的核。Druid段的大小应该使任何给定段上的计算都能在最多500毫秒内完成。 Druid的基本计算单位是[段](../design/segments.md)。进程并行地扫描段,给定进程可以根据`druid.processing.numThreads`的配置并发扫描。为了并行处理更多的数据并提高性能可以向集群中添加更多的核。Druid段的大小应该使任何给定段上的计算都能在最多500毫秒内完成。
Druid在内部将扫描段的请求存储在优先队列中。如果一个给定的查询需要扫描比集群中可用处理器总数更多的段并且许多类似昂贵的查询同时运行我们不希望任何查询都被耗尽。Druid的内部处理逻辑将扫描一个查询中的一组段扫描完成后立即释放资源允许继续扫描来自另一个查询的第二组段。通过保持段计算时间非常小我们确保不断地产生资源并且与不同查询相关的段都被处理。 Druid在内部将扫描段的请求存储在优先队列中。如果一个给定的查询需要扫描比集群中可用处理器总数更多的段并且许多类似昂贵的查询同时运行我们不希望任何查询都被耗尽。Druid的内部处理逻辑将扫描一个查询中的一组段扫描完成后立即释放资源允许继续扫描来自另一个查询的第二组段。通过保持段计算时间非常小我们确保不断地产生资源并且与不同查询相关的段都被处理。

View File

@ -23,7 +23,7 @@ Druid的查询执行方法因查询的 [数据源类型](#数据源类型) 而
直接在 [表数据源](datasource.md#table) 上操作的查询使用由Broker进程引导的**分散-聚集**方法执行。过程如下: 直接在 [表数据源](datasource.md#table) 上操作的查询使用由Broker进程引导的**分散-聚集**方法执行。过程如下:
1. Broker根据 `"interval"` 参数确定哪些 [](../design/Segments.md) 与查询相关。段总是按时间划分的,因此任何间隔与查询间隔重叠的段都可能是相关的。 1. Broker根据 `"interval"` 参数确定哪些 [](../design/segments.md) 与查询相关。段总是按时间划分的,因此任何间隔与查询间隔重叠的段都可能是相关的。
2. 如果输入数据使用 [`single_dim` partitionsSpec](../DataIngestion/native.md#partitionsSpec) 按范围分区并且过滤器与用于分区的维度匹配则Broker还可以根据 `"filter"` 进一步修剪段列表。 2. 如果输入数据使用 [`single_dim` partitionsSpec](../DataIngestion/native.md#partitionsSpec) 按范围分区并且过滤器与用于分区的维度匹配则Broker还可以根据 `"filter"` 进一步修剪段列表。
3. Broker在删除了查询的段列表之后将查询转发到当前为这些段提供服务的数据服务器如Historical或者运行在MiddleManagers的任务 3. Broker在删除了查询的段列表之后将查询转发到当前为这些段提供服务的数据服务器如Historical或者运行在MiddleManagers的任务
4. 对于除 [Scan](scan.md) 之外的所有查询类型,数据服务器并行处理每个段,并为每个段生成部分结果。所做的具体处理取决于查询类型。如果启用了 [查询缓存](querycached.md)则可以缓存这些部分结果。对于Scan查询段由单个线程按顺序处理结果不被缓存。 4. 对于除 [Scan](scan.md) 之外的所有查询类型,数据服务器并行处理每个段,并为每个段生成部分结果。所做的具体处理取决于查询类型。如果启用了 [查询缓存](querycached.md)则可以缓存这些部分结果。对于Scan查询段由单个线程按顺序处理结果不被缓存。

View File

@ -472,3 +472,412 @@ You can add more Query servers as needed based on query load. If you increase th
Congratulations, you now have a Druid cluster! The next step is to learn about recommended ways to load data into Congratulations, you now have a Druid cluster! The next step is to learn about recommended ways to load data into
Druid based on your use case. Read more about [loading data](../ingestion/index.md). Druid based on your use case. Read more about [loading data](../ingestion/index.md).
## 集群部署
Apache Druid旨在作为可伸缩的容错集群进行部署。
在本文档中,我们将安装一个简单的集群,并讨论如何对其进行进一步配置以满足您的需求。
这个简单的集群将具有以下特点:
* 一个Master服务同时起Coordinator和Overlord进程
* 两个可伸缩、容错的Data服务来运行Historical和MiddleManager进程
* 一个Query服务运行Druid Broker和Router进程
在生产中我们建议根据您的特定容错需求部署多个Master服务器和多个Query服务器但是您可以使用一台Master服务器和一台Query服务器将服务快速运行起来然后再添加更多服务器。
### 选择硬件
#### 首次部署
如果您现在没有Druid集群并打算首次以集群模式部署运行Druid则本指南提供了一个包含预先配置的集群部署示例。
##### Master服务
Coordinator进程和Overlord进程负责处理集群的元数据和协调需求它们可以运行在同一台服务器上。
在本示例中我们将在等效于AWS[m5.2xlarge](https://aws.amazon.com/ec2/instance-types/m5/)实例的硬件环境上部署。
硬件规格为:
* 8核CPU
* 31GB内存
可以在`conf/druid/cluster/master`下找到适用于此硬件规格的Master示例服务配置。
##### Data服务
Historical和MiddleManager可以分配在同一台服务器上运行以处理集群中的实际数据这两个服务受益于CPU、内存和固态硬盘。
在本示例中我们将在等效于AWS[i3.4xlarge](https://aws.amazon.com/cn/ec2/instance-types/i3/)实例的硬件环境上部署。
硬件规格为:
* 16核CPU
* 122GB内存
* 2 * 1.9TB 固态硬盘
可以在`conf/druid/cluster/data`下找到适用于此硬件规格的Data示例服务配置。
##### Query服务
Druid Broker服务接收查询请求并将其转发到集群中的其他部分同时其可以可选的配置内存缓存。 Broker服务受益于CPU和内存。
在本示例中我们将在等效于AWS[m5.2xlarge](https://aws.amazon.com/ec2/instance-types/m5/)实例的硬件环境上部署。
硬件规格为:
* 8核CPU
* 31GB内存
您可以考虑将所有的其他开源UI工具或者查询依赖等与Broker服务部署在同一台服务器上。
可以在`conf/druid/cluster/query`下找到适用于此硬件规格的Query示例服务配置。
##### 其他硬件配置
上面的示例集群是从多种确定Druid集群大小的可能方式中选择的一个示例。
您可以根据自己的特定需求和限制选择较小/较大的硬件或较少/更多的服务器。
如果您的使用场景具有复杂的扩展要求则还可以选择不将Druid服务混合部署例如独立的Historical Server
[基本集群调整指南](../../operations/basicClusterTuning.md)中的信息可以帮助您进行决策,并可以调整配置大小。
#### 从单服务器环境迁移部署
如果您现在已有单服务器部署的环境,例如[单服务器部署示例](chapter-3.md)中的部署并且希望迁移到类似规模的集群部署则以下部分包含一些选择Master/Data/Query服务等效硬件的准则。
##### Master服务
Master服务的主要考虑点是可用CPU以及用于Coordinator和Overlord进程的堆内存。
首先计算出来在单服务器环境下Coordinator和Overlord已分配堆内存之和然后选择具有足够内存的Master服务硬件同时还需要考虑到为服务器上其他进程预留一些额外的内存。
对于CPU可以选择接近于单服务器环境核数1/4的硬件。
##### Data服务
在为集群Data服务选择硬件时主要考虑可用的CPU和内存可行时使用SSD存储。
在集群化部署时出于容错的考虑最好是部署多个Data服务。
在选择Data服务的硬件时可以假定一个分裂因子`N`将原来的单服务器环境的CPU和内存除以`N`,然后在新集群中部署`N`个硬件规格缩小的Data服务。
##### Query服务
Query服务的硬件选择主要考虑可用的CPU、Broker服务的堆内和堆外内存、Router服务的堆内存。
首先计算出来在单服务器环境下Broker和Router已分配堆内存之和然后选择可以覆盖Broker和Router内存的Query服务硬件同时还需要考虑到为服务器上其他进程预留一些额外的内存。
对于CPU可以选择接近于单服务器环境核数1/4的硬件。
[基本集群调优指南](../../operations/basicClusterTuning.md)包含有关如何计算Broker和Router服务内存使用量的信息。
### 选择操作系统
我们建议运行您喜欢的Linux发行版同时还需要
* **Java 8**
> [!WARNING]
> Druid服务运行依赖Java 8可以使用环境变量`DRUID_JAVA_HOME`或`JAVA_HOME`指定在何处查找Java,有关更多详细信息,请运行`verify-java`脚本。
### 下载发行版
首先,下载并解压缩发布安装包。最好首先在单台计算机上执行此操作,因为您将编辑配置,然后将修改后的配置分发到所有服务器上。
[下载](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
```
tar -xzf apache-druid-0.17.0-bin.tar.gz
cd apache-druid-0.17.0
```
在安装包中有以下文件:
* `LICENSE`和`NOTICE`文件
* `bin/*` - 启停等脚本
* `conf/druid/cluster/*` - 用于集群部署的模板配置
* `extensions/*` - Druid核心扩展
* `hadoop-dependencies/*` - Druid Hadoop依赖
* `lib/*` - Druid核心库和依赖
* `quickstart/*` - 与[快速入门](chapter-2.md)相关的文件
我们主要是编辑`conf/druid/cluster/`中的文件。
#### 从单服务器环境迁移部署
在以下各节中,我们将在`conf/druid/cluster`下编辑配置。
如果您已经有一个单服务器部署,请将您的现有配置复制到`conf/druid /cluster`以保留您所做的所有配置更改。
### 配置元数据存储和深度存储
#### 从单服务器环境迁移部署
如果您已经有一个单服务器部署,并且希望在整个迁移过程中保留数据,请在更新元数据/深层存储配置之前,按照[元数据迁移](../../operations/metadataMigration.md)和[深层存储迁移](../../operations/DeepstorageMigration.md)中的说明进行操作。
这些指南针对使用Derby元数据存储和本地深度存储的单服务器部署。 如果您已经在单服务器集群中使用了非Derby元数据存储则可以在新集群中可以继续使用当前的元数据存储。
这些指南还提供了有关从本地深度存储迁移段的信息。集群部署需要分布式深度存储例如S3或HDFS。 如果单服务器部署已在使用分布式深度存储,则可以在新集群中继续使用当前的深度存储。
#### 元数据存储
在`conf/druid/cluster/_common/common.runtime.properties`中,使用您将用作元数据存储的服务器地址来替换"metadata.storage.*":
* `druid.metadata.storage.connector.connectURI`
* `druid.metadata.storage.connector.host`
在生产部署中我们建议运行专用的元数据存储例如具有复制功能的MySQL或PostgreSQL与Druid服务器分开部署。
[MySQL扩展](../../Configuration/core-ext/mysql.md)和[PostgreSQL](../../Configuration/core-ext/postgresql.md)扩展文档包含有关扩展配置和初始数据库安装的说明。
#### 深度存储
Druid依赖于分布式文件系统或大对象blob存储来存储数据最常用的深度存储实现是S3适合于在AWS上和HDFS适合于已有Hadoop集群
##### S3
在`conf/druid/cluster/_common/common.runtime.properties`中,
* 在`druid.extension.loadList`配置项中增加"druid-s3-extensions"扩展
* 注释掉配置文件中用于本地存储的"Deep Storage"和"Indexing service logs"
* 打开配置文件中关于"For S3"部分中"Deep Storage"和"Indexing service logs"的配置
上述操作之后,您将看到以下的变化:
```json
druid.extensions.loadList=["druid-s3-extensions"]
#druid.storage.type=local
#druid.storage.storageDirectory=var/druid/segments
druid.storage.type=s3
druid.storage.bucket=your-bucket
druid.storage.baseKey=druid/segments
druid.s3.accessKey=...
druid.s3.secretKey=...
#druid.indexer.logs.type=file
#druid.indexer.logs.directory=var/druid/indexing-logs
druid.indexer.logs.type=s3
druid.indexer.logs.s3Bucket=your-bucket
druid.indexer.logs.s3Prefix=druid/indexing-logs
```
更多信息可以看[S3扩展](../../Configuration/core-ext/s3.md)部分的文档。
##### HDFS
在`conf/druid/cluster/_common/common.runtime.properties`中,
* 在`druid.extension.loadList`配置项中增加"druid-hdfs-storage"扩展
* 注释掉配置文件中用于本地存储的"Deep Storage"和"Indexing service logs"
* 打开配置文件中关于"For HDFS"部分中"Deep Storage"和"Indexing service logs"的配置
上述操作之后,您将看到以下的变化:
```json
druid.extensions.loadList=["druid-hdfs-storage"]
#druid.storage.type=local
#druid.storage.storageDirectory=var/druid/segments
druid.storage.type=hdfs
druid.storage.storageDirectory=/druid/segments
#druid.indexer.logs.type=file
#druid.indexer.logs.directory=var/druid/indexing-logs
druid.indexer.logs.type=hdfs
druid.indexer.logs.directory=/druid/indexing-logs
```
同时:
* 需要将Hadoop的配置文件core-site.xml, hdfs-site.xml, yarn-site.xml, mapred-site.xml放置在Druid进程的classpath中可以将他们拷贝到`conf/druid/cluster/_common`目录中
更多信息可以看[HDFS扩展](../../Configuration/core-ext/hdfs.md)部分的文档。
### Hadoop连接配置
如果要从Hadoop集群加载数据那么此时应对Druid做如下配置
* 在`conf/druid/cluster/_common/common.runtime.properties`文件中更新`druid.indexer.task.hadoopWorkingPath`配置项将其更新为您期望的一个用于临时文件存储的HDFS路径。 通常会配置为`druid.indexer.task.hadoopWorkingPath=/tmp/druid-indexing`
* 需要将Hadoop的配置文件core-site.xml, hdfs-site.xml, yarn-site.xml, mapred-site.xml放置在Druid进程的classpath中可以将他们拷贝到`conf/druid/cluster/_common`目录中
请注意您无需为了可以从Hadoop加载数据而使用HDFS深度存储。例如如果您的集群在Amazon Web Services上运行即使您使用Hadoop或Elastic MapReduce加载数据我们也建议使用S3进行深度存储。
更多信息可以看[基于Hadoop的数据摄取](../../DataIngestion/hadoopbased.md)部分的文档。
### Zookeeper连接配置
在生产集群中我们建议使用专用的ZK集群该集群与Druid服务器分开部署。
`conf/druid/cluster/_common/common.runtime.properties` 中,将 `druid.zk.service.host` 设置为包含用逗号分隔的hostport对列表的连接字符串每个对与ZK中的ZooKeeper服务器相对应。例如" 127.0.0.1:4545"或"127.0.0.1:3000,127.0.0.1:3001、127.0.0.1:3002"
您也可以选择在Master服务上运行ZK而不使用专用的ZK集群。如果这样做我们建议部署3个Master服务以便您具有ZK仲裁。
### 配置调整
#### 从单服务器环境迁移部署
##### Master服务
如果您使用的是[单服务器部署示例](chapter-3.md)中的示例配置则这些示例中将Coordinator和Overlord进程合并为一个合并的进程。
`conf/druid/cluster/master/coordinator-overlord` 下的示例配置同样合并了Coordinator和Overlord进程。
您可以将现有的 `coordinator-overlord` 配置从单服务器部署复制到`conf/druid/cluster/master/coordinator-overlord`
##### Data服务
假设我们正在从一个32CPU和256GB内存的单服务器部署环境进行迁移在老的环境中Historical和MiddleManager使用了如下的配置
Historical单服务器
```json
druid.processing.buffer.sizeBytes=500000000
druid.processing.numMergeBuffers=8
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
druid.indexer.fork.property.druid.processing.numThreads=1
```
在集群部署中我们选择一个分裂因子假设为2则部署2个16CPU和128GB内存的Data服务各项的调整如下
Historical
* `druid.processing.numThreads`设置为新硬件的(`CPU核数 - 1`
* `druid.processing.numMergeBuffers` 使用分裂因子去除单服务部署环境的值
* `druid.processing.buffer.sizeBytes` 该值保持不变
MiddleManager:
* `druid.worker.capacity`: 使用分裂因子去除单服务部署环境的值
* `druid.indexer.fork.property.druid.processing.numMergeBuffers`: 该值保持不变
* `druid.indexer.fork.property.druid.processing.buffer.sizeBytes`: 该值保持不变
* `druid.indexer.fork.property.druid.processing.numThreads`: 该值保持不变
调整后的结果配置如下:
新的Historical(2 Data服务器)
```json
druid.processing.buffer.sizeBytes=500000000
druid.processing.numMergeBuffers=8
druid.processing.numThreads=31
```
新的MiddleManager2 Data服务器
```json
druid.worker.capacity=4
druid.indexer.fork.property.druid.processing.numMergeBuffers=2
druid.indexer.fork.property.druid.processing.buffer.sizeBytes=100000000
druid.indexer.fork.property.druid.processing.numThreads=1
```
##### Query服务
您可以将现有的Broker和Router配置复制到`conf/druid/cluster/query`下的目录中,无需进行任何修改.
#### 首次部署
如果您正在使用如下描述的示例集群规格:
* 1 Master 服务器(m5.2xlarge)
* 2 Data 服务器(i3.4xlarge)
* 1 Query 服务器(m5.2xlarge)
`conf/druid/cluster`下的配置已经为此硬件确定了,一般情况下您无需做进一步的修改。
如果您选择了其他硬件,则[基本的集群调整指南](../../operations/basicClusterTuning.md)可以帮助您调整配置大小。
### 开启端口(如果使用了防火墙)
如果您正在使用防火墙或其他仅允许特定端口上流量准入的系统,请在以下端口上允许入站连接:
#### Master服务
* 1527Derby元数据存储如果您正在使用一个像MySQL或者PostgreSQL的分离的元数据存储则不需要
* 2181Zookeeper如果使用了独立的ZK集群则不需要
* 8081Coordinator
* 8090Overlord
#### Data服务
* 8083Historical
* 80918100-8199Druid MiddleManager如果`druid.worker.capacity`参数设置较大的话则需要更多高于8199的端口
#### Query服务
* 8082Broker
* 8088Router如果使用了
> [!WARNING]
> 在生产中我们建议将ZooKeeper和元数据存储部署在其专用硬件上而不是在Master服务器上。
### 启动Master服务
将Druid发行版和您编辑的配置文件复制到Master服务器上。
如果您一直在本地计算机上编辑配置则可以使用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
```
> [!WARNING]
> 在生产中我们建议将ZooKeeper运行在其专用硬件上。
### 启动Data服务
将Druid发行版和您编辑的配置文件复制到您的Data服务器。
在发行版根目录中运行以下命令以启动Data服务
```json
bin/start-cluster-data-server
```
您可以在需要的时候增加更多的Data服务器。
> [!WARNING]
> 对于具有复杂资源分配需求的集群您可以将Historical和MiddleManager分开部署并分别扩容组件。这也使您能够利用Druid的内置MiddleManager自动伸缩功能。
### 启动Query服务
将Druid发行版和您编辑的配置文件复制到您的Query服务器。
在发行版根目录中运行以下命令以启动Query服务
```json
bin/start-cluster-query-server
```
您可以根据查询负载添加更多查询服务器。 如果增加了查询服务器的数量,请确保按照[基本集群调优指南](../../operations/basicClusterTuning.md)中的说明调整Historical和Task上的连接池。
### 加载数据
恭喜您现在有了Druid集群下一步是根据使用场景来了解将数据加载到Druid的推荐方法。
了解有关[加载数据](../DataIngestion/index.md)的更多信息。

View File

@ -1,69 +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包括一组参考配置和用于单机部署的启动脚本
* `nano-quickstart`
* `micro-quickstart`
* `small`
* `medium`
* `large`
* `large`
* `xlarge`
`micro-quickstart`适合于笔记本电脑等小型机器,旨在用于快速评估测试使用场景。
`nano-quickstart`是一种甚至更小的配置目标是具有1个CPU和4GB内存的计算机。它旨在在资源受限的环境例如小型Docker容器中进行有限的评估测试。
其他配置旨在用于一般用途的单机部署,它们的大小适合大致基于亚马逊i3系列EC2实例的硬件。
这些示例配置的启动脚本与Druid服务一起运行单个ZK实例,您也可以选择单独部署ZK。
通过[Coordinator配置文档](../../Configuration/configuration.md#Coordinator)中描述的可选配置`druid.coordinator.asOverlord.enabled = true`可以在单个进程中同时运行Druid Coordinator和Overlord。
虽然为大型单台计算机提供了示例配置但在更高规模下我们建议在集群部署中运行Druid以实现容错和减少资源争用。
#### 单服务器参考配置
##### Nano-Quickstart: 1 CPU, 4GB 内存
* 启动命令: `bin/start-nano-quickstart`
* 配置目录: `conf/druid/single-server/nano-quickstart`
##### Micro-Quickstart: 4 CPU, 16GB 内存
* 启动命令: `bin/start-micro-quickstart`
* 配置目录: `conf/druid/single-server/micro-quickstart`
##### Small: 8 CPU, 64GB 内存 (~i3.2xlarge)
* 启动命令: `bin/start-small`
* 配置目录: `conf/druid/single-server/small`
##### Medium: 16 CPU, 128GB 内存 (~i3.4xlarge)
* 启动命令: `bin/start-medium`
* 配置目录: `conf/druid/single-server/medium`
##### Large: 32 CPU, 256GB 内存 (~i3.8xlarge)
* 启动命令: `bin/start-large`
* 配置目录: `conf/druid/single-server/large`
##### X-Large: 64 CPU, 512GB 内存 (~i3.16xlarge)
* 启动命令: `bin/start-xlarge`
* 配置目录: `conf/druid/single-server/xlarge`
---

View File

@ -1,421 +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>
## 集群部署
Apache Druid旨在作为可伸缩的容错集群进行部署。
在本文档中,我们将安装一个简单的集群,并讨论如何对其进行进一步配置以满足您的需求。
这个简单的集群将具有以下特点:
* 一个Master服务同时起Coordinator和Overlord进程
* 两个可伸缩、容错的Data服务来运行Historical和MiddleManager进程
* 一个Query服务运行Druid Broker和Router进程
在生产中我们建议根据您的特定容错需求部署多个Master服务器和多个Query服务器但是您可以使用一台Master服务器和一台Query服务器将服务快速运行起来然后再添加更多服务器。
### 选择硬件
#### 首次部署
如果您现在没有Druid集群并打算首次以集群模式部署运行Druid则本指南提供了一个包含预先配置的集群部署示例。
##### Master服务
Coordinator进程和Overlord进程负责处理集群的元数据和协调需求它们可以运行在同一台服务器上。
在本示例中我们将在等效于AWS[m5.2xlarge](https://aws.amazon.com/ec2/instance-types/m5/)实例的硬件环境上部署。
硬件规格为:
* 8核CPU
* 31GB内存
可以在`conf/druid/cluster/master`下找到适用于此硬件规格的Master示例服务配置。
##### Data服务
Historical和MiddleManager可以分配在同一台服务器上运行以处理集群中的实际数据这两个服务受益于CPU、内存和固态硬盘。
在本示例中我们将在等效于AWS[i3.4xlarge](https://aws.amazon.com/cn/ec2/instance-types/i3/)实例的硬件环境上部署。
硬件规格为:
* 16核CPU
* 122GB内存
* 2 * 1.9TB 固态硬盘
可以在`conf/druid/cluster/data`下找到适用于此硬件规格的Data示例服务配置。
##### Query服务
Druid Broker服务接收查询请求并将其转发到集群中的其他部分同时其可以可选的配置内存缓存。 Broker服务受益于CPU和内存。
在本示例中我们将在等效于AWS[m5.2xlarge](https://aws.amazon.com/ec2/instance-types/m5/)实例的硬件环境上部署。
硬件规格为:
* 8核CPU
* 31GB内存
您可以考虑将所有的其他开源UI工具或者查询依赖等与Broker服务部署在同一台服务器上。
可以在`conf/druid/cluster/query`下找到适用于此硬件规格的Query示例服务配置。
##### 其他硬件配置
上面的示例集群是从多种确定Druid集群大小的可能方式中选择的一个示例。
您可以根据自己的特定需求和限制选择较小/较大的硬件或较少/更多的服务器。
如果您的使用场景具有复杂的扩展要求则还可以选择不将Druid服务混合部署例如独立的Historical Server
[基本集群调整指南](../../operations/basicClusterTuning.md)中的信息可以帮助您进行决策,并可以调整配置大小。
#### 从单服务器环境迁移部署
如果您现在已有单服务器部署的环境,例如[单服务器部署示例](chapter-3.md)中的部署并且希望迁移到类似规模的集群部署则以下部分包含一些选择Master/Data/Query服务等效硬件的准则。
##### Master服务
Master服务的主要考虑点是可用CPU以及用于Coordinator和Overlord进程的堆内存。
首先计算出来在单服务器环境下Coordinator和Overlord已分配堆内存之和然后选择具有足够内存的Master服务硬件同时还需要考虑到为服务器上其他进程预留一些额外的内存。
对于CPU可以选择接近于单服务器环境核数1/4的硬件。
##### Data服务
在为集群Data服务选择硬件时主要考虑可用的CPU和内存可行时使用SSD存储。
在集群化部署时出于容错的考虑最好是部署多个Data服务。
在选择Data服务的硬件时可以假定一个分裂因子`N`将原来的单服务器环境的CPU和内存除以`N`,然后在新集群中部署`N`个硬件规格缩小的Data服务。
##### Query服务
Query服务的硬件选择主要考虑可用的CPU、Broker服务的堆内和堆外内存、Router服务的堆内存。
首先计算出来在单服务器环境下Broker和Router已分配堆内存之和然后选择可以覆盖Broker和Router内存的Query服务硬件同时还需要考虑到为服务器上其他进程预留一些额外的内存。
对于CPU可以选择接近于单服务器环境核数1/4的硬件。
[基本集群调优指南](../../operations/basicClusterTuning.md)包含有关如何计算Broker和Router服务内存使用量的信息。
### 选择操作系统
我们建议运行您喜欢的Linux发行版同时还需要
* **Java 8**
> [!WARNING]
> Druid服务运行依赖Java 8可以使用环境变量`DRUID_JAVA_HOME`或`JAVA_HOME`指定在何处查找Java,有关更多详细信息,请运行`verify-java`脚本。
### 下载发行版
首先,下载并解压缩发布安装包。最好首先在单台计算机上执行此操作,因为您将编辑配置,然后将修改后的配置分发到所有服务器上。
[下载](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
```
tar -xzf apache-druid-0.17.0-bin.tar.gz
cd apache-druid-0.17.0
```
在安装包中有以下文件:
* `LICENSE`和`NOTICE`文件
* `bin/*` - 启停等脚本
* `conf/druid/cluster/*` - 用于集群部署的模板配置
* `extensions/*` - Druid核心扩展
* `hadoop-dependencies/*` - Druid Hadoop依赖
* `lib/*` - Druid核心库和依赖
* `quickstart/*` - 与[快速入门](chapter-2.md)相关的文件
我们主要是编辑`conf/druid/cluster/`中的文件。
#### 从单服务器环境迁移部署
在以下各节中,我们将在`conf/druid/cluster`下编辑配置。
如果您已经有一个单服务器部署,请将您的现有配置复制到`conf/druid /cluster`以保留您所做的所有配置更改。
### 配置元数据存储和深度存储
#### 从单服务器环境迁移部署
如果您已经有一个单服务器部署,并且希望在整个迁移过程中保留数据,请在更新元数据/深层存储配置之前,按照[元数据迁移](../../operations/metadataMigration.md)和[深层存储迁移](../../operations/DeepstorageMigration.md)中的说明进行操作。
这些指南针对使用Derby元数据存储和本地深度存储的单服务器部署。 如果您已经在单服务器集群中使用了非Derby元数据存储则可以在新集群中可以继续使用当前的元数据存储。
这些指南还提供了有关从本地深度存储迁移段的信息。集群部署需要分布式深度存储例如S3或HDFS。 如果单服务器部署已在使用分布式深度存储,则可以在新集群中继续使用当前的深度存储。
#### 元数据存储
在`conf/druid/cluster/_common/common.runtime.properties`中,使用您将用作元数据存储的服务器地址来替换"metadata.storage.*":
* `druid.metadata.storage.connector.connectURI`
* `druid.metadata.storage.connector.host`
在生产部署中我们建议运行专用的元数据存储例如具有复制功能的MySQL或PostgreSQL与Druid服务器分开部署。
[MySQL扩展](../../Configuration/core-ext/mysql.md)和[PostgreSQL](../../Configuration/core-ext/postgresql.md)扩展文档包含有关扩展配置和初始数据库安装的说明。
#### 深度存储
Druid依赖于分布式文件系统或大对象blob存储来存储数据最常用的深度存储实现是S3适合于在AWS上和HDFS适合于已有Hadoop集群
##### S3
在`conf/druid/cluster/_common/common.runtime.properties`中,
* 在`druid.extension.loadList`配置项中增加"druid-s3-extensions"扩展
* 注释掉配置文件中用于本地存储的"Deep Storage"和"Indexing service logs"
* 打开配置文件中关于"For S3"部分中"Deep Storage"和"Indexing service logs"的配置
上述操作之后,您将看到以下的变化:
```json
druid.extensions.loadList=["druid-s3-extensions"]
#druid.storage.type=local
#druid.storage.storageDirectory=var/druid/segments
druid.storage.type=s3
druid.storage.bucket=your-bucket
druid.storage.baseKey=druid/segments
druid.s3.accessKey=...
druid.s3.secretKey=...
#druid.indexer.logs.type=file
#druid.indexer.logs.directory=var/druid/indexing-logs
druid.indexer.logs.type=s3
druid.indexer.logs.s3Bucket=your-bucket
druid.indexer.logs.s3Prefix=druid/indexing-logs
```
更多信息可以看[S3扩展](../../Configuration/core-ext/s3.md)部分的文档。
##### HDFS
在`conf/druid/cluster/_common/common.runtime.properties`中,
* 在`druid.extension.loadList`配置项中增加"druid-hdfs-storage"扩展
* 注释掉配置文件中用于本地存储的"Deep Storage"和"Indexing service logs"
* 打开配置文件中关于"For HDFS"部分中"Deep Storage"和"Indexing service logs"的配置
上述操作之后,您将看到以下的变化:
```json
druid.extensions.loadList=["druid-hdfs-storage"]
#druid.storage.type=local
#druid.storage.storageDirectory=var/druid/segments
druid.storage.type=hdfs
druid.storage.storageDirectory=/druid/segments
#druid.indexer.logs.type=file
#druid.indexer.logs.directory=var/druid/indexing-logs
druid.indexer.logs.type=hdfs
druid.indexer.logs.directory=/druid/indexing-logs
```
同时:
* 需要将Hadoop的配置文件core-site.xml, hdfs-site.xml, yarn-site.xml, mapred-site.xml放置在Druid进程的classpath中可以将他们拷贝到`conf/druid/cluster/_common`目录中
更多信息可以看[HDFS扩展](../../Configuration/core-ext/hdfs.md)部分的文档。
### Hadoop连接配置
如果要从Hadoop集群加载数据那么此时应对Druid做如下配置
* 在`conf/druid/cluster/_common/common.runtime.properties`文件中更新`druid.indexer.task.hadoopWorkingPath`配置项将其更新为您期望的一个用于临时文件存储的HDFS路径。 通常会配置为`druid.indexer.task.hadoopWorkingPath=/tmp/druid-indexing`
* 需要将Hadoop的配置文件core-site.xml, hdfs-site.xml, yarn-site.xml, mapred-site.xml放置在Druid进程的classpath中可以将他们拷贝到`conf/druid/cluster/_common`目录中
请注意您无需为了可以从Hadoop加载数据而使用HDFS深度存储。例如如果您的集群在Amazon Web Services上运行即使您使用Hadoop或Elastic MapReduce加载数据我们也建议使用S3进行深度存储。
更多信息可以看[基于Hadoop的数据摄取](../../DataIngestion/hadoopbased.md)部分的文档。
### Zookeeper连接配置
在生产集群中我们建议使用专用的ZK集群该集群与Druid服务器分开部署。
`conf/druid/cluster/_common/common.runtime.properties` 中,将 `druid.zk.service.host` 设置为包含用逗号分隔的hostport对列表的连接字符串每个对与ZK中的ZooKeeper服务器相对应。例如" 127.0.0.1:4545"或"127.0.0.1:3000,127.0.0.1:3001、127.0.0.1:3002"
您也可以选择在Master服务上运行ZK而不使用专用的ZK集群。如果这样做我们建议部署3个Master服务以便您具有ZK仲裁。
### 配置调整
#### 从单服务器环境迁移部署
##### Master服务
如果您使用的是[单服务器部署示例](chapter-3.md)中的示例配置则这些示例中将Coordinator和Overlord进程合并为一个合并的进程。
`conf/druid/cluster/master/coordinator-overlord` 下的示例配置同样合并了Coordinator和Overlord进程。
您可以将现有的 `coordinator-overlord` 配置从单服务器部署复制到`conf/druid/cluster/master/coordinator-overlord`
##### Data服务
假设我们正在从一个32CPU和256GB内存的单服务器部署环境进行迁移在老的环境中Historical和MiddleManager使用了如下的配置
Historical单服务器
```json
druid.processing.buffer.sizeBytes=500000000
druid.processing.numMergeBuffers=8
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
druid.indexer.fork.property.druid.processing.numThreads=1
```
在集群部署中我们选择一个分裂因子假设为2则部署2个16CPU和128GB内存的Data服务各项的调整如下
Historical
* `druid.processing.numThreads`设置为新硬件的(`CPU核数 - 1`
* `druid.processing.numMergeBuffers` 使用分裂因子去除单服务部署环境的值
* `druid.processing.buffer.sizeBytes` 该值保持不变
MiddleManager:
* `druid.worker.capacity`: 使用分裂因子去除单服务部署环境的值
* `druid.indexer.fork.property.druid.processing.numMergeBuffers`: 该值保持不变
* `druid.indexer.fork.property.druid.processing.buffer.sizeBytes`: 该值保持不变
* `druid.indexer.fork.property.druid.processing.numThreads`: 该值保持不变
调整后的结果配置如下:
新的Historical(2 Data服务器)
```json
druid.processing.buffer.sizeBytes=500000000
druid.processing.numMergeBuffers=8
druid.processing.numThreads=31
```
新的MiddleManager2 Data服务器
```json
druid.worker.capacity=4
druid.indexer.fork.property.druid.processing.numMergeBuffers=2
druid.indexer.fork.property.druid.processing.buffer.sizeBytes=100000000
druid.indexer.fork.property.druid.processing.numThreads=1
```
##### Query服务
您可以将现有的Broker和Router配置复制到`conf/druid/cluster/query`下的目录中,无需进行任何修改.
#### 首次部署
如果您正在使用如下描述的示例集群规格:
* 1 Master 服务器(m5.2xlarge)
* 2 Data 服务器(i3.4xlarge)
* 1 Query 服务器(m5.2xlarge)
`conf/druid/cluster`下的配置已经为此硬件确定了,一般情况下您无需做进一步的修改。
如果您选择了其他硬件,则[基本的集群调整指南](../../operations/basicClusterTuning.md)可以帮助您调整配置大小。
### 开启端口(如果使用了防火墙)
如果您正在使用防火墙或其他仅允许特定端口上流量准入的系统,请在以下端口上允许入站连接:
#### Master服务
* 1527Derby元数据存储如果您正在使用一个像MySQL或者PostgreSQL的分离的元数据存储则不需要
* 2181Zookeeper如果使用了独立的ZK集群则不需要
* 8081Coordinator
* 8090Overlord
#### Data服务
* 8083Historical
* 80918100-8199Druid MiddleManager如果`druid.worker.capacity`参数设置较大的话则需要更多高于8199的端口
#### Query服务
* 8082Broker
* 8088Router如果使用了
> [!WARNING]
> 在生产中我们建议将ZooKeeper和元数据存储部署在其专用硬件上而不是在Master服务器上。
### 启动Master服务
将Druid发行版和您编辑的配置文件复制到Master服务器上。
如果您一直在本地计算机上编辑配置则可以使用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
```
> [!WARNING]
> 在生产中我们建议将ZooKeeper运行在其专用硬件上。
### 启动Data服务
将Druid发行版和您编辑的配置文件复制到您的Data服务器。
在发行版根目录中运行以下命令以启动Data服务
```json
bin/start-cluster-data-server
```
您可以在需要的时候增加更多的Data服务器。
> [!WARNING]
> 对于具有复杂资源分配需求的集群您可以将Historical和MiddleManager分开部署并分别扩容组件。这也使您能够利用Druid的内置MiddleManager自动伸缩功能。
### 启动Query服务
将Druid发行版和您编辑的配置文件复制到您的Query服务器。
在发行版根目录中运行以下命令以启动Query服务
```json
bin/start-cluster-query-server
```
您可以根据查询负载添加更多查询服务器。 如果增加了查询服务器的数量,请确保按照[基本集群调优指南](../../operations/basicClusterTuning.md)中的说明调整Historical和Task上的连接池。
### 加载数据
恭喜您现在有了Druid集群下一步是根据使用场景来了解将数据加载到Druid的推荐方法。
了解有关[加载数据](../DataIngestion/index.md)的更多信息。

Binary file not shown.

Before

Width:  |  Height:  |  Size: 65 KiB