跳转到主要内容

架构

Druid 采用分布式架构，专为云环境设计且易于运维。您可以独立配置和扩展各项服务，从而在集群操作中实现最大的灵活性。这种设计增强了容错性：一个组件的故障不会立即影响其他组件。

下图展示了构成 Druid 架构的服务、它们在服务器上的典型排列方式，以及查询和数据在架构中的流动方式。

Druid architecture

以下章节描述了此架构的各个组件。

Druid 服务​

Druid 包含多种类型的服务：

  • Coordinator 管理集群上的数据可用性。
  • Overlord 控制数据摄入工作负载的分配。
  • Broker 处理来自外部客户端的查询。
  • Router 将请求路由至 Broker、Coordinator 和 Overlord。
  • Historical 存储可供查询的数据。
  • Middle Manager 和 Peon 负责摄入数据。
  • Indexer 作为 Middle Manager + Peon 任务执行系统的替代方案。

您可以在 Web 控制台的服务 (Services) 选项卡中查看服务。

Druid services

Druid 服务器​

您可以根据喜好部署 Druid 服务。为了方便部署，我们建议将它们组织为三种服务器类型：Master（主节点）、Query（查询节点） 和 Data（数据节点）。

Master 服务器​

Master 服务器管理数据摄入和可用性。它负责启动新的摄入任务，并协调 Data 服务器上的数据可用性。

Master 服务器将操作分配给 Coordinator 和 Overlord 服务。

Coordinator 服务​

Coordinator 服务监控 Data 服务器上的 Historical 服务。它们负责将分片 (Segments) 分配给特定的服务器，并确保分片在各个 Historical 节点之间达到均衡。

Overlord 服务​

Overlord 服务监控 Data 服务器上的 Middle Manager 服务，是 Druid 数据摄入的控制器。它们负责将摄入任务分配给 Middle Manager，并协调分片的发布。

Query 服务器​

Query 服务器提供用户和客户端应用程序交互的端点，将查询路由到 Data 服务器或其他 Query 服务器（以及可选的代理 Master 服务器请求）。

Query 服务器将操作分配给 Broker 和 Router 服务。

Broker 服务​

Broker 服务接收来自外部客户端的查询，并将这些查询转发到 Data 服务器。当 Broker 收到这些子查询的结果时，会将它们合并并返回给调用者。通常，您应该直接查询 Broker，而不是直接查询 Data 服务器上的 Historical 或 Middle Manager 服务。

Router 服务​

Router 服务在 Broker、Overlord 和 Coordinator 前面提供统一的 API 网关。

Router 服务还运行 Web 控制台，这是一个用于加载数据、管理数据源和任务，以及查看服务器状态和分片信息的 UI。

Data 服务器​

Data 服务器执行摄入任务并存储可查询的数据。

Data 服务器将操作分配给 Historical 和 Middle Manager 服务。

Historical 服务​

Historical 服务处理历史数据的存储和查询，包括系统中已存在足够长时间并已提交的所有流数据。Historical 服务从深度存储下载分片并响应针对这些分片的查询。它们不接受写入。

Middle Manager 服务​

Middle Manager 服务处理新数据的摄入。它们负责读取外部数据源并发布新的 Druid 分片。

Peon 服务​

Peon 服务是由 Middle Manager 派生的任务执行引擎。每个 Peon 运行一个独立的 JVM，负责执行单个任务。Peon 始终与派生它们的 Middle Manager 运行在同一主机上。

Indexer 服务（可选）​

Indexer 服务是 Middle Manager 和 Peon 的替代方案。Indexer 不会为每个任务派生单独的 JVM 进程，而是将任务作为单个 JVM 进程中的独立线程运行。

与 Middle Manager + Peon 系统相比，Indexer 设计得更易于配置和部署，并且能更好地在任务之间共享资源，这有助于流式摄入。目前 Indexer 被指定为实验性功能。

通常，您会部署以下选项之一：MiddleManager、使用 Kubernetes 的 MiddleManager-less 摄入，或 Indexer。您不应该同时部署这些选项中的多个。

服务共置 (Colocation of services)​

对于大多数集群，按服务器类型共置 Druid 服务通常能更好地利用硬件资源。对于超大规模集群，为了避免资源竞争，可能需要将 Druid 服务分开，使它们运行在独立的服务器上。

本节描述与服务共置相关的指南和配置参数。

Coordinator 和 Overlord​

Coordinator 服务的负载往往随着集群中分片数量的增加而增加。Overlord 的负载也会随集群中分片数量的增加而增加，但程度低于 Coordinator。

在分片数量非常高的集群中，将 Coordinator 和 Overlord 服务分离是有意义的，这样可以为 Coordinator 的分片平衡工作提供更多资源。

您可以通过设置 druid.coordinator.asOverlord.enabled 属性将 Coordinator 和 Overlord 服务作为单个组合服务运行。有关详细信息，请参阅 Coordinator 操作。

Historical 和 Middle Manager​

在摄入量或查询负载较高时，将 Historical 和 Middle Manager 服务部署在不同的主机上以避免 CPU 和内存竞争是有意义的。

Historical 服务还可以从空闲内存中受益以用于内存映射分片，这也是分开部署 Historical 和 Middle Manager 服务的另一个原因。

外部依赖​

除了内置的服务类型外，Druid 还有三个外部依赖。这些依赖旨在利用现有的基础设施（如果有的话）。

深度存储 (Deep storage)​

Druid 使用深度存储来存储所有已摄入系统的数据。深度存储是所有 Druid 服务器都可以访问的共享文件存储。在集群部署中，这通常是分布式对象存储（如 S3 或 HDFS）或网络挂载文件系统。在单机部署中，这通常是本地磁盘。

Druid 将深度存储用于以下目的：

  • 用于存储您摄入的所有数据。为了低延迟查询而加载到 Historical 服务上的分片也会为了备份目的保留在深度存储中。此外，仅存在于深度存储中的分片可用于深度存储查询。
  • 作为 Druid 服务之间后台数据传输的方式。Druid 以称为分片 (Segments) 的文件形式存储数据。

Historical 服务在本地磁盘上缓存数据分片，并从该缓存以及内存缓存中响应查询。Historical 服务磁盘上的分片提供了 Druid 闻名的低延迟查询性能。

您也可以直接从深度存储进行查询。当查询仅存在于深度存储中的分片时，您是用一定的性能损耗换取了无需扩展 Historical 服务即可查询更多数据的能力。

在确定存储容量时，请记住以下几点：

  • 深度存储需要能够容纳您摄入 Druid 的所有数据。
  • Historical 服务的磁盘存储需要能够容纳您想要加载以运行查询的数据。Historical 服务上的数据应该是您频繁访问且需要低延迟查询的数据。

深度存储是 Druid 弹性、容错设计的关键部分。即使所有数据服务器都丢失并重新配置，Druid 也可以从深度存储中引导恢复。

有关更多详细信息，请参阅 深度存储 页面。

元数据存储 (Metadata storage)​

元数据存储保存各种共享的系统元数据，例如分片使用信息和任务信息。在集群部署中，这通常是传统的 RDBMS（如 PostgreSQL 或 MySQL）。在单机部署中，通常是本地存储的 Apache Derby 数据库。

有关更多详细信息，请参阅 元数据存储 页面。

ZooKeeper​

用于内部服务发现、协调和领导者选举。

有关更多详细信息，请参阅 ZooKeeper 页面。

了解更多​

请参阅以下主题以获取更多信息：