Merge pull request #23 from cwiki-us-docs/feature/getting_started
调整目录结构
This commit is contained in:
GitHub
commit
c19959e1e9
|
|
@ -34,8 +34,8 @@
|
|||
|
||||
* [架构设计]()
|
||||
* [整体设计](design/Design.md)
|
||||
* [段设计](design/Segments.md)
|
||||
* [进程与服务](design/Processes.md)
|
||||
* [段设计](design/segments.md)
|
||||
* [进程与服务](design/processes.md)
|
||||
* [Coordinator](design/Coordinator.md)
|
||||
* [Overlord](design/Overlord.md)
|
||||
* [Historical](design/Historical.md)
|
||||
|
|
|
|||
25
_sidebar.md
25
_sidebar.md
|
|
@ -6,11 +6,30 @@
|
|||
- [Druid 介绍](design/index.md)
|
||||
- [快速开始](tutorials/index.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）
|
||||
- [JWT](jwt/README.md)
|
||||
- [MessagePack](message-pack/index.md)
|
||||
- [Protocol Buffers](protocol-buffers/index.md)
|
||||
- [设计](design/architecture.md)
|
||||
- [段（Segments）](design/segments.md)
|
||||
- [进程和服务](design/processes.md)
|
||||
- [深度存储](dependencies/deep-storage.md)
|
||||
- [元数据存储](dependencies/metadata-storage.md)
|
||||
- [ZooKeeper](dependencies/zookeeper.md)
|
||||
|
||||
- 摄取（Ingestion）
|
||||
- [面试问题和经验](interview/index.md)
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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将查询向下转发到所选进程。
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Druid进程可以按照您喜欢的方式部署，但是为了便于部署，我
|
|||
* **Query**: 运行Broker和可选的Router进程，处理来自外部客户端的请求
|
||||
* **Data**: 运行Historical和MiddleManager进程，执行摄取负载和存储所有可查询的数据
|
||||
|
||||
关于进程和服务组织的更多信息，可以查看[Druid进程与服务](Processes.md)
|
||||
关于进程和服务组织的更多信息，可以查看[Druid进程与服务](processes.md)
|
||||
|
||||
|
||||
<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
|
||||
|
|
@ -77,7 +77,7 @@ Druid数据被存储在"datasources"中，类似于传统RDBMS中的表。每一
|
|||
|
||||
周期性地，段被提交和发布，此时，它们将被写入到深度存储且变得不可更改，同时从MiddleManager移动到Historical进程。有关段的信息也写入到元数据存储中，这个信息是一个自描述的信息，包括段的schema、大小以及在深度存储中的位置，Coordinator可以根据这些信息来知道集群上应该有哪些数据是可用的
|
||||
|
||||
有关段文件格式的信息，请参见[段文件](Segments.md)
|
||||
有关段文件格式的信息，请参见[段文件](segments.md)
|
||||
|
||||
有关数据在Druid的建模，请参见[schema设计](../DataIngestion/schemadesign.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ org.apache.druid.cli.Main server historical
|
|||
|
||||
[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中与该进程相关联的服务段路径下被宣布，同时，该段可供查询。
|
||||
|
||||
### 从缓存加载和服务段
|
||||
|
||||
|
|
|
|||
|
|
@ -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`
|
||||
|
||||
|
|
@ -60,7 +60,7 @@
|
|||
|
||||
该项功能仅仅对多值维度是比较有用的。如果你在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来筛选多值维度值中的特定值。这些维度规范采用代理维度规范和筛选条件。从"分解"行中，查询结果中只返回与给定筛选条件匹配的行。
|
||||
|
||||
|
|
|
|||
|
|
@ -131,7 +131,7 @@ Druid的原生类型系统允许字符串可能有多个值。这些 [多值维
|
|||
|
||||
在默认模式(`true`)下，Druid将NULL和空字符串互换处理，而不是根据SQL标准。在这种模式下，Druid SQL只部分支持NULL。例如，表达式 `col IS NULL` 和 `col = ''` 等效，如果 `col` 包含空字符串，则两者的计算结果都为true。类似地，如果`col1`是空字符串，则表达式 `COALESCE(col1，col2)` 将返回 `col2`。当 `COUNT(*)` 聚合器计算所有行时，`COUNT(expr)` 聚合器将计算expr既不为空也不为空字符串的行数。此模式中的数值列不可为空；任何空值或缺少的值都将被视为零。
|
||||
|
||||
在SQL兼容模式(`false`)中，NULL的处理更接近SQL标准，该属性同时影响存储和查询，因此为了获得最佳行为，应该在接收时和查询时同时设置该属性。处理空值的能力会带来一些开销；有关更多详细信息，请参阅 [段文档](../design/Segments.md#SQL兼容的空值处理)。
|
||||
在SQL兼容模式(`false`)中，NULL的处理更接近SQL标准，该属性同时影响存储和查询，因此为了获得最佳行为，应该在接收时和查询时同时设置该属性。处理空值的能力会带来一些开销；有关更多详细信息，请参阅 [段文档](../design/segments.md#SQL兼容的空值处理)。
|
||||
|
||||
### 聚合函数
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
|
||||
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>
|
||||
<ins class="adsbygoogle"
|
||||
|
|
|
|||
|
|
@ -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的内部处理逻辑将扫描一个查询中的一组段，扫描完成后立即释放资源，允许继续扫描来自另一个查询的第二组段。通过保持段计算时间非常小，我们确保不断地产生资源，并且与不同查询相关的段都被处理。
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Druid的查询执行方法因查询的 [数据源类型](#数据源类型) 而
|
|||
|
||||
直接在 [表数据源](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"` 进一步修剪段列表。
|
||||
3. Broker在删除了查询的段列表之后，将查询转发到当前为这些段提供服务的数据服务器（如Historical或者运行在MiddleManagers的任务）。
|
||||
4. 对于除 [Scan](scan.md) 之外的所有查询类型，数据服务器并行处理每个段，并为每个段生成部分结果。所做的具体处理取决于查询类型。如果启用了 [查询缓存](querycached.md)，则可以缓存这些部分结果。对于Scan查询，段由单个线程按顺序处理，结果不被缓存。
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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` 设置为包含用逗号分隔的host：port对列表的连接字符串，每个对与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
|
||||
```
|
||||
|
||||
新的MiddleManager（2 Data服务器）
|
||||
|
||||
```json
|
||||
druid.worker.capacity=4
|
||||
druid.indexer.fork.property.druid.processing.numMergeBuffers=2
|
||||
druid.indexer.fork.property.druid.processing.buffer.sizeBytes=100000000
|
||||
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服务
|
||||
|
||||
* 1527（Derby元数据存储，如果您正在使用一个像MySQL或者PostgreSQL的分离的元数据存储则不需要）
|
||||
* 2181（Zookeeper，如果使用了独立的ZK集群则不需要）
|
||||
* 8081（Coordinator）
|
||||
* 8090（Overlord）
|
||||
|
||||
#### Data服务
|
||||
|
||||
* 8083（Historical）
|
||||
* 8091，8100-8199（Druid MiddleManager，如果`druid.worker.capacity`参数设置较大的话，则需要更多高于8199的端口）
|
||||
|
||||
#### Query服务
|
||||
|
||||
* 8082（Broker）
|
||||
* 8088（Router，如果使用了）
|
||||
|
||||
> [!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)的更多信息。
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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`
|
||||
|
||||
---
|
||||
|
|
@ -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` 设置为包含用逗号分隔的host：port对列表的连接字符串，每个对与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
|
||||
```
|
||||
|
||||
新的MiddleManager（2 Data服务器）
|
||||
|
||||
```json
|
||||
druid.worker.capacity=4
|
||||
druid.indexer.fork.property.druid.processing.numMergeBuffers=2
|
||||
druid.indexer.fork.property.druid.processing.buffer.sizeBytes=100000000
|
||||
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服务
|
||||
|
||||
* 1527（Derby元数据存储，如果您正在使用一个像MySQL或者PostgreSQL的分离的元数据存储则不需要）
|
||||
* 2181（Zookeeper，如果使用了独立的ZK集群则不需要）
|
||||
* 8081（Coordinator）
|
||||
* 8090（Overlord）
|
||||
|
||||
#### Data服务
|
||||
|
||||
* 8083（Historical）
|
||||
* 8091，8100-8199（Druid MiddleManager，如果`druid.worker.capacity`参数设置较大的话，则需要更多高于8199的端口）
|
||||
|
||||
#### Query服务
|
||||
|
||||
* 8082（Broker）
|
||||
* 8088（Router，如果使用了）
|
||||
|
||||
> [!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 |
Loading…
Reference in New Issue