add link
This commit is contained in:
liujianhuan
parent
df8a1511c7
commit
c55862679e
|
|
@ -0,0 +1,13 @@
|
|||
<!-- toc -->
|
||||
### 推荐的配置文件组织方式
|
||||
### 通用配置
|
||||
### Master
|
||||
#### Coordinator
|
||||
#### Overlord
|
||||
### Data
|
||||
#### MiddleManager and Peons
|
||||
#### Indexer
|
||||
#### Historical
|
||||
### Query
|
||||
#### Broker
|
||||
#### Router
|
||||
|
|
@ -0,0 +1 @@
|
|||
<!-- toc -->
|
||||
|
|
@ -0,0 +1 @@
|
|||
<!-- toc -->
|
||||
|
|
@ -0,0 +1 @@
|
|||
<!-- toc -->
|
||||
|
|
@ -52,14 +52,49 @@ Druid中的所有数据都被组织成*段*，这些段是数据文件，通常
|
|||
|
||||
### Druid数据模型
|
||||
#### 数据源
|
||||
Druid数据存储在数据源中，与传统RDBMS中的表类似。Druid提供了一个独特的数据建模系统，它与关系模型和时间序列模型都具有相似性。
|
||||
#### 主时间戳列
|
||||
Druid Schema必须始终包含一个主时间戳。主时间戳用于对 [数据进行分区和排序](#分区)。Druid查询能够快速识别和检索与主时间戳列的时间范围相对应的数据。Druid还可以将主时间戳列用于基于时间的[数据管理操作](datamanage.md)，例如删除时间块、覆盖时间块和基于时间的保留规则。
|
||||
|
||||
主时间戳基于 [`timestampSpec`](#timestampSpec) 进行解析。此外，[`granularitySpec`](#granularitySpec) 控制基于主时间戳的其他重要操作。无论从哪个输入字段读取主时间戳，它都将作为名为 `__time` 的列存储在Druid数据源中。
|
||||
|
||||
如果有多个时间戳列，则可以将其他列存储为 [辅助时间戳](schemadesign.md#辅助时间戳)。
|
||||
|
||||
#### 维度
|
||||
维度是按原样存储的列，可以用于任何目的, 可以在查询时以特殊方式对维度进行分组、筛选或应用聚合器。如果在禁用了 [rollup](#Rollup) 的情况下运行，那么该维度集将被简单地视为要摄取的一组列，并且其行为与不支持rollup功能的典型数据库的预期完全相同。
|
||||
|
||||
通过 [`dimensionSpec`](#dimensionSpec) 配置维度。
|
||||
|
||||
#### 指标
|
||||
Metrics是以聚合形式存储的列。启用 [rollup](#Rollup) 时，它们最有用。指定一个Metric允许您为Druid选择一个聚合函数，以便在摄取期间应用于每一行。这有两个好处：
|
||||
|
||||
1. 如果启用了 [rollup](#Rollup)，即使保留摘要信息，也可以将多行折叠为一行。在 [Rollup教程](../Tutorials/chapter-5.md) 中，这用于将netflow数据折叠为每（`minute`，`srcIP`，`dstIP`）元组一行，同时保留有关总数据包和字节计数的聚合信息。
|
||||
2. 一些聚合器，特别是近似聚合器，即使在非汇总数据上，如果在接收时部分计算，也可以在查询时更快地计算它们。
|
||||
|
||||
Metrics是通过 [`metricsSpec`](#metricsSpec) 配置的。
|
||||
|
||||
### Rollup
|
||||
#### 什么是rollup
|
||||
Druid可以在接收过程中将数据进行汇总，以最小化需要存储的原始数据量。Rollup是一种汇总或预聚合的形式。实际上，Rollup可以极大地减少需要存储的数据的大小，从而潜在地减少行数的数量级。这种存储量的减少是有代价的：当我们汇总数据时，我们就失去了查询单个事件的能力。
|
||||
|
||||
禁用rollup时，Druid将按原样加载每一行，而不进行任何形式的预聚合。此模式类似于您对不支持汇总功能的典型数据库的期望。
|
||||
|
||||
如果启用了rollup，那么任何具有相同[维度](#维度)和[时间戳](#主时间戳列)的行（在基于 `queryGranularity` 的截断之后）都可以在Druid中折叠或汇总为一行。
|
||||
|
||||
rollup默认是启用状态。
|
||||
|
||||
#### 启用或者禁用rollup
|
||||
|
||||
Rollup由 `granularitySpec` 中的 `rollup` 配置项控制。 默认情况下，值为 `true`(启用状态)。如果你想让Druid按原样存储每条记录，而不需要任何汇总，将该值设置为 `false`。
|
||||
|
||||
#### rollup示例
|
||||
有关如何配置Rollup以及该特性将如何修改数据的示例，请参阅[Rollup教程](../Tutorials/chapter-5.md)。
|
||||
|
||||
#### 最大化rollup比率
|
||||
通过比较Druid中的行数和接收的事件数，可以测量数据源的汇总率。这个数字越高，从汇总中获得的好处就越多。一种方法是使用[Druid SQL](../Querying/druidsql.md)查询，比如：
|
||||
```
|
||||
SELECT SUM("cnt") / COUNT(*) * 1.0 FROM datasource
|
||||
```
|
||||
#### 最佳rollup VS 尽可能rollup
|
||||
### 分区
|
||||
#### 为什么分区
|
||||
|
|
|
|||
|
|
@ -1 +1,6 @@
|
|||
<!-- toc -->
|
||||
<!-- toc -->
|
||||
## Schema设计
|
||||
### Druid数据模型
|
||||
### 与其他设计模式类比
|
||||
### 一般提示以及最佳实践
|
||||
#### 辅助时间戳
|
||||
|
|
@ -1 +1,3 @@
|
|||
<!-- toc -->
|
||||
<!-- toc -->
|
||||
### 锁
|
||||
#### `compact`
|
||||
|
|
@ -2,10 +2,10 @@
|
|||
|
||||
## Broker
|
||||
### 配置
|
||||
对于Apache Druid Broker的配置，请参见 [Broker配置]()
|
||||
对于Apache Druid Broker的配置，请参见 [Broker配置](../Configuration/configuration.md#Broker)
|
||||
|
||||
### HTTP
|
||||
对于Broker的API的列表，请参见 [Broker API]()
|
||||
对于Broker的API的列表，请参见 [Broker API](../Operations/api.md#Broker)
|
||||
|
||||
### 综述
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
<!-- toc -->
|
||||
## Coordinator进程
|
||||
### 配置
|
||||
对于Apache Druid的Coordinator进程配置，详见 [Coordinator配置]()
|
||||
对于Apache Druid的Coordinator进程配置，详见 [Coordinator配置](../Configuration/configuration.md#Coordinator)
|
||||
|
||||
### HTTP
|
||||
对于Coordinator的API接口，详见 [Coordinator API]()
|
||||
对于Coordinator的API接口，详见 [Coordinator API](../Operations/api.md#Coordinator)
|
||||
|
||||
### 综述
|
||||
Druid Coordinator程序主要负责段管理和分发。更具体地说，Druid Coordinator进程与Historical进程通信，根据配置加载或删除段。Druid Coordinator负责加载新段、删除过时段、管理段复制和平衡段负载。
|
||||
|
|
@ -18,7 +18,7 @@ Druid Coordinator定期运行，每次运行之间的时间是一个可配置的
|
|||
org.apache.druid.cli.Main server coordinator
|
||||
```
|
||||
### 规则
|
||||
可以根据一组规则自动从集群中加载和删除段。有关规则的详细信息，请参阅[规则配置]()。
|
||||
可以根据一组规则自动从集群中加载和删除段。有关规则的详细信息，请参阅[规则配置](../Operations/retainingOrDropData.md)。
|
||||
|
||||
### 清理段
|
||||
每次运行时，Druid Coordinator都会将数据库中可用段的列表与集群中的当前段进行比较,不在数据库中但仍在集群中服务的段将被标记并附加到删除列表中,被遮蔽的段（它们的版本太旧，它们的数据被更新的段替换）也会被丢弃。
|
||||
|
|
@ -31,14 +31,14 @@ org.apache.druid.cli.Main server coordinator
|
|||
|
||||
### 合并段
|
||||
|
||||
每次运行时，Druid Coordinator都通过合并小段或拆分大片段来压缩段。当您的段没有进行段大小（可能会导致查询性能下降）优化时，该操作非常有用。有关详细信息，请参见[段大小优化]()。
|
||||
每次运行时，Druid Coordinator都通过合并小段或拆分大片段来压缩段。当您的段没有进行段大小（可能会导致查询性能下降）优化时，该操作非常有用。有关详细信息，请参见[段大小优化](../Operations/segmentSizeOpt.md)。
|
||||
|
||||
Coordinator首先根据[段搜索策略](#段搜索策略)查找要压缩的段。找到某些段后，它会发出[压缩任务]()来压缩这些段。运行压缩任务的最大数目为 `min(sum of worker capacity * slotRatio, maxSlots)`。请注意，即使 `min(sum of worker capacity * slotRatio, maxSlots)` = 0，如果为数据源启用了压缩，则始终会提交至少一个压缩任务。请参阅[压缩配置API]()和[压缩配置]()以启用压缩。
|
||||
Coordinator首先根据[段搜索策略](#段搜索策略)查找要压缩的段。找到某些段后，它会发出[压缩任务](../DataIngestion/taskrefer.md#compact)来压缩这些段。运行压缩任务的最大数目为 `min(sum of worker capacity * slotRatio, maxSlots)`。请注意，即使 `min(sum of worker capacity * slotRatio, maxSlots)` = 0，如果为数据源启用了压缩，则始终会提交至少一个压缩任务。请参阅[压缩配置API](../Operations/api.md#Coordinator)和[压缩配置](../Configuration/configuration.md#Coordinator)以启用压缩。
|
||||
|
||||
压缩任务可能由于以下原因而失败:
|
||||
|
||||
* 如果压缩任务的输入段在开始前被删除或覆盖，则该压缩任务将立即失败。
|
||||
* 如果优先级较高的任务获取与压缩任务的时间间隔重叠的[时间块锁]()，则压缩任务失败。
|
||||
* 如果优先级较高的任务获取与压缩任务的时间间隔重叠的[时间块锁](../DataIngestion/taskrefer.md#锁)，则压缩任务失败。
|
||||
|
||||
一旦压缩任务失败，Coordinator只需再次检查失败任务间隔中的段，并在下次运行中发出另一个压缩任务。
|
||||
|
||||
|
|
@ -64,14 +64,14 @@ Coordinator首先根据[段搜索策略](#段搜索策略)查找要压缩的段
|
|||
|
||||
如果Coordinator还有足够的用于压缩任务的插槽，该策略则继续搜索剩下的段并返回 `bar_2017-10-01T00:00:00.000Z_2017-11-01T00:00:00.000Z_VERSION` 和 `bar_2017-10-01T00:00:00.000Z_2017-11-01T00:00:00.000Z_VERSION_1`。最后，因为在 `2017-09-01T00:00:00.000Z/2017-10-01T00:00:00.000Z` 时间间隔中只有一个段，所以 `foo_2017-09-01T00:00:00.000Z_2017-10-01T00:00:00.000Z_VERSION` 段也会被选择。
|
||||
|
||||
搜索的起点可以通过 [skipOffsetFromLatest]() 来更改设置。如果设置了此选项，则此策略将忽略范围内的时间段（最新段的结束时间 - `skipOffsetFromLatest`）， 该配置项主要是为了避免压缩任务和实时任务之间的冲突。请注意，默认情况下，实时任务的优先级高于压缩任务。如果两个任务的时间间隔重叠，实时任务将撤消压缩任务的锁，从而终止压缩任务。
|
||||
搜索的起点可以通过 [skipOffsetFromLatest](../Configuration/configuration.md#Coordinator) 来更改设置。如果设置了此选项，则此策略将忽略范围内的时间段（最新段的结束时间 - `skipOffsetFromLatest`）， 该配置项主要是为了避免压缩任务和实时任务之间的冲突。请注意，默认情况下，实时任务的优先级高于压缩任务。如果两个任务的时间间隔重叠，实时任务将撤消压缩任务的锁，从而终止压缩任务。
|
||||
|
||||
> [!WARNING]
|
||||
> 当有很多相同间隔的小段，并且它们的总大小超过 `inputSegmentSizeBytes` 时，此策略当前无法处理这种情况。如果它找到这样的段，它只会跳过它们。
|
||||
|
||||
### Coordinator控制台
|
||||
|
||||
Druid Coordinator公开了一个web GUI，用于显示集群信息和规则配置。有关详细信息，请参阅[Coordinator控制台]()。
|
||||
Druid Coordinator公开了一个web GUI，用于显示集群信息和规则配置。有关详细信息，请参阅[Coordinator控制台](../Operations/manageui.md)。
|
||||
|
||||
### FAQ
|
||||
|
||||
|
|
|
|||
|
|
@ -21,12 +21,12 @@ Apache Druid不提供的存储机制，深度存储是存储段的地方。深
|
|||
|
||||
### S3适配
|
||||
|
||||
请看[druid-s3-extensions]()扩展文档
|
||||
请看[druid-s3-extensions](../Configuration/core-ext/s3.md)扩展文档
|
||||
|
||||
### HDFS
|
||||
|
||||
请看[druid-hdfs-extensions]()扩展文档
|
||||
请看[druid-hdfs-extensions](../Configuration/core-ext/hdfs.md)扩展文档
|
||||
|
||||
### 其他深度存储
|
||||
|
||||
对于另外的深度存储等，可以参见[扩展列表]()
|
||||
对于另外的深度存储等，可以参见[扩展列表](../Configuration/extensions.md)
|
||||
|
|
@ -2,16 +2,16 @@
|
|||
|
||||
## Overload进程
|
||||
### 配置
|
||||
对于Apache Druid的Overlord进程配置，详见 [Overlord配置]()
|
||||
对于Apache Druid的Overlord进程配置，详见 [Overlord配置](../Configuration/configuration.md#Overlord)
|
||||
|
||||
### HTTP
|
||||
对于Overlord的API接口，详见 [Overlord API]()
|
||||
对于Overlord的API接口，详见 [Overlord API](../Operations/api.md#Overlord)
|
||||
|
||||
### 综述
|
||||
Overlord进程负责接收任务、协调任务分配、创建任务锁并将状态返回给调用方。Overlord可以配置为本地模式运行或者远程模式运行（默认为本地）。在本地模式下，Overlord还负责创建执行任务的Peon， 在本地模式下运行Overlord时，还必须提供所有MiddleManager和Peon配置。本地模式通常用于简单的工作流。在远程模式下，Overlord和MiddleManager在不同的进程中运行，您可以在不同的服务器上运行每一个进程。如果要将索引服务用作所有Druid索引的单个端点，建议使用此模式。
|
||||
|
||||
### Overlord控制台
|
||||
Druid Overlord公开了一个web GUI，用于管理任务和worker。有关详细信息，请参阅[Overlord控制台]()。
|
||||
Druid Overlord公开了一个web GUI，用于管理任务和worker。有关详细信息，请参阅[Overlord控制台](../Operations/manageui.md)。
|
||||
|
||||
### worker黑名单
|
||||
如果一个MiddleManager的任务失败超过阈值，Overlord会将这些MiddleManager列入黑名单。不超过20%的MiddleManager可以被列入黑名单，被列入黑名单的MiddleManager将定期被列入白名单。
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ Query服务提供用户和客户端应用程序交互，将查询路由到Data
|
|||
|
||||
Router进程是*可选*的进程，相当于是为Druid Broker、Overlord和Coordinator提供一个统一的API网关。Router是可选的，因为也可以直接与Druid的Broker、Overlord和Coordinator。
|
||||
|
||||
Router还运行着[Druid控制台]()，一个用于数据源、段、任务、数据进程（Historical和MiddleManager）和Coordinator动态配置的管理UI。用户还可以在控制台中运行SQL和本地Druid查询。
|
||||
Router还运行着[Druid控制台](../Operations/manageui.md)，一个用于数据源、段、任务、数据进程（Historical和MiddleManager）和Coordinator动态配置的管理UI。用户还可以在控制台中运行SQL和本地Druid查询。
|
||||
|
||||
#### Data服务
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ Data服务执行摄取作业并存储可查询数据。
|
|||
|
||||
[Indexer](./Indexer.md) 进程是MiddleManager和Peon的替代方法。Indexer在单个JVM进程中作为单个线程运行任务，而不是为每个任务派生单独的JVM进程。
|
||||
|
||||
与MiddleManager + Peon系统相比，Indexer的设计更易于配置和部署，并且能够更好地实现跨任务的资源共享。Indexer是一种较新的功能，由于其内存管理系统仍在开发中，因此目前被指定为[实验性的特性]()。它将在Druid的未来版本中继续成熟。
|
||||
与MiddleManager + Peon系统相比，Indexer的设计更易于配置和部署，并且能够更好地实现跨任务的资源共享。Indexer是一种较新的功能，由于其内存管理系统仍在开发中，因此目前被指定为[实验性的特性](../Development/experimental.md)。它将在Druid的未来版本中继续成熟。
|
||||
|
||||
通常，您可以部署MiddleManagers或indexer，但不能同时部署两者。
|
||||
|
||||
|
|
@ -97,7 +97,7 @@ Coordinator进程的工作负载往往随着集群中段的数量而增加。Ove
|
|||
|
||||
通过设置 `druid.Coordinator.asOverlord.enabled` 属性，Coordinator进程和Overlord进程可以作为单个组合进程运行。
|
||||
|
||||
有关详细信息，请参阅[Coordinator配置]()。
|
||||
有关详细信息，请参阅[Coordinator配置](../Configuration/configuration.md#Coordinator)。
|
||||
|
||||
#### Historical和MiddleManager
|
||||
|
||||
|
|
|
|||
|
|
@ -4,19 +4,19 @@
|
|||
> [!WARNING]
|
||||
> Router是一个可选的和实验性的特性，因为它在Druid集群架构中的推荐位置仍在不断发展。然而，它已经在生产中经过了测试，并且承载了强大的Druid控制台，所以您应该放心地部署它。
|
||||
|
||||
Apache Druid Router用于将查询路由到不同的Broker。默认情况下，Broker根据 [规则]() 设置路由查询。例如，如果将最近1个月的数据加载到一个 `热集群` 中，则可以将最近一个月内的查询路由到一组专用的Broker,超出此范围的查询将路由到另一组Broker。该设置的主要功能是为了提供查询隔离，以便对较重要数据的查询不会受到对较不重要数据的查询的影响。
|
||||
Apache Druid Router用于将查询路由到不同的Broker。默认情况下，Broker根据 [规则](../Operations/retainingOrDropData.md) 设置路由查询。例如，如果将最近1个月的数据加载到一个 `热集群` 中，则可以将最近一个月内的查询路由到一组专用的Broker,超出此范围的查询将路由到另一组Broker。该设置的主要功能是为了提供查询隔离，以便对较重要数据的查询不会受到对较不重要数据的查询的影响。
|
||||
|
||||
出于查询路由的目的，如果您有一个TB数据规模的Druid集群，您应该只使用Router进程。
|
||||
|
||||
除了查询路由，Router还运行 [Druid控制台](), 一个用于数据源、段、任务、数据进程（Historical和MiddleManager）和Coordinator动态配置的管理UI。用户还可以在控制台中运行SQL和本地Druid查询。
|
||||
除了查询路由，Router还运行 [Druid控制台](../Operations/manageui.md), 一个用于数据源、段、任务、数据进程（Historical和MiddleManager）和Coordinator动态配置的管理UI。用户还可以在控制台中运行SQL和本地Druid查询。
|
||||
|
||||
### 配置
|
||||
|
||||
对于Apache Druid Router的配置，请参见 [Router 配置]()
|
||||
对于Apache Druid Router的配置，请参见 [Router 配置](../Configuration/configuration.md#Router)
|
||||
|
||||
### HTTP
|
||||
|
||||
对于Router的API列表，请参见 [Router API]()
|
||||
对于Router的API列表，请参见 [Router API](../Operations/api.md#Router)
|
||||
|
||||
### 运行
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
<!-- toc -->
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
<!-- toc -->
|
||||
### 通用
|
||||
### Master
|
||||
#### Coordinator
|
||||
#### Overlord
|
||||
### Data
|
||||
#### MiddleManager
|
||||
#### Peon
|
||||
#### Historical
|
||||
### Query
|
||||
#### Broker
|
||||
#### Router
|
||||
|
|
@ -0,0 +1 @@
|
|||
<!-- toc -->
|
||||
|
|
@ -0,0 +1 @@
|
|||
<!-- toc -->
|
||||
|
|
@ -0,0 +1 @@
|
|||
<!-- toc -->
|
||||
Loading…
Reference in New Issue