add link

Configuration/configuration.md

@@ -0,0 +1,13 @@
+<!-- toc -->
+### 推荐的配置文件组织方式
+### 通用配置
+### Master
+#### Coordinator
+#### Overlord
+### Data
+#### MiddleManager and Peons
+#### Indexer
+#### Historical
+### Query
+#### Broker
+#### Router

Configuration/core-ext/hdfs.md

@@ -0,0 +1 @@
+<!-- toc -->

Configuration/core-ext/s3.md

@@ -0,0 +1 @@
+<!-- toc -->

Configuration/extensions.md

@@ -0,0 +1 @@
+<!-- toc -->

DataIngestion/ingestion.md

@@ -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
 ### 分区
 #### 为什么分区

DataIngestion/schemadesign.md

@@ -1 +1,6 @@
-<!-- toc -->
+<!-- toc -->
+## Schema设计
+### Druid数据模型
+### 与其他设计模式类比
+### 一般提示以及最佳实践
+#### 辅助时间戳

DataIngestion/taskrefer.md

@@ -1 +1,3 @@
-<!-- toc -->
+<!-- toc -->
+### 锁
+#### `compact`

Design/Broker.md

@@ -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)
 
 ### 综述
 

Design/Coordinator.md

@@ -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
 

Design/Deepstorage.md

@@ -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)

Design/Overlord.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将定期被列入白名单。

Design/Processes.md

@@ -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
 

Design/Router.md

@@ -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)
 
 ### 运行
 

Development/experimental.md

@@ -0,0 +1 @@
+<!-- toc -->

Operations/api.md

@@ -0,0 +1,12 @@
+<!-- toc -->
+### 通用
+### Master
+#### Coordinator
+#### Overlord
+### Data
+#### MiddleManager
+#### Peon
+#### Historical
+### Query
+#### Broker
+#### Router

Operations/manageui.md

@@ -0,0 +1 @@
+<!-- toc -->

Operations/retainingOrDropData.md

@@ -0,0 +1 @@
+<!-- toc -->

Operations/segmentSizeOpt.md

@@ -0,0 +1 @@
+<!-- toc -->