TL;DR

• 场景：实时 + 历史 OLAP，需要稳定摄入、可扩展查询与可预期的集群运维。

• 结论：按 Master（Coordinator/Overlord）/Query（Broker/Router）/Data（Historical/MiddleManager）拆分，配合 ZK、元库与 Deep Storage，优先治理 Segment 与任务调度。

• 产出：架构要点清单、版本/依赖矩阵（待你确认）、常见故障定位与修复速查卡。

基础架构

Coordinator Node

Druid 的 Coordinator 组件主要负责集群中历史节点(Historical Node)的数据负载均衡和生命周期管理。具体来说，它的核心职责包括以下几个方面：

1. 数据负载均衡：

2. 监控各历史节点的负载情况

3. 根据配置的均衡策略在节点间迁移 Segment

4. 确保数据均匀分布，避免某些节点过载

5. 处理新加入或失效节点后的数据重分布

6. 生命周期管理：

7. 按照预先定义的规则(Rule)管理数据

8. 协调新数据的加载流程

9. 定期检查并卸载过期数据

10. 根据需要复制重要数据以提高可用性

11. 执行数据的冷热分层策略

Coordinator 的运行是周期性的，其执行间隔由 druid.coordinator.period 参数控制，默认值为 60000 毫秒(60 秒)。每次运行时，Coordinator 会：

1. 集群状态同步：

2. 维持与 ZooKeeper 的持久连接

3. 实时获取集群拓扑和节点状态信息

4. 监控历史节点的加入、离开或故障情况

5. 元数据管理：

6. 连接配置的元数据库(通常是 MySQL 或 PostgreSQL)

7. 读取和维护所有 Segment 的元信息

8. 获取和处理数据管理规则(Rule)配置

9. 记录 Segment 的分布和状态变更

10. 决策执行：

11. 根据规则和当前状态生成数据管理计划

12. 向历史节点下发加载/卸载指令

13. 协调节点间的数据迁移操作

14. 处理数据复制和均衡的请求

在实际应用中，Coordinator 的这些功能确保了 Druid 集群能够：

• 自动适应工作负载变化

• 优雅处理节点扩容或故障

• 按需保留有价值的历史数据

• 高效利用集群存储资源

Overlord Node

进程监视 MiddleManager 进程，并且是 Druid 数据摄入的主节点，负责将提取任务分配给 MiddleManagers 并协调 Segment 发布，包括接受、拆解、分配 Task，以及创建 Task 相关的锁，并返回 Task 的状态。

Historical Node

加载生成好的数据文件，以供数据查询。Historical Node 是整个集群查询性能的核心所在，Historical 会承担绝大部分的 Segment 查询。

• Historical 进程从 Deep Storage 中下载 Segment，并响应有关这些 Segment 的查询请求（这些请求来自 Broker 进程）

• Historical 进程不处理写入请求

• Historical 进程采用了无共享架构设计，它知道如何去加载和删除 Segment，以及如何基于 Segment 来响应查询。即便底层的深度存储无法正常工作，Historical 进程还是能针对其已同步的 Segments，正常提供查询服务。

• 底层的深度存储无法正常工作，Historical 进程还是能针对其已同步的 Segments，正常提供查询服务。

MiddleManager Node

及时摄入实时数据，生成 Segment 数据文件

• MiddleManager 进程是执行提交任务的工作节点，MiddleManagers 将任务转发给在不同 JVM 中运行的 Peon 进程

• MiddleManager、Peon、Task 的对应关系是：每个 Peon 进程一次只能运行一个 Task 任务，但一个 MiddleManager 却可以管理多个 Peon 进程

Broker Node

接收客户端查询请求，并将这些查询转发给 Histo 和 MiddleManagers。当 Brokers 从这些子查询中收到结果时，它们会合并这些结果并将它们返回给调用者。

• Broker 节点负责转发 Client 查询请求的

• Broker 通过 ZooKeeper 能够知道哪个 Segment 在哪些节点上，将查询转发给相应节点

• 所有节点返回数据后，Broker 会所有节点的数据进行合并，然后返回给 Client

Router Node

（可选）负责将路由转发到 Broker、Coordinator、Overlords

• Router 进程可以在 Broker、Overlords、Coordinator 进程之上，提供一层统一的 API 网关

• Router 进程是可选的，如果集群数据规模已经到达了 TB 级别，需要考虑启动（druid.router.managerProxy.enable=true）

• 一旦集群规模达到一定数量级，那么发生故障的概率就会变得不容忽视，而 Router 支持将请求只发送给健康的节点，避免请求失败。

• 同时，查询的响应时间和资源消耗，也会随着数据量的增长而变高，而 Router 支持设置查询的优先级和负载均衡策略，避免了大查询造成的队列堆积或查询热点等问题

如何分类

Druid 的进程可以被任意部署，为了理解与部署组织方便，这些进程分为了三类：

• Master：Coordinator、Overlord 负责数据可用性和摄取

• Query：Broker、Router 负责处理外部请求

• Data：Historical、MiddleManager，负责实际的 Ingestion 负载和数据存储

其他依赖

Deep Storage 存放生成的 Segment 数据文件，并供历史服务器下载，对于单节点集群可以是本地磁盘，而对于分布式集群一般是 HDFS。

• Druid 使用 Deep Storage 来做数据的备份，也作为 Druid 进程之间在后台传输数据的一种方式

