整体架构
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：各节点之间通信的主要方式。
- Coordinator节点和Historical节点之间的数据块加载和释放
- Realtime节点和Historical节点之间的数据块消息发布
- Coordinator等的leader选举
- Indexing服务任务的管理
- MySQL：用于Druid元数据的保存。
- Deep Storage： 数据的实际存储。在Druid中的数据块称为segment，segment存储在Deep Storage中。
