Слияние кода завершено, страница обновится автоматически
Druid有一个多进程、分布式的架构，该架构设计为云友好且易于操作。每个Druid进程都可以独立配置和扩展，在集群上提供最大的灵活性。这种设计还提供了增强的容错能力：一个组件的中断不会立即影响其他组件。
Druid有若干不同类型的进程，简单描述如下：
Druid进程可以按照您喜欢的方式部署，但是为了便于部署，我们建议将它们组织成三种服务器类型：Master、Query和Data。
关于进程和服务组织的更多信息，可以查看Druid进程与服务
<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script> <script> (adsbygoogle = window.adsbygoogle || []).push({}); </script>除了内置的进程类型外，Druid同时有三个外部依赖，它们旨在利用现有的基础设施（如果有的话）。
每个Druid服务器都可以访问的共享文件存储。在集群部署中，通常使用一个像S3或HDFS这样的分布式对象存储，或者是一个网络挂载的文件系统。在单服务器部署中，通常使用本地磁盘。Druid使用深度存储来存储任何已被系统接收的数据。
Druid只使用深度存储作为数据备份，并作为在后台Druid进程之间传输数据的一种方式。为了响应查询，Historical进程不会从深层存储中读取数据，而是从本地磁盘读取在执行任何查询之前预缓存的段，这意味着Druid在查询期间不需要访问深层存储，这有助于它提供尽可能最好的查询延迟。这也意味着您必须在深层存储和所有Historical进程中都有足够的磁盘空间来存储计划加载的数据。
深度存储是Druid弹性、容错设计的重要组成部分。即使每个数据服务器都丢失并重新配置，Druid也可以从深层存储启动。
有关更多详细信息，请参见深度存储
元数据存储包含各种共享的系统元数据，如段可用性信息和任务信息。在集群部署中，通常使用像PostgreSQL或MySQL这样的传统RDBMS。在单服务器部署中，通常使用本地存储的Apache Derby数据库。
有关更多详细信息，请参见元数据存储
用于内部服务发现、协调和领导选举。
有关更多详细信息，请参见Zookeeper
下图显示了使用建议的Master/Query/Data服务组织，查询和数据如何通过此体系结构流动：
Druid数据被存储在"datasources"中，类似于传统RDBMS中的表。每一个数据源可以根据时间进行分区，可选地还可以进一步根据其他属性进行分区。每一个时间范围称为一个"块（chunk）"(例如，如果数据源按天分区，则为一天)。在一个块中，数据被分为一个或者多个"段（segments）"。每个段是一个单独的文件，一般情况下由数百万条数据组成。由于段被组织成时间块，因此有时将段视为存在于如下时间线上是有帮助的：
一个数据源可能有几个段到几十万甚至几百万个段。每个段都是在MiddleManager上创建的，但此时段是可变的和未提交的。段构建过程包括以下步骤，旨在生成一个紧凑且支持快速查询的数据文件：
周期性地，段被提交和发布，此时，它们将被写入到深度存储且变得不可更改，同时从MiddleManager移动到Historical进程。有关段的信息也写入到元数据存储中，这个信息是一个自描述的信息，包括段的schema、大小以及在深度存储中的位置，Coordinator可以根据这些信息来知道集群上应该有哪些数据是可用的
有关段文件格式的信息，请参见段文件
有关数据在Druid的建模，请参见schema设计
*索引(Indexing)*是创建新段的一种机制，*切换(handoff)*是发布新段并开始由Historical进程提供服务的机制。该机制在索引端的工作方式如下：
在Coordinator和Historical方面：
段都有一个由四部分组成的标识符，包含以下组件：
segmentGranularity 有关）例如这个一个段标识符，数据源为 clarity-cloud0, 时间块为 2018-05-21T16:00:00.000Z/2018-05-21T17:00:00.000Z, 版本为 2018-05-21T15:56:09.909Z 以及分区编号为 1:
clarity-cloud0_2018-05-21T16:00:00.000Z_2018-05-21T17:00:00.000Z_2018-05-21T15:56:09.909Z_1
分区号为0的段（块中的第一个分区）忽略分区号，如下例所示，该段与上一个时间块位于同一时间块中，但分区号为0而不是1：
clarity-cloud0_2018-05-21T16:00:00.000Z_2018-05-21T17:00:00.000Z_2018-05-21T15:56:09.909Z
您可能想知道上一节中描述的“版本号”是用来做什么的。或者，你可能不想知道，在这种情况下对你有好处，你可以跳过这一节！
它支持批处理模式覆盖。在Druid中，如果您所做的只是附加数据，那么每个时间块只有一个版本。但是当您覆盖数据时，幕后发生的事情是，使用相同的数据源、相同的时间间隔、但更高的版本号创建一组新的段。这向Druid系统的其他部分发出了一个信号：旧版本应该从集群中删除，新版本应该替换它。
这个切换对用户来说似乎是瞬间发生的，因为Druid通过首先加载新数据（但不允许查询它）来处理这个问题，然后在新数据全部加载后，将所有新查询切换为使用这些新段。几分钟后，它会把旧的段卸载下来。
每个段都有一个生命周期，涉及以下三个主要领域：
used 的布尔标识，控制着段是否可查询。被实时任务创建的段在发布之前是可用的，因为它们仅在完成之时发布，并且不再接受额外的数据行可以使用Druid SQL查询 sys.segments 表检查当前活动段的状态，它包括以下标志：
is_published: 如果段元数据已发布到元数据存储且 used 是true的话，则为trueis_available: 如果段当前可用于查询（实时任务或Historical进程），则为trueis_realtime: 如果段仅在实时任务上可用，则为true。对于使用实时摄取的数据源，这通常从true开始，然后在发布和切换段时变为falseis_overshadowed: 如果段已发布（ used 设置为true），并且被某些其他已发布段完全覆盖，则为true。一般来说，这是一个过渡状态，处于该状态的段很快将其 used 标志自动设置为false查询首先进入Broker, Broker首先鉴别哪些段可能与本次查询有关。 段的列表总是按照时间进行筛选和修剪的，当然也可能由其他属性，具体取决于数据源的分区方式。然后，Broker将确定哪些Historical和MiddleManager为这些段提供服务、并向每个进程发送一个子查询。 Historical和MiddleManager进程接收查询、处理查询并返回结果，Broker将接收到的结果合并到一起形成最后的结果集返回给调用者。
Broker精简是Druid限制每个查询扫描数据量的一个重要方法，但不是唯一的方法。对于比Broker更细粒度级别的精简筛选器，每个段中的索引结构允许Druid在查看任何数据行之前，找出哪些行（如果有的话）与筛选器集匹配。一旦Druid知道哪些行与特定查询匹配，它就只访问该查询所需的特定列。在这些列中，Druid可以从一行跳到另一行，避免读取与查询过滤器不匹配的数据。
因此，Druid使用三种不同的技术来最大化查询性能：
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )