From fb40c5812ec31f1d39efb8c1f2d5f0948be3b65c Mon Sep 17 00:00:00 2001 From: YuCheng Hu Date: Tue, 27 Jul 2021 12:53:47 -0400 Subject: [PATCH] =?UTF-8?q?=E8=B0=83=E6=95=B4=E9=A1=B5=E9=9D=A2=E7=BB=93?= =?UTF-8?q?=E6=9E=84=E5=92=8C=E7=9B=AE=E5=BD=95=E7=BB=93=E6=9E=84?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- SUMMARY.md | 4 ++-- _sidebar.md | 19 ++++++++++++++++--- design/Broker.md | 2 +- design/Design.md | 4 ++-- design/Historical.md | 2 +- design/{Processes.md => processes.md} | 0 design/{Segments.md => segments.md} | 0 querying/dimensionspec.md | 2 +- querying/druidsql.md | 2 +- querying/multi-value-dimensions.md | 2 +- querying/multitenancy.md | 2 +- querying/queryexecution.md | 2 +- 12 files changed, 27 insertions(+), 14 deletions(-) rename design/{Processes.md => processes.md} (100%) rename design/{Segments.md => segments.md} (100%) diff --git a/SUMMARY.md b/SUMMARY.md index 226de4a..50f1ab5 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -34,8 +34,8 @@ * [架构设计]() * [整体设计](design/Design.md) - * [段设计](design/Segments.md) - * [进程与服务](design/Processes.md) + * [段设计](design/segments.md) + * [进程与服务](design/processes.md) * [Coordinator](design/Coordinator.md) * [Overlord](design/Overlord.md) * [Historical](design/Historical.md) diff --git a/_sidebar.md b/_sidebar.md index 03fec2f..31d6940 100644 --- a/_sidebar.md +++ b/_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) - - [MessagePack](message-pack/index.md) - - [Protocol Buffers](protocol-buffers/index.md) + - [设计](design/architecture.md) + - [段（Segments）](design/segments.md) + - [进程和服务](design/processes.md) + - [深度存储](dependencies/deep-storage.md) + - [元数据存储](dependencies/metadata-storage.md) + - [ZooKeeper](dependencies/zookeeper.md) - 摄取（Ingestion） - [面试问题和经验](interview/index.md) diff --git a/design/Broker.md b/design/Broker.md index 7ffed55..9767249 100644 --- a/design/Broker.md +++ b/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将查询向下转发到所选进程。 diff --git a/design/Design.md b/design/Design.md index f623abc..6c2e897 100644 --- a/design/Design.md +++ b/design/Design.md @@ -19,7 +19,7 @@ Druid进程可以按照您喜欢的方式部署，但是为了便于部署，我 * **Query**: 运行Broker和可选的Router进程，处理来自外部客户端的请求 * **Data**: 运行Historical和MiddleManager进程，执行摄取负载和存储所有可查询的数据 -关于进程和服务组织的更多信息，可以查看[Druid进程与服务](Processes.md) +关于进程和服务组织的更多信息，可以查看[Druid进程与服务](processes.md) @@ -77,7 +77,7 @@ Druid数据被存储在"datasources"中，类似于传统RDBMS中的表。每一 周期性地，段被提交和发布，此时，它们将被写入到深度存储且变得不可更改，同时从MiddleManager移动到Historical进程。有关段的信息也写入到元数据存储中，这个信息是一个自描述的信息，包括段的schema、大小以及在深度存储中的位置，Coordinator可以根据这些信息来知道集群上应该有哪些数据是可用的 -有关段文件格式的信息，请参见[段文件](Segments.md) +有关段文件格式的信息，请参见[段文件](segments.md) 有关数据在Druid的建模，请参见[schema设计](../DataIngestion/schemadesign.md) diff --git a/design/Historical.md b/design/Historical.md index e0ea081..9662ebb 100644 --- a/design/Historical.md +++ b/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中与该进程相关联的服务段路径下被宣布，同时，该段可供查询。 ### 从缓存加载和服务段 diff --git a/design/Processes.md b/design/processes.md similarity index 100% rename from design/Processes.md rename to design/processes.md diff --git a/design/Segments.md b/design/segments.md similarity index 100% rename from design/Segments.md rename to design/segments.md diff --git a/querying/dimensionspec.md b/querying/dimensionspec.md index 6630b0c..2228010 100644 --- a/querying/dimensionspec.md +++ b/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来筛选多值维度值中的特定值。这些维度规范采用代理维度规范和筛选条件。从"分解"行中，查询结果中只返回与给定筛选条件匹配的行。 diff --git a/querying/druidsql.md b/querying/druidsql.md index ed83139..5971053 100644 --- a/querying/druidsql.md +++ b/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兼容的空值处理)。 ### 聚合函数 diff --git a/querying/multi-value-dimensions.md b/querying/multi-value-dimensions.md index e8cb518..9313728 100644 --- a/querying/multi-value-dimensions.md +++ b/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)