调整页面结构和目录结构

SUMMARY.md

@@ -34,8 +34,8 @@
 
 * [架构设计]()
   * [整体设计](design/Design.md)
-  * [段设计](design/Segments.md)
+  * [段设计](design/segments.md)
-  * [进程与服务](design/Processes.md)
+  * [进程与服务](design/processes.md)
     * [Coordinator](design/Coordinator.md)
     * [Overlord](design/Overlord.md)
     * [Historical](design/Historical.md)

_sidebar.md

@@ -6,11 +6,24 @@
   - [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)
   
 - 设计（Design）
-  - [JWT](jwt/README.md)
+  - [设计](design/architecture.md)
-  - [MessagePack](message-pack/index.md)
+  - [段（Segments）](design/segments.md)
-  - [Protocol Buffers](protocol-buffers/index.md)
+  - [进程和服务](design/processes.md)
+  - [深度存储](dependencies/deep-storage.md)
+  - [元数据存储](dependencies/metadata-storage.md)
+  - [ZooKeeper](dependencies/zookeeper.md)
 
 - 摄取（Ingestion）
   - [面试问题和经验](interview/index.md)

design/Broker.md

@@ -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将查询向下转发到所选进程。
 

design/Design.md

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

design/Historical.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中与该进程相关联的服务段路径下被宣布，同时，该段可供查询。
 
 ### 从缓存加载和服务段
 

querying/dimensionspec.md

@@ -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来筛选多值维度值中的特定值。这些维度规范采用代理维度规范和筛选条件。从"分解"行中，查询结果中只返回与给定筛选条件匹配的行。
 

querying/druidsql.md

@@ -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兼容的空值处理)。
 
 ### 聚合函数
 

querying/multi-value-dimensions.md

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

querying/multitenancy.md

@@ -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的内部处理逻辑将扫描一个查询中的一组段，扫描完成后立即释放资源，允许继续扫描来自另一个查询的第二组段。通过保持段计算时间非常小，我们确保不断地产生资源，并且与不同查询相关的段都被处理。
 

querying/queryexecution.md

@@ -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查询，段由单个线程按顺序处理，结果不被缓存。