整体架构

Druid集群是由一组扮演不同角色的，功能不同的节点组成的，我们先从这幅图介绍一下几类节点，以及它们之间的通信方式。

节点类型

• Broker：接收客户端的查询请求；转发查询到Realtime和Historical节点；接收查询结果并进行合并，发回给客户端。Broker通过Zookeeper确定Realtime和Historical节点是否存在。
• Indexing Service：在将批量和实时数据导入系统时，将数据转换为Druid的索引结构保存在系统中。
• Coordinator：监控Historical节点，以确保数据的可靠性；协调每个Historical节点加载的数据块，读取Zookeeper来判断存在的Historical节点，并通过创建Zookeeper的标识，告知Historical进行加载或释放数据块。
• Historial：处理历史（非实时）数据的存储和查询，和数据存储介质紧密联系，响应Broker的查询请求，并将查询到的结构返回给Broker。在Zookeeper中记录每个Historical节点保存的数据块。
• Realtime：将实时数据导入到系统中。

外部依赖

• Zookeeper：各节点之间通信的主要方式。

1. Coordinator节点和Historical节点之间的数据块加载和释放
2. Realtime节点和Historical节点之间的数据块消息发布
3. Coordinator等的leader选举
4. Indexing服务任务的管理

• MySQL：用于Druid元数据的保存。
• Deep Storage： 数据的实际存储。在Druid中的数据块称为segment，segment存储在Deep Storage中。