更新文件
This commit is contained in:
parent
1127bb2439
commit
4c67d616e4
|
|
@ -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.
|
||||
Loading…
Reference in New Issue