mirror of https://github.com/apache/druid.git
Updated docs (#12978)
This commit is contained in:
Jill Osborne
GitHub
parent
eb3a12ac7d
commit
ca2b540693
|
|
@ -22,10 +22,6 @@ title: "Router Process"
|
|||
~ under the License.
|
||||
-->
|
||||
|
||||
|
||||
> The Router is an optional and [experimental](../development/experimental.md) feature due to the fact that its recommended place in the Druid cluster architecture is still evolving.
|
||||
> However, it has been battle-tested in production, and it hosts the powerful [Druid console](../operations/druid-console.md), so you should feel safe deploying it.
|
||||
|
||||
The Apache Druid Router process can be used to route queries to different Broker processes. By default, the broker routes queries based on how [Rules](../operations/rule-configuration.md) are set up. For example, if 1 month of recent data is loaded into a `hot` cluster, queries that fall within the recent month can be routed to a dedicated set of brokers. Queries outside this range are routed to another set of brokers. This set up provides query isolation such that queries for more important data are not impacted by queries for less important data.
|
||||
|
||||
For query routing purposes, you should only ever need the Router process if you have a Druid cluster well into the terabyte range.
|
||||
|
|
|
|||
|
|
@ -43,13 +43,7 @@ to compute approximate histograms, with the following modifications:
|
|||
increasing accuracy when there are few data points, or when dealing with
|
||||
discrete data points. You can find some of the details in [this post](https://metamarkets.com/2013/histograms/).
|
||||
|
||||
Approximate histogram sketches are still experimental for a reason, and you
|
||||
should understand the limitations of the current implementation before using
|
||||
them. The approximation is heavily data-dependent, which makes it difficult to
|
||||
give good general guidelines, so you should experiment and see what parameters
|
||||
work well for your data.
|
||||
|
||||
Here are a few things to note before using them:
|
||||
Here are a few things to note before using approximate histograms:
|
||||
|
||||
- As indicated in the original paper, there are no formal error bounds on the
|
||||
approximation. In practice, the approximation gets worse if the distribution
|
||||
|
|
|
|||
|
|
@ -22,8 +22,6 @@ title: "Apache Kafka Lookups"
|
|||
~ under the License.
|
||||
-->
|
||||
|
||||
> Lookups are an [experimental](../experimental.md) feature.
|
||||
|
||||
To use this Apache Druid extension, [include](../../development/extensions.md#loading-extensions) `druid-lookups-cached-global` and `druid-kafka-extraction-namespace` in the extensions load list.
|
||||
|
||||
If you need updates to populate as promptly as possible, it is possible to plug into a Kafka topic whose key is the old value and message is the desired new value (both in UTF-8) as a LookupExtractorFactory.
|
||||
|
|
|
|||
|
|
@ -134,8 +134,6 @@ If you want to ingest data from other fields in addition to the Kafka message co
|
|||
- the Kafka event timestamp
|
||||
- the Kafka event value that stores the payload.
|
||||
|
||||
> The Kafka inputFormat is currently designated as experimental.
|
||||
|
||||
For example, consider the following structure for a message that represents a fictitious wiki edit in a development environment:
|
||||
- **Event headers**: {"environment": "development"}
|
||||
- **Event key**: {"key: "wiki-edit"}
|
||||
|
|
|
|||
|
|
@ -22,9 +22,6 @@ title: "Globally Cached Lookups"
|
|||
~ under the License.
|
||||
-->
|
||||
|
||||
|
||||
> Lookups are an [experimental](../experimental.md) feature.
|
||||
|
||||
To use this Apache Druid extension, [include](../extensions.md#loading-extensions) `druid-lookups-cached-global` in the extensions load list.
|
||||
|
||||
## Configuration
|
||||
|
|
|
|||
|
|
@ -155,8 +155,6 @@ Be sure to change the `delimiter` to the appropriate delimiter for your data. Li
|
|||
|
||||
Configure the Kafka `inputFormat` to load complete kafka records including header, key, and value.
|
||||
|
||||
> That Kafka `inputFormat` is currently designated as experimental.
|
||||
|
||||
| Field | Type | Description | Required |
|
||||
|-------|------|-------------|----------|
|
||||
| type | String | Set value to `kafka`. | yes |
|
||||
|
|
|
|||
|
|
@ -393,9 +393,7 @@ them to create the final segments. Finally, they push the final segments to the
|
|||
|
||||
#### Multi-dimension range partitioning
|
||||
|
||||
> Multiple dimension (multi-dimension) range partitioning is an experimental feature.
|
||||
> Multi-dimension range partitioning is not supported in the sequential mode of the
|
||||
> `index_parallel` task type.
|
||||
> Multi-dimension range partitioning is not supported in the sequential mode of the `index_parallel` task type.
|
||||
|
||||
Range partitioning has [several benefits](#benefits-of-range-partitioning) related to storage footprint and query
|
||||
performance. Multi-dimension range partitioning improves over single-dimension range partitioning by allowing
|
||||
|
|
|
|||
|
|
@ -22,9 +22,6 @@ title: "Lookups"
|
|||
~ under the License.
|
||||
-->
|
||||
|
||||
|
||||
> Lookups are an [experimental](../development/experimental.md) feature.
|
||||
|
||||
Lookups are a concept in Apache Druid where dimension values are (optionally) replaced with new values, allowing join-like
|
||||
functionality. Applying lookups in Druid is similar to joining a dimension table in a data warehouse. See
|
||||
[dimension specs](../querying/dimensionspecs.md) for more information. For the purpose of these documents, a "key"
|
||||
|
|
|
|||
Loading…
Reference in New Issue