• 当相应查询时，Historical 首先从本地磁盘读取预取的段，这也意味着需要在 Deep Storage 和加载的数据 Historical 中拥有足够的磁盘空间。

Metadata Storage

存储 Durid 集群的元数据信息，如 Segment 的相关信息，一般使用 MySQL。

ZooKeeper

Druid 集群通过以下几个关键机制来确保集群内各节点的协调工作：

1. Coordinator 节点的 Leader 选举机制

• 选举协议：采用基于 Zookeeper 的 Leader 选举算法

• 职责范围：

• 监控 Historical 节点的 Segment 加载状态

• 协调 Segment 在集群中的分布

• 管理 Segment 的加载和丢弃策略

• 选举过程：当当前 Leader 下线时，所有 Coordinator 节点会参与新一轮选举，最先在 Zookeeper 上创建临时节点的成为新 Leader

2. Historical 节点发布 Segment 的协议

• 发布流程：

• Historical 节点完成 Segment 加载后，会在元数据存储中更新状态

• 向 Coordinator 发送 Segment 可用通知

• Coordinator 验证元数据一致性后，将该 Segment 标记为可查询

• 容错机制：如果发布过程中失败，Segment 会被标记为失败状态，并由 Coordinator 安排重试

3. Coordinator 和 Historical 间的 Segment 管理协议

• Load Segment 流程：

• Coordinator 根据负载均衡策略选择目标 Historical 节点

• 发送 HTTP 请求通知 Historical 加载指定 Segment

• Historical 从深度存储下载 Segment 数据并加载到内存

• Drop Segment 流程：

• Coordinator 发送删除指令给 Historical

• Historical 从内存卸载 Segment 并删除本地副本

• 更新元数据状态

4. Overlord 节点的 Leader 选举机制

• 选举特点：与 Coordinator 类似，同样基于 Zookeeper

• 职责范围：

• 接收和处理任务提交请求

• 分配任务给 MiddleManager

• 监控任务执行状态

• 故障转移：当 Leader 失效时，新 Leader 会接管所有正在运行的任务状态

5. Overlord 和 MiddleManager 间的任务管理协议

• 任务分配流程：

• Overlord 接收任务提交请求

• 根据 MiddleManager 的负载情况选择执行节点

• 通过 HTTP 接口将任务描述发送给 MiddleManager

• 状态同步机制：

• MiddleManager 定期向 Overlord 发送心跳和任务状态更新

• Overlord 监控任务进度，必要时进行重试或重新调度

• 容错处理：当 MiddleManager 失联时，Overlord 会将任务重新分配给其他可用节点

这些协调机制共同确保了 Druid 集群在分布式环境下的可靠运行和数据一致性。

架构演进

初始版本~0.6.0

2012-2013 年

0.7.0~0.12.0

2013 年-2018 年

集群管理

0.13.0~当前版本

Lambda 架构

从大的架构上看，Druid 是一个 Lambda 架构。Lambda 架构是由 Storm 坐着 Nathan Marz 提出的一个实时大数据处理框架，Lambda 架构设计是为了处理大规模数据时，同时发挥流处理和批处理的优势：

• 通过批处理提供全面、准确的数据

• 通过流处理提供低延迟的数据从而达到平衡延迟、吞吐量和容错性的目的，为了满足下游的及时查询，批处理和流处理的结果会合并。

Lambda 架构包含三层：BatchLayer、SpeedLayer、Serving Layer

• BatchLayer：批处理层，对离线的历史数据进行预计算，为了下游能够快速查询想要的结果，由于批处理基于完成的历史数据集，准确性可以得到保证，批处理层可以用 Hadoop、Spark、Flink 等框架计算。

• SpeedLayer：加速处理层，处理实时的增量数据，这一层重点在于低延迟，加速层的数据不如批处理层那样完整和准确，但是可以填补批处理高延迟导致的数据空白。加速层可以使用 Storm、Spark Streaming 和 Flink 等框架计算。

• ServingLayer：合并层，将历史数据、实时数据合并在一起，输出到数据库或者其他介质，供下游分析

流式数据链路

Raw Data - Kafka - Streaming Processor（Optional 实时 ETL）- Kafka（Optional）- Druid - Application/User

批处理数据链路

Raw data - Kafka（Optional） - HDFS - ETL Process（Optional）- Druid - Application/User

错误速查

其他系列

🚀 AI 篇持续更新中（长期更新）

AI 炼丹日志-29 - 字节跳动 DeerFlow 深度研究框斜体样式架 私有部署 测试上手 架构研究，持续打造实用 AI 工具指南！AI-调查研究-108-具身智能 机器人模型训练全流程详解：从预训练到强化学习与人类反馈🔗 AI模块直达链接

💻 Java 篇持续更新中（长期更新）

Java-154 深入浅出 MongoDB 用 Java 访问 MongoDB 数据库 从环境搭建到 CRUD 完整示例 MyBatis 已完结，Spring 已完结，Nginx 已完结，Tomcat 已完结，分布式服务正在更新！深入浅出助你打牢基础！🔗 Java模块直达链接

📊 大数据板块已完成多项干货更新（300 篇）：

包括 Hadoop、Hive、Kafka、Flink、ClickHouse、Elasticsearch 等二十余项核心组件，覆盖离线+实时数仓全栈！大数据-278 Spark MLib - 基础介绍 机器学习算法 梯度提升树 GBDT 案例 详解🔗 大数据模块直达链